An existing process calls for a custom workflow when essential steps, exception handling, or controls fall outside the add-on’s documented capability—not simply because the process is recurring or important. If the work can be expressed as automated sign-off requests combined with human decisions, an approval add-on is the closer option to test. The decision turns on whether that pattern covers the complete process in its actual deployment context.
What the add-on fit establishes
The available approval fact supports a specific capability: sign-off requests can be automated while human decision-making remains part of the workflow. That makes an approval add-on relevant when requests, decisions, and approvals form the core operating pattern.
It does not establish universal coverage of process-specific routing, data transformations, system coordination, exceptions, or other mandatory requirements. Each of those behaviors must be checked against current documentation and the process’s actual needs rather than inferred from the approval capability alone.
When a custom workflow becomes the candidate
| Condition | Working conclusion |
|---|---|
| The essential work maps to sign-off requests and human decisions, and the documented capability covers the required variations | An add-on is a plausible fit |
| An essential step depends on branching, exception treatment, data handling, or system coordination not addressed by the add-on documentation | A custom workflow should be evaluated |
| A requirement can be removed or standardized without changing the process’s purpose or necessary controls | Simplifying the process may avoid a custom design |
| The tool appears suitable, but the deployment context and relevant AI risks have not been reviewed | The decision remains incomplete |
A custom workflow does not automatically mean replacing existing tools. It can instead represent the process-specific layer needed where the add-on’s documented pattern stops short.
Why deployment context matters
For workflows involving AI, NIST states that measurement approaches for identifying AI risks are connected to deployment context. A generic tool description therefore does not, by itself, establish that a workflow is ready for implementation.
The context review should examine the conditions in which the workflow will operate, including its intended use, operating conditions, decision points, and identified risks. This guidance does not establish that every context-specific concern requires a custom workflow, nor does it prescribe a particular architecture. It supports reviewing the context before approving either an add-on-based or custom design.
What still needs confirmation
Before choosing an approach, the responsible team should be able to confirm:
- The add-on’s current documentation covers every essential step and exception relevant to the process.
- Human decisions remain explicit rather than being treated as automated approvals.
- Any process-specific routing, data handling, or system coordination has a documented solution.
- For an AI-related workflow, the intended deployment context and relevant risk-measurement approach have been recorded.
- Any custom requirement is necessary because an essential need is not covered by the add-on—not merely because customization appears possible.
- Unresolved documentation or context gaps remain labeled as unconfirmed rather than being used to support either outcome.
The practical rule is straightforward: when documented add-on behavior covers the essential process in the relevant deployment context, the add-on remains the closer fit. When an essential requirement falls outside that behavior and cannot be simplified, a custom workflow deserves evaluation. If the available evidence cannot answer those questions, the fit is unresolved.