The Three Workflow Types in SAP Advanced Workflow

Workflow Types Overview

SAP Advanced Workflow supports three distinct workflow types. Each serves a different business purpose, has different trigger mechanisms, and requires different configuration approaches. Most IM implementations use all three types in combination — approval workflows to gate business decisions, notification workflows to keep participants informed, and automation workflows to execute system logic.

The three types are not mutually exclusive. A single IM event (e.g., plan submission) might trigger an approval workflow, which upon completion triggers a notification workflow to alert participants, which then triggers an automation workflow to update quotas. Understanding when and how to use each type is the foundation of effective Advanced Workflow design.

Approval Workflows: Route Decisions Through Human Approvers

Purpose and Use Cases

Approval workflows route a business decision through one or more human approvers before an action is taken. The workflow holds the decision in a pending state, assigns tasks to approvers, waits for their response, and then routes based on their action (Approve, Reject, or Return for Revision). An approval workflow is always human-centric — at least one step requires a human decision.

In IM implementations, approval workflows are used for:

• Compensation plan release approval: A manager submits a compensation plan for their team. The workflow routes it to the director for approval. The director reviews the plan and either approves it (plan goes into effect) or rejects it (plan sent back for revision). A typical flow: Manager → Director → VP (if plan exceeds $1M).
• Quota change approval: A territory manager requests a quota adjustment. The workflow routes to the sales director for approval. The director reviews the justification and approves or denies the change. If denied, the requestor receives feedback and can submit a revised request.
• Incentive exception approval: A calculation produces an outlier result (e.g., commission is 3x the typical amount for the role). The workflow routes the exception to a compensation analyst for review. The analyst can approve the result as-is, override with a corrected amount, or return it for investigation.
• Dispute resolution: A participant disputes their quota or commission. The workflow routes to a compensation analyst or disputes team for investigation. The analyst approves the dispute (adjustment is made) or rejects it (participant receives explanation).

The Approval Chain Structure

An approval workflow is composed of a sequence of approval steps. Each step has one or more potential approvers who are selected based on routing rules. The workflow waits for the assigned approver(s) to respond. Their response determines whether the workflow moves to the next step, returns to a previous step, or terminates.

A simple two-level approval chain looks like this:

• Step 1 (Manager Approval): Workflow routes to the participant's direct manager. Manager reviews. If Approve → advance to Step 2. If Reject → end workflow and notify participant.
• Step 2 (Director Approval): Workflow routes to the director (manager's manager). Director reviews. If Approve → end workflow and notify participant of approval. If Reject → return to Step 1 for manager revision.

A more complex approval chain might include conditional routing:

• Step 1 (Manager Approval): Manager approves plan.
• Step 2 (Director Approval): Check plan value. If < $500K → skip to Step 4. If >= $500K → proceed to director approval.
• Step 3 (VP Approval): Director forwards to VP for high-value plans.
• Step 4 (Final Notification): Send approval notification to participant.

Approver Selection: How Workflows Identify Who Should Approve

The critical decision in approval workflow configuration is how to identify the correct approver at each step. SAP Advanced Workflow supports three approver selection modes:

Specific User: Hard-code a user ID or email. Example: "Send to compensation-team@company.com". This is rarely used for dynamic approval chains (because approvers change) but is useful for static escalation paths (always escalate high-value exceptions to the compensation director).

Role-Based Lookup: Identify approvers by role. Example: "Find all users with role = 'Compensation Analyst' in the participant's region". The workflow routes to anyone with that role. This is useful when multiple people can approve and any one of them will do. However, it can create bottlenecks if only one person has the role in a given region.

Hierarchy-Based Lookup: Navigate the participant's reporting hierarchy to find the approver. This is the most common pattern in IM. Example: "Route to participant.manager.id" (direct manager) or "participant.manager.manager.id" (director). The Groovy script evaluates the hierarchy relationship and returns the approver ID.

Hierarchy-based lookup is powerful but fragile. If the participant's manager ID is null (manager not set, or participant has no manager), the routing fails. If the manager is also a participant in the workflow, you create a circular approval chain. If the manager is terminated or inactive, the workflow must escalate. Robust approval workflows include null checks and fallback logic.

Escalation: What Happens When an Approval Isn't Completed

Escalation rules define what happens when an approver doesn't respond within a defined time window. Without escalation, a workflow could wait forever for an approver who is out of office or who simply forgets to act.

SAP Advanced Workflow supports several escalation strategies:

Auto-Approve: If no action is taken within N days (e.g., 5 days), automatically approve and move to the next step. This is useful for non-critical approvals. Risk: approver was deliberately delaying for a reason.

Escalate to Backup Approver: If the primary approver doesn't respond, route to a backup (e.g., the primary approver's manager, or a compensation manager). The workflow assignment transfers to the backup. This is common for plan approvals: if the manager doesn't approve within 5 days, escalate to the director.

Send Reminder: Send the approver a reminder email after N days. The workflow remains pending. If still no action after M days, escalate to a backup. This is a hybrid approach.

Reject and Route Back: If no action within N days, reject the submission and route it back to the initiator with a message like "Approval expired — please resubmit." This is rare but used when approval windows are strict.

Escalation timing is configured at the step level. A workflow might have multiple escalations:

• Manager approval: Escalate to director after 3 days, auto-approve after 7 days.
• Director approval: Send reminder after 2 days, escalate to VP after 5 days.

Escalation logic must account for time zones, holidays, and weekends. IM systems typically have business calendars that define working days. Escalation timers respect the business calendar — a 5-day SLA means 5 business days, not 5 calendar days.

Parallel vs Sequential Approval

Approval workflows can route to multiple approvers in two ways:

Sequential: Approver 1 → Approver 2 → Approver 3. Each approver must respond before the workflow advances. If any approver rejects, the workflow terminates. Sequential approval is standard for hierarchical approval chains (manager → director → VP).

Parallel: Approver 1, Approver 2, and Approver 3 all receive the approval task simultaneously. The workflow waits for all three to respond (or waits for any one to approve, depending on configuration). Parallel approval is used when you need multiple stakeholder sign-offs who don't have a hierarchy relationship. Example: Plan must be approved by both the sales director (for territory coverage) and the compensation manager (for budget impact).

Parallel approval creates complexity because the workflow must define what "done" means. Does every approver need to approve? Or is one approval sufficient? What if some approve and others reject? Parallel workflows have higher failure risk because timing and dependencies are harder to reason about.

SLA Timers and Approval Windows

SLA (Service Level Agreement) timers define how long an approval step can remain pending. The timer starts when the approval task is assigned to the approver. If the approver doesn't respond before the timer expires, escalation logic triggers.

SLA timers are typically configured in business days, not calendar days. A 3-day SLA means the approver has 3 business days to respond. If a business day is Monday-Friday 9am-5pm in the participant's time zone, then a task assigned on Friday at 4pm has an SLA deadline of Wednesday morning (Monday and Tuesday are business days, Wednesday morning is when the deadline is reached).

SLA configuration is step-specific. A 2-step approval workflow might have:

• Step 1 (Manager): 3-day SLA, escalate to director if not approved.
• Step 2 (Director): 5-day SLA, auto-approve if not acted upon.

Rejection and Return Logic

When an approver rejects or returns an approval step, the workflow must decide what happens next. Three common patterns:

Reject Terminates Workflow: If manager rejects the plan approval, the workflow ends. The initiator is notified of the rejection with a comment from the manager. The initiator can revise and resubmit, which creates a new workflow instance.

Return for Revision: If the manager rejects, the workflow returns to the initiator (the person who originally submitted the plan). The initiator receives the rejection comment and can revise the plan and resubmit it to the workflow. This keeps the same workflow instance in a "pending revision" state until the initiator resubmits.

Return to Previous Step: If director rejects, the workflow returns to the manager with a comment "Director requests changes. Please revise and resubmit." The manager can revise and approve again, or reject. This keeps the workflow active but cycles it back.

Each pattern has trade-offs. "Reject terminates" is simple and clean but requires resubmission (which creates a new workflow instance and loses audit trail continuity). "Return for revision" keeps the audit trail intact but requires the initiator to have edit permissions. "Return to previous step" keeps the chain intact but adds steps and complexity.

Approval Workflow Example: Two-Step Plan Approval

Here's a concrete example of a typical approval workflow configuration:

• Trigger: Plan status changes to "SUBMITTED_FOR_APPROVAL".
• Condition: Only trigger if plan.type = "INCENTIVE" (exclude administrative plans).
• Step 1 - Manager Review:
  • Approver: participant.manager.id (direct manager from org hierarchy).
  • SLA: 3 business days.
  • Task assignment email: "Plan [planName] submitted for your approval."
  • Escalation: After 3 days, escalate to participant.manager.manager.id (director).
  • On Approve: Advance to Step 2.
  • On Reject: Send notification to initiator. Workflow ends.
• Step 2 - Director Review (Value-Based):
  • Condition: Check plan.annual_value. If < $500K, skip this step and go to Step 3. If >= $500K, proceed.
  • Approver: participant.manager.manager.id (director).
  • SLA: 5 business days.
  • Escalation: After 5 days, auto-approve (assume director concurrence).
  • On Approve: Advance to Step 3.
  • On Reject: Return to Step 1 (manager revises plan).
• Step 3 - Final Notification:
  • No human approval. Send email to participant: "Your plan has been approved and is now effective."
  • Workflow outcome: "APPROVED".
  • Return outcome to IM. IM updates plan status to "ACTIVE".

Notification Workflows: Send Automated Messages

Purpose and Use Cases

Notification workflows send automated messages to recipients when IM events occur. They don't involve human decisions — they simply detect an event and dispatch a message (email, SMS, in-app alert, or API call). Notification workflows are the mechanism for keeping participants, managers, and administrators informed about compensation events.

Common notification use cases in IM:

• Plan released to participant: A compensation plan is released and assigned to a participant. Workflow sends email: "Your Q2 incentive plan is now available in SAP SuccessFactors. Review your targets and commission structure."
• Compensation statement ready: A calculation completes and a participant's statement is published. Workflow sends email: "Your Q2 statement is ready. Your commission: $5,240. View details in SuccessFactors."
• Quota updated: A territory quota is adjusted (by an admin, or by automation workflow). Workflow sends email to the affected participant: "Your Q2 territory quota has been updated to $2M (from $1.8M)."
• Calculation run completed: A monthly calculation cycle completes. Workflow sends email to all affected participants: "July calculations are complete. Statements are now available."
• Dispute filed or resolved: A participant files a dispute about their commission. Workflow sends confirmation email: "We received your dispute. Our team will review and respond within 5 business days."

Notification Configuration

A notification workflow configuration includes:

Trigger Event: The IM event that fires the notification. Examples: "plan.released", "statement.published", "quota.updated", "calculation.completed", "dispute.submitted".

Condition (optional): Filter which events trigger the notification. Example: Only send quota update notifications if quota_change_amount > 10% (ignore small adjustments). Or: Only send statements if participant.status = "ACTIVE" (don't notify terminated participants).

Recipients: Who receives the notification. This can be static (always send to the participant) or dynamic (send to participant + manager if commission > $10K, otherwise just the participant). Recipients are determined via Groovy script or role lookup.

Message Channel: Where the message is sent (email, SMS, in-app alert, webhook to external system).

Message Subject and Body: The notification content. Both use templates with context variables.

Context Variables: Personalizing Notification Content

Notification templates use context variables to insert participant-specific data into the message. These variables are populated by the workflow engine based on the triggering event and the participant's data.

Common context variables in IM notification workflows:

• ${participant.name} — Participant's full name.
• ${participant.email} — Participant's email address.
• ${participant.id} — Participant ID / username.
• ${plan.name} — Name of the compensation plan.
• ${plan.type} — Plan type (INCENTIVE, SALARY, BONUS, etc.).
• ${plan.period} — Period covered by the plan (Q2 2026, July 2026, etc.).
• ${statement.commission_amount} — Commission calculated in the statement.
• ${statement.quota_achievement} — Quota achievement %, if applicable.
• ${quota.territory} — Territory name / code.
• ${quota.new_value} — New quota value after adjustment.
• ${quota.old_value} — Previous quota value.
• ${workflow.submittedBy} — User who submitted the item being notified about.
• ${workflow.completedAt} — Timestamp when the workflow completed.

Example notification subject: "Statement Ready: ${plan.name} for ${plan.period}"

Example notification body:

Hi ${participant.name},

Your ${plan.period} compensation statement is ready.

Commission: $${statement.commission_amount}
Quota Achievement: ${statement.quota_achievement}%
Territory: ${quota.territory}

View your full statement in SAP SuccessFactors.

Questions? Contact: compensation-team@company.com

Dynamic Recipients: Routing Notifications Based on Context

Some notifications go to the participant. Others go to the manager or compensation team. Notification workflows can use Groovy to determine recipients dynamically.

Example: Send statement notification to participant AND manager if commission > $15K:

• If statement.commission_amount > 15000, recipients = [participant.email, participant.manager.email].
• Else, recipients = [participant.email].

Example: Send quota update to participant AND compensation team if adjustment is large:

• If abs(quota.new_value - quota.old_value) / quota.old_value > 0.20, add "compensation-team@company.com" to recipients.
• Always include participant.

Push vs Email Notifications

Notifications can be delivered via multiple channels:

Email: Sent to the recipient's email address. Most common in IM. Email is reliable, includes full message content, and creates a searchable record. Drawback: recipients must check email to see the notification.

Push Notification: Appears in-app in SuccessFactors as an alert or task. Recipients see it immediately in their dashboard. Drawback: limited message length, disappears if not read.

SMS: Text message to recipient's phone. Useful for time-critical notifications (e.g., "Your statement is ready — action required"). Less common in compensation workflows due to cost and message length constraints.

Webhook (API Callback): Post the notification to an external system (Slack, Microsoft Teams, custom app). Useful for integrating IM notifications into existing communication workflows.

A single notification workflow can send to multiple channels. Example: Send statement-ready notification as email AND as a push notification in SuccessFactors.

Notification Templates and Reusability

SAP Advanced Workflow allows you to define notification templates. A template is a pre-built message subject and body with context variables built in. You create a template once, then reference it from multiple notification workflows.

Benefits of templates:

• Consistency: All "statement ready" notifications use the same template, ensuring consistent messaging.
• Maintenance: Update the template once, and all workflows that use it automatically use the new version.
• Translation: A single template can have translations for multiple languages. Workflow delivers the message in the participant's preferred language.

Automation Workflows: Execute System Actions

Purpose and Use Cases

Automation workflows execute programmatic actions without human involvement. They run Groovy scripts, call REST APIs, update IM data, or trigger other workflows in response to IM events. Automation workflows are the mechanism for closing the feedback loop between IM and backend systems, and for executing complex business logic that the IM formula engine can't express.

Common automation use cases in IM:

• Automatically update quota when territory changes: A participant is assigned to a new territory. Workflow detects the assignment event, looks up the territory's standard quota, and updates the participant's quota in IM. No manual data entry required.
• Trigger calculation run when credits reach threshold: A participant's credit balance (e.g., professional development credits earned) reaches a milestone. Workflow triggers a calculation run to compute their updated commission. This creates real-time or near-real-time compensation visibility.
• Call external REST API after plan completion: A compensation plan completes (all statements published). Workflow calls an external payroll system API: "Plan ABC is complete. Sync commissions to payroll for processing." The payroll system receives the data and queues it for next pay cycle.
• Flag calculation exceptions automatically: A calculation produces outlier results (commission 5x the mean for the role). Workflow detects the outlier, logs it in a central exception dashboard, and routes it for human review if it exceeds a threshold.
• Archive old periods and cleanup: A period closes and all statements are finalized. Workflow automatically archives participant data from that period (moves to archive table, deletes temporary data) to keep the IM system responsive.

Automation Workflow Configuration

An automation workflow consists of:

Trigger Event: The IM event that initiates the workflow. Examples: "territory.assigned", "statement.finalized", "calculation.completed", "period.closed".

Condition: Optional filter to narrow which events trigger the automation. Example: Only execute quota update if the participant is in the EMEA region and has a "Direct Sales" role.

Action(s): What the workflow does when triggered. Actions can be:

• Update IM Data: Change a field in IM (participant quota, commission amount, plan status). Executed via the IM API.
• Call REST Endpoint: Make an HTTP POST/GET/PUT to an external system (payroll, CRM, data warehouse, Slack, etc.). Pass participant data and event details in the request body. Optionally handle the response.
• Run Groovy Script: Execute custom Groovy code to perform calculations, transformations, validations, or data enrichment.
• Trigger Another Workflow: Invoke a different workflow (e.g., when an approval workflow completes, trigger a notification workflow).

Automation workflows are typically sequential: check condition → execute action 1 → execute action 2 → log result. There's no branching on human decision (unlike approval workflows). The workflow is deterministic — given the same input, it always produces the same output.

The Risks of Automation Workflows

Automation workflows are powerful but risky. A single bug can cascade across hundreds of participants.

Example risk scenario:

• Automation workflow: "When a period closes, calculate bonus for all participants and update their commission field."
• Bug in Groovy script: A null-check is missing. If a participant is missing a required field (salary_band), the script throws an exception.
• Outcome: The workflow fails silently. Some participants get their bonus calculated. Others don't. The system appears to have completed normally, but data is inconsistent. This is discovered weeks later during reconciliation.

Example risk scenario 2:

• Automation workflow: "When statement is published, call payroll API to sync commission."
• Bug: The REST API call doesn't check the response status. If the API returns an error (e.g., "Participant not found in payroll system"), the workflow logs success anyway.
• Outcome: Payroll never receives the commission. Participant is paid incorrectly. Finance discovers the discrepancy. Workflow execution must be audited.

Groovy Scripting in Automation Workflows

Automation workflows often rely on Groovy scripts to execute complex logic. Common Groovy patterns:

// Pattern: Validate participant data before updating
if (participant == null || participant.id == null) {
  log.error("Invalid participant: " + participant)
  return false
}

// Pattern: Null-safe navigation
def managerEmail = participant?.manager?.email ?: "team@company.com"

// Pattern: Conditional logic based on data
if (participant.region == "APAC") {
  newQuota = baseQuota * 1.15  // 15% adjustment for APAC
} else if (participant.region == "EMEA") {
  newQuota = baseQuota * 1.05  // 5% for EMEA
} else {
  newQuota = baseQuota  // No adjustment for other regions
}

// Pattern: Call REST API
import groovy.json.JsonSlurper
def response = httpClient.post(
  url: "https://payroll.company.com/api/sync",
  headers: ["Authorization": "Bearer " + apiToken],
  body: ["participant_id": participant.id, "commission": commission]
)
if (response.status != 200) {
  log.warn("Payroll sync failed for " + participant.id + ": " + response.body)
}

Workflow Type Comparison Table

Aspect	Approval Workflow	Notification Workflow	Automation Workflow
Human involvement	Required (approvers review and decide)	None (message dispatch only)	None (system action only)
Primary output	Approval decision (Approve / Reject / Return)	Message sent to recipient(s)	System action (data update, API call, script execution)
Escalation	Escalates if approver doesn't respond in SLA window	No escalation (message sent once)	No escalation (runs once on trigger)
Routing logic complexity	High (approver hierarchy, conditions, fallbacks)	Medium (recipient selection, template variables)	High (Groovy scripts, conditional actions, error handling)
Common IM use case	Plan approval, quota change, exception approval	Statement ready, quota updated, period closed	Quota sync, calculation trigger, payroll integration
Failure mode	Approval stuck (approver not found, SLA expires)	Message not delivered (wrong recipient, invalid address)	Silent failure (script runs but produces wrong result)
Testing complexity	Medium (need approvers, need to simulate SLA passage)	Low (send test message, verify delivery)	High (need data validation, need to test all edge cases)

Trigger Events in SAP Advanced Workflow

Workflow trigger events come from IM. A workflow can listen for these events:

• plan.submitted_for_approval — A compensation plan is submitted and awaits approval. Typical trigger for approval workflows.
• plan.approved — A plan completes approval chain and is activated. Trigger for notification workflows (notify participant that plan is now active).
• plan.rejected — A plan approval is rejected. Trigger for notification to notify participant and manager of rejection reason.
• calculation.completed — A calculation run finishes (period calculations, exceptions identified). Trigger for notification (notify participants that statements are ready) or automation (post calculation results to external system).
• statement.published — A participant's statement is published. Trigger for notification (email the participant their statement).
• quota.updated — A participant's quota is changed (admin update or auto-calculation). Trigger for notification (inform participant) or automation (sync to CRM).
• dispute.submitted — A participant files a dispute about their commission or quota. Trigger for approval workflow (route to disputes team for review) or notification (confirm receipt to participant).
• dispute.resolved — A dispute is approved or rejected. Trigger for notification (outcome to participant).
• period.closed — A compensation period is closed (no more changes allowed, calculations finalized). Trigger for automation (archive old data, cleanup) or notification (notify all participants that period is closed).
• participant.updated — A participant's master data is changed (manager, territory, role). Trigger for automation (update related data, recalculate commission).

Combining Workflow Types in Real Implementations

Most IM implementations use all three workflow types in combination. Here's a realistic scenario:

Scenario: Quarterly compensation plan release with approval and statement publication.

• Event 1: Plan is submitted for approval by compensation team.
• Trigger: plan.submitted_for_approval
• Workflow 1 (Approval): Route to VP of Sales for review. VP approves or rejects. If approved → event plan.approved fires.

• Event 2: Plan is approved.
• Trigger: plan.approved
• Workflow 2 (Automation): Run Groovy script to validate plan participants match current headcount. Sync approved plan to data warehouse. Trigger calculation run.

• Event 3: Calculation completes.
• Trigger: calculation.completed
• Workflow 3 (Automation): Publish statements (execute script to convert calculation results to statement format). Fire statement.published event.

• Event 4: Statements are published.
• Trigger: statement.published
• Workflow 4 (Notification): Send email to all participants: "Your Q2 statement is ready. View in SuccessFactors." Email includes participant name, commission amount, quota achievement.

• Event 5: Participant disputes their statement.
• Trigger: dispute.submitted
• Workflow 5 (Approval): Route dispute to compensation analyst for review. Analyst reviews and approves adjustment or rejects dispute. If approved → automation workflow updates participant's commission.

This chain shows how workflows interact: approval → automation → automation → notification → approval. Each workflow is independent but triggers the next based on event outcomes.

Key Takeaways

• Approval workflows are human-centric. They route decisions through approvers, handle escalation, and audit approval chains. Use them for any business decision that requires human sign-off.
• Notification workflows are event-driven messaging. They deliver automated messages with personalized content to keep stakeholders informed. Use them to replace manual status emails.
• Automation workflows are system actions. They execute Groovy scripts, call APIs, and update data without human involvement. Use them to close feedback loops and automate deterministic business logic.
• Most IM implementations combine all three types. They work together: approval triggers automation triggers notification triggers another approval.
• Automation workflows are the highest-risk type. A single bug affects all participants. Test thoroughly before production activation.