Start an agent from a system alert

A system alert is a short message another system sends to Centrus when something happens in it: a job changes status in BigChange, a quote changes status in Simpro, a job is logged in Joblogic, a tenant reports a repair in Fixflo, a customer opens a ticket in Freshdesk, or a client assigns you a work order in Ostara. These messages are often called webhooks, which is why the triggers are named BigChange webhook, Simpro webhook, JobLogic webhook, Fixflo webhook, Freshdesk webhook and Ostara webhook.

An agent that starts from one of these waits until the system sends an event you have ticked, then runs once for that event. Centrus does not keep checking the other system for changes. The other system has to be told where to send its alerts, and that set-up is done once, in the other system, by someone with the right access there.

app.centrus.ai/app/agents/workflow-builder

Agents

Build modular AI workflows with reusable nodes

Job completed summary

1,240 / 10,000 creditsValidateResetRunsSettingsUpdate & Publish

Job finished

Job status changed

2

Fetch the job

Get job

Write the visit summary

GPT-5.6 Terra

Email the customer

1 action enabled

AI builderMap

1. 1BigChange webhook in the Trigger group. Simpro webhook, JobLogic webhook, Fixflo webhook, Freshdesk webhook and Ostara webhook sit just below it.
2. 2The trigger on the canvas. Its summary shows the event it listens for, here Job status changed.
3. 3Connection: the account the alerts come from. Here it is the Harbour FM BigChange account.
4. 4Event types: the events that start a run. Only Job status changed is ticked.
5. 5Set this up in BigChange: what to do in BigChange and the address to paste there. Simulate webhook, for testing, is further down the panel.

All six triggers work the same way, and the next few sections cover that shared pattern. The sections after that cover what is different for each system, with an example agent for each. For how alerts compare with schedules, emails, chat and phone calls, see Choose how an agent starts.

In Centrus, anyone who can edit the agent can add the trigger, connect the account and test it. The step in the other system needs someone with admin rights there, or, for Joblogic, Joblogic support. For Ostara, someone with access to the Ostara portal adds it and Ostara Support then whitelists the address. It helps to line that person up before you start.

1. 1Drag the trigger for your system from the Trigger group onto the canvas, and connect it to the first step.
2. 2Click Save draft. Until the agent has been saved once, Connect is greyed out and there is no secret to copy.
3. 3Open Connection and click Connect, then enter the account details for that system. These are stored against this agent only.
4. 4Under Event types (Events on the Ostara webhook), tick only the events this agent should run for.
5. 5Follow the steps under Set this up in for your system, copying the address (and, for Simpro, Fixflo and Freshdesk, the secret, or for Ostara, the webhook username and password) into the other system.
6. 6Test it with Simulate webhook, then click Save and Publish. Alerts only start runs once the agent is published.

Quote accepted alert

Save draft1

Save and Publish

Simpro webhook

No event types selected

1. 1Save draft. The agent has to exist before an account can be connected to it.
2. 2Connection, with Connect greyed out and the message: Save this workflow as a draft first, then connect Simpro.
3. 3Secret, which reads Connect Simpro to generate the secret. until Simpro is connected.

Alert triggers always use the agent's own connection, because an event from another system has no person behind it. If Integration mode in Settings is set to Per-user, the agent cannot be published and validation shows a message such as Simpro webhook cannot use per-user credentials. Use the agent Simpro connection. Start an agent when an email arrives explains how to switch it back to Agent-level.

Where to find the account details is explained in BigChange REST in Agent Builder, Simpro in Agent Builder and Joblogic in Agent Builder. Fixflo asks for a Subdomain and API token, and Freshdesk asks for a Subdomain and API key. Ostara asks for a Username, API key and Client host name, described in Ostara in Agent Builder.

Each trigger lists every event its system can send, grouped by record: jobs, quotes, invoices, issues, tickets and so on. Each tick is one event type, with its label and its code underneath, such as Reported and issue.status.reported. The Ostara webhook is the exception: its Events section is one list of 25 names, with no groups and no codes. The agent runs for the ticked events and ignores the rest, at no cost.

New Fixflo issue

Reported

3

Fetch the issue

Get issue

Create the job

Create job

Tell the tenant

1 action enabled

1. 1Event types, with one tick: Reported.
2. 2The intro. Most systems add a line here about how their events behave, so read it before you tick.
3. 3The trigger's summary on the canvas. It names up to two ticked events, then switches to a count such as 3 event types. The Ostara webhook names every ticked event instead.

Tick as few events as the job needs. Every ticked event that arrives starts a run, and every run costs credits, so an agent that ticks Job modified in BigChange or Ticket updated in Freshdesk can run dozens of times a day for edits nobody cares about. Pick the most specific event that exists, such as Job status changed rather than Job modified, and add a Filter step after the record is fetched for anything the tick cannot narrow down.

The ticks on the node and the events chosen in the other system should match. The other system decides what it sends, and Centrus decides what it runs for. Unticking an event in Centrus stops the runs straight away, but the other system keeps sending that event until someone edits its subscription, so tidy both.

An agent cannot be published with nothing ticked. Validation shows a message such as Simpro webhook needs at least one event type selected before it can be published.

Every trigger shows the web address the other system should send its alerts to, with a Copy button. BigChange, Joblogic and Ostara call it the endpoint URL; Simpro, Fixflo and Freshdesk call it the Callback URL. Every organisation uses the same address for a given system, so Centrus needs a second piece of information to know which agent an event belongs to:

TriggerWho sets it upWhat they pasteHow Centrus knows it is yours

BigChange webhookA BigChange user with API Key ManagementThe endpoint URLYour BigChange customer ID, which BigChange sends with every event

Simpro webhookA Simpro administratorCallback URL and SecretSimpro signs every event with the secret

JobLogic webhookJoblogic supportThe endpoint URLYour Joblogic tenant ID, which Joblogic sends with every event

Fixflo webhookA Fixflo administratorCallback URL and SecretFixflo signs every event with the secret

Freshdesk webhookA Freshdesk administratorCallback URL, Custom headers line and a rule bodyThe secret travels in a header on every event

Ostara webhookAn Ostara portal user, then Ostara SupportThe endpoint URL, webhook username and passwordOstara signs in with the webhook username and password on every event

• BigChange and Joblogic send your account's own ID with each event: the customer ID for BigChange and the tenant ID for Joblogic. Centrus matches it against the account connected on the trigger, so there is no secret to copy.
• Simpro, Fixflo and Freshdesk use a Secret that Centrus creates when you connect the account. Simpro and Fixflo use it to sign each event, and Freshdesk sends it in a header. Events that do not carry the right secret are turned away.
• Ostara signs in with a Webhook username and Webhook password that Centrus creates when you connect the account. The username tells Centrus which agent the event is for, and events with the wrong pair are turned away.

Each agent has its own secret. If a second agent listens to the same Simpro build, Fixflo agency or Freshdesk helpdesk, it needs its own subscription or rule in that system, with its own secret. Clicking Disconnect on the trigger deletes the secret, and connecting again creates a new one, so after a disconnect, paste the new secret into the other system. Ostara's webhook username and password work the same way: each agent has its own pair and needs its own endpoint in the Ostara portal, and a disconnect replaces the pair.

You do not have to wait for a real job to finish to see whether the agent works. Simulate webhook, at the bottom of the trigger's Details, runs the agent with a sample event for a record you name.

1. 1Save the agent. Simulate webhook stays greyed out until the agent has been saved, but the agent does not have to be published.
2. 2Select the trigger and scroll to Simulate webhook.
3. 3Choose the Event type (Event for Ostara) to pretend has happened.
4. 4Fill in the record: Entity id for BigChange, Reference for Simpro, Data (optional) for Joblogic, Issue id for Fixflo, Ticket id for Freshdesk, or Work order id for Ostara. Use a real record, so that a following Get step can find it. If the field is empty, the button stays greyed out or Centrus asks for it, for example Provide an Issue id to simulate against.
5. 5Click Simulate webhook. Centrus shows Simulated webhook started. See the Runs panel., opens Runs and, after a moment, the new run.

Simulate runs the agent as you last saved it, without contacting the other system for the event itself. Everything after the trigger is real, though. The Get steps read live records, and any email, text or new job the agent sends or creates really happens, so point the send steps at yourself while you test. It is charged like any other run.

Simulate does not check the ticks. It will run an event type the node does not tick, so a good simulated run proves the steps work, not that the right events are ticked. Nothing in Runs marks a run as simulated either, so make a note of when you ran it. For dry runs and other ways to test, see Test an agent before it goes live.

Run now in Runs starts the agent without any event, so steps that read the event have nothing to work with. Use Simulate webhook for alert agents instead.

The trigger's output is the event exactly as the system sent it, plus the time it arrived. How much that tells you depends on the system. Some send only the record's ID and expect you to look the rest up. Others send the record's details with the event.

{
  "triggerType": "simpro",
  "triggeredAt": "2026-10-09T14:12:08.000Z",
  "ID": "quote.status",
  "build": "https://harbourfm.simprosuite.com",
  "description": "Quote #51874 status has been changed.",
  "name": "Quote",
  "action": "status",
  "reference": { "companyID": 0, "quoteID": 51874 },
  "date_triggered": "2026-10-09T15:12:06+01:00"
}

A step reads the event with a reference that starts with trigger.json. To fetch the record, add the system's Get step after the trigger and give it the record's ID with the reference for your system:

• BigChange: {{ trigger.json.data.entityId }}. Most job, contact, invoice and quote events carry only this ID, so follow them with a BigChange REST step such as Get job. Deleted events carry the ID of a record that no longer exists, so do not fetch it. Job status changed also says which status the job moved from and to, and vehicle tracking events carry all their details.
• Simpro: the IDs under reference, such as {{ trigger.json.reference.quoteID }} or {{ trigger.json.reference.jobID }}. Simpro events never carry the record's details, so always follow them with a Simpro Get step.
• Joblogic: the record's details arrive under data, so the agent can often use them straight away. Visits, invoices, quotes, sites and assets can also be fetched with {{ trigger.json.data.id }}. Do not fetch jobs this way: the ID in a job event is not reliable for looking the job up.
• Fixflo: {{ trigger.json.payload.Id }}, followed by a Fixflo Get issue step. The event also carries the issue's status.
• Freshdesk: {{ trigger.json.ticket_id }}, plus whatever the rule body includes: subject, description, status, priority, source, the requester's email, the latest public comment and when it changed. Add a Freshdesk Get ticket step for anything else.
• Ostara: {{ trigger.json.id }}, the work order number, followed by an Ostara Get work order step. It also says what happened and when, and may carry the work order's status, client reference, ETA and visit times, but Ostara decides which of these it fills in.

The Step data references box on later steps lists only triggeredAt under Run trigger, so type these references in yourself. Run the agent once with Simulate webhook and open the first step in Runs to see the exact field names your system sends. Read the Runs panel explains how to read a run.

Only published agents run for alerts. While an agent is a draft, or after it has been reverted to draft or archived, events that arrive for it are skipped, not queued. Publishing later does not replay them, so a job that finished while the agent was a draft never gets its summary email.

When you publish, Centrus checks that at least one event is ticked and that the agent uses its own connection, not per-user credentials. It does not check that the account is connected, or that the other system has been set up, so confirm both with Simulate webhook and a real event before you rely on the agent.

Changes to the ticks can take effect as soon as you save, even on a published agent, while the steps that run stay as they were last published. To keep the two in step, publish again straight after you change the ticks. Publish, pause and restore versions covers publishing in full.

BigChange offers the longest list of events. They fall into four kinds:

• Jobs: Job created, Job deleted, Job modified and Job status changed, plus created, deleted and modified events for job groups, job group line items and job line items.
• Other records: created, deleted and modified events for contacts, invoices, quotes, purchase orders, notes, people, resources, users, sales opportunities, stock details, stock items and vehicles.
• Worksheets: Worksheet answers modified, for when an engineer fills in a worksheet.
• Vehicle tracking: harsh acceleration, braking and steering, journeys completed, idling, trips and live driving. Tracking driving fires every mile, every minute or on a sharp turn, so only tick it if the agent really needs live vehicle positions.

For most maintenance work, the useful ones are Job created for new work, Job status changed for jobs that are completed, cancelled or running late, Worksheet answers modified for certificates and checklists, and Invoice created for finance follow-up. There is no event for a completed job as such: tick Job status changed, and when you add the webhook in BigChange, set its status filter to the completed statuses. BigChange makes you pick at least one status for this event, and then only sends jobs moving to those statuses.

The set-up is done in the BigChange developer portal by someone who can manage API keys there. In short:

1. 1Open API Key Management at developers.bigchange.com.
2. 2On the API key this agent is connected with (usually named Centrus AI), choose ⋮ → Manage webhooks → Add Webhook. Do not create a second API key.
3. 3Paste the endpoint URL from the node. The suggested description is Centrus Agent Builder.
4. 4Tick the same event types as the node. Do not tick attachments. If you tick Job status changed, set the status filter.
5. 5Save, then wait up to 10 minutes before the first events arrive.

Job finished

Job status changed

Fetch the job

Get job

4

Write the visit summary

GPT-5.6 Terra

Email the customer

1 action enabled

1. 1The steps to follow in BigChange.
2. 2The endpoint URL, which is the same for every organisation, with Copy.
3. 3Entity id in Simulate webhook. Use the ID of a real BigChange job, so that Get job can find it.
4. 4Fetch the job, the Get job step that loads the job from the ID in the event.

Example: a summary email when a job is completed. Harbour FM wants every customer to get a short visit summary as soon as the engineer finishes. The BigChange webhook, Job finished, ticks Job status changed, with the status filter in BigChange set to the completed statuses. Fetch the job reads the job with {{ trigger.json.data.entityId }}. Write the visit summary, an Intelligence step, turns the job's notes into a few plain sentences for the customer, and Email the customer sends it from Outlook to the site contact, for example to Northgate Housing for a boiler service at Riverside House.

Simpro sends events for almost every record: jobs, quotes, invoices, credits, payments, leads, customers, sites, contacts, assets, employees, purchase orders, schedules, notes and attachments. Most have created, updated and deleted events, and the main records also have a status changed event. Jobs add events for each stage: pending, in progress, complete, invoiced and archived.

The most useful ones are usually Job created, Job stage complete, Quote status changed, Invoice status changed and the job schedule events for bookings. Simpro events carry only record IDs, so every Simpro agent needs a Simpro Get step after the trigger.

A Simpro administrator adds the subscription. If API is missing from the Setup menu in Simpro, the person signed in is not an administrator.

1. 1Connect Simpro on the trigger and save the agent, then copy the Secret.
2. 2In Simpro, sign in as an administrator, open System, then Setup, hover over API near the bottom and choose Webhook Subscriptions.
3. 3Choose Create Subscription and enter a name. Email is optional, and Simpro may send debugging emails to it.
4. 4Paste the secret from the node into Secret, and the Callback URL from the node into Callback URL.
5. 5Select the same events as the ticks on the node, set Status to Enabled and save.
6. 6Choose Test Subscription. Centrus accepts the test without starting a run.

Quote accepted

Quote status changed

Fetch the quote

Get quote

Only accepted quotes

Keep ALL of 1 rule(s)

3

Text the office

To 07700 900412

1. 1The steps to follow in Simpro.
2. 2Callback URL and Secret, the two values to paste into the subscription.
3. 3Only accepted quotes, a Filter that lets the run carry on only for quotes at your accepted status.

Example: tell the office when a quote is accepted. Simpro has no separate event for an accepted quote, so the trigger ticks Quote status changed and the agent checks the status itself. Fetch the quote reads the quote with {{ trigger.json.reference.quoteID }}. Only accepted quotes keeps the run going only when the quote's status is the one your business uses for an accepted quote, and Text the office sends Sarah Price, the office manager, a text on 07700 900412, such as: Quote 51874 for Northgate Housing accepted, £4,860.00. Please book the work.

Agents have no step for sending a WhatsApp message, so this example sends a text with Send SMS. An Outlook or Gmail email to the office works too. Send text messages from an agent explains the Send SMS step.

Centrus only matches events from the Simpro address you entered when you connected, so connect with the same build address your team signs in to. Because every quote status change starts a run, a run that stops at the Filter still pays the run fee.

Joblogic's events cover jobs, visits, invoices, quotes, purchase orders, credits, customers, sites, contacts, assets, PPM contracts, notes, forms and visit parts, with many smaller groups for line items. Most groups have Created, Updated and Deleted, and jobs also have Status Updated. The node lists them under each group heading, and the canvas summary joins the two, as in Job Created.

For most maintenance work, start with Job Created or Status Updated, Visit Created or Updated for engineer bookings, and Quote or Invoice events for the office. Joblogic sends the record's details with the event, so many agents need no Get step at all.

Joblogic is the one system you cannot set up yourself. Joblogic support adds the webhook for your account; it cannot be done in Joblogic itself or through its API. Send support the endpoint URL from the node and the list of categories you need, such as Job and Visit. Each category they enable sends created, updated and deleted events, and the agent runs only for the ones ticked on the node.

New job logged

Job Created

Text the on-call engineer

To 07700 900587

4

1. 1Connection. Events are matched to this agent by the tenant ID on this connection.
2. 2Event types, with Created ticked under Job.
3. 3Set this up with Joblogic support, with the endpoint URL to send them.
4. 4Text the on-call engineer, a Send SMS step that uses the job details from the event.

Example: text the engineer when a job is logged. When the office logs a reactive job out of hours, the on-call engineer needs to know straight away. The JobLogic webhook, New job logged, ticks Job Created. Text the on-call engineer sends Dylan Hughes a text on 07700 900587 with the site, the customer and the fault from the event's details, for example: New job at Harbour View Apartments for Northgate Housing: no hot water in flat 12. There is no Get step, because the job details come with the event.

To test, choose an event such as Job Created in Simulate webhook, which you can search, and optionally paste sample details into Data (optional) in the form {"id":1126891}.

Fixflo's events follow a repair issue through its life. Under Issue status you can tick Any issue state change, or one stage: Reported, Quotes requested, Quotes awaiting review, Quotes reviewed, Job awarded, Awaiting job completion, Job completed or Closed. Reported is the one for new repairs, and Job awarded and Job completed suit contractor work.

A stage tick only matches when Fixflo includes the issue's status in the event. If it might not, tick Any issue state change instead, and add a Filter after Get issue to keep only the stage you want. A second group, Other subscribe events, lists Issue add, Issue closed, Property changed, Property added, Property deactivated and Job invoice updated, but the node warns that these may not fire until Fixflo publishes their details.

A Fixflo administrator adds the webhook on Fixflo's webhook configuration page, the page that logs deliveries and responses:

1. 1Connect Fixflo on the trigger and save the agent, then copy the Secret.
2. 2In Fixflo, open the webhook configuration page and create a webhook. Paste the Callback URL and the secret from the node.
3. 3Subscribe to Issue state change. If the node also ticks one of the other subscribe events, select that event in Fixflo as well.
4. 4Leave RemoveBody switched off. Centrus cannot check the secret on an event with no body.
5. 5Use Fixflo's activity log to confirm that deliveries succeed.

New Fixflo issue

Reported

Fetch the issue

Get issue

Create the job

Create job

3

Tell the tenant

1 action enabled

1. 1The steps to follow in Fixflo.
2. 2The RemoveBody warning. With RemoveBody on, Centrus turns every event away.
3. 3Create the job, which raises the job in BigChange from the issue's details.

Example: turn a new Fixflo issue into a job and tell the tenant. A tenant at Riverside House reports a leaking radiator in Fixflo. The Fixflo webhook, New Fixflo issue, ticks Reported. Fetch the issue loads the full issue with {{ trigger.json.payload.Id }}. Create the job raises a job in BigChange with the property address and the tenant's description, and Tell the tenant emails the tenant from Outlook to say the repair has been logged and someone will be in touch to book a visit.

To test, choose an event such as Issue status Reported in Simulate webhook, enter a real Issue id and, if you like, a Status (optional). Simulate does not contact Fixflo for the event, so check real deliveries in Fixflo's activity log.

Freshdesk has three ticks under Ticket: Ticket created, Ticket updated and Any ticket delivery, which matches either. What counts as an update is decided by the rules you write in Freshdesk, not by Centrus.

In Freshdesk, webhooks are sent by automation rules, so a Freshdesk administrator adds a rule whose action is Trigger Webhook. The node gives the steps, and the order of the rules in Freshdesk matters.

New support ticket

Ticket created

Fetch the ticket

Get ticket

Triage and draft a reply

GPT-5.6 Terra

Save the draft as a note

Add note

3

1. 1Event types, with Ticket created ticked.
2. 2Set this up in Freshdesk, with the steps for the creation and updates rules.
3. 3Save the draft as a note, a Freshdesk Add note step. Notes are private unless you set them otherwise.

1. 1Connect Freshdesk on the trigger and save the agent.
2. 2In Freshdesk, go to Admin, then Workflows, then Automations. On Freshdesk Omni, it is Admin Settings, then Configuration and Workflows, then Ticket Automations.
3. 3On the Ticket creation tab, add a rule with a condition that matches the tickets you want and the action Trigger Webhook. Choose POST, JSON and Advanced content, paste the Callback URL, and paste the Custom headers line as one pair per line, with Requires authentication switched off. Paste the Creation rule body as the content.
4. 4If the agent should also run for updates, add a rule on the Ticket updates tab in the same way, using the Updates rule body.
5. 5Place each rule where Freshdesk will reach it. If the tab is set to Execute first matching rule, an earlier rule can stop yours running; either move it up or switch the tab to Execute all matching rules.

Example: triage new tickets and draft a reply. Harbour FM's helpdesk gets repair requests from residents. The Freshdesk webhook, New support ticket, ticks Ticket created. Fetch the ticket loads it with {{ trigger.json.ticket_id }}. Triage and draft a reply, an Intelligence step, decides how urgent it is (a gas smell or a flood ahead of a dripping tap) and writes a reply. Save the draft as a note adds the draft as a private note, so a member of the team reads it, adjusts it and sends it.

• Status and priority arrive as numbers: Open 2, Pending 3, Resolved 4, Closed 5, and priority from Low 1 to Urgent 4.
• Hourly rules in Freshdesk cannot call a webhook, so this trigger cannot start an agent for ageing tickets or for no reply after a number of hours. A schedule can do that instead.
• An agent that writes to the ticket it is watching can set off the updates rule again and start itself in a loop. If the agent ticks Ticket updated, add a Filter that ignores its own changes.
• To test, enter a real Ticket id in Simulate webhook. For a Ticket updated event, fill in modified_on (required for ticket updated) as well, in the form 2026-10-03T15:30:00Z.

Ostara's events follow a work order a client has given you. The Events section lists all 25 in one list, such as Assigned, Job Accepted, ETA Provided, Job Started, Job Stopped, Cancelled and Notes Added. Assigned is the one for new work orders. Job Stopped also fires when a job is paused, so an agent on it should not assume the work is finished. Every event is listed in Ostara in Agent Builder.

Centrus does not register the endpoint with Ostara. Someone with access to the Ostara portal adds it, and Ostara sends nothing until Ostara Support has whitelisted it:

1. 1Connect Ostara on the trigger and save the agent. Webhook username and Webhook password appear under the endpoint URL.
2. 2In the Ostara portal, open your avatar, then API Integration. Add an endpoint and choose Webhook, not Email.
3. 3Paste the endpoint URL from the node, and choose basic authentication with the webhook username and password. Do not use the API key you connected with.
4. 4Tick the same events as the node.
5. 5Ask Ostara Support to whitelist the URL, then set the endpoint to Active.

New Ostara work order

Assigned

Fetch the work order

Get work order

Raise the job

Create job

Accept the work order

Accept job

4

1. 1The steps to follow in the Ostara portal.
2. 2The endpoint URL, which is the same for every organisation, with Copy.
3. 3Webhook username and Webhook password, which Ostara signs in with. They are shown in full, with no copy button.
4. 4Accept the work order, an Ostara Accept job step that accepts the work order once the job exists.

Example: raise a job for each new work order. Northgate Housing assigns Harbour FM work order 48213 at Riverside House in Ostara. The Ostara webhook, New Ostara work order, ticks Assigned. Fetch the work order loads it with {{ trigger.json.id }}. Raise the job creates a job in BigChange with the work order number as its reference, and Accept the work order accepts it in Ostara, with the new job number as the external reference.

To test, choose an Event in Simulate webhook and enter a real Work order id. The sample carries only the number and the event, so follow the trigger with Get work order. A simulated alert is a real run, so in this example Accept job really accepts the work order. Put an Approval step in front of it while you test.

An alert trigger costs nothing while it waits. Each event that starts a run costs 1 automation credit for the run, plus whatever its steps use: a Get step, an Intelligence step, a text. Events you have not ticked, and events for draft agents, cost nothing because no run starts.

Noisy events are what make an alert agent expensive. A Filter at the start of the agent saves step costs but not the run fee, so the best saving is a narrower tick: Job status changed with a status filter in BigChange instead of Job modified, Job stage complete in Simpro instead of Job updated, or Reported in Fixflo instead of Any issue state change. If several agents listen for the same event, each one runs and each one is charged.

If the other system sends the same event twice, for example after a network hiccup, Centrus recognises it and the agent runs only once. Centrus answers each delivery straight away, then starts the run. Once an event has been accepted, it is not tried again: if the run fails, it stays failed in Runs, and you can redo the work with Simulate webhook on the same record. Steps that have retry switched on in their own settings still retry within the run.

Your organisation's limits apply to alert runs like any other. If the monthly credits have run out, or too many runs are already going at once, the run fails as it starts and shows the reason in Runs, and that event is not picked up later. Automation credits and usage limits explains the limits.

Centrus does not list the alerts it receives, so the clues are in Runs and in the other system's delivery log. Start with the most common causes:

• Nothing arrives. Check the agent is published, then check the other system: the subscription is enabled, it uses the address from the node, and it sends the events you ticked. For BigChange, the webhook must be on the API key the agent is connected with. For Joblogic, the tenant ID on the connection must be the account support set up. For Simpro, connect with the same build address the events come from. For Ostara, the endpoint must be a Webhook, Active and whitelisted by Ostara Support, and use this agent's webhook username and password.
• The wrong events fire. Compare the ticks on the node with the events chosen in the other system. Joblogic sends created, updated and deleted for every category support enables, and Freshdesk sends whatever its rules match, so narrow the rule's conditions as well as the ticks.
• Simpro or Fixflo reports a failed delivery. The secret does not match. This usually happens after Disconnect and Connect, which creates a new secret, or when a second agent's secret was pasted. Copy the Secret from this agent's node into the subscription again.
• Ostara alerts stop after a disconnect. Connecting again creates a new webhook username and password, so update the endpoint in the Ostara portal with the new pair.
• Freshdesk shows success but nothing runs. Freshdesk counts the delivery as a success even when Centrus turns the event away, so check the header line, that the content is Advanced JSON pasted from the node, and that the body still has its placeholders, such as {{ticket.id}}.
• The run starts but a Get step fails. The reference is pointing at the wrong field. Open the first step in Runs to see what the system sent, and check the reference against the list under What the run receives, above.

Simulated runs only test the steps. To prove the whole chain, make a real change in the other system, such as moving a test job to Completed, and watch for the run in Runs.