The Status That Multiplied
Northwind Health has a single Workfront instance shared by three groups: Marketing (60 users, 90 active projects), Clinical Operations (140 users, 310 projects), and Facilities (35 users, 25 projects). Marketing wants a project status called 'Awaiting Legal' that only its group can see, because 15 to 20 projects per month wait on legal review. The other groups do not want their status picklists polluted. Marketing also wants the status to drive a dashboard tile and a report prompt, and it wants projects to keep the status if ownership changes to Clinical Operations. The system administrator must decide whether to create a system-level status or a group-level status, how to protect existing reports, and what happens when a project is reassigned. The instance already uses four global statuses and a custom 'Review Stage' field.
1. Recommend whether to create a system-level status or a group-level status, and explain the tradeoffs for Marketing, Clinical Operations, and reporting.
Read the worked answer
Create a group-level status scoped to Marketing, not a system status. Marketing's need is local: only 60 users and about 90 projects, and Clinical Operations explicitly does not want its picklist changed. A system status would solve visibility but impose a new option on 175 users in the other two groups and would appear in global prompts. A group status keeps the picklist clean and lets Marketing use 'Awaiting Legal' on its projects.
The tradeoff is reporting and portability. Group statuses should be mapped to a status category ('Equates With') so reports and dashboards can use the category rather than the label. Build the dashboard tile and report prompt on the category or on a dedicated custom field, not on the label. Do not promise that the status survives a group change: if the project moves to Clinical Operations, the status may become invalid or be remapped. If legal review must persist across groups, add a 'Legal Review' custom field and treat the status as a Marketing-only workflow signal.
2. How should the administrator implement the status so the dashboard and report prompt work for all viewers without exposing Marketing's status to other groups?
Read the worked answer
Implement the status with a carefully chosen status category, then avoid label-based reporting. The dashboard tile should filter on the category and on the Marketing group, not on the literal text 'Awaiting Legal.' The report prompt should be built on the custom 'Review Stage' field or another field that all groups can see, with a fixed status-category filter behind it. If the prompt is built on status labels, users may see only statuses available to their group, or they may see labels they cannot apply, which creates confusion.
Also check report sharing and run-as settings. The dashboard should be shared with the groups that need it, and the report should run with the viewer's access unless there is a deliberate reason to use the report owner's access. Test with a Marketing user, a Clinical Operations user, and a Facilities user to confirm that the prompt behaves predictably and that no one sees 'Awaiting Legal' unless Marketing owns the project.
3. A Marketing project with the new status is reassigned to Clinical Operations. What happens, what data risk exists, and what would you do?
Read the worked answer
Expect the status to become invalid on the Clinical Operations project because the group-level status is not available to that group. Workfront may remap it to a default status or leave it in a state that Clinical Operations cannot select. Reports that filter on the literal label may drop the project or show a blank status. The custom 'Review Stage' field and other custom data should remain, which is why the cross-group signal should live in that field rather than only in the status.
Before reassignment, confirm whether legal review is still relevant. If it is, copy the state into a group-neutral custom field and set the project to a Clinical Operations status. Update any reports that used the Marketing label to filter on the custom field and the status category. If the status must be retained for audit, document the old value in a field or an update, because the status picklist itself is not a reliable cross-group archive.