Suite Approval Foundations - Matthew Correia

01 /

Problem

Starting an approval required configuration spread across several products: document attributes, fixed Governance variables, participant mappings, and a separate submission step. Because participant data lived outside Governance, required values could be missing or incorrect, leaving workflow tasks without an assignee and causing approval cases to stall.

Journey Modeller exposed the deeper issue. Its documents could not use the legacy attribute infrastructure, so extending Approval product by product would only reproduce the same dependency. The challenge was to create a suite-wide integration model without forcing existing customers to migrate.

In Explorer, each supported document type required custom participant attributes to be created, then mapped separately to fixed workflow roles.

Approval participant values were entered in the Editor through document attributes mixed among the organisation’s other custom fields, with no visible connection to approvals. Users had to know which fields to complete before switching to Collaboration Hub, where submission neither exposed existing assignments nor allowed missing ones to be resolved.

01 /

Problem

Starting an approval required configuration spread across several products: document attributes, fixed Governance variables, participant mappings, and a separate submission step. Because participant data lived outside Governance, required values could be missing or incorrect, leaving workflow tasks without an assignee and causing approval cases to stall.

Journey Modeller exposed the deeper issue. Its documents could not use the legacy attribute infrastructure, so extending Approval product by product would only reproduce the same dependency. The challenge was to create a suite-wide integration model without forcing existing customers to migrate.

02 /

Process

I reframed the request from a Journey Modeller integration into a product-model problem. I mapped the end-to-end flow, compared keeping attributes, creating a Governance-owned data layer, and replacing the legacy model, then worked through prototypes and implementation constraints with customer preview participants, customer-facing specialists, engineers, and adjacent suite teams.

The hybrid model split responsibility clearly: workflow modellers defined the roles each workflow needed; Governance turned those requirements into fields and collected or validated assignments; product teams launched the shared flow. This kept a reliability-critical interaction in UI Governance could control while preserving existing attribute-based setups.

Mapping the existing journey across configuration, modelling, publishing, submission and execution exposed how approval data and actions were distributed across multiple products and document-specific infrastructure.

I explored several potential homes for participant configuration: organisation-level Hub settings, direct assignment within the workflow model, workflow-defined roles, and template-led creation. Defining participants alongside workflow roles was selected as the most scalable direction, and best fitting to the authoring flow our customers already used.

The submission experience evolved from a legacy workflow selector into a focused flow that dynamically exposed and resolved the participants required by the selected workflow, while progressively aligning the interaction with the suite and SAP Fiori design systems.

02 /

Process

I reframed the request from a Journey Modeller integration into a product-model problem. I mapped the end-to-end flow, compared keeping attributes, creating a Governance-owned data layer, and replacing the legacy model, then worked through prototypes and implementation constraints with customer preview participants, customer-facing specialists, engineers, and adjacent suite teams.

The hybrid model split responsibility clearly: workflow modellers defined the roles each workflow needed; Governance turned those requirements into fields and collected or validated assignments; product teams launched the shared flow. This kept a reliability-critical interaction in UI Governance could control while preserving existing attribute-based setups.

03 /

Solution

The shipped trigger allowed participant roles to vary by workflow instead of relying on three fixed variables. When a user selected a workflow, the Governance submission modal revealed its required roles, surfaced known values, and required missing assignments before the case could start.

This changed the model from:
Document attributes → Org-level mapping → Workflow variables → Participants

to:
Workflow-defined roles → Approval submission UI → Participant assignments

Existing attribute-based integrations continued to work, so customers were not forced into immediate migration. I designed the workflow configuration, participant-assignment behaviour, and Hub submission experience, then supported the work through release and handover.

The shipped configuration allowed each approval workflow to define its own participant roles. Existing document attributes could still supply values for compatibility, while roles could also be filled directly during submission and optionally constrained to a user category.

Within Process Governance, modellers defined participant roles and their data sources, assigned those roles to workflow tasks, and published the completed workflow for use by integrated products.

From a document’s existing approval entry point, selecting a workflow revealed the participant roles it required. Existing values were surfaced where available, missing assignments could be completed in the submission modal, and the case started only after the required participants were resolved.

03 /

Solution

The shipped trigger allowed participant roles to vary by workflow instead of relying on three fixed variables. When a user selected a workflow, the Governance submission modal revealed its required roles, surfaced known values, and required missing assignments before the case could start.

This changed the model from:
Document attributes → Org-level mapping → Workflow variables → Participants

to:
Workflow-defined roles → Approval submission UI → Participant assignments

Existing attribute-based integrations continued to work, so customers were not forced into immediate migration. I designed the workflow configuration, participant-assignment behaviour, and Hub submission experience, then supported the work through release and handover.

04 /

Outcome

Delivered
Shipped the first release of the workflow-centred approval model, with dynamic participant roles and Governance-owned collection and validation.

Enabled
Removed the blocker for Journey Modeller to begin product-side integration and gave other products a reusable route into Approval. Existing Governance customers could keep the legacy trigger; wider adoption of the new path was still early when I left.

Clarified
Established a repeatable integration pattern: workflows declare participant requirements, Governance gathers and checks assignments, and product teams provide the entry point.