Extending Case Approvals In SAP Sales & Service Cloud V2 + ESM: Using Business Roles For Multi-Users

This blog post is a continuation of: Assigning a Custom Party Role to a Case for Approvals in SAP Sales & Service Cloud v2 + ESM

Introduction

The previous blog post walked through how to create a Custom Party Role, add it to a Case Party Schema, and wire it into an Autoflow approval — a clean and effective pattern for routing a case to a named approver.

But what happens when your business scenario requires more than one approver? What if an entire team needs to approve a case, and that team membership changes over time?

SAP Sales & Service Cloud v2 (SSC v2) and ESM do not have a native Branch or Approval Hierarchy construct the way some other products do. There is no built-in concept of “send to a department” or “broadcast to a group approval pool.” You cannot pick a Business Role directly in the Approval Rule as a recipient group — the approval framework works with individual people assigned to the case.

This extension blog describes a practical pattern to bridge that gap:

Use a Business Role in SSC v2 as the governed container of approvers. Sync its membership from IAS via IPS over SCIM. Populate a non-unique Custom Party Role on the Case with all members of that Business Role. Then use the Case Approval flow to route to all those party role members simultaneously.

The result: a fully dynamic, centrally governed multi-user approval — without needing a branch or hierarchy model.

The Problem: No Branch, No Hierarchy, But Multiple Approvers Needed

In SSC v2/ESM case approvals, the approval process resolves its recipients from people assigned to a specific party role on the case. This works well for a single approver — assign one person to the “Line Approver” party role, and the approval goes to them.

However, real-world scenarios often require:

A team of approvers where any one member can take action (e.g., a support management pool)
A scenario where all members must approve (e.g., a compliance sign-off)
A quorum approval (e.g., at least 2 out of 5 approvers must accept)

And critically: approval team membership changes. People join, leave, change roles. Hardcoding names in configuration is not maintainable.

The answer lies in combining three capabilities:

Business Roles in SSC v2 — as a group of approvers with a meaningful identity
IAS User Groups + IPS SCIM provisioning — for centralized lifecycle management of who is in that group
BTP Extensibility for Assignment of Users to Case from Business Role
Non-unique Custom Party Role on the Case — as the runtime carrier of multiple approvers that the approval flow reads

Architecture Overview

IAS (Identity Authentication Service)
└── User Group: “CASE_APPROVERS_GRP1”
├── User A
├── User B
└── User C
│
│ IPS SCIM Sync (Business Role provisioning)
▼
SSC v2 / ESM
└── Business Role: Z_CASE_APPROVERS_GRP1
├── User A (assigned this Business Role)
├── User B (assigned this Business Role)
└── User C (assigned this Business Role)
│
│ Manual or Automated Party Assignment(BTP Extension)
▼
Case → Custom Party Role: Z_GRP_APPROVER (non-unique)
├── User A (Party on Case)
├── User B (Party on Case)
└── User C (Party on Case)
│
│ Autoflow → Approval Action
▼
Approval Tasks sent to User A, User B, User C
(All / Any One / At Least X — configurable)

2026-08-26_10-34-02 (1).Gif

Why This Pattern Works Without a Branch or Hierarchy

Challenge	How It's Solved
No group/branch concept in approvals	Business Role acts as the group container; its members are loaded into a non-unique party role on the case
Approval team changes over time	IAS group membership is updated → IPS SCIM sync propagates changes to SSC v2 Business Role → Next case uses the updated team
Different cases need different approval groups	Create one Business Role + Custom Party Role per approval group; populate the right one on each case based on conditions
Need any-one or all-must-approve semantics	Controlled by the Approval Rule setting — no process redesign needed
Hardcoded user names in configuration	No user names anywhere in config — only role/group names

Summary

This pattern extends the Custom Party Role + Autoflow approval approach with a scalable, centrally governed layer. By treating a Business Role as the approval group, syncing its members from IAS via IPS over SCIM, and surfacing them on the case through a non-unique Custom Party Role, you unlock multi-user approval semantics in SAP SSC v2 / ESM — without needing any branch, hierarchy, or hardcoded user configuration.

The result is an approval flow that is:

Dynamic — membership changes in IAS flow through automatically
Flexible — supports any-one, all-must, or quorum approval modes
Maintainable — no user names in process configuration
Governed — IAS is the single source of truth for who approves what

Related blogs:

Source link