Workflows and events

Miridia raises an event each time an important change occurs. For example, a customer is created, a product price changes, or a shipment is delivered. Each event has a trigger. You attach workflows to a trigger. When the event occurs, Miridia sends the event data to each workflow that is attached to that trigger.

A workflow runs in an external workflow engine, or at a webhook address that you own. Thus you can add behaviour to Miridia without a change to Miridia itself. For example, you can send a message when an order is cancelled, or push a price change to your store.

Workflow engines

Connect an engine in the same way as other integrations. Read Connect an integration.

The default engine

A business can connect more than one workflow engine. Miridia makes each new workflow in the default engine. The first engine that you activate becomes the default. Each engine that you add after it is not the default, until you make it the default.

For example, you connect n8n first and Zapier second. n8n stays the default, and Miridia makes each new workflow in n8n.

How a workflow runs

1. A change occurs, for example a user saves a new product price.
2. Miridia raises one or more events. A price change raises OnProductUpdated and OnProductPriceChange.
3. For each event, Miridia finds each active workflow that is attached to the trigger.
4. Miridia runs the workflows in their position order. Each workflow gets a POST request with the event data.

You can change the position order of the workflows for an entity type. Use this when one workflow must run before another.

Automatic workflows and manual actions

A workflow can run automatically, or a user can start it:

• Automatic: the workflow runs each time its trigger occurs. This is the default.
• Single action: the workflow shows as an action on the details page of one record, for example "Sync this order" on the order page. It runs for that one record.
• Multi action: the workflow shows as a bulk action on the list page, for example "Sync orders" on the orders list. It runs for the selected records.

A workflow usually uses only one of these surfaces.

Workflows for one record

Usually a workflow runs for each record of its entity type. You can also bind a workflow to one record. For example:

• A high-value order that needs a special notification route.
• One product that needs its own restock workflow.

Switch a workflow off

A new workflow is active immediately, and it shows in the workflow list. To stop a workflow without a delete, switch it off. The workflow stays in the engine, but Miridia does not send events to it.

{
  "triggerId": 15,
  "title": "Tell the team about cancelled orders",
  "description": "Sends a message when an order status changes to Cancelled.",
  "entityType": "Order",
  "isSingleAction": false,
  "isMultiAction": false
}

{
  "isEnabled": false
}

The trigger catalogue

The tables give each trigger that you can attach a workflow to. The event name is the name that the event data and the API use.

Customers

Products and inventory

Orders

Shipments and delivery plans

A "dispatch" is a delivery plan: a group of shipments that leave together.

Purchase orders

Transfer orders

Work orders

Bills of material

Suppliers

Businesses, users, vehicles, and integrations

Next steps