Skip to content
Mesonify

Module

Automations

When a record changes or another system sends a request, Mesonify checks your conditions and acts. Start from a template, test it on a real record, and read what every run did.

Request a demoAll modules

An automation is three steps:

  1. When something happens
  2. If your conditions hold
  3. Then the actions run

Device went down

WHENTrigger

the status of a device changesDevice status

IFConditions
  • StatusisNon-Operational
  • ANDPrevious statusisOperational
THENActions
  1. Create eventType: Fault, Priority: High, Deadline: +1 day
  2. Send notificationPush and e-mail, role: Maintenance

What it does

When, if, then

Three cards, read from the top down: what starts the automation, the conditions that have to hold and the actions it runs, in the order you list them. No code anywhere.

Any record, any change

An event, a device or its status, a part, an order, a request or a nonconformance is created, changes or is deleted. Narrow a change to one field, or to a field reaching a value.

Every hour, whatever is open

The hourly check looks at every open event, order, request and nonconformance, which is how a deadline two days away or a fault nobody has taken gets caught. It runs once per record.

Conditions in plain words

Is one of, rose above, fell below, changed from, is within the next, is overdue. Join them with AND or OR, or leave them out and run every time.

Actions across the platform

Notify by push and e-mail, create an event, an order request or a nonconformance, change a device's status, update a field or call a webhook.

Messages that write themselves

Insert a field into a title or a message and each run fills it in from the record that started it, so one automation says something different every time.

How it works

  1. Start from a template

    Device went down, fault unassigned for four hours, part below minimum, deadline in two days, order over the limit. A template fills the automation in, and anything in it can be changed.

  2. Say when, if and then

    Pick the record and what has to happen to it, add the conditions, then list the actions in the order they should run.

  3. Test it on a real record

    Pick a record and run the test. Nothing is written: you see every condition with the value it read, and the message each person would get.

  4. Switch it on

    Every run is listed with what each action did and a link to what it created. A run the once-per-record limit held back is listed too.

Other systems

Started from outside, and reporting back

An automation does not have to wait for something to change in Mesonify. Your ERP or a sensor gateway can start one, and an automation can tell those systems what it did.

  • A webhook request starts it

    The other system sends a request to the automation's own address, with its key. Name a record and the automation runs for it; name none and it runs on the values the request carried.

  • Values from the request

    A temperature or a sensor ID sent with the request can be compared in the conditions and written into the notification, the event or the nonconformance it raises.

  • Signed on the way out

    Call a webhook sends the automation, the run and the record as JSON, signed with a secret, so the receiving system can tell the request really came from your Mesonify.

  • Safe to send twice

    A request sent again with the same idempotency key counts once, and an outgoing call that fails for a moment is tried again, up to three attempts in all.

The key is shown once, when it is created. Only its fingerprint is kept, so a lost key is replaced rather than recovered.

In control

Automation you can see into

Something that acts on its own has to be easy to check. Each automation keeps a record of what it did, and says so when it stops doing it.

  • Runs you can read

    When it ran, for which record and how it ended. Open a run to see each action, the error if one failed, and the event, request, nonconformance or device it touched.

  • Told when it stops working

    An automation whose last three runs failed is marked as needing attention, and whoever created it gets a push and an e-mail that opens it.

  • Held back, never silent

    A run stopped by the once-per-record limit is listed as skipped, so a throttled automation is told apart from an idle one. Automations that start each other are stopped before they loop.

  • Its name on its work

    An event or a nonconformance it raises names the automation as its creator, and a status it changes shows in the device's history like one set by hand.

Automations sit behind a permission of their own. An automation writes with system rights, so it can change a field its author could not change by hand.

Part of

MES, Manufacturing Execution

See the platform

Works with

Modules are switched on per customer. Start with the ones you need and add the rest when you are ready.

See Automations running on your own plant.

Ask for a demo with your own devices, parts and jobs.

Request a demoAll modules