Designing automation that still works a year later.

01

Automate the stable, not the interesting

The best first automations are boring: status syncs, field copies, notifications, record creation, file routing. They are high volume, low judgment and unlikely to change next quarter. Judgment-heavy steps stay with people.

• Count how often the step happens and how long it takes today.
• Ask whether the rule would survive a reorganization.
• Automate the handoff before you automate the decision.
• Keep a human approval where the cost of being wrong is high.

02

Design scenarios to be readable

A scenario is code. If the next person cannot follow it, they will rebuild it rather than fix it. Small, single-purpose scenarios beat one enormous one that does everything.

• One clear job per scenario, with a descriptive name.
• Modules named for what they do, not left as defaults.
• Filters and mappings documented where the logic is not obvious.
• Shared logic factored out rather than copied into five places.

03

Error handling is the feature

Integrations fail: APIs rate limit, records get deleted mid-run, someone renames a field. The question is whether you find out from a log or from an angry stakeholder three weeks later.

• Explicit error routes rather than silent rollback.
• Retries with backoff for transient failures only.
• Alerting to a channel a real person watches.
• Idempotent writes so a rerun does not duplicate records.
• A documented manual recovery path for each scenario.

04

Logging you can actually investigate with

When something looks wrong, you need to answer what ran, on which record, with what data, and what came back. Build that in from the start rather than reconstructing it under pressure.

• Log the record identifier and the decision taken, not just success.
• Keep enough history to investigate a complaint from last month.
• Watch execution volume — cost and rate limits are real constraints.
• Never log credentials or personal data you do not need.

05

Governance, ownership and change control

Automation becomes infrastructure fast. Treat it that way: an inventory, an owner per scenario, a change process, and separate credentials that do not belong to one employee's account.

• A single inventory of scenarios, purpose, owner and systems touched.
• Service accounts and connections that survive staff changes.
• Test in a sandbox or on safe data before production.
• A review when a connected system upgrades or a field changes.

06

Fusion, App Builder, or neither

Fusion is the right tool for connecting systems and orchestrating steps. Heavier custom logic, custom interfaces or Adobe-native extensions often belong in App Builder, and some problems are best solved by changing the process instead.

• Fusion: orchestration, syncs, integrations, scheduled work.
• App Builder: custom UI, complex logic, Adobe-native extensibility.
• Data Connect and Snowflake: reporting and analytics at warehouse scale.
• Sometimes the answer is removing the step, not automating it.