Custom workflows
How to automate custom tasks
Your task may not have a ready-made template. Perhaps a supplier email needs to become a project folder, a delivery note needs to update three records, or a completed form needs a different approval route for each customer. Custom automation starts by describing that particular job precisely enough that somebody else could carry it out.
Key takeaways
Specify one finished result before selecting software.
Give every run a stable task or event ID.
Keep uncertain inputs in a visible review queue.
To automate custom tasks, define the trigger, required inputs, permitted actions and finished result. Choose integrations that can perform those actions, build one complete test case, then add duplicate checks, exception handling and approval. Use AI only for steps that need interpretation, such as reading varied text.
- Describe the task
- Connect the inputs
- Apply rules or AI
- Review exceptions
- Record completion
Write a task contract
Describe what starts the work and what must be true when it ends. “Organise supplier emails” is too broad. “For each accepted supplier submission, create one folder, save its attachments and assign a review task to the project owner” has a testable result. Name the source mailbox, destination and responsible person.
List required fields and their types. A project reference should match an existing project; a requested date should have an agreed timezone. Include an example of a valid input and an example that must stop. Agree which missing details a person may supply and which require a new submission from the sender.
Choose the connection that supports the task
Check what each existing application can actually read or change. A supported connector or API may provide a stable record ID and clear error response. A scheduled file export may be enough when immediate updates are unnecessary. The right connection depends on the required result, not on how many integrations appear in a tool catalogue.
If an application only offers a browser interface, inspect whether it permits the proposed automation and how often the interface changes. Include maintenance and login requirements in the decision. Do not design a process that depends on sharing somebody’s password or making private records publicly accessible.
Worked example: supplier submission to project review
Consider an illustrative design studio receiving supplier details for an existing project. The workflow assigns an event ID, checks the project reference, creates a folder and stores the original attachments. A task then tells the project owner what arrived and what needs checking. The example is a design exercise, not a claimed customer result.
If the email uses informal wording, AI can propose the project reference and a short summary. A lookup must still confirm that reference. Two plausible matches should create a review item. The automation should not guess which project owns the documents.
| Step | Expected result | When to stop |
|---|---|---|
| Receive | One event ID and original message | Missing source identity |
| Match | One existing project | No match or multiple matches |
| Save | Attachments linked to the project | Incomplete upload |
| Assign | One review task with an owner | Owner cannot be resolved |
| Finish | Links and completion state recorded | Destination action failed |
Make retries safe
Suppose a folder is created but the response is lost. Repeating the whole workflow could create a second folder and two review tasks. Store the event ID with the destination record and look for it before creating another. Record each completed step so a retry can continue from the failed action.
Separate retryable failures, such as a temporarily unavailable service, from inputs that need correction. Use a limited retry policy, then notify the owner with the task ID and failed step. Repeated notifications should update the same exception rather than bury the team in new alerts.
Test the custom behaviour before release
Build a small test set from approved or invented examples. Include a valid submission, a missing project reference, two matching projects, a duplicate event, an unavailable destination and a file that cannot be saved. Write the expected outcome before running each case.
Review both the result and the side effects. A correct summary is not enough if the workflow created the wrong folder. Keep important writes behind review during the pilot. n8n’s human-review feature is one example of a tool-call approval mechanism; the chosen platform must support the controls your task requires.
Measure whether the task is worth maintaining
Record the manual handling time, review time, corrections and support work over a representative sample. Count a run as complete only when the next person can use its output. A workflow that moves work into an unattended error queue has not finished the job.
Once the single task is dependable, extend it one step at a time. Keep a named owner, a short recovery guide and a way to pause new runs. Bring the filled-in brief below when discussing a custom build so the conversation can focus on your actual process.
Your ready-to-use checklist
0 of 8 checked
Make the next step clear.
How to automate custom tasks — planning brief
Free templateSources and notes
Sources checked on October 19, 2026.
- n8n: human review for AI tool calls
An implementation reference for pausing selected AI tool calls for approval.
