Access levels and license types

[SamanthaSi5]

I only just realized that when license types changed to Standard/Light/Contributor/External many of our user's access levels changed to those default types as well. Prior to the change we had a lot of custom access levels set for various user groups, but it seems like those are no longer relevant. Are access levels and licences essentially the same thing now? Has anyone else experienced this?

Secondly, we want the bulk of our users to only have access to projects that they are involved with, but in my discussions with Workfront support it seems like the only way to do that is to grant them access to projects on an individual basis (see below). Does anyone know a way around this? We ideally by default only want users to be able to view their projects in the system and nothing else. 

Thank you!

Workfront support response: 

By default, Workfront access levels apply broadly, which means users with “View” access can potentially see all projects and documents. If you'd like users to only see the specific items they’re involved in (such as projects they’ve submitted or proofs they’ve been added to), here’s how you can set that up:

Recommended Approach:
Limit Default Access
Set the user's access level for Projects and Documents to “No Access” or “View” (if minimal visibility is acceptable).

Use Permissions for Specific Access
Grant access to individual projects or proofs by:

Adding the user to a project team

Assigning them a task

Including them in a proof workflow

Letting them submit a request

These actions will automatically give them the appropriate access to those specific items.

Project Settings
Ensure that your project settings are configured so that only invited users can access them. This helps prevent broad visibility.

Optional: Bulk Share or Use Templates
For existing items, you can bulk-share access. For new projects, consider using templates to share with the right users automatically.

[Lyndsy-Denk]

I won't speak to access levels because we're still on legacy, but I can add thoughts on your project-level access question. As support says, there is a Venn diagram of settings for you to consider. To be clear, Workfront does automatically share an object if the user is somehow associated with the object, such as:

• The user creates the object (for example, submits a request)
• Is assigned to a task or request
• Is added as a sponsor, resource manager, or user in the People area

Anyone else needs to be added manually to the Share are of the object.

Where you have additional control is in:

1. Project settings > Access is probably your primary driver for automating limited access and how. I strongly recommend requiring the use of templates to ensure these automations are applied (instead of leaving it up to project owners to repeatedly have to configure). For example, I have a template that I use to jump start building a request queue. To control access, I set the Access settings rather differently for request queues than regular projects (see attached).
2. Portfolios and Programs cascade sharing permissions. Consequently, if they have no share permissions set, nothing will cascade. (Of course, make sure they're shared just enough so that the right people can file projects into those spaces.) Note that, because sharing cascades portfolio-to-program-to-project, you can tell any of the sub-objects to not inherit permissions. We strip sharing permissions from a program if the work filed within is of sensitive information. Example: Press releases, early work on a product launch.
3. Yes, for many of our generic, low access users, they don't usually have much visibility into the project. It's the proof they're looking for. Most of these folks don't know how to dig for projects in the system anyway. Lack of knowledge is sometimes part of the security plan.

[KatherineLa]

Hi there,

You've got two different concepts in your question, I'll start with the License Types versus Access Levels one first, it's a little easier. 

In "old" Workfront, we had 5 License Types (Plan, Work, Reviewer, Requestor and External). In the new structure, that's collapsed to 4 (Standard, Light, Contributor, External). It's not a 100% perfect mapping, but I think of it as if Plan/Work collapsed into Standard, Light is unique and focuses mostly on approvals and then the old Reviewer/Requestor mostly collapsed into Contributor. 

As instance admins, we take those license types and create Access Levels from there, to further sub-divide those features into role-appropriate abilities for our users. When I'm explaining these to folks, I explain them as something like your drivers license. They govern the core features that can be accessed at all, much like my drivers license says I can drive a passenger vehicle or a motorcycle, but wouldn't allow me to drive a semi or a school bus. We've got 15 of those, though they all map to one of the 4 license types. 

What might look confusing is that when the switch happened, you also suddenly had new Access Levels that did match those new License Types. Honestly, I promptly removed them from our instance, I don't want the clutter. My old ones are just fine. Each Access Level then maps to one of the License Types. I attached a screenshot here showing a few of ours. 

If you want to double-check that the new, possibly unwanted, access levels aren't in-use, you could go into the User page and group by 'Access Level'. Check to see that nobody is assigned the extra ones, and then remove them. Alternately, you could keep them around but just mark them as Do Not Use, or Sample Level so you could look at them easily in the future. 

The next part is about record-level security, and I'll answer that in a separate response. That continues the silly drivers-license analogy part.