Read-Confirmation
I designed and helped deliver Read Confirmation for SAP Signavio Collaboration Hub, enabling teams to request and track acknowledgement of published process updates.
I located the capability in Hub, where employees already viewed the content, rather than routing it through a heavier Process Governance workflow. The result was a focused loop: request, notify, confirm, and monitor.
Key Decision
Keep acknowledgement in Hub rather than route it through Process Governance, accepting lighter orchestration for lower friction and no Governance licence requirement.
Key Decision
Keep acknowledgement in Hub rather than route it through Process Governance, accepting lighter orchestration for lower friction and no Governance licence requirement.
Evidence / Validation
Prototype reviews narrowed the initial brief; post-release feedback from pilot customers focused on group support and persistent task visibility rather than changes to the core flow.
Evidence / Validation
Prototype reviews narrowed the initial brief; post-release feedback from pilot customers focused on group support and persistent task visibility rather than changes to the core flow.
Delivery Status
Shipped in Hub for individual recipients; group targeting followed soon after. Persistent tasks, reminders, escalation, and richer reporting remained follow-on platform needs.
Delivery Status
Shipped in Hub for individual recipients; group targeting followed soon after. Persistent tasks, reminders, escalation, and richer reporting remained follow-on platform needs.
01 /
Problem
In regulated organisations, publishing an updated process may not be enough; teams may need evidence that affected employees have seen it. Hub had no native way to request or track that acknowledgement.
A workflow-backed approach offered richer tasks and reporting, but added setup, moved recipients into another product, and required Governance access. Early customer discussions also revealed broader needs: groups, reminders, escalation, persistent tasks, and reporting, so the challenge was defining a useful first release without turning acknowledgement into a full task-management product.
01 /
Problem
In regulated organisations, publishing an updated process may not be enough; teams may need evidence that affected employees have seen it. Hub had no native way to request or track that acknowledgement.
A workflow-backed approach offered richer tasks and reporting, but added setup, moved recipients into another product, and required Governance access. Early customer discussions also revealed broader needs: groups, reminders, escalation, persistent tasks, and reporting, so the challenge was defining a useful first release without turning acknowledgement into a full task-management product.
02 /
Process
I modelled the experience around Process Owners, who create and monitor requests, and Process Consumers, who review published content and confirm it. Through wireframes, prototypes, and reviews with product, engineering, internal experts, and customer representatives, I tested recipient selection, notifications, confirmation, monitoring, and the boundary of the first release.
I narrowed the initial scope to individual recipients and a request → notify → confirm → monitor flow. As that moved into development, I designed group support as the next phase. This introduced a privacy constraint: the interface could not expose confidential group membership through selection, progress, or reporting.
02 /
Process
I modelled the experience around Process Owners, who create and monitor requests, and Process Consumers, who review published content and confirm it. Through wireframes, prototypes, and reviews with product, engineering, internal experts, and customer representatives, I tested recipient selection, notifications, confirmation, monitoring, and the boundary of the first release.
I narrowed the initial scope to individual recipients and a request → notify → confirm → monitor flow. As that moved into development, I designed group support as the next phase. This introduced a privacy constraint: the interface could not expose confidential group membership through selection, progress, or reporting.
03 /
Solution
Process Owners could create a request from a published process revision, select recipients, send it, and monitor completion. Recipients received an in-product notification and email, then confirmed directly while viewing the relevant process.
A follow-on release added privacy-safe group targeting. Individual users and groups remained distinct where needed, preventing group membership from leaking through the experience.
Persistent task lists, automated reminders, escalation, and richer reporting remained follow-on platform needs rather than being added to the core acknowledgement flow.
03 /
Solution
Process Owners could create a request from a published process revision, select recipients, send it, and monitor completion. Recipients received an in-product notification and email, then confirmed directly while viewing the relevant process.
A follow-on release added privacy-safe group targeting. Individual users and groups remained distinct where needed, preventing group membership from leaking through the experience.
Persistent task lists, automated reminders, escalation, and richer reporting remained follow-on platform needs rather than being added to the core acknowledgement flow.
04 /
Outcome
Delivered
A native Hub capability for requesting, confirming, and monitoring acknowledgement, followed soon afterwards by group targeting.
Enabled
Recipients could participate in context without workflow configuration or a Governance licence.
Clarified
Lightweight governance actions could live directly in the publication experience, while persistent tasks, reminders, escalation, and richer reporting required broader platform capabilities.