Receive M3 Table Events with CMS049
This guide covers the inbound direction: having a change on an M3 table — for example a new or updated purchase order line — trigger a Vince Platform workflow immediately, without polling and without going through MEC or ION.
This guide is about M3 pushing events into Vince Platform. If you instead want a workflow to call out to the M3 API, see Connecting to Infor M3.
M3 does this with two programs working together:
- CMS045 (Event subscription. Open) — decides which table M3 listens to.
- CMS049 (Event subscriber web services. Open) — decides which changes on that table trigger a call, and where to send it.
When a change matches the filters configured in CMS049, M3 sends the event data as JSON in an HTTP call to a webhook URL. M3 doesn't wait for or use the response — it only notifies. Anything that needs to go back to M3 is done separately, with normal M3 API calls (see Connecting to Infor M3).
CMS049 can also be used with events from M3's Event Analytics feature, which supports more complex subscription scenarios than a direct table subscription. That setup is involved enough to warrant a guide of its own — look for it in a future addition to this section.
When to use it
Use CMS045 and CMS049 together when a Vince Platform workflow should react to a change on an M3 table as it happens — for example a new or changed purchase order line — without polling and without going through MEC or ION. Each event that passes the filter starts one workflow execution.
CMS045/CMS049 is one of several ways to get data out of M3 — alongside BODs via Infor ION, the Data Lake, and direct calls to the M3 API. See Choosing an Integration Approach for a full comparison and a decision tree to help you pick.
Don't use it when:
- The table is very active and can't be filtered down hard. Every event that passes the filter becomes a workflow execution — see Pitfalls.
- M3 needs an answer in the same call. CMS049 is fire-and-forget: it sends the event and doesn't wait for or use the response.
- You need guaranteed delivery with automatic retry. If the call fails or times out, the event is logged as an error, not retried — see Pitfalls.
How it fits together
- A change happens on an M3 table.
- The CMS045 subscription for that table picks it up.
- The CMS049 definition checks it against its filters, and if it matches, sends it as an HTTP POST (JSON body) to the configured URL.
- In Vince Platform, that URL is a workflow webhook, so the call starts a workflow execution directly — no MEC or ION in between.
Set up the webhook in Vince Platform first — CMS049 needs its URL.
1. Vince Platform: create the webhook
- Create the workflow that will receive the events. It can start with a single Transform step — the rest of the logic can be built once you can see real event payloads.
- Go to Administration → Integrations → Webhooks and create a new webhook pointing to that workflow. See Webhooks for the full field reference.
- Copy the generated URL. It contains a token, which is the only authentication CMS049 needs — there's no separate auth layer to configure.
2. M3: create the event subscription (CMS045)
In CMS045 (Event subscription. Open), add a subscription with publisher M3 and the M3 table name as the
event name, for example MPLINE for purchase order lines. Enable it for event-based API calls and set it
active.
3. M3: create the event subscriber definition (CMS049)
In CMS049 (Event subscriber web services. Open), create the definition:
| Field | Value |
|---|---|
| Trigger filters | The fields and conditions that must match, using logical expressions such as Changed value or Equal |
| Web service | The Vince Platform webhook URL from step 1 |
| Authentication type | None — the token is already in the URL. The exact label for this option may vary slightly between M3 versions. |
| Information message (optional) | Extra text sent in the message field of the JSON, alongside the event data |
4. M3: restart the autojob
Changes in CMS045 or CMS049 aren't active until the event subscription autojob is restarted:
- Go to MNS050 → the autojob subsystem (normally
ASJ) → option 11, Job in subsystem. - Find CMS949 (Event subscription – Event log).
- End it, then start it again.
The restart route through MNS050 is the same for both. Where they differ is troubleshooting: the concept log for the autojob is enabled in Server View on-prem, and on the administration pages in a cloud environment. If you don't have access to either in a multi-tenant cloud tenant, check with your M3 administrator.
5. Test
Test in an environment with low transaction volume first. Make a change that should match the filter, and confirm an execution appears in the workflow's run history in Vince Platform.
Working example
A subscription on MPLINE (purchase order lines) sends a body like this to the webhook (values anonymized):
{
"tenant": "null",
"publisher": "M3",
"operation": "U",
"document": "MPLINE",
"timestamp": "1790932561081",
"id": "6ee8d50d-eccc-4abf-92d5-2c3952cdca50",
"elements": [
{ "name": "CONO", "oldvalue": "null", "newvalue": "100" },
{ "name": "PUNO", "oldvalue": "null", "newvalue": "1000012345" },
{ "name": "ORTY", "oldvalue": "null", "newvalue": "P10" },
{ "name": "SUNO", "oldvalue": "null", "newvalue": "SUP001" },
{
"name": "keyValue",
"oldvalue": "null",
"newvalue": "ICCONO,100,ICPUNO,1000012345+,ICPNLI,10,ICPNLS,0,ICPNLX,10"
}
],
"message": ""
}
Missing values arrive as the text "null", not as a real empty/null value. Test for the string, not for
absence.
A first Transform step can flatten elements into a plain object the rest of the workflow can use:
(
$body := $context.data.trigger.body;
$v := function($n) { $body.elements[name = $n].newvalue };
{
"eventId": $body.id,
"operation": $body.operation,
"company": $v("CONO"),
"poNumber": $v("PUNO"),
"orderType": $v("ORTY"),
"supplier": $v("SUNO")
}
)
The exact path to the webhook body ($context.data.trigger.body above) can vary slightly by workflow version —
check the actual payload in the execution log if your Transform doesn't pick it up.
Pitfalls
Respect the event you set up. This is the most important point. Every event that passes the CMS049 filter starts a workflow execution, and a normal M3 environment can produce several hundred events per second — a subscription on a very active table with loose filters can flood Vince Platform with executions. Before going live:
- Pick the table deliberately and estimate how many changes it gets per day.
- Filter as narrowly as the use case allows: specific fields, operations, and values.
- Test in an environment with lower volume than production.
Forgetting the autojob restart. Changes in CMS045 or CMS049 don't take effect until CMS949 is restarted — see step 4.
No retry. Failed calls are written to the CMS049 error log with the receiver's reason, the event's primary key, and the function that caused the event. After fixing the cause, the original action can be reprocessed manually if needed.
The webhook URL is a secret. Anyone with the URL can start the workflow. Don't paste it into tickets or chat messages, and rotate it if it leaks.
Further reading
- Webhooks — create and manage the webhook that receives the events
- Connecting to Infor M3 — the reverse direction: calling out to the M3 API from a workflow
- Infor ION — an alternative inbound route, for M3 BODs rather than table-level events
- Transform — shape the incoming event payload for the rest of the workflow