Mobile app development for document approval

Document approval in a mobile app: where the process breaks

A typical failure looks the same across companies: the approval route exists not in the system but in email and chats.

The file goes as an attachment, replies come as "approved" comments, and the current version is searched for by labels like "final", "edits applied". In the end, the document status is known by the secretary — and even then only approximately.

The cost of such a scheme is approval delays that are invisible in reporting: the document seems to be in progress, but in fact it is waiting for one person.

If the approver is at a site or on a business trip, the signature waits for their return to the office while contract deadlines pass. And the second version attached to the email resets the entire cycle: signatures have to be collected again.

Even when 1C:Document Management is already deployed in the environment, the mobile part is often reduced to viewing: the file opens, but no action on it is available.

Approval from a phone turns into "read it, I'll be back — I'll sign." The bottleneck here is not the connection or the screen, but the fact that the route is not described as data.

Mobile document approval closes this not because the screen is more convenient, but because the document gets a single status: who has it now, how long it has been pending, what remains until signature.

A decision is made from any location — sign, reject with a reason, pass to the next person, leave a comment on a clause. Below we look at how this is structured in the app and on the service side.

Measurable effect: faster decisions and fewer returns for revision

A decision is made where the person is, not where the work laptop is open. The approver receives a notification with a link to a specific document, reads it on their phone, and signs or sends it for revision with a comment.

The approval cycle is reduced from several days to hours, and documents stuck waiting stop accumulating: the deadline no longer depends on whether the person returned to their workplace.

Returns for revision fall because a comment cannot be left "verbally." The approval screen requires linking the edit to a fragment of the document, selecting the comment type, and specifying exactly what is violated.

The route is set by roles and document type, so after an edit the document does not go for another round to those whose approval has already been obtained — only the affected sections are re-approved.

Transparency of statuses rests on an explicit state model: draft, under approval, has comments, signed, archived. Each transition is written to a log — you can see who has the document now and how long it has been there.

The revision history stores all versions with author and time, so "I had a different version" stops being an argument: the needed revision is opened and compared line by line.

Engineer-wise, this requires careful synchronization. The app caches the document locally and works with a weak connection, and the queue of operations goes to the server when it is restored — without duplicate signatures and repeated comments.

We build the exchange with the existing electronic document management environment, including 1C:Document Management, preserving already adopted routes, roles, and access rights.

Implementation options: native client, hybrid, web portal

The choice of platform is determined not by taste, but by where the approver makes decisions and what is needed from the device.

If the environment includes signature, scanning of a paper original, biometrics, and regular work without network — the requirements for the client are one thing; if a manager once a week looks at the verdict from a laptop — another. Below are real alternatives that are chosen between at the start of a project.

In practice, a combination more often wins: a web portal for infrequent decisions and administrative actions, a native client for frequent operations, signatures, and offline, while the messenger works as a notification channel.

At the selection stage, we separately check where the draft is stored, how conflicts of simultaneous edits are resolved, and what happens to the document if the network disappears at the moment of sending.

Implementation stages: from route analysis to handover to support

Before writing code, we record how approval works now: endorsement chains, return points, deadlines, workarounds in email. An error in the role schema is more expensive than others — it is fixed already in the released app, together with status migration.

Therefore, the app development stages proceed sequentially: each relies on an approved artifact from the previous one.

1. Audit of approval routes. We analyze current chains: who initiates, who endorses, who approves, what happens upon rejection and upon deadline expiry. The output is a status transition map.

2. Role and access setup. A "role × action" matrix: view, edit, sign, revoke, delegate. We delineate rights at the document and attachment level.

3. Build. Approval list, document card, signature, attachments, version history. We take statuses from the server, not from the local cache — otherwise, when two signatures conflict, the state diverges.

4. Integration and notifications. Exchange with the accounting system; signature is idempotent — a repeated request during a connection failure does not create a second endorsement.

5. Acceptance checks. Parallel endorsement, revocation after signature, delegation, connection loss in the middle of signing. For each scenario — expected status and log entry.

6. Pilot implementation. One group on real documents: route completion time, share of approvals on the first round, support requests. Based on the results, we adjust the role schema, not just the interface.

7. Handover to support. Configurations, route schemas, version release regulations, signature error monitoring. After that, roles and routes change without rebuilding the app.

What remains with you after launch: configurations and regulations

We hand over not only the built app but also the working environment around it: without these materials, second-line support starts guessing the approval logic from the code and bypassing access restrictions. Below is what we record in the app documentation and agree with your team before handover.

• Approval route schema — all branches of document movement: sequential, parallel, with return for revision, with conditional transition by document type or amount. Points where the route changes without releasing a new app version are marked separately.
• Role schema and access policies — who sees, who approves, who only reads, who administers. The rules are described at the role level, not for specific employees, so nothing breaks during staff changes.
• Update regulations — release procedure: build, internal check, phased rollout to a share of users, rollback to the previous version. It states which changes can be rolled out without going through app stores.
• Server-side operations regulations — backup schedule, retention period for approval history, procedure for actions when external services are unavailable. Verified by restoration from a copy, not only described.
• Employee instructions — short role-based scenarios: how to approve, how to return with a comment, how to sign offline, what to do if access is lost. With screen illustrations, not descriptions of buttons.
• Integration description — which systems are connected to accounts, electronic signatures, and notifications, what rights the app is granted, and what happens when access is revoked.
• Handover procedure and point of contact — access to builds, storage, and monitoring is transferred to your accounts, not left with external ones.

We write each document so that a new engineer can use it without calling us. A month after launch, we conduct a review: we look at which instruction items were actually opened and rewrite those that did not work.

Case study: contract approval from a phone in minutes

The customer is a logistics operator, TransLine: lawyers in the head office, commercial directors in the regions and at sites.

Contracts were approved by email, the file went through a chain of six participants, and by the third round there were four different revisions of the same document in the thread.

The median cycle held at 7 business days, every fifth contract went for another round, and a lost edit was sometimes found after signing.

What was restructured in the route

The sequential chain was replaced with a mixed one: the lawyer, finance, and commercial director receive the document simultaneously; only the signatory and budget owner have a blocking step.

Edits are linked to a contract clause, not to a file copy: a participant works with one master document; on save, the system compares revisions and immediately shows the conflict.

The notification leads directly to the disputed clause — the decision is made with one touch, and the document can be read offline: the decision goes into the queue and is applied when the connection appears.

Metrics before and after

The median contract approval cycle decreased from 7 business days to 1.5.

The share of returns for revision fell from 34% to 11% — due to parallel branches and early revision conflict, not "acceleration for acceleration's sake." Lost revisions disappeared as a class: the log records who changed what in each clause, and this removes disputes like "we approved a different version." Overdue against the internal weekly standard decreased from 22% to 3%.

Native client or web portal: what to choose in your case

The choice is determined by scenarios: where the employee signs and edits documents and whether there is network there. If approval happens on the road, at a site, or without coverage, a native client for the platform with local storage and offline signature is needed.

If almost all approval happens from the office, a web portal covers the task without releases across the device fleet.

Synchronization modes differ in the size of the local copy: a full copy of documents available to the user, lazy loading of attachments on demand, or online-only operation.

The server maintains revisions and an operation log, so a document version conflict is resolved not by "last write wins" but by comparing the base revision: the discrepancy is returned to the user as a conflict with a choice — keep your edit, theirs, or merge both.

Working over a weak channel is not just slow. The client keeps outgoing operations in a queue and retries sending when the network appears, repeating it without duplicates using idempotent keys; attachments are sent in parts with integrity checks.

We choose the option based on the share of operations outside the office and the criticality of offline signature — this is visible from the approval log, not from interface preferences.

Frequently asked questions about integration, access, and protection

Before the start, the same technical questions usually come up: how the app connects to the existing document management, who will see a specific document, what happens during a connection failure. We address them point by point — without generic wording.

Who will see which documents?

Roles, routes, and the visibility scope are taken from the accounting system — by department, project, or classification. Rights are checked on the server with every request, so substituting parameters on the device does not open other people's files.

What happens if there is no network?

Documents available in advance are read from the local cache, and a decision or edit enters the sending queue.

When the connection appears, operations go to the server; if the document version has already changed, the system marks the discrepancy instead of overwriting someone else's decision.

How is data protected on the device itself?

Local storage is encrypted, the cache has a limited lifetime and is cleared upon logout. Screenshots and copying of attachments are disabled, and if the device is lost, access is revoked remotely.

What is included in support after launch?

Updates are released without stopping operation, diagnostics are collected from anonymized events. We maintain compatibility with current operating system branches and a response procedure for requests.

Let's discuss the task and come back with an estimate and plan

So that the project start does not stretch into months of correspondence, it is enough to describe the process as it works now.

Document approval is almost always tied to people, not to a regulation: who applies the first endorsement, who signs, at which step the paperwork usually gets stuck.

The more precisely you describe this path, the fewer assumptions we build into the estimate — and the fewer edits will surface at acceptance.

What we need from you for the estimate and work plan:

• Roles and rights: who initiates the document, who approves, who only sees, who can return it for revision.
• Routes: typical approval chains, their branching conditions, and cases where an additional round is needed.
• Source systems: where documents are currently stored — storage, corporate portal, accounting system — and how access to them is opened.
• Constraints: closed environment, data storage requirements, corporate security policies, and employee login.
• Scope and timelines: approximate number of users, frequency of operations, the date by which the app must be with people.
• Acceptance owner: the person who will confirm that routes and notifications work as intended.
• Offline operation requirements: whether drafts and signature are needed when there is no connection.

Describe the task in free form — roles, routes, systems, and timelines are enough. We will come back with an estimate, a stage-by-stage work plan, and a handover-to-support option after launch.