Summary and recommendation
Workfront user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Workfront user management runs through Setup > Users > Users, accessible to System Administrators and Plan-license users who have been granted administrative access to Users.
Adding a user requires First Name, Last Name, Email Address, and an Access Level - the license type is inferred from the Access Level selected, not set as a separate field.
New accounts are active immediately;
there is no draft or pending state, so provisioning should only be triggered when access is genuinely needed.
Workfront uses a three-layer permission model: license type sets the ceiling, access level defines actual capabilities within that ceiling, and object-level sharing (View / Contribute / Manage) controls per-record access.
Administrators can only assign access levels at or below their own license tier, which limits delegation risk but requires planning when onboarding admins across groups.
Quick facts
| Admin console path | Main Menu > Setup > Users > Users |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| System Administrator | Full access to all Setup areas, all objects, and all users. Can manage licenses, access levels, and system configuration. | Consumes a Plan license | System Administrator access level bypasses all object-level sharing restrictions. Assign sparingly. | ||
| Plan (license type) | Can create and manage projects, tasks, issues, reports, dashboards, portfolios, and programs. Can be granted administrative access to specific areas (users, teams, groups, etc.) by a System Administrator. | Cannot access Setup unless granted administrative privileges by a System Administrator. | Highest-tier paid license; custom pricing | Plan license users can be granted partial admin rights (e.g., manage users or billing) without full System Administrator access. | |
| Work (license type) | Can work on tasks and issues, log time, upload documents, and update objects they have access to. Cannot create projects by default. | Cannot create portfolios, programs, or reports by default. Cannot access Setup. | Mid-tier paid license; custom pricing | Access level assigned to the user further restricts what a Work license holder can do beyond the license ceiling. | |
| Review (license type) | Can view and comment on objects. Can approve work. Cannot create or edit most objects. | Cannot create tasks, projects, or issues. Cannot log time. | Lower-tier paid license; custom pricing | Primarily intended for stakeholders who need visibility and approval capability only. | |
| Request (license type) | Can submit requests via the Requests area. Can view their own submitted requests. | Cannot access projects, tasks, reports, or most other objects. | Lowest-tier paid license; custom pricing | Very limited scope; suitable only for external requestors or occasional submitters. | |
| External User (license type) | Can view documents shared with them via a public link. No login to Workfront required. | Cannot log in to Workfront. Cannot access any internal objects. | Free; does not consume a paid license seat | External users are not created as named users in the system; they access content only via shared links. |
Permission model
- Model type: hybrid
- Description: Workfront uses a two-layer model. The first layer is a license type (Plan, Work, Review, Request) that sets the ceiling of what a user can do. The second layer is an access level (a named configuration assigned to the user) that defines actual permissions within that ceiling. Access levels are role-based templates that administrators create and assign. Object-level sharing provides a third, granular layer: individual objects (projects, tasks, portfolios, etc.) can be shared with specific users or teams at View, Contribute, or Manage permission levels.
- Custom roles: Yes
- Custom roles plan: Not documented
- Granularity: Administrators can create custom access levels based on built-in license types, toggling on/off capabilities such as Create, Edit, Delete, View for each object type. Object sharing further refines access per record.
How to add users
- Log in as a System Administrator or a Plan-license user with administrative access to Users.
- Click the Main Menu icon, then click Setup.
- In the left panel, click Users > Users.
- Click New User (or Add Multiple Users for bulk entry).
- Enter the required fields: First Name, Last Name, Email Address, Access Level, and License Type.
- Optionally configure Home Group, Home Team, Job Role, Manager, and custom form data.
- Click Add This User (or Save) to create the account.
- The user receives an email invitation to set their password and log in (unless SSO is enforced).
Required fields: First Name, Last Name, Email Address, Access Level
Watch out for:
- Email address must be unique across the Workfront instance; duplicate emails are rejected.
- If SSO is enforced, the user's email must match their IdP identity exactly or login will fail.
- A user's license type is determined by the access level selected, not set independently in the UI.
- New users are active immediately upon creation; there is no draft or pending state.
- Administrators can only assign access levels at or below their own license type.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Yes | Setup > Users > Users > Import Users (uploads a .xlsx or .csv file using Workfront's provided template) |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Requires SSO configuration (SAML 2.0); auto-provisioning creates Workfront accounts on first SSO login when enabled. Not SCIM-based. |
How to remove or deactivate users
- Can delete users: Verify in tenant
- Delete/deactivate behavior: This app exposes delete operations in its API documentation, but the admin-console path may present removal as deactivation, archiving, or deletion depending on tenant configuration. Confirm whether the UI action is reversible before treating removal as recoverable.
- Log in as a System Administrator or a Plan-license user with administrative access to Users.
- Click the Main Menu icon, then click Setup.
- In the left panel, click Users > Users.
- Locate the user in the list (use search or filters as needed).
- Select the checkbox next to the user's name.
- Click the More menu (three-dot icon) or the Actions menu, then click Deactivate.
- Confirm the deactivation in the dialog that appears.
- The user's status changes to Inactive and they are immediately unable to log in.
| Data impact | Behavior |
|---|---|
| Owned records | All objects (projects, tasks, issues, documents, reports) previously owned or assigned to the deactivated user remain in the system and retain their associations. Ownership is not automatically transferred. |
| Shared content | Shared content remains accessible to other users who had access. The deactivated user's name continues to appear in historical records, comments, and audit logs. |
| Integrations | API tokens and session tokens for the deactivated user are invalidated. Any integrations or automations authenticating as that user will stop functioning. |
| License freed | Deactivating a user frees their license seat, making it available for reassignment to a new active user. |
Watch out for:
- Deactivated users still appear in user lists and reports unless filters are applied to exclude inactive users.
- If a deactivated user is the sole approver on a pending approval, the approval process may stall; reassign approvals before deactivating.
- Scheduled reports or notifications set to deliver to the deactivated user will stop delivering but are not automatically reassigned.
- Reactivating a user restores their access level and group memberships as previously configured.
- Users who have never logged in or have no work associations may have a delete option available, but this is not documented for users with any work history.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Plan | Full project management capabilities, reporting, portfolio management, and optional administrative privileges. | Custom pricing; highest per-seat cost tier |
| Work | Task and issue execution, time logging, document management, and collaboration on assigned work. | Custom pricing; mid-tier per-seat cost |
| Review | Viewing, commenting, and approving work items. | Custom pricing; lower per-seat cost |
| Request | Submitting and tracking requests via the Requests queue only. | Custom pricing; lowest per-seat cost |
- Where to check usage: Setup > System > Licenses - displays total purchased licenses per type, currently active (used) licenses, and remaining available licenses.
- How to identify unused seats: In Setup > System > Licenses, the license summary shows active vs. purchased counts per license type. Administrators can also run a user report filtered by Last Login Date to identify users who have not logged in recently, then cross-reference with license type to find candidates for deactivation.
- Billing notes: Workfront is sold under Adobe enterprise agreements with custom pricing. License counts and costs are negotiated per contract. Deactivating users frees seats within the contracted license pool but does not automatically reduce billing; contract terms govern seat minimums and true-up schedules.
The cost of manual management
Every app that relies on manual provisioning carries a hidden coordination cost, and Workfront compounds it in two ways. First, deactivating a user does not automatically reassign their open tasks, pending approvals, or scheduled reports - each must be cleaned up manually before or after deactivation, or approval workflows stall.
Second, identifying inactive accounts requires running a separate user report filtered by Last Login Date and cross-referencing it against the license summary in Setup > System > Licenses, because the license screen itself shows only aggregate counts, not per-user activity.
Bulk imports via CSV require Workfront's specific template format; importing a custom-formatted spreadsheet produces errors without clear field-mapping guidance, adding friction to any high-volume onboarding.
Auto-provisioning via SAML SSO reduces manual steps but requires a correctly pre-configured default access level - if that default is wrong, every JIT-provisioned user lands with incorrect permissions on first login.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Manual management in Workfront is workable for organizations with low user churn and a small administrator team, provided access level templates are defined and validated before any provisioning begins. The three-layer permission model (license → access level → object sharing) gives precise control but demands upfront governance work;
without documented access level standards, every app in the portfolio risks inconsistent permission assignments over time.
For organizations with frequent onboarding or offboarding, the absence of native SCIM and the manual cleanup required around deactivation create compounding overhead. SAML-based JIT provisioning reduces creation effort but does not handle deactivation or access level changes - those still require manual action or API automation.
Teams should weigh whether the deactivation cleanup burden justifies investing in API-based lifecycle management before committing to a purely manual workflow.
Bottom line
Workfront's manual user management is precise but operationally demanding.
The license-from-access-level inference, the absence of automatic task and approval reassignment on deactivation, and the aggregate-only license usage screen all require administrators to build compensating processes - documented access level templates, pre-deactivation checklists, and regular inactive-user audits via custom reports.
For low-volume environments with stable teams, these processes are manageable. For organizations running frequent workforce changes across every app in their stack, the manual overhead accumulates quickly and the case for API-driven automation becomes difficult to ignore.
Automate Workfront workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
