Business events - Operator Guide

Business events is the eventing surface of Lattice: events raised from ordinary Finance and Operations activity - a sales order confirmed, a journal posted, a production order ended - that downstream systems subscribe to. This guide is for the person who owns those events in a live environment: finding out what this environment can raise, turning an event on, scoping the noisy ones, and checking that nothing was silently lost.

Audience. An integration or functional owner of business events, working inside Finance and Operations.

What is authoritative elsewhere. The per-event reference - every event, its trigger and its payload - is Event catalog and the per-event pages beside it; each page names the process step that raises its event. The security model is in Security model.

---

Before you start

Three Lattice pages cover business events.

Page	Menu path	Privilege → duty → role
Business event catalog	System administration > Inquiries > Lattice business events	MGCLatticeBusinessEventCatalogView → MGCLatticeIntegrationServiceMonitoringDuty → MGCLatticeIntegrationAdministratorRole, MGCLatticeIntegrationOperatorRole, MGCLatticeIntegrationReadOnlyRole
Business event log	System administration > Inquiries > Lattice business events	MGCLatticeIntegrationOperationsView → MGCLatticeIntegrationServiceMonitoringDuty → MGCLatticeIntegrationAdministratorRole, MGCLatticeIntegrationOperatorRole, MGCLatticeIntegrationReadOnlyRole
Batch job event filters	System administration > Setup > Lattice business events	MGCLatticeBatchJobEventFilterMaintain → MGCLatticeSetupDuty → MGCLatticeIntegrationAdministratorRole

Browsing the catalog and the log is open to the operator and read-only roles; changing filters is administrator-only, because a filter decides whether an event fires at all.

Know which page is whose. Lattice's catalog page is a read of what this environment can raise. Activating an event and binding it to an endpoint happens in the standard Finance and Operations business events catalog, which Lattice does not replace.

---

Discovering what events exist

Click path - find an event and read its payload

1. Go to System administration > Inquiries > Lattice business events > Business event catalog.
2. Type part of the event name in the quick filter above the list.
3. Select the event's row.
4. Open the Payload fields tab to read the shape of the JSON a subscriber receives, field by field. The Details tab carries Description, Contract class and Last refreshed.

Click path - download a sample payload

1. Select the event's row in the Business event catalog list.
2. On the action pane, in the Payload group, click Download sample payload.
3. Collect <event>_sample.json from your browser's downloads. It has one property per payload field, named exactly as published, with a representative value of the right type: company fields carry the current company, and the envelope fields (BusinessEventId, EventId, eventSequence, correlationId, schemaVersion) are filled the way a real emission fills them. The values are samples, not records from this environment.

Click path - rebuild the catalog after a deployment

1. Go to System administration > Inquiries > Lattice business events > Business event catalog.
2. Click Refresh catalog on the action pane.
3. Check Last refreshed on the Details tab of any event to confirm the rebuild.

The same action is also a periodic task at System administration > Periodic tasks > Lattice business events > Refresh catalog. The catalog and the reference list are shared by every legal entity, so one refresh serves the whole environment.

The list shows the business events discovered in this environment - Lattice's own and everything else that is code-defined - by Business event ID and Name. The header of the selected event adds its Module and Payload fields (how many). Two tabs describe the selected event:

Tab	Shows
Details	Description, Contract class, Last refreshed
Payload fields	One row per field the event emits: Sequence, JSON field, Display label, Type

Payload fields is the useful one for a subscriber conversation: it is the shape of the JSON your consumer will receive, field by field, taken from the event's contract class rather than from a document.

Rebuild the catalog after any deployment that adds or changes events - the page reads a stored catalog, and Last refreshed tells you how current it is.

Cross-reference keys in payloads. 35 events about customers, vendors, orders, journals and other covered records carry a crossReferences field: the keys external systems hold for the record (for example a CRM's account id), one externalSystem and externalKey pair per system, or an empty list when there are none. It appears in Payload fields after a catalog refresh. Keys are set up and maintained as described in Cross-reference keys, which also lists the events.

---

Activating an event and sending it somewhere

Discovery and activation are separate. Lattice's page tells you what exists; the standard catalog turns it on.

Click path - create an endpoint (standard Finance and Operations page)

1. Go to System administration > Setup > Business events > Business events catalog. This opens the standard Business events workspace, which Lattice does not replace.
2. Open the Endpoints tab.
3. Click New.
4. Choose the endpoint type - Service Bus, Event Grid, HTTPS, Power Automate or any other type your environment offers - and complete the connection details it asks for.
5. Save the endpoint.

Click path - activate an event against that endpoint (standard Finance and Operations page)

1. Confirm the event and its payload first on the Lattice Business event catalog page (System administration > Inquiries > Lattice business events).
2. Go to System administration > Setup > Business events > Business events catalog.
3. Open the Business event catalog tab.
4. Find the event by name or category and select its row. Fields passed to event shows the payload, and Download schema exports it for the consuming team.
5. Click Activate and choose the endpoint and the legal entity to activate it for.

The endpoint types available, and the fields each one asks for, depend on what is configured in your environment. Verify the endpoint step against your own Business events workspace.

Because business events are ordinary Finance and Operations business events, they route to any supported endpoint with no code. The endpoint and activation steps are in the React to business events scenario; this guide does not repeat them.

An event that is not activated in the standard catalog does not send, regardless of what the Lattice catalog shows.

---

Filtering batch job events

The batch job status changed event fires for every batch job whose status is changed through the job record, for example with Change status on the Batch jobs page. The batch job event filters are exclusions: a job that matches an enabled row is filtered out, and its status changes do not raise the event. With no rows, nothing is filtered out.

Click path - filter out jobs

1. Go to System administration > Setup > Lattice business events > Batch job event filters.
2. Click New. The row starts with Enabled and Match any status already set to Yes.
3. Type a Description so the row's purpose is obvious to whoever reads it next.
4. Type the text the job's caption must contain in Caption contains, and leave it blank to match any caption.
5. Type a class name in Task class to match only jobs that run a specific task, and leave it blank to match any class.
6. To filter out only one status, clear Match any status and choose the status in On status.
7. Click Save.

Click path - stop filtering a job out

1. Go to System administration > Setup > Lattice business events > Batch job event filters.
2. Select the row.
3. Clear Enabled to keep the row but stop it matching, or click Delete to remove it.
4. Click Save.

Each row is one filter. The same combination of Caption contains, Task class, Match any status and On status can be entered only once.

Column	Meaning when set	When empty
Enabled	The row is considered	A cleared row is ignored entirely
Description	Your note describing the row's purpose (up to 500 characters)	No effect on matching
Caption contains	The job's caption must contain this text, case-insensitively (up to 200 characters)	Any caption matches
Task class	The job must contain a task of this class	Any class matches
Match any status	The row matches whatever the new status is	-
On status	Used only when Match any status is cleared: the job's new status must equal it	-

Three rules decide whether a job is filtered out:

• Within a row, criteria are combined with AND. Every criterion you set must match. An empty criterion is a wildcard.
• Across rows, the match is OR. The job is filtered out if any enabled row matches.
• With no enabled rows, nothing is filtered out. Every status change that reaches the trigger raises the event.

A new row defaults to Enabled = Yes and Match any status = Yes, so a row with just a Caption contains value filters out every status change of the jobs whose caption contains that text.

Worked examples

You want to leave out	Row
Every status change of the nightly invoice job	Caption contains invoice, Match any status set
Only the withholds of that job	Caption contains invoice, Match any status cleared, On status = Withhold
Any job running a specific task class	Task class = the class name, Match any status set
Two unrelated jobs	Two rows - they are ORed

Two behaviors worth knowing

• An unrecognised task class matches nothing. If Task class does not resolve to a class in the application, that row never matches - a typo leaves the job in the event instead of filtering it out.
• Set-based operations do not raise the event. The event is raised from the batch job record update. The batch server's own start, finish and cancellation transitions, and other set-based data operations that bypass that path, do not fire it. This is a documented limitation of the trigger, not a configuration problem.

---

Recurring data job health alerts

Recurring data job health changed tells you when a data management recurring integration starts failing, backs up, goes silent, loses its batch job or recovers, instead of hearing it from the business. Lattice evaluates the health of every recurring data job every 15 minutes (the Lattice recurring data job health alerts background process) and raises the event once per change of health, only for the jobs you switch alerts on for. The payload is on the event page.

Click path - turn on alerts for a job

1. Go to System administration > Inquiries > Lattice > Integration operations > Recurring integration health, select the job and choose Recurring integration details.
2. On the Health thresholds FastTab, set Alerts enabled to Yes. Adjust the job's thresholds if the defaults do not fit it, for example a Silence period (minutes) for a job that must receive a file every hour. Save. On the page, changing the setting needs the integration administrator role. An integration, or the integration operator role, can set the same switch, AlertsEnabled, on the LatticeRecurringJobHealths entity.
3. Activate Recurring data job health changed (category System administration) in the standard business events catalog, as in Activating an event and sending it somewhere, for all legal entities or for the company the job's batch job runs in.

Three behaviors worth knowing:

• Changes only. A job that stays Broken is reported once, when it becomes Broken, and again when it recovers. Switching alerts on does not report the current health, and neither does a job's first evaluation; Recurring integration health shows it.
• One company per job. Recurring data jobs are shared by all legal entities; the event is raised in the company of the job's processing batch job, or, when the job has none, in the company the background process runs in. A change in a company where the event is not activated is not sent later. Activating it for all legal entities is the simplest way to receive every job.
• Refreshing on the page raises it too. Refresh health, Refresh all, the job actions and saving the thresholds on the health pages evaluate the job the same way and raise the event for a change they find.

Changing the cadence. System administration > Setup > Process automations > Background processes lists Lattice recurring data job health alerts; change its interval there or switch it off. Switched off, the health pages and their workspace tiles show only what the last evaluation found until someone refreshes them.

---

Checking coverage and reconciliation

Three further actions check coverage and repair delivery. Each is a menu item under System administration > Periodic tasks > Lattice business events, next to the catalog refresh, and each needs the integration administrator role, which holds a dedicated Execute privilege for it through the batch maintenance duty (MGCLatticeBatchMaintenanceDuty).

Click path - run one of these actions

1. Go to System administration > Periodic tasks > Lattice business events and choose the action from the table below.
2. The coverage report and the reference list run immediately. The reconciliation sweep opens a dialog: run it now. You do not need to schedule it: the Lattice business event reconciliation background process runs it by itself (System administration > Setup > Process automations, Background processes tab).
3. Read the outcome in the infolog.

The same submenu also holds the jobs that raise events on a schedule or on demand:

• Sales price agreement effectivity (effective/expired) events raises the sales price agreement effective and expired events. The Lattice sales price effectivity events background process runs it daily for every legal entity: in each legal entity where the events are active, it reports that legal entity's prices and raises each event in that legal entity. There is nothing to schedule per legal entity. Run it from here to send the current legal entity's events at once; a run from the menu item covers only the legal entity you open it in. Each legal entity keeps its own position, so no event is sent twice, even though the background process also runs.
• The three resync actions (Publish all customer / item / external item business events) raise the Customer created, Released product created and External item changed events again for every existing record. They run immediately, not as batch jobs. Each one works in the current legal entity and stops without sending anything when its event isn't activated there. Run them in each legal entity after you activate the event, to seed a subscriber.

The Workflow stalled/failed alert scan is under Periodic tasks > Lattice. You do not need to schedule it: the Lattice workflow stalled or failed alerts background process runs it hourly. Do not also schedule it, because the scan remembers what it has reported.

Action	Menu item	What it answers
Business event coverage report	MGCLatticeBusinessEventCoverageReport	Refreshes the catalog, ensures the reference list is loaded, and reports coverage gaps to the infolog - what this environment exposes versus the external reference list of Finance and Operations business events
Load business event reference list	MGCLatticeBusinessEventReferenceSeed	Loads the embedded reference list the coverage report compares against. The coverage report seeds it automatically if it is empty, so you rarely run this alone
Business event reconciliation sweep	MGCLatticeBusinessEventReconciliationSweep	Re-publishes outbound events that failed silently (logged with an error outcome and never resent) from the payload stored on the log row. The Lattice business event reconciliation background process runs it hourly

The reconciliation sweep is the safety net for the failure mode that leaves no trace in the dead-letter queue: a publish that errored and was swallowed. When such a publish fails, the Error row in the business event log stores the event's payload, and the sweep re-publishes from it. The replay carries the original payload, eventSequence and correlationId, so a subscriber can recognize it; it is a new delivery with a new EventId, not a deduplicated one. Two parameters bound the sweep: the maximum number of re-publish attempts, and a minimum age before a failed row is eligible, so events that may still be in flight are left alone. The business event log is shared by every legal entity and shows the legal entity each event was raised in (Legal entity column). One run covers the whole environment: each row is replayed in that legal entity, and only where the event is activated, so the one background process serves the whole environment and there is no sweep job to schedule.

Each row the sweep touches keeps its Error status, so the original failure stays on record, and gets one of these reconciliation states:

Reconciliation state	Meaning
Resolved	The replay wrote the event to the business events commit log again. A new Success row records the replay
Not reconciled, with a retry count and a Last replay error	The replay failed again - the publish failed, the stored payload couldn't be restored, or the event isn't activated in the row's legal entity. The next run tries again. A failed replay writes no new Error row and doesn't raise the Business event publish failed alert again
Exhausted	The replay failed on the attempt that reached the maximum retries. The sweep stops trying; fix the cause from the last replay error and resend the event from its source
Manual intervention required	The event is audit-only: it has no replay factory, so the sweep can't re-publish it

Only the Retail assortment published event opts in to the business event log. Process assortments records the published item list in its own transaction and sends the event after that transaction has committed, so a failed publish is caught, logged as an Error row with its payload and announced by the Business event publish failed event; the next Process assortments run does not send an unchanged list again, so the sweep is what delivers it. A row that stores no payload is rebuilt from the assortment's current state (today's item list and prices, and a new eventSequence), and such a row whose assortment no longer exists stays failed.

Click path - see what a sweep did

1. Go to System administration > Inquiries > Lattice business events > Business event log.
2. Filter Business event log status to Error.
3. Read the Reconciliation state, Retry count, Last retry and Last replay error columns.

---

Standard procedures

Two Finance and Operations procedures this guide depends on. They are standard platform pages, not Lattice ones.

Click path - assign a Lattice role to a user

1. Go to System administration > Security > Assign users to roles.
2. Select the role in the list on the left - for the pages in this guide, the integration administrator role to change filters, or the operator or read-only role to browse the catalog.
3. Click Manually assign / exclude users.
4. Select the user's row.
5. Click Assign to role.

Click path - schedule a job as a recurring batch

1. In the legal entity the job should run for, go to the periodic menu item you want to schedule. For business events that is System administration > Periodic tasks > Lattice business events > Refresh catalog.
2. Set the job's own options in the dialog first.
3. Expand Run in the background and set Batch processing to Yes.
4. Set Task description so the job is recognizable in the batch list, and choose a Batch group.
5. Click Recurrence, set the pattern and its start, and click OK.
6. Click OK to submit the job.
7. Watch it under System administration > Inquiries > Batch jobs.

---

What this guide does not cover

Topic	Where
Every event, its trigger and its payload	Event catalog and the per-event pages
Which hook or Chain-of-Command trigger raises which event	The Trigger column of Event catalog, and the Trigger / Hook section of each event's page
Activating events and binding endpoints (standard Finance and Operations)	React to business events, Offering deep dive
Roles, duties and privileges	Security model
Contract versioning and the ordering/correlation envelope	What every payload contains
Page-by-page reference for every Lattice page	Page reference
Integration operations and data entities	Integration operations, Data entities

The reconciliation sweep runs by itself. The Lattice business event reconciliation background process polls hourly with the sweep's defaults (5 retries, events at least 15 minutes old) and creates a batch job only when a failed event is due. For other values, switch the background process off on System administration > Setup > Process automations and schedule the sweep from its own dialog instead.