Custom workflows in Paperclip: where the typical scenario breaks
The typical approval automation scenario passes confidently on demo data and falls apart on a live flow of requests.
We build custom workflows in Paperclip not as a copy of a ready-made template, but as a process map: where data moves between systems, who confirms a stage, what happens when an external service fails.
The difference shows up in the second week of operation — when requests with partially filled fields appear in the queue.
The first bottleneck is manual operations in the process. An employee exports a table, moves statuses around, transfers details from email into a card.
Each such step is a point where requests are lost and duplicate records appear in reference data: a counterparty is created twice because the previous attempt was not saved completely.
The second is approval without an explicit stage owner. A request goes for review, the responsible person goes on vacation, no escalation is provided — the request hangs until the client calls. Approval automation must close the stage by timeout itself, not after a reminder in chat.
The third is silence when an external system fails. The integration returned an error, the scenario formally completed, and no one learned about it until reporting reconciliation.
We explain how this is closed: an event log for each step, retries with increasing delay, a separate branch for failure.
What manual process assembly gives instead of ready-made templates
A ready-made template covers the typical scenario until the first exception: as soon as an additional branch or external system appears, people start bypassing the template manually.
That is why in Paperclip we assemble the scheme according to the actual request route, rather than fitting the process to a ready-made form.
Effects visible in metrics
- Share of operations without a human. Field validation, routing by type, and notification go to automation; people are left only with decisions involving incomplete data.
- Request completion time is reduced by removing waiting, not by speeding people up: the duration is counted from receipt to closure and is visible for each stage.
- Recovery after a branch failure. The step state is saved, so the process continues from the last successful action, not from the beginning of the route.
- Route transparency. Each step has a fixed owner, deadline, and transition condition — you can see who has the request and what exactly is holding it up.
Which class of failures goes away
- Input errors: required fields and format checks move control to the input, so defects do not reach the assignee.
- Lost requests: handoff between steps is recorded in the scheme, not in correspondence.
- Stuck approvals: timers return the step to the responsible person instead of endless waiting.
- Duplicates: rerunning a step does not create a second task for the same request.
The result is not a "beautiful scheme" but countable metrics: fewer manual operations, a shorter request route, predictable recovery after failure, and a traceable list of failure reasons.
Three approaches to scenario assembly and their limitations
An automation scenario can be assembled in three ways: take a typical template, modify a ready-made one, or describe the logic from scratch. The difference between them shows up not in simple steps, but where conditional branching logic, exception handling, and retries appear.
| Option | When it fits | Limitations |
|---|---|---|
| Typical template | the process repeats without deviations: request, approval, notification | logic is predefined; non-standard branching and custom exceptions cannot be expressed |
| Modification of a ready-made scenario | the base chain covers most of the process | edits go into someone else's structure; some checks remain outside your control |
| Manual assembly | multiple data sources, different logic by request type | higher requirements for the scheme, tests, and maintenance |
Typical template: parameter configuration
In a template, only parameters change — recipients, deadlines, required card fields — while the structure remains unchanged.
This is a quick start, but the boundaries are visible immediately: as soon as you need your own set of conditions or a rerun after an external service failure, the template hits its limits. Extending it with point edits is often more costly than describing the needed branch from scratch.
Manual assembly of branches and exceptions
Here we build the condition tree ourselves: by what attribute the process goes into one branch or another, what is considered an error, after how many retries the task is passed to the responsible person.
Such a scenario survives external service failures and abnormal data without stopping the entire process. The price for flexibility is a flow scheme, tests for each branch, and instructions for those who will maintain the scenario after launch.
How we assemble a scenario: stages of engineering work
We assemble the scenario from the process, not from the interface: we record which steps people perform today, where data is moved manually, and what is considered task completion. The analysis gives a map of bottlenecks and an honest list of what automation actually removes.
Preparing the scheme and connections between systems
In the scheme, each step is a block with explicit inputs and outputs: what comes from the accounting system, what goes further, under what condition the scenario follows the exception branch.
We configure connections on events, not on scheduled polling — the reaction arrives within seconds, and extra runs do not load the systems.
- Process analysis — interviews with executors, target result, list of steps for automation.
- Scenario scheme — branches, transition conditions, failure points; we agree before assembly so edits do not surface in the finished scenario.
- Connection setup — access rights, exchange formats, record matching rules: duplicates and lost requests are cut off at the input.
- Exception branches — behavior when data is insufficient: postpone, return to the responsible person, raise a notification.
Testing on production data
- Run on a copy of real data from a past period — the scenario goes through all branches, including rare ones.
- Failure tests — we simulate external system unavailability and check that the operation retries without duplicates.
- Handover to maintenance — scheme, instructions, logs, and error notifications.
After that, the scenario lives on: per-step metrics show where delay accumulates, and edits are made pointwise, without rebuilding the entire process.
What you have on hand after project delivery
After project delivery, you are left not only with a working scenario but also with a complete documentation set, according to which you can develop it on your own or hand it over to another team.
The artifacts are divided into two parts: technical — for engineers, and operational — for employees and the process owner.
Technical part
- Route scheme — all transitions, branches, and external system call points are drawn on a diagram with trigger conditions: a new engineer does not need to reconstruct the logic from the log.
- Role-based access rules — a "role → action → resource" matrix; service accounts, their lifetimes, and revocation procedure are described separately.
- Error handling settings — retry policy with increasing delay, list of exceptions, and a notification scenario for the responsible person when the external system does not respond.
Operational part
- Instructions for employees — short scenarios for each manual step: what to do when a task is returned, how to pass it to a colleague, where to look when in doubt.
- Change procedure — route edits go through a test environment and review by a second engineer, rather than being made directly in the working version.
- Event log — collection and storage of records about runs, failures, and manual interventions is configured: incident analysis takes minutes instead of hours searching through correspondence.
The set is updated as the process evolves — you get not a one-off document but a living knowledge base for your automation.
Case study: how manual approvals in procurement were removed
Requests arrived by email and messengers, then were manually transferred to a table, and approval went through a chain of four people. No one could see whose step the purchase was stuck at, and the edit history lived in emails.
We analyzed the process step by step and assembled custom scenarios in Paperclip: rule-based routing, field checks, and a single change log.
What it was like
The average request approval time was 4 business days; for urgent items it reached a week. The share of returns for revision was 38%: a request was rejected due to unfilled fields or an incorrect category, and it went around again.
The approver spent about 11 hours a week on reconciliation and correspondence, and data was re-entered into the accounting system.
What it became
The route is built by procurement type, amount, and department — the request goes to participants without manual forwarding.
Approval time was reduced to 9 business hours, and the share of returns for revision was 7%: required fields and attachments are checked before submission, and a rejected request is returned to the author with a specific comment.
14 of 17 operations were moved from manual mode to automatic — task creation, notifications, export to the accounting system.
The approver's workload decreased to 2 hours a week — the freed-up time went to working with suppliers. The change log shows who edited the request and when, so disputed cases are analyzed by facts, not from memory.
What to do if typical scenarios are already assembled in Paperclip?
Typical scenarios assembled in Paperclip are not a problem but a foundation: there is no need to rewrite them from scratch. We analyze routes by three criteria: where the logic matches the target, where it partially diverges, and where it relies on workarounds.
The first group is transferred as is, the second is supplemented with steps, and the third is rebuilt — usually about a quarter.
Technical debt in automation manifests exactly here: duplicated conditions in different branches, manual confirmations once put in "temporarily", copies of the same approval for different departments. Such areas are reduced to common rules — after that, editing one step does not affect five routes.
Migration without stopping work runs in two circuits. New routes are assembled alongside the old ones and run on a copy of the process: we compare statuses, notifications, and records in accounting systems on identical requests.
While discrepancies remain, the working flow goes along the previous branch, and we switch in groups of requests — with the ability to roll back a separate group.
Request history is preserved: identifiers, attachments, comments, and transition chains are transferred linked to the same cards. Reporting and search across past requests are not broken, and a specialist opens a request and sees the entire path it took before the transition.
What to rewrite and what to leave as is depends on the structure of your routes. Describe the current picture — we will return with a rebuild plan and switchover procedure.
Technical doubts and platform limitations
Paperclip confidently covers typical approval routes, and questions begin at the boundaries: deep branching, third-party services, live reference data. Below are direct answers about where the platform limitation is real and where it is removed by design.
We analyze these boundaries at the scheme stage, not after the first failure in operation. Therefore each answer describes both the limit and the workaround.
How complex branching can the platform handle?
The engine supports nesting, but scheme readability degrades earlier than capability. We move a branch deeper than 3-4 levels into a separate subprocess with explicit input and output — it can be tested separately and called from different scenarios.
Parallel branches are consolidated with a merge step and a pre-defined rule for what to do when results conflict.
What happens if the external system is unavailable at the moment of the call?
The scenario does not fail: the call goes into retries with increasing delay, and after they are exhausted — into a queue of unprocessed items for manual review.
The task is not lost, the responsible person sees it in a separate list, and the other branches of the process continue working. We mark critical steps so that continuation is impossible without operator confirmation.
Will the scenario break when reference data changes?
We put field mappings into a separate layer: when the reference data structure changes, one mapping table is edited, not the route logic.
The reference data version is fixed at the moment the process starts, so instances already in progress do not break and complete according to the previous rules.
Who maintains the scenarios after handover?
We hand over the scheme, step descriptions, error handling rules, and change log. Each edit is a new version of the scenario with the ability to roll back to the previous one within minutes, without stopping current processes. Your team handles typical refinements according to our documentation; we take on complex changes.
Let's discuss the task: what will be included in the estimate and work plan
To return with an estimate and plan, rather than general wording, we need input from your side: a description of the processes as they run now, participant roles, and the steps where delays most often accumulate.
Examples of documents, a list of external systems for exchange, and access restrictions are useful — what can be connected and what remains in a closed circuit. Also send the areas that live in spreadsheets and correspondence: they show best where automation removes load.
In response, you receive an analysis you can already use to make a decision:
- a process map: where manual operations are now, where duplication occurs, and which areas we cover first;
- a composition of stages with the labor intensity of each and the order of execution;
- control points: at which steps you see an intermediate result and have time to correct course;
- handover procedure: accesses, environments, the procedure for putting into production operation and rolling back to the previous version;
- acceptance criteria: which checks on your data confirm that the process runs end to end;
- a list of risks and limitations with workaround options;
- reporting format and support procedure after launch.
Describe the task in free form — we will return with an estimate and plan where each stage is tied to a result and a control point.
