Workflow and event messages

Purpose

This page describes the workflow and event logic in Automotive. It shows how business deviations are detected, assigned to users, and tracked in daily work without requiring every process to be monitored manually.

Business value

• You make deviations in sales, purchasing, and logistics processes visible early.
• You assign events deliberately to users or responsibility areas.
• You reduce unnecessary alerts by marking ignorable errors consciously.
• You use event messages as an operational control layer above the running process.

Core logic

The workflow logic works in three steps:

1. The system detects a business error or relevant event.
2. Error codes and event codes determine whether a message is created and which technical workflow function is used.
3. The event message appears for processing, is linked to related processes, and can be tracked by status and filters.

graph LR;

%% Nodes
A[Business deviation]
B[Error code]
C[Event code with function name]
D[Event message with linked processes]
E[Open or completed]

%% Flow
A -.- B
linkStyle 0 stroke:#ffffff
B ==> C
C ==> D
D ==> E

%% Classes
class A btProcessTitle
class B,C,D,E btProcessActive

Which work pages the code provides

The current code provides four clearly separated work objects for users and key users:

This means the workflow logic in Automotive is not just an abstract rule set. It is a concrete work surface with list, card, and drilldown behavior.

Review and rate error codes

Error codes describe the business situations detected by the system. In code, the dedicated Error Codes page is used for this. For users, the most important field is May Be Ignored.

Review consciously:

• which messages are only informational?
• which messages always require action?
• which errors would otherwise create unnecessary alert noise in daily operations?

Ignoring too much weakens process control. Being too strict leads to a flood of warnings in which truly critical events are lost.

Event codes and responsibility

Event codes define which business situation is connected to which technical workflow function. The Event Codes page therefore shows not only code and description, but also the Function Name field.

From an end-user perspective, this matters because the field is not just a label. It is the technical hook into workflow handling. Changes to it should therefore never be made without business and technical alignment.

Important questions during setup are:

• who should be informed for which deviation?
• does the topic need individual ownership or team responsibility?
• is it clear what action is expected from the message?

The quality of the event logic therefore depends not only on technical settings, but strongly on clearly defined responsibilities.

Use event messages in daily operations

The Event Messages List page is the daily work list for notable cases. In code, this list is filtered by default to not handled messages. Open cases therefore come to the front automatically.

The list shows, among other things:

• event codes and event description
• the actual message text
• linked processes
• customer number, plant, and unloading point
• handled status

The Event Messages card additionally shows:

• date and time
• handled by
• handling date
• linked process entries

Use at least these views:

• all events for the overall picture
• open events for daily execution
• completed events for evidence and traceability

Especially in teams with high message volume, this filtering is important so that current issues do not disappear among completed cases.

Open linked processes directly

Each message can store Links. In code, these links are managed through Process Type and Process No. On the links page, a drilldown opens the affected process directly.

The workflow supports links to, among others:

• automotive sales orders
• sales delivery call-offs and detailed call-offs
• purchase orders and purchase call-offs
• production-synchronous call-offs
• inbound delivery EDI cases
• sales transport data, open or posted

This is essential in daily work: users do not have to interpret the message first and search separately for the document. They can jump directly into the affected process.

For linked sales orders, the code also copies customer number, plant, and unloading point into the event message. That improves filtering and prioritization.

Addition from BE-Automotive workflow handbook

The handbook extends the baseline description with a concrete setup sequence for operational start:

1. Create workflow with code, description, and category.
2. Select the matching workflow event (example: release of delivery call-off).
3. Keep condition on <Always> when no automotive-specific condition is required.
4. Use response Send a Notification and maintain recipient.
5. Activate workflow and trigger a test message.

Click to enlarge

Technical prerequisites from training

• Notification setup must contain a valid entry for type New Record.
• SMTP setup is required for email dispatch.
• Job queue processing for notification entries requires active task processing (Codeunit 1509).

Operational monitoring then runs through workflow message overview and sent-notification entries.

Click to enlarge

Typical use cases

The public source material describes the workflow block only briefly. The code, however, shows clearly which processes are really connected to the event logic. Typical scenarios include:

• date deviations in call-off or purchasing processes
• quantity deviations between expected and actual processing
• unusual situations in automotive sales orders or transport data
• inbound EDI cases that require deliberate review or follow-up
• cases where a user must deliberately set a message to handled and document the operational completion

Control steps

Typical failure patterns

Result

• You understand how Error Codes, Event Codes, Event Messages, and Links interact in Automotive.
• You can set up the event logic so that functionally relevant deviations become visible and directly accessible.
• You use open and completed messages as an operational control, processing, and evidence layer.