Getting notified by your workflows

A workflow can tell you what it did. There are two ways, and you can use both.

Send notification delivers a message to your MFICore mailbox and pushes it to your phone or desktop app. Nothing to configure — it works as soon as you add the node.

Email sends through your configured SMTP server to any address. Use it when you want the message in an inbox rather than in MFICore.

Adding a notification

In the workflow builder, add a Send notification node and give it:

• Subject — a short label, e.g. "Morning briefing".
• Message — the body. This is template-interpolated, so you can drop in values from earlier steps, such as = from an LLM node or = from a data node.

Leave Body is HTML off unless you are deliberately writing HTML. With it off, your text is sent exactly as written — line breaks are kept, and characters like < are shown rather than swallowed.

Every notification arrives as its own message in your mailbox, like an email. A daily workflow using the subject "Morning briefing" gives you one dated message per run, which you can read, file or delete on its own.

Two things follow the subject rather than the individual message, so a recurring notification stays manageable:

• Mute — muting one "Morning briefing" stops the ones that come after it from notifying you. The messages still arrive in your mailbox; they just stop lighting up your phone.
• The folder you file it in — move one into a folder and the next one with that subject goes there too. You can also set this up in advance under Rules, either by subject keyword or with the Platform notifications rule, which files everything MFICore sends you.

To clear a run of them at once, tick the messages in the list and use the bulk mark-read, move or delete buttons above it.

Who receives it

Notifications always go to the site owner. There is no recipient field.

This is deliberate. These messages are delivered from MFICore itself rather than from a person, so they carry the platform's name. If any workflow editor could type in a username, they could send official-looking MFICore messages to anyone on the system. Telling you about your own site's automation does not require that, so the option does not exist.

If you need to reach someone else, use the Email node.

Being told when something breaks

A scheduled workflow that starts failing is silent by default — the runs pile up in the run history and nothing tells you.

In the builder's settings panel, turn on Notify me if a run fails. You then get a notification whenever a run of that workflow fails or times out, including the error and the run id so you can go straight to it.

Worth turning on for anything you actually depend on. Test runs never notify, since you are already looking at the result.

Linking back to the run

Every run exposes its own identifiers, which you can use in a message body:

• — the run that sent the notification
• — the workflow it belongs to
• — the site

For example, a body ending with Run: gives you something to search for when you go looking at the history.

run is a reserved name. If one of your own nodes assigns a variable called run, it replaces these values for the rest of that workflow.

Where notifications appear

• Web — Communication → Mailbox, with an unread count in the sidebar.
• Native app — the Mailbox from the flyout menu, plus a push notification if you have push configured and have allowed notifications on the device.

Notifications are ordinary messages once delivered, so you can file them into folders and delete them like anything else. You cannot reply to one — there is no person on the other end.

Choosing how you are told

Under Account → Notifications — the same place in the web dashboard and in the app — there is a switch for each kind of notification and each way it can reach you:

| | Push | Email | |---|---|---| | Messages from people — someone sends you mail | on | off | | Friend requests — a request arrives, or someone accepts yours | on | off | | Workflow alerts — workflow results and run failures | on | off | | App notices — backup, relocation and expiry notices for your apps | on | off | | Certificates — renewals, failures and expiry warnings for your sites | on | off |

Those are the starting points. Everything always lands in your mailbox whatever you choose here; these only decide what else happens.

Push sends the notification to your phone or desktop app. It needs the MFICore app installed, with notifications allowed — the devices it is going to are listed further down the same page.

Email sends to your account address, and never contains the message. It tells you who it is from and the subject, and links back to MFICore to read it. That is deliberate: your mailbox can carry private conversations, and turning this on should not copy them into another company's inbox.

Muting still wins. A muted subject does not notify you, so it is not pushed or emailed either.

Certificates

Your sites are served over https using certificates that renew themselves about 30 days before they expire. Normally you never have to think about them — but when one stops renewing, your site starts showing visitors a security warning, and that is worth hearing about before it happens.

You will be told when:

• a site's certificate is issued for the first time, so you know https is working;
• it renews, with the new expiry date;
• a renewal fails, with the error and what to check;
• one is running out — at 14, 7, 3 and 1 days, each more urgent than the last;
• a problem you were told about is fixed.

Because most of these are good news, the Certificates row has its own Tell me about setting:

• Everything — the default.
• Only when something is wrong — skips the routine renewals and keeps the failures and warnings. Usually the one you want.
• Nothing — no certificate notifications at all, not even in your mailbox.

Every notice links straight to that site's SSL / certificate panel, where you can see the current status, the expiry date, when it will renew and the last error.

If a renewal keeps failing, the usual causes are the domain's A record no longer pointing at us, the nameservers having been changed away from us on a delegated domain, or a CAA record on the domain blocking Let's Encrypt. Renewal is retried automatically every 12 hours, so fixing the cause is usually all that is needed.

You will not be told about certificates for shared platform addresses — those belong to the cluster rather than to you, and your administrators are the ones notified if they go wrong.

Friend requests

A friend request now reaches you the same way: it arrives as a message, so it pushes to your phone and can be emailed if you asked for it. In the app, tapping that notification opens the Friends screen, where you can accept or decline. Both the web sidebar and the app's flyout show a count of requests waiting on you.

Accepting tells the other person. Declining does not.

Costs

A notification meters a small workflow-action credit plus a message send, the same as any other message from your account. See Billing & usage.