Role-based mobile workflow
02 / 08Designing a Role-based Mobile Workflow Experience
How New Flow turned one shared mobile app into role-based entry points for Coordinators and Assignees
At a glance
Challenge As New Flow carried more Workflow capabilities inside the existing app, the same Workspace began serving users with different responsibilities. Each role needed to start with the information it needed most.
Response Permissions and Workspace roles determine which view appears inside the Workspace: Coordinator, Spotlight, or Gallery.
Delivered We shipped the Coordinator and Assignee experiences, along with a shared pattern for Action content and controls.
Context & challenge
One shared app began serving users with different Workflow responsibilities
As New Flow carried more Workflow capabilities inside the existing app, the same Workspace began serving users with different responsibilities. The challenge was no longer simply adapting the flow to mobile, but helping each role start with the information they needed most.
V10 and New Flow shared the mobile app. In both versions, a Workspace represents the full process and an Action is one task within it. In New Flow, Coordinators follow the Workspace as a whole while Assignees work on assigned Actions.
The design therefore had to preserve the shared app and the existing Workspace and Action model, while changing what each role saw after entry.
Research & alignment
The mobile design started from an existing Web permission model
The role permissions were proposed by the product team and reviewed jointly by Product, Design, and Engineering. The Web experience had already implemented the model, so the mobile work did not redefine the underlying roles or permissions.
Before mobile design began, the Marketing team tried the Web experience. We used the existing Web model as the baseline for translating role-based entry into the mobile app.
Design strategy
Turn the permission model into a role-based mobile entry experience
Everyone enters a Workspace in the same way. Once inside, Coordinators see the Workspace overview. Assignees see their assigned work in Spotlight or Gallery, depending on the Workflow Template permission.
The design changes what each role sees inside the Workspace, not where they enter it.
Decision 01
Use permissions and roles to choose the first view
Accounts used either an Internal or Client Portal. Internal Portal users could hold a Coordinator or Assignee role within a Workspace. Client Portal users held the Assignee role.
After entering the Workspace, Coordinators saw the Coordinator view. For Assignees, the Workflow Template permission chose the task view. Spotlight showed the current Action for linear work. Gallery kept the rest of the Workspace visible when order and context mattered.
Decision 02
Design around what each role needs first
Coordinators needed to see progress across the Workspace and know when to step in. Assignees needed enough context to understand their task and a clear way to complete it.
The Workspace role determines the view shown after entry. Each view keeps the status beside the action the user can take.
Final experience
What Coordinators and Assignees see inside a Workspace
The final design has one Coordinator view and two Assignee views. All three use the same Workspace and Action data, arranged around the task each role came to do.
Coordinator
Coordinator checks the Workspace before opening an Action
The Coordinator view shows the Workspace overview. Coordinators can check progress and spot work that may need their attention before opening an individual Action.
Assignee · Spotlight
Focus on the current Action
Spotlight keeps the current Action, its status, and the available control on one screen. It works for tasks that do not require the Assignee to review the rest of the Workspace.
Assignee · Gallery
See the Workspace before choosing an Action
Gallery shows the order and status of every Action. Assignees can see where their work sits in the process before opening the task that needs attention.
Reusable patterns & collaboration
A shared Action pattern across all three views
I defined one Action pattern for content, status, ownership, and controls. The Coordinator view, Spotlight, and Gallery arrange the same pieces differently instead of using separate components.
Product and Mobile Engineering helped check the pattern against permission rules, Action states, and implementation limits. We also designed it so other Workflow objects, including Automation, could use it later.
Impact & reflection
One shared app, with role-based views at the point of work
The final design was reviewed against the existing permission model and implemented across Coordinator and Assignee views. New Flow remained in the same app as V10, and all three views used the same Action pattern.
Evidence boundary
Because no task-completion or time-on-task data was available, the case does not claim efficiency improvements.
What I learned
The hardest mobile decision was deciding what each role needed to see after entering a Workspace. Removing Web features was secondary.
Role-based views gave Assignees a focused view when they needed it and the wider Workspace when they did not.
Next Project