Make tasks, responsibilities and approvals visible in one workflow.
Discuss your projectWorkflow software supports work in which people review requests, provide missing information and make decisions. Each step has an owner, required data and permitted transitions. Process automation can carry out fixed system steps; the workflow determines who decides and handles exceptions. A customer portal can show agreed progress without publishing every internal task and note.
This fits when work stalls between people or departments, approvals are scattered across messages or it is unclear which information a decision was based on. Start with one request type, a process owner and the people handling the work each day.
First assess whether the existing product already provides a suitable workflow. Unclear decision rules or missing responsibilities need organisational agreements first. Another task list does not resolve them by itself.
Workflow software is useful when people need to assess, assign or approve tasks. I design work queues, ownership and permitted state transitions. Employees can see which task is ready, what information is missing and what to do next; the system makes responsibility explicit. [1]
The software checks who may take over, return or close a task. Concurrent edits receive an explicit handling strategy so an approval does not silently overwrite a recent change. Notifications support the queue and are not the only place an open task remains visible. [2][3]
Choose a situation. See who acts, which data version is reviewed and what comes next. This example requires one approval.
The buttons only change this fictional example. They do not create real requests, emails or tasks. This explains process rules; it is not a security test.
Submission, approval and completing the follow-up are separate steps. Repeating the identical approval command does not record a second approval in this design.
The submitted data version is sent for review.
Awaiting review · Version 1 · Follow-up action: Not startedApproval is recorded for the reviewed data version. The follow-up action has its own status.
Approved · Version 1 · Follow-up action: PendingThe identical command has already been processed. Its recorded outcome is retained.
Approved · Version 1 · Follow-up action: PendingThe follow-up action is complete in the example. The decision remains separately traceable.
Approved · Version 1 · Follow-up action: CompletedChoose based on the task, the people involved and what you can maintain.
| Approach | Useful when | What to consider |
|---|---|---|
| Configure an existing workflow | The current product supports the tasks, roles and exceptions. | Also check version-specific approval, handoffs and options for resuming processing after a failure. |
| Custom workflow software | Collaboration and decision rules do not fit the existing environment sufficiently. | Tasks, data, permissions, history and daily operation need to be designed together. |
| Process automation alongside the workflow | A fixed check or system action can run without human review. | Can operate alongside the human workflow; error handling and ownership are still required. |
A useful estimate starts with the scope. I distinguish development work from recurring usage and operating costs. These are the main drivers:
Work stalls because it is unclear who takes the next step.
Workflow software shows who needs to act and what comes next. Business process automation first defines how that collaboration should work. Steps with fixed input and rules can then be handled through process automation, while exceptions and approvals remain with people.
Which exceptions, deadlines and permissions determine the process?
Use the prerequisites, acceptance checks and cost factors above to define your assignment. Agree who can approve the outcome and who will maintain the solution. The project approach explains discovery, delivery and handover.
Read the project approachI first compare the required tasks, decision rules and exceptions with existing features. Configuration may be sufficient. Custom development is considered for concrete limitations, such as work spanning several systems and responsible teams.
An n8n consultant can define fixed checks or integrated actions. We agree where the decision is stored and how the workflow receives the status of a follow-up action. Starting automation does not mean the action has completed.
We define which changes require a new version and review. The earlier approval stays linked to the old version. New information does not receive implicit approval, and concurrent decisions must not silently overwrite one another.
The decision and external processing have separate statuses. An authorised operator follows the agreed recovery route. If the external outcome is uncertain, investigate whether the action already happened before considering another attempt.
These primary sources explain the technical principles behind this guide. The project recommendations are OXIAE’s interpretation; they do not imply endorsement by the publishers. Product documentation applies to the named platform.
Authorization for human task actions and roles.
Link and relevance checked:Criteria for accessible task lists and interaction.
Link and relevance checked:Traceability of important state and ownership changes.
Link and relevance checked:Exploring Workflow software? Use the project checklist to describe your task, systems and intended outcome. Collect open questions and download a brief for your conversation.
Create your project brief