On This Page
A written request says: “When an order is paid, update the contact.” In this illustrative workflow, that one line is missing the order that gets canceled after payment, the guest who later creates an account and the buyer who never granted marketing permission.
The operator knows these cases because they have handled them. A developer can implement the one-line rule perfectly and still create the wrong result.
An ingested conversation about building workplace agents argues that the people who understand a task should shape its automation. It also names the catch: those people still need the right data and permission to act. That tension is the useful part of the idea.
The exception is where expertise lives
A normal-path diagram is easy to draw. Event arrives, field is mapped, record is updated. The expert’s knowledge often appears when the diagram fails.
What if two contacts share an email? What if a shipment is split? What if the latest order event arrives before an older one? What if the destination accepts an update but the source has already changed?
The expert does not need to know the answer to every API question. They do need to say which business state should win. “A canceled order must not qualify a contact for the post-purchase message” is a business rule. How to enforce it across late events is an engineering problem.
A task expert supplies real exception cases and the intended outcome. Engineering makes those reviewed rules safe to execute against source and destination records.
Our integration guide tells readers to name a source of truth for each object. That choice should come from the people responsible for the records. Code can then check event freshness and destination state against it.
Give the expert a way to show, not only tell
The objection is fair: “If users build their own automations, we will get dozens of unreviewed rules touching customer data.” That is a real risk. The answer is not to hide the task from them. It is to separate authorship from authority.
Let the expert mark a handful of actual records: this one should update, this one should wait, this one should be suppressed. Ask why. Keep the source version and expected outcome with each example. These are better specifications than a sentence about “handling exceptions.”
Then make the allowed action narrow. A proposed mapping can be edited and previewed without sending anything. A live write needs the right credentials, approved fields and an enforceable scope. A promotional action also needs a valid consent basis. Our double opt-in guide covers one way that permission can be recorded for email marketing; an order alone does not supply it.
In Tajo’s mapping tools, a template can be checked with synthetic data before a draft rule is created. The three fields below are straightforward. The expert’s harder question is what the map leaves out: whose consent definition governs the next message? Passing this preview cannot answer that policy question.
Review a sync before it runs
Sync customer updates to my email platform.
Customer sync
| Source field | Destination field | Rule |
|---|---|---|
email | EMAIL | Direct |
first_name | FIRSTNAME | Direct |
last_name | LASTNAME | Direct |
Synthetic preview passed
3 fields mapped · No destination writes
Illustrative layout based on Tajo's mapping tools. A synthetic preview and a saved draft do not activate a sync.
| Expert supplies | System enforces |
|---|---|
| Which order state counts | Event freshness and state lookup |
| Which customer identity is intended | Stable identifiers and conflict handling |
| Which cases should wait | Queue, review state and timeout policy |
| What a correct result looks like | Destination read-back or other postcondition |
| Which communication purpose is allowed | Permission and suppression at execution |
The division is not a wall. Engineers must question an impossible or unsafe rule, and experts must inspect real results. It is a way to keep each decision with the person or system that can actually defend it.
Start with the last ten real cases
An imagined perfect workflow is a weak test. Take a small set of recent cases from the actual process, with customer data handled under the team’s access rules. Mark the normal ones and the exceptions. If the rules cannot explain the ten, the automation is not ready to decide the eleventh.
For a first sync, a synthetic test order can demonstrate the mechanics. Production authorization and a sample of real cases are separate steps. The Brevo Shopify integration guide recommends checking a test contact and order in the destination before activating campaigns.
There is a cost to this method. The expert must spend time making tacit rules explicit. Someone must review cases where experts disagree. The team may learn that the process is inconsistent today, which is uncomfortable.
Some exceptions cannot be resolved with a permanent rule on the first pass. A guest identity may lack enough evidence to merge, or a consent record may be ambiguous. The specification should say “hold for review” and name who can decide, rather than force a yes or no from incomplete data. Record the decision and its reason. Over time, that queue shows whether the same uncertainty deserves a clearer rule, a better source field or continued human judgment. The automation is doing useful work even when its correct output is a bounded pause.
That is also the point. An agent can make a consistent decision only after the team decides what consistency means. Otherwise it scales the fastest person’s guess.
The shortest specification is often one real exception, explained all the way through.
Frequently Asked Questions
Should the task expert build an automation without an engineer?
The task expert should define the normal path, exceptions and acceptable outcomes. Engineering still needs to enforce identity, permissions, data contracts, retries and tests wherever the workflow acts on customer systems.
Why do workflow specifications miss important cases?
A summary of the normal path often leaves out exceptions people resolve from experience. Review recent real cases with the task expert and make the handling rule explicit before automating.
Where should the first automation start?
Start with one recurring task, one source of truth, one clear result and a few observed exception cases. Let the expert approve the rule and verify the destination state before expanding scope.