Processes, forms and approvals

This lesson builds the people part of Fleet Customer Onboarding in the process builder: the inputs, a form for fleet sales, an approval for Maria's master data check, and an approval for Dan's credit decision. The decision itself comes in lesson 3, and the trigger from S/4HANA in lesson 4. For now the process starts with test inputs.

Process inputs and data types

A process has a process context: inputs set by the trigger, plus outputs of each step. Define a data type for anything structured. Contoso's data type FleetCustomer holds the business partner number, name, sales area 1710 / 10 / 00, expected annual volume in pieces, fleet size and the requested credit limit in USD. Steps map their inputs from the context with the binding dialogs; a misspelled or unmapped field is the most common silent defect in a process.

Step by step: building the process

1. In SAP Build, create a project of type Business Process, then a process named Fleet Customer Onboarding.
2. Add process inputs (for now) for the business partner number and name, so the process can be started with test data.
3. Add an input form for fleet sales: fleet size, expected annual volume of CMC-ALT-100 and CMC-ALT-240, requested credit limit, and a comment. Mark required fields as required.
4. Add an approval form for Maria: subject with the partner name, the captured data shown read-only, and Approve and Reject buttons. Set the recipient to a group rather than a person, so substitution and absence do not block the process.
5. Add a condition after Maria's approval: Rejected goes to a notification step and ends; Approved continues.
6. Add the credit decision (lesson 3) and a second approval form for Dan when the decision says a finance approval is needed.
7. Add an action that writes the approved credit limit back to S/4HANA (lesson 4), then an end event.
8. Set a due date on both approval tasks; Contoso uses three working days for the master data check.

Forms that testers can trust

Approvals and recipients

An approval step creates a task in the recipients' inbox. The task carries the form, the subject and the due date. Recipients can be users or groups, and can be mapped from the context, for example from a decision output that names the approver group. Contoso sends master data tasks to the group CMC_O2C_MASTERDATA (Maria and her backup) and credit tasks to CMC_FIN_CREDIT (Dan and a deputy). Groups come from the identity provider; testing with the right test users in each group is part of test preparation.

Conditions and notifications

Conditions branch on context values: the approval outcome, a decision output, or a form field. Keep them simple and name each branch after its business meaning ("Master data rejected", "Finance approval needed"), because the names appear in the process diagram that Maria and Dan review and in the instance log testers read. Notifications (mail steps) close each branch so that the person who started the work learns the result; a reject that ends silently leaves fleet sales asking for days. Contoso's rule is that every end event is preceded by a notification that says what happened and, for rejects, why.

What goes wrong in testing

• Recipient is one person. When Maria is on vacation, every onboarding stops. Use groups.
• Unmapped outputs. The approval's decision is not mapped into the condition; every instance takes the default branch.
• Text where numbers belong. A requested limit captured as text never matches "greater than 50,000".
• No reject path test. Teams test approve, approve, approve; the reject notification has a broken recipient.
• Due dates ignored. Nobody tests what happens when a task is overdue.