On this page
In short
- Name the problems you're solving: which revision is current, who approved it and when, and why reviews stall. Those decide the scope.
- Check what you already own first; document libraries and approval flows in your office suite may cover a simple process well.
- A custom app fits when approval rules vary by document type, documents link to your own data, or people outside the office suite need to review or read them.
- Treat each document as a record with a status, a current revision and an approval history, with the file attached to it.
- Decide what happens to the files already on the drive before launch, and keep the first release to one document type or department.
The problems worth solving
Common symptoms of a shared-drive approval process, and what fixes each
Several copies called final
- What it costs
- People work from an old revision
- What fixes it
- One record per document with a single released revision
Approvals buried in email
- What it costs
- No proof of who approved what, or when
- What fixes it
- Approvals recorded against the revision, with name and time
Reviews stall
- What it costs
- Changes wait weeks for one reviewer
- What fixes it
- An owner and due date for each step, with reminders and delegation
Anyone can edit the released copy
- What it costs
- Unapproved changes reach the floor or the customer
- What fixes it
- Released revisions are read-only; changes start a new revision
Nobody knows what's due for review
- What it costs
- Procedures go years without a check
- What fixes it
- A review date on each document, with a reminder to its owner
Old revisions deleted or overwritten
- What it costs
- No way to show what applied at a given date
- What fixes it
- Superseded revisions kept, read-only, with their dates
| Symptom | What it costs | What fixes it |
|---|---|---|
| Several copies called final | People work from an old revision | One record per document with a single released revision |
| Approvals buried in email | No proof of who approved what, or when | Approvals recorded against the revision, with name and time |
| Reviews stall | Changes wait weeks for one reviewer | An owner and due date for each step, with reminders and delegation |
| Anyone can edit the released copy | Unapproved changes reach the floor or the customer | Released revisions are read-only; changes start a new revision |
| Nobody knows what's due for review | Procedures go years without a check | A review date on each document, with a reminder to its owner |
| Old revisions deleted or overwritten | No way to show what applied at a given date | Superseded revisions kept, read-only, with their dates |
Pick the two or three that hurt most. A first release that fixes those well is worth more than one that tries to handle every document the company has.
Check the tools you already own first
Before scoping a custom app, check what your existing tools can do with some configuration. The details below are as of 2026 and vary by plan and edition; confirm them with your licensing partner or the vendor.
Options to rule in or out first (product details as of 2026)
SharePoint document libraries with approvals
- Where it fits
- You run Microsoft 365, the documents are Office files, and reviewers all have company accounts
- What to check
- Version history and approval settings on the library, whether a Power Automate approval flow is needed, and which features your plan includes
Google Drive approvals
- Where it fits
- You run Google Workspace and the process is a simple sign-off
- What to check
- Whether your edition includes approvals (not every edition does), and how you'd show which revision is current
A dedicated document control or quality management product
- Where it fits
- Controlled documents are part of a regulated quality system, with training records and audits tied to them
- What to check
- Fit with your quality procedures, per-user licensing, validation support if you need it, and how documents get out if you leave
A simple custom workflow app
- Where it fits
- Rules and links the options above don't handle well; see the next section
- What to check
- Ownership of the code, hosting, support after launch, and who maintains the rules
| Option | Where it fits | What to check |
|---|---|---|
| SharePoint document libraries with approvals | You run Microsoft 365, the documents are Office files, and reviewers all have company accounts | Version history and approval settings on the library, whether a Power Automate approval flow is needed, and which features your plan includes |
| Google Drive approvals | You run Google Workspace and the process is a simple sign-off | Whether your edition includes approvals (not every edition does), and how you'd show which revision is current |
| A dedicated document control or quality management product | Controlled documents are part of a regulated quality system, with training records and audits tied to them | Fit with your quality procedures, per-user licensing, validation support if you need it, and how documents get out if you leave |
| A simple custom workflow app | Rules and links the options above don't handle well; see the next section | Ownership of the code, hosting, support after launch, and who maintains the rules |
Our guide to custom web apps vs. low-code covers where Power Apps and Power Automate fit and where they strain. If one of the options above fits, use it; we'd rather you didn't pay for a build you don't need.
When a simple custom app fits
- Approval rules vary by document type. A work instruction needs the area supervisor and quality; a specification needs engineering and quality; a policy needs HR and a director. Encoding that as data is simpler in an app than in a tangle of flows.
- Documents link to your own data. A work instruction belongs to a part, a station or a product; a form belongs to a process. Linking documents to records in your own databases lets people find the current revision from where they work.
- Readers aren't all office users. Plant-floor staff on shared tablets, contractors or suppliers need to read the current revision, or review one, without a full office-suite license or access to the whole drive.
- Reporting across the process. Leadership wants to see what's in review, what's overdue and what's due for periodic review, across departments, in one place.
- An existing app is the natural home. If you already have an internal app that people use daily, adding document approvals there can beat sending people to another tool.
Documents as records, files as attachments
The core design choice: a document is a record in a database, with a number, a title, an owner, a type, a status and a list of revisions. The file is attached to a revision. Folders stop deciding anything; the status does.
document approval / draft to releaseddiagram
Released revisions are never edited in place; any change starts a new revision and a new approval.
Statuses to agree (adjust to your procedures)
Draft
- Meaning
- Being written or revised
- Who can see it
- Author and anyone they share it with
In review
- Meaning
- Waiting on reviewers and approvers
- Who can see it
- Author, reviewers, approvers
Released
- Meaning
- The current approved revision
- Who can see it
- Everyone with access to that document type
Superseded
- Meaning
- Replaced by a later revision; kept for history
- Who can see it
- Roles that need history, such as quality or audit
Obsolete
- Meaning
- Withdrawn with no replacement
- Who can see it
- Roles that need history
| Status | Meaning | Who can see it |
|---|---|---|
| Draft | Being written or revised | Author and anyone they share it with |
| In review | Waiting on reviewers and approvers | Author, reviewers, approvers |
| Released | The current approved revision | Everyone with access to that document type |
| Superseded | Replaced by a later revision; kept for history | Roles that need history, such as quality or audit |
| Obsolete | Withdrawn with no replacement | Roles that need history |
Files can stay in storage you already run, with the app reading and writing them through that storage's API, or move to storage the app owns. Either works; decide based on who else needs to reach the files and where backups are already handled.
Approval rules by document type
Example rules (your procedures decide the real ones)
Work instruction
- Reviewers and approvers
- Area supervisor, then quality
- Periodic review
- Every two years, or on a process change
Specification
- Reviewers and approvers
- Engineering and quality, in parallel
- Periodic review
- On change only
Form or template
- Reviewers and approvers
- Process owner
- Periodic review
- Every three years
Company policy
- Reviewers and approvers
- Policy owner, HR, then a director
- Periodic review
- Yearly
| Document type | Reviewers and approvers | Periodic review |
|---|---|---|
| Work instruction | Area supervisor, then quality | Every two years, or on a process change |
| Specification | Engineering and quality, in parallel | On change only |
| Form or template | Process owner | Every three years |
| Company policy | Policy owner, HR, then a director | Yearly |
- Rules as data, not code. Document types, reviewers by role and review intervals live in tables an administrator can change, so a new department doesn't need a release.
- In order or in parallel. Some approvals must happen in sequence; others can run at once. Let each rule say which.
- Rejection with a reason. A rejection sends the revision back to the author with comments, and a resubmission restarts the approvals that the change affects.
- Delegation for absences. An approver on leave can delegate to a named person for a date range, recorded as such, so reviews don't stall and the record shows who actually approved.
- A summary of changes. Each revision carries a short note on what changed and why, so approvers don't have to compare two files line by line.
Sign-in, permissions and the audit trail
- Company sign-in. Staff sign in with the accounts they already have, through Microsoft Entra ID, Okta or Google, and access ends when their account does. Our guide to SSO and least-privilege access for internal apps covers roles and group mapping.
- Permissions by document type. Who can read, author and approve is set per document type and role, not per folder.
- Everything recorded. Submission, each review, each approval or rejection, release and supersession are recorded with the person and time, and can't be edited afterwards.
- Regulated records. If your documents fall under electronic records and signature rules, such as the FDA's 21 CFR Part 11 for records that FDA regulations require some life-science manufacturers to keep, requirements go well beyond this guide. Confirm them with your quality or regulatory lead before choosing a route; a product with validation support may be the better fit.
Reminders that keep reviews moving
- One email per task, with a link. Approvers get a message naming the document and what's needed, with a link straight to the review screen.
- Reminders before the due date, then escalation. A reminder as the due date nears, and a note to the approver's manager or the process owner if it passes, following rules you set.
- A personal queue. Each person sees what's waiting on them in one list, so approvals don't depend on finding an email.
- Periodic review reminders. Document owners are reminded as review dates approach, and overdue reviews appear on a report.
What to do with the files already on the drive
The drive holds years of drafts, copies and finals. Bringing all of it into the new app brings the confusion with it. Decide the rule before launch.
- Identify the current revisions. For each document in the first release, the owner confirms which file is the current approved revision. This is the slow part; plan time for it.
- Load current revisions as released, with their number, owner, type and last approval date as best known, marked as loaded from the old process.
- Leave the rest where it is, read-only. Old drafts and copies stay on the drive, locked, for reference, and the folders say where the current documents now live.
- Freeze and switch. Pick a date after which no approvals happen by email for that document type, and tell everyone before it arrives.
Our guide to replacing a spreadsheet or Access database covers cutover planning for internal tools in more detail.
A first release small enough to finish
Example scope for a first release
One or two document types, one department
- Later
- Every document type across the company
Draft, review, release and supersede, with approval rules
- Later
- Training acknowledgements tied to new revisions
Company sign-in, roles and audit trail
- Later
- Access for suppliers or customers
Email reminders and a personal queue
- Later
- Chat notifications and mobile apps
Search and a list of current revisions
- Later
- Links from records in other systems
| In | Later |
|---|---|
| One or two document types, one department | Every document type across the company |
| Draft, review, release and supersede, with approval rules | Training acknowledgements tied to new revisions |
| Company sign-in, roles and audit trail | Access for suppliers or customers |
| Email reminders and a personal queue | Chat notifications and mobile apps |
| Search and a list of current revisions | Links from records in other systems |
Write acceptance criteria for the first release before it's built; our guide to how fixed-price software projects work covers scoping a release around them.
Approvals living in inboxes?
Bring the document types you'd start with, who approves each one and a few examples from the drive. On a scoping call we'll talk through whether a tool you already own covers it, what a simple app would add, and what a fixed-price first release would include.
Not ready to talk yet? Draft a project brief first
Questions to settle before you build
Take this to the document owners, quality and IT
- Which problems are you solving first: current revision, proof of approval, stalled reviews or periodic review?
- Have you checked what your office suite and existing quality tools can do on your plan?
- Which document types are in the first release, and who reviews and approves each one?
- Are any documents subject to regulatory electronic records or signature rules?
- Who needs to read documents, including anyone without a company office-suite license?
- Where will files be stored, and who else needs to reach them?
- Which files on the drive are the current revisions, and who confirms them?
- Who maintains document types, approval rules and roles after launch?
Our experience includes full-stack web applications in React, Next.js, TypeScript and Node.js, database design on SQL Server, PostgreSQL and MySQL, OAuth and OIDC sign-in, and transactional email. See web application development for what we build, and how we work for the fixed-price process.
Sources
See it applied
- Illustrative sample. Not client work.See a sample scope for an internal tool →An invented request and approval portal that replaces a spreadsheet and email, on an existing SQL Server database with the company's existing single sign-on.
- Illustrative sample. Not client work.See a sample handover package →The handover index for an invented plant-floor dashboard: repositories, infrastructure as code, the pipeline, runbooks, a data dictionary, the credential handover list, alerts, known limitations and sign-off.
Share this guide
Related services
- Web application development Internal tools and portals behind your company sign-in, built with React, Next.js and TypeScript.
- Custom software development Workflow apps and integrations built to work with the systems you already run, quoted at a fixed price.
- AWS cloud & DevOps Hosting, backups, deployment pipelines and monitoring for the apps we build.