‹ Suite Approval Foundations

‹ Prev.

Design System ›

Next ›

Change Propagation

Change Propagation gave SAP Signavio Variant Management a controlled way to keep local process variants aligned with updates to their reference templates.

Brought in under a fixed deadline, I led design from framing through delivery. I turned an underdefined automation promise into a review-led workflow that automated only high-confidence changes and kept structural or ambiguous updates under human control.

Variant owners were notified of published template updates, reviewed automatic and manual changes in Hub, and could later inspect decisions by revision in History. The review flow shipped first; the fuller History view followed shortly afterwards.

Key Decision

Use Hub for review and handover to the Process Editor for complex changes. This was the most viable compromise between feasibility and workflow fit.

Key Decision

Use Hub for review and handover to the Process Editor for complex changes. This was the most viable compromise between feasibility and workflow fit.

Evidence / Validation

Pilot-customer workshops, rapid prototypes, and engineering feasibility work shaped the scope and Hub/Editor boundary.

Evidence / Validation

Pilot-customer workshops, rapid prototypes, and engineering feasibility work shaped the scope and Hub/Editor boundary.

Delivery Status

Shipped the Hub review flow with automatic/manual resolution and export traceability; the full History view followed shortly afterwards.

Delivery Status

Shipped the Hub review flow with automatic/manual resolution and export traceability; the full History view followed shortly afterwards.

01 /

Problem

Organisations could create local variants from a shared template, but once those variants diverged, later template updates were difficult to detect, understand, apply, and trace. Users had to recreate changes manually in the Process Editor, while the team had already committed to the feature before its product model or technical feasibility was clear.

Once a template and its local variant diverged, later template changes did not reliably carry across: a newly added task could remain missing from the variant. The feature needed to surface that difference without imposing every update automatically.

01 /

Problem

Organisations could create local variants from a shared template, but once those variants diverged, later template updates were difficult to detect, understand, apply, and trace. Users had to recreate changes manually in the Process Editor, while the team had already committed to the feature before its product model or technical feasibility was clear.

Once a template and its local variant diverged, later template changes did not reliably carry across: a newly added task could remain missing from the variant. The feature needed to surface that difference without imposing every update automatically.

02 /

Process

I worked with product, engineering, domain experts, and the pilot customer to define the trigger, ownership model, automation boundary, review experience, and traceability requirements.

Interactive wireframes helped engineering compare the Process Editor, Comparator, Hub, and a standalone flow, and rule out infeasible directions early. Editor-native review was the most natural experience but too risky within the deadline, so we used Hub as a bounded coordination surface and kept complex model editing in the Editor. Customer workshops then tested the feasible model, clarified where review was essential, and aligned the first-release scope.

The working interaction model connected template publication to variant-owner notification, review, selective application and a new anchored revision. Mapping the loop exposed where user decisions, repeat review and system notifications had to remain explicit.
Pilot-customer input established the need to inspect automatic changes individually or together, while design and engineering synthesis exposed constraints around revisions, save state and the existing Editor. Together, these inputs narrowed broad automation into an explicit, review-led model.
I compared six potential environments. The Process Editor was the strongest semantic fit, but its technical and delivery risk made it infeasible under the deadline; Hub offered the only viable compromise that still preserved product logic, process context and a practical handoff to modelling.
The review UI evolved from a flat change list through explorations shaped by the required automatic–manual separation and the decision to use Hub. The final prototype strengthened hierarchy, change-level actions and orientation while preserving a path towards broader automation later.

02 /

Process

I worked with product, engineering, domain experts, and the pilot customer to define the trigger, ownership model, automation boundary, review experience, and traceability requirements.

Interactive wireframes helped engineering compare the Process Editor, Comparator, Hub, and a standalone flow, and rule out infeasible directions early. Editor-native review was the most natural experience but too risky within the deadline, so we used Hub as a bounded coordination surface and kept complex model editing in the Editor. Customer workshops then tested the feasible model, clarified where review was essential, and aligned the first-release scope.

The working interaction model connected template publication to variant-owner notification, review, selective application and a new anchored revision. Mapping the loop exposed where user decisions, repeat review and system notifications had to remain explicit.
Pilot-customer input established the need to inspect automatic changes individually or together, while design and engineering synthesis exposed constraints around revisions, save state and the existing Editor. Together, these inputs narrowed broad automation into an explicit, review-led model.
I compared six potential environments. The Process Editor was the strongest semantic fit, but its technical and delivery risk made it infeasible under the deadline; Hub offered the only viable compromise that still preserved product logic, process context and a practical handoff to modelling.
The review UI evolved from a flat change list through explorations shaped by the required automatic–manual separation and the decision to use Hub. The final prototype strengthened hierarchy, change-level actions and orientation while preserving a path towards broader automation later.

03 /

Solution

Publishing a template update notified affected variant owners, who reviewed proposed changes in a dedicated Hub flow. Reliably automatable updates could be applied there; structural or ambiguous changes opened in the Process Editor for guided manual completion before users returned to confirm them.

Resolving the update anchored the variant to the relevant template revision. Export-based traceability shipped in the first release, followed shortly afterwards by a full History view.

The Hub experience kept process context beside a structured change list: owners could accept or ignore reliable automatic updates, coordinate remaining manual work, and inspect propagation decisions in History. The review surfaces shipped first, with the fuller History view following shortly afterwards.
Published template updates notified variant owners, who reviewed automatic changes before resolving remaining manual work through an Editor handoff and returning to Hub to confirm completion; audit and export history kept the outcome traceable. The Process Editor screens show existing, unchanged UI, my work defined the surrounding Hub experience and cross-product handoff.

03 /

Solution

Publishing a template update notified affected variant owners, who reviewed proposed changes in a dedicated Hub flow. Reliably automatable updates could be applied there; structural or ambiguous changes opened in the Process Editor for guided manual completion before users returned to confirm them.

Resolving the update anchored the variant to the relevant template revision. Export-based traceability shipped in the first release, followed shortly afterwards by a full History view.

The Hub experience kept process context beside a structured change list: owners could accept or ignore reliable automatic updates, coordinate remaining manual work, and inspect propagation decisions in History. The review surfaces shipped first, with the fuller History view following shortly afterwards.
Published template updates notified variant owners, who reviewed automatic changes before resolving remaining manual work through an Editor handoff and returning to Hub to confirm completion; audit and export history kept the outcome traceable. The Process Editor screens show existing, unchanged UI, my work defined the surrounding Hub experience and cross-product handoff.

04 /

Outcome

Delivered. The agreed workflow shipped within the deadline, with bounded automation, explicit review, guided manual completion, and traceability. The full History view followed in the next release.

Enabled. Pilot-customer workshops created clearer agreement on first-release scope and follow-on priorities.

Clarified. The work identified what stronger future propagation would require: Editor-native staging and review, richer model-difference data, broader automation, nuanced revision handling, and stronger recovery and audit support.

‹ Suite Approval Foundations

‹ Prev.

Design System ›

Next ›