Automation  ·  Platform engineering

How to update several systems from one automated process

Finance issues the credit, support never hears, and the customer is told nothing for a week. Here is how a process that updates every system it touches actually works, the prompts that build it, and what running it demands.

Built with Tray Headless

  1. Step Approved decision
  2. Step Write in a set order
  3. System NetSuite
  4. System Stripe
  5. Step Tell everyone affected
Also Undo what already ran

Updates run in a set order, each one checks before it writes, and the people affected hear about it as the last step.

The short answer

What is a multi-system update?

Updating several systems from one process means writing each change in a set order, with the system of record first, checking before each write so a rerun never makes the same change twice, handing work for other teams over as a tracked task, telling everyone the change affects, and having a plan for undoing the earlier steps if a later one fails. Most processes do the first write well and lose the rest. The money moves in the ERP, and the CRM, the help desk and the customer find out late or never.

Stage 5 of 7: Act across systems. Part of Process automation, end to end : every stage, the systems it runs on and the guide that builds it.

What matters here

  • Decide the order of updates on purpose. Write to the system of record first, and to the systems that copy it after.
  • Check before every write. A rerun should find the change already made and move on.
  • Hand work for another team over as a tracked task with an owner, not as a message.
  • Make telling people a step of the process. The customer and the account owner are systems too.
  • Know how to undo each step. When step four fails, steps one to three need a plan.
  • Record every update with the run that made it, so a change can be traced back to its decision.

Who this is for

You build or own automated processes that end in changes to several systems: a credit in the ERP, a refund in the payment system, a note in the CRM and a reply to the customer.

How it works in practice

What has to happen between a decision being made and every system reflecting it.

  1. 1

    The updates are listed in order

    System of record first, then the systems that copy it, then the people who need to know.

  2. 2

    Each update checks before it writes

    If the change is already there from an earlier attempt, it is skipped instead of repeated.

  3. 3

    Work for other teams becomes a task

    A ticket with an owner and a due date in the system that team works in.

  4. 4

    Everyone affected is told

    The account owner in the CRM and Slack, the customer through the help desk.

  5. 5

    A failure undoes or holds what came before

    Each earlier step has a matching undo or a hold, so systems never disagree for long.

What a multi-system update is made of

Four pieces, and the second is the one that makes reruns safe.

A set order

The system that owns the truth is written first. Copies follow. A copy written before its source is a record that may never be true.

Writes that are safe to repeat

Each write looks for its change first, by the ID of the decision that caused it. Found means skip; missing means write.

Tracked handoffs

Work another team has to do lands as a task in their tool, with the context attached and an owner who can be asked about it.

An undo for each step

A credit can be reversed, a task can be closed, a message can be followed up. Written down before the process goes live, not worked out during an incident.

The Tray Headless prompts

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

  1. 1

    List the updates and set their order

    The order decides what goes wrong when something fails.

    Headless skills build-workflow 

    Use build-workflow. The systems in play are NetSuite, Stripe,
Salesforce, Zendesk, Jira and Slack, or whatever we run in those
seats.

For one approved refund, list every change the process has to make:
the credit memo in NetSuite, the refund in Stripe, the note on the
Salesforce account, the reply and status in Zendesk.

Order them so the system that owns the money is written first and
the systems that copy it follow. Write the order down in the
workflow description, with the reason for it.
  2. 2

    Check before every write

    A rerun should never make the same change twice.

    Headless skills build-workflow tray-gotchas 

    Use build-workflow and tray-gotchas. Store the ID of the decision
that caused the change on every record the process creates: the
credit memo, the refund, the note.

Before each write, look for a record with that ID. If it exists, skip
the write and carry its details forward. Only write when it is
missing. Do this for every write, not only the ones that have failed
before.
  3. 3

    Hand work to other teams as tracked tasks

    A message in a channel is not a handoff.

    Where the process needs another team to act, such as engineering
fixing the bug behind a refund, create a Jira task in that team's
project with the context, the customer and a due date, and link it
to the source record.

Post the task in the team's Slack channel. When the task closes,
update the source record so the requester can see it was done.
  4. 4

    Tell everyone the change affects

    The customer finding out last is the most common failure.

    As the last step, tell the people affected: reply to the customer in
Zendesk with what was done and when they will see it, add a note for
the account owner in Salesforce and send them a Slack message, and
close the ticket.

Only send these after every write above has succeeded. A customer
told about a refund that later failed is worse than one told a day
late.
  5. 5

    Plan the undo for each step

    When step four fails, steps one to three need a plan.

    Headless skills tray-patterns 

    Use tray-patterns. For each update, define what happens if a later
step fails: reverse it (void the credit memo), hold it (leave the
refund pending), or leave it and alert (a note on the account is
harmless).

When a step fails after its retries, run the undo for the steps
before it, park the case with what was done and undone, and alert
the process owner. Never leave systems disagreeing with no one told.
  6. 6

    Validate it, then hand it to the process owner

    Because the list of systems grows over time.

    Run the per-step checks and the whole-workflow audit before this goes
live. Test a clean run, a rerun of a run that already finished, a
failure at each step, and a handoff task that is closed later.

Then open the same workflow in Tray Build so the process owner can
add a system, change the order or edit the customer message in the
visual canvas without a deployment.

What it connects to

One decision, written to every system it affects, in an order that keeps them in agreement.

NetSuite

Receive the credit memo first, as the system that owns the money.

Reads and writes

Stripe

Issue the refund, checked against the credit so it is never sent twice.

Reads and writes

Salesforce

Show the account owner what was done, with a link to the decision.

Writes

Zendesk

Tell the customer and close the ticket once every write has succeeded.

Writes

Jira

Hold work handed to another team, with an owner and a due date.

Reads and writes

Slack

Tell the account owner and the receiving team what changed.

Writes

Same build, other stacks

The design does not change if you run something else in one of these seats. The same prompts build it against Microsoft Dynamics 365, SAP S/4HANA, Microsoft Teams, ServiceNow, HubSpot or Oracle.

Connections in this build

Field mapping, templates and common problems for each pairing: NetSuite + Stripe, NetSuite + Salesforce, Stripe + Salesforce and Salesforce + Zendesk.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Running it in production

This is where a process changes real records, so the order and the undo are the design.

It runs on the platform, not on your laptop

Updates finish whenever the decision lands, including the ones that wait on a retry.

Every change is traceable

Each record carries the ID of the decision that made it, so a change can be traced back in one search.

Credentials are managed, never in code

Write access only to the objects this process changes in each system, nothing broader.

Systems never disagree silently

A failed step undoes or holds the steps before it, and the process owner is told.

The owner changes the steps

Systems, order and messages, all open in Tray Build and changed without a deployment.

Questions people ask

Which system should be written first?

The one that owns the truth, usually the ERP for money and the CRM for the customer. Systems that copy it are written after, so a failure never leaves a copy ahead of its source.

How do you stop a rerun creating duplicates?

Store the ID of the decision on every record the process creates, and look for it before each write. If it is there, the step is skipped.

What happens if one update fails?

The earlier steps are reversed or held according to a plan written before go-live, the case is parked with what was done, and the process owner is alerted.

How is this different from exception handling and retries?

That guide covers what happens when any single step fails. This covers the shape of the updates themselves: their order, the handoffs between teams and the undo across steps.

Which metric matters most?

Time from decision to the customer being told. It catches every step that is slow or forgotten, because telling the customer comes last.

Related guides

Platform engineering

How to handle exceptions and retries in automated workflows

Sort failures into ones to retry and ones a person must fix, make retries safe to repeat, park what fails with its context, and alert an owner. The prompts.

Finance

How to automate approval routing

Hold who approves what as data, send each approver the facts they need where they work, set a deadline that escalates, and keep the record. The prompts.

Platform engineering

How to build webhook fan-out

Acknowledge before you fan out, verify the signature first, retry per consumer, and make replay possible. The Headless prompts that build it.

Last reviewed October 2026.