BTP & Integrationintermediate

BTP Build Process Automation Part 3: Forms, Conditions and Decision Tables

Key takeaway

Model business rules cleanly: form design with validations, conditions for simple branching, decision tables for rules like approval thresholds and approver determination, inputs/outputs, and keeping rules maintainable by business experts.

Explanation

📌 KEY POINTS
✅ Forms collect structured input with validations (required fields, formats).
✅ Conditions handle simple branches inside the process.
✅ Decision tables externalize rules (e.g. amount + cost center → approver level).
✅ Business experts can maintain decisions without changing the process flow.
⚠️ Encoding thresholds as nested conditions in the process makes every policy change a redesign.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 2 built a workflow. Now rules.

━━━━━━━━━━━━━━━━━━━━
▶ 1. FORMS

Fields, validation, layout.

━━━━━━━━━━━━━━━━━━━━
▶ 2. CONDITIONS

Simple branching.

━━━━━━━━━━━━━━━━━━━━
▶ 3. DECISION TABLES

Inputs, outputs, rows.

━━━━━━━━━━━━━━━━━━━━
▶ 4. APPROVER DETERMINATION

By amount, org unit, category.

━━━━━━━━━━━━━━━━━━━━
▶ 5. MAINTENANCE

Versioning decisions; testing.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Create a decision: amount → approval level.
Call it in the process before approval.
Test edge amounts.

✅ CHECKPOINT: approver changes by amount without process changes.

Code example

ABAP Code

===== DECISION TABLE (example) =====Input: amount, category | Output: approverGroupamount <= 5,000                → TEAM_LEAD5,000 < amount <= 50,000       → DEPT_HEADamount > 50,000 and category = CAPEX → CFOamount > 50,000 (other)        → DIRECTOR ===== PROCESS =====Trigger → Decision "ApproverDetermination" → Approval (recipients: ${decision.approverGroup})

Real project scenario

A capital-expenditure workflow had approval thresholds hard-coded in nested conditions; a policy change required redesign and testing. Moving thresholds into a decision table let finance change them directly.

Common mistakes

Nested conditions for policies.
No form validation.
Overlapping rules.
Untested edge values.
Rules scattered.

Best practices

Decision tables.
Validated forms.
Clean rule rows.
Edge testing.
Central rules.

Interview angle

Questions: "Condition vs decision table?", "How do you determine approvers?", "Who maintains decisions?"
Strong answer: forms, conditions, decisions, determination, maintenance.

Practice this lesson

Quick check

1. When is a simple condition enough instead of a decision table?

2. Capex approval thresholds were hard-coded in nested conditions and every policy change needed redesign. What is better?

3. What should be tested when creating a decision table for approval thresholds?

Interview questions

1. A project team is working on SAP Build Process Automation. Using the Build Process Automation Architecture: APIs, Task Center, Work Zone and Governance scenario, how would you approach the requirement from design through validation?

Answer it in your own words first, then compare.

2. What design decisions and trade-offs matter most when implementing SAP Build Process Automation, particularly for SAP Build Process Automation Fundamentals: Processes, Forms, Decisions and Automations?