How the M91 Alert Flow Moves an Alert From Software to a Person

Learn how the M91 alert flow sends a titled request, gets a human response, and returns the answer to software.

• Software calls the M91 send URL with a title.

• M91 alerts phones in a channel, and a person chooses a response.

• Software reads the answer and continues or stops its work.

The M91 alert flow sends a request from software to a person. The person responds, and the answer goes back to the software.

Software sends a titled request to M91. M91 raises the alert, and it stays open until someone responds or a rule closes it.

An alert is a request for a person to take action. For example, a workflow may ask someone to approve a risky payment.

The software approval flow has four handoffs:

1. Software sends. It sends a titled request to M91.

2. M91 alerts. M91 raises the alert for the phones in a channel.

3. A person responds. The person chooses an available response option.

4. Software continues. The software reads the answer and chooses what happens next.

A channel is a group of people who can receive and handle alerts. For the reason a workflow may need a person, see the earlier guide, Why a Workflow Sometimes Needs a Human Decision.

The M91 send URL is a web address that software can call. A request with a title raises an alert, while a request without a title only checks the connection.

A browser, scheduled task, spreadsheet, shortcut, or other URL tool can call the send URL. The sending system does not need an SDK just to raise an alert.

An SDK is a software kit that helps a program use a service. M91 provides a single send URL, so an SDK is not required for this basic task.

A safe connection test uses the send URL without a title. It returns channel information, but it wakes nobody.

Adding a title changes the request into a real alert. For example, software could send, “Approve payment release?”

The simple GET form supports basic fields, such as a title and severity. A POST request supports the full request, including attachments and a callback URL.

M91 sends the alert to the channel’s phones. A person chooses one of the available response options.

A response option is a button or choice shown to the person. Options might include “I’ll handle it,” “Approve,” or “Seen.”

A SHARED response claims responsibility and removes the alert for other people. This tells the group that one person has taken the task.

A PERSONAL response does not claim responsibility. Other people may still see and respond to the alert.

Taking responsibility is different from simply answering or acknowledging an alert. It also does not mean that a phone call was answered.

M91 places the alert, but it cannot tell whether a placed call was picked up. Phone behavior can also differ by device and operating system.

Do not assume silent mode or Do Not Disturb works the same way on every phone.

After the person responds, M91 makes the decision available to the software that sent the alert. Software can read the alert status and decision, or receive events at a callback URL.

A callback URL is a web address that receives information from M91. The software gives M91 this address when it creates the alert.

The returned-result loop is simple:

1. Receive the answer. The software gets the person’s response.

2. Check the answer. It checks the response and alert status.

3. Continue or stop. It performs the next step or stops the workflow.

The software that sent the alert acts on the answer. M91 does not perform the approved action for the software.

M91 can send a callback when a person responds and when an alert closes. M91 may retry a callback, so the receiving system must handle the same event more than once.

Optional callback note: M91 supports an idempotency key and an HMAC-SHA256 signature. An idempotency key helps spot repeated events. A signature helps check that the event came from the expected sender.

Software must choose how long to wait and what to do if no answer arrives. M91 does not expire an alert by itself on the server.

A timeout is the software’s own waiting limit. After that limit, the workflow might stop, send another alert, or use another process.

An alert can remain open until someone responds, software closes it, or a configured rule closes it. Stopping the wait does not mean the alert was handled.

The software should set its no-answer plan before sending the alert. It should also check whether the alert is still open, resolved, or closed.

See how M91 can send a decision request to a real person.