Does anyone have any recommendations or best practices naming thousands of access profiles for a single application, so end-users are able to find what they need?
We have an application with over 6K access profiles (companywide app and access profiles are a combination of teams, environments and permission sets) and we’re struggling to narrow down simple searches for access profiles in the Request Center.
We made the effort of having “human friendly” AP names and descriptions, as they will be used by non-tech people, but we also needed to standardize them, so we were able to script their creation. That may have introduced too many common words, but we’re running out of ideas on how to balance human language and query based in keywords.
Also, using quotes to denote exact matches don’t seem to work either.
I searched for ideas for improvement to the Request Center, and I couldn’t find anything related that I could upvote, so I’m coming here to ask for advice/experiences on how to deal with this.
The documentation linked by @naveenkarthikkrk absolutely covers the important points in figuring out the right naming convention.
You’ll also need to take your own organization’s structure and access into account as you plan your standards. Without a lot of background into your app structure, it will be a little difficult to recommend one, but here is an example template:
AP - < App Name > - < Department/Division Name > - < Access Alias >
Here, “AP” is just indicative for ‘Access Profile’ and optional. To keep it unambiguous as to what it is, you can have the prefix.
The next one is to narrow down what app we’re searching. If you have a ton of apps, and each app has a ton of access profiles, it only helps to have a naming convention that can kinda go from broad scope to narrower. Plus it gives the end users an easy to follow, intuitive flow.
The next part could be how you divide the app further. Is access specific to departments or divisions? Perhaps go with that.
Finally the access alias: This part can be subjective and further be subdivided, but your organization may have a few entitlements grouped together (which is why you have the access profile) often, and you can contextually name what that access is for in this part of the access profile name.
Does that convention work for you? You may also need to take into account how you’ve been naming entitlements, roles, certifications, rules and transforms. It’s nice to keep it consistent (as much as possible) with the convention you’re following so far.
Thanks Naveen and Sushant. We already have a naming convention following a similar approach: “Client environment permissionSet” and all of these access profiles are nested under applications we configured as a catalog item for each system (e.g.: Snowflake, AWS, Google, Salesforce, and so on).
We 200+ systems to connect and over 500 client spaces to configure for at least 2 or 3 environments and several tens of permissions per environment, so our challenge is how we can offer a user experience in our Request Center that isn’t so daunting to non-tech people who get presented with a catalog of ~200 apps and some already contain thousands of access profiles they need to filter out to find what they’re searching for.
We tested the “segments” to reduce the number of items they will see, but we risk to hide things that they may need on a temporary basis.
We’re building roles to capture a sort of baseline for their accesses, expecting that the Request Center would remove those accesses from their view, but the access profiles already assigned are still listed in the catalog, so we’re trying to at least find a “keyword system” to make easier to find what people are looking for… so far unsuccessful.
I hope that helps to clarify why we’re looking to hear other customers experience with similar challenges, to hopefully learn how to onboard such big catalogs while we still implement least privilege access as we go.