Post go-live

Most implementations do not end at cutover. The client runs old and new systems side by side for a period, other applications still feed the old system, or a subsidiary stays on the legacy product. superglue turns these ongoing flows into scheduled tools that run without you and tell you when they fail.

Build a sync

Describe the flow to the agent as you would to a colleague. Include the direction, the trigger and what counts as a conflict:

Every night at 02:00 Europe/Berlin, copy new and changed customers from GP to Intacct.
GP is the source of truth until 31 January. Skip customers already changed in Intacct
that day and list them in the result.

The agent builds and tests the tool with you, shows a real result, and asks for approval before the first write. The Build an integration playbook covers this workstream; select it or just describe the outcome.

Incremental syncs keep a checkpoint between runs, such as the last processed timestamp, so each run picks up where the previous one stopped. The agent sets this up when the flow needs it.

Schedule it

Open the saved tool, select Deploy, and add a schedule with a frequency, timezone and the input the run should use. Test the schedule once, then enable it. Scheduled runs act as the person who created the schedule and use the credential pinned in the schedule, so pin the client’s production credential explicitly.

For flows triggered by events rather than time, such as an approved invoice in the new ERP that must post back to the old one, use an incoming webhook instead. See Deploying a tool for both.

Get alerted

Set up notifications under Settings so failures reach you without watching the dashboard:

On failure sends a Slack message or email as soon as a scheduled run fails, with the failed step and a link to investigate.
Daily and weekly summaries list successful and failed runs per tool, which suits a client status email.

Filter rules by tool name pattern, for example contoso-*, so each engagement’s alerts go to the right channel. See Notifications.

Investigate and repair

When a sync fails, open the run under Runs and select Investigate. The agent opens with the run loaded, explains the failure, and proposes a fix. Typical causes after go-live are a changed field in the target, a new code value in the source, or an expired credential. When the fix changes the tool, the agent tests it before proposing the edit, and the previous version stays in the tool’s version history.

Wind down

When parallel run ends, disable the schedule instead of deleting the tool. The run history stays available for the client’s audit, and the tool can be reenabled if the timeline slips.