Your Excel cash-flow sheet still opens. Its formulas still calculate. But the bank feed stopped delivering yesterday, so the report is answering today's question with yesterday's evidence.
A useful first automation brings a feed problem to someone's attention and tells them where to investigate. It should make the failure visible before the next cash review—not silently rewrite the workbook or repeatedly retry an unexplained error.
This guide describes a small monitoring workflow and its test plan. It is a design to configure in your workspace, not a one-click installation.
Reviewed on 1 November 2026 against BankSync's current automation documentation.
What the workflow should answer
| Question | Evidence |
|---|---|
| Which feed needs attention? | The feed bound to the trigger |
| What happened? | Its run status, counts and recorded error |
| Who will investigate? | A deliberately chosen workspace audience |
| Is recovery complete? | A successful delivery and verified destination rows |
Give the automation one clear job
Choose one important feed, such as the transaction feed behind your weekly Excel report. Name the automation so a colleague understands its purpose: “Review failed delivery to cash-flow workbook”.
The automation overview distinguishes the trigger, the steps and the permission grant. A trigger starts the work; reading steps obtain evidence; an action tells someone what needs attention.
From the feed's Automate menu, choose the relevant failure trigger. The trigger reference lists both When a feed fails and When a delivery fails. Choose the event that matches the problem you want to monitor; they are not interchangeable labels for every possible failure.
A small workflow to configure
Bind the feed trigger
Select the specific feed you want to monitor, rather than every feed by default.
Read the relevant context
Use the documented Read a feed or Read a sync run step for the identifier supplied by the trigger.
Compose a concise review message
Include enough context to identify the feed and explain the next manual check.
Notify the chosen workspace audience
Use Notify the workspace for an in-app notification, or the documented Send an email step for eligible workspace members.
Test, publish and approve
Review the test output, publish the version and have an authorised signed-in member approve its grant.
Enable and observe
Turn it on, then check run history and the next genuine triggering event.
An event supplies identifiers and metadata, not a complete bank statement. Read the details you need rather than assuming a transaction amount or a human-readable error is already present in every trigger payload.
The app-step reference documents the read and notification steps. Notify the workspace creates an in-app notification; it is not email. Send an email has workspace audience choices, including Only me, which means the member who approves the automation. Check the recipient meaning before approval.
Keep notification content short. A colleague usually needs the feed identity, what failed and where to review it—not a list of every merchant and payment.
Suggested message contents
| Include | Purpose |
|---|---|
| Feed name or identifier | Find the affected workflow |
| Run identifier, when available | Inspect the specific delivery |
| Status or error summary | Choose the next diagnostic check |
| Next action | Review the feed run and destination connection |
| Named owner in your team process | Avoid assuming someone else will handle it |
Rehearse failure before enabling it
BankSync's testing guide explains that draft tests use trigger samples. Reading steps can read real data under your permissions, while sending and writing steps show their samples instead of performing those effects.
Open More → Settings to review the trigger's test data. Use a sample compatible with the chosen trigger, then run Test and inspect what each step received and returned. A passing test means your sample path worked; it does not prove every future bank or destination error is covered.
For event-triggered automations, the builder's Run now rehearses the event with sample data. Do not mistake that for proof that a real notification was delivered.
A practical test matrix
| Case | What to verify |
|---|---|
| Expected failure sample | The correct feed/run is identified |
| Missing optional detail | The message remains understandable |
| Wrong or inaccessible binding | The failure is visible rather than silently ignored |
| Notification audience | Only the intended workspace audience is selected |
| Successful recovery | The destination contains the expected records |
Treat publication and permission as separate steps
Publishing saves the automation version. The grant guide explains that permissions are derived from the steps, resources and configuration. Read the listed banks, feeds, tables and destinations before approving.
Approval must come from a signed-in member who holds the required permissions. An API key or agent cannot approve the grant. After approval, turn the automation on. Changes to permissions, bindings or configuration can require approval again; check the current state after editing.
Keep the first workflow narrow. A notification-only response is easier to inspect than a chain that also reruns a feed, changes rows and sends several messages.
Keep a scheduled or manual safety check
Bank and feed events are documented as best-effort. They can arrive late and, rarely, be missed. For a critical report, keep a scheduled inspection of feed history or a regular manual check alongside event notifications.
That check should inspect evidence, not just whether an automation is enabled. Look at the feed's last successful delivery, the latest run's counts and the relevant destination rows. Some days legitimately have no new transactions, so an unchanged row count alone is not a failure.
After fixing a connection or mapping problem, review the recovery run before changing the report's status back to current. A notification marked completed proves the notification workflow ran; it does not prove that the underlying bank data is complete.
Recovery checklist
| Check | Ready when |
|---|---|
| Bank connection | Any reauthentication request is resolved |
| Destination connection | The intended workbook or database is accessible |
| Mapping | Required fields point to the intended columns |
| Feed run | Outcome and written/skipped/failed counts are understood |
| Destination sample | Expected records are present without unexplained duplicates |