Looking to see what the max number of classifications IIQ will allow? I have been advised that if too many classifications are used it could affect the performance of IIQ, wondering what the tipping point is for classifications. Looking to tag a few thousand of entitlements and wanting to know if classifications is the best approach.
@langn -
No hard limit: According to SailPoint’s official documentation, there is no fixed maximum number of classification labels that can be defined or assigned. IdentityIQ 8.1 introduced classifications (tags on roles/entitlements to flag sensitive access) and explicitly notes that “There is no limit to the number of Classifications that Roles and Entitlements can reference.” In other words, you can create and use as many classification categories as needed; IdentityIQ does not impose an official numeric cap.
Practical considerations: Even without a hard limit, it’s wise to keep the number of classification categories reasonable. Classifications are meant to highlight important attributes (e.g. High Risk, Sensitive Data, etc.), so having an excessive number of categories could be unwieldy to manage and diminish their usefulness. SailPoint’s design assumes classifications are relatively few, broad categories for risk or sensitivity marking, rather than a unique tag for every entitlement. In practice, organizations often use a handful of classification values (for example, a few levels of data sensitivity or access criticality). While you could define dozens, using too many may complicate administration and user understanding, even if the software can technically handle it.
Classification overhead: Attaching classifications to thousands of entitlements does introduce some overhead in IdentityIQ. Each classification on an entitlement is stored as a relationship (via an intermediary “ObjectClassification” object) . When you have very large numbers of entitlements tagged, certain operations need to process those classification links, which can affect performance. For example, IdentityIQ can display classification icons in access request screens, approvals, or certification reviews to warn of sensitive access. This means additional lookups or joins to retrieve classification info for each entitlement shown. In reports, SailPoint explicitly warns that including classifications can slow things down: “Including classifications in the Identity Entitlements Detail Report can impact performance.” (Identity Entitlements Detail Report) By default that report shows classification data for each entitlement, but you have the option to omit it to improve speed. This illustrates that fetching and rendering classification metadata across many items adds processing time.
Certifications and UI: The performance impact is most noticeable in entitlement-heavy processes like certifications and search. SailPoint notes that “the main issues with large entitlements are the processing burden they place on the IdentityIQ system during certifications” (Best practices for working with a large entitlement catalog in IdentityIQ). If you include thousands of entitlements (each potentially with classification tags) in an access review campaign, the system must load and display all those items and their classification icons. This can translate to longer page load times and heavier memory usage during certifications or when generating certification data. In extreme cases (tens of thousands of items), reviewers might experience slower interface performance. For this reason, IdentityIQ provides configuration options: for instance, you can globally disable showing classifications in certifications by default to reduce overhead (Working with Classifications in IdentityIQ), enabling it only when necessary.
Effective access indexing: IdentityIQ’s backend handles classifications in ways that can affect performance. There is a task option to “Index classifications,” which adds an entitlement’s classifications to each identity’s entitlement data when building effective access indexes (Effective Access Indexing). This ensures that if an entitlement is inherited indirectly (say via a role or nested group), its classification propagates to the user’s access list. However, indexing classifications means more data to write and store for each identity entitlement record. Similarly, the “Promote classifications” option will copy a child entitlement’s classification up to parent entitlements in a hierarchy (Effective Access Indexing). These features are useful for visibility, but they also mean additional processing during aggregation or refresh tasks. In environments with thousands of entitlements, turning on these options will increase task runtimes proportionally. It’s not inherently “bad” to do so – IdentityIQ is designed to scale to millions of entitlements (SailPoint Supports World’s Largest Identity Governance Deployments | Business Wire) – but administrators should be aware of the extra work involved.
Search and UI filtering: Using many classifications can also slightly impact search performance. IdentityIQ allows you to filter entitlements by classification in the Entitlement Catalog UI or Advanced Analytics searches (Working with Classifications in IdentityIQ) (Working with Classifications in IdentityIQ). Internally, this means queries have to join the entitlements with their classification table. With proper indexing this is efficient, but if you had, say, 50,000 entitlements tagged with one or more of 100 different classifications, the search has to sift through a large volume of tag records. Ensuring your database has adequate indexing on classification references (which IdentityIQ should handle out of the box) and that queries are tuned is important. In summary, using classifications as intended (for a subset of important entitlements) has minimal performance impact, but tagging every entitlement or using an excessive number of distinct classification labels can introduce extra load during reporting, certifications, and searches.
Managing thousands of entitlements in an IdentityIQ deployment requires careful planning to maintain performance and usability. SailPoint’s guidance for large entitlement catalogs highlights several best practices:
Clean up and rationalize data: “Cleanse the data on managed systems before aggregating.” In other words, if an application or source has obsolete or unused entitlements (permissions, groups, roles, etc.), try to remove or archive them at the source before pulling them into IdentityIQ. The fewer irrelevant items you aggregate, the less clutter and overhead in the product. Reducing noise up front will make everything from search to certifications more efficient.
Focus on what matters (avoid review fatigue): Not every entitlement needs to be exposed to end-users or included in every certification. Identify which entitlements are high-risk or require oversight and which are low-impact. SailPoint advises asking “what really needs to be certified?” and notes that not all entitlements must be reviewed in every campaign (Best practices for working with a large entitlement catalog in IdentityIQ). For example, you might exclude low-sensitivity “birthright” entitlements from a manager certification and handle them via an automated policy instead. Using IdentityIQ’s targeting features, you can include or exclude entitlements in certifications based on criteria (application, classification, etc.). This reduces the workload on both the system and the reviewers – a smaller, more relevant review set improves performance and governance outcomes.
Use requestability and scopes: In the Entitlement Catalog, you can mark entitlements as requestable or not. A best practice is to set rarely-used or technical entitlements as unrequestable (so they don’t appear for end-user access requests) (Edit Entitlements in bulk? : r/sailpoint - Reddit). This streamlines the access request UI by exposing only the entitlements that a user might logically request. It doesn’t directly impact backend performance much, but it improves user experience and indirectly reduces load (fewer items for the UI to handle in dropdowns/search results). Similarly, leverage scoping to partition entitlements if your IdentityIQ instance is segmented – e.g. an admin of one business unit only sees their unit’s entitlements.
Role-based grouping: Consider grouping entitlements into roles or access profiles to reduce the direct management of individual entitlements. IdentityIQ roles (particularly IT roles or application roles) allow you to bundle multiple entitlements together as a single assignable unit. A user requests or is assigned the role, and behind the scenes they get the collection of entitlements. This has two benefits: (1) It makes life easier for users and approvers (they handle one role instead of 10 entitlements) and (2) it cuts down the number of individual entitlements being processed in certifications or requests. The system might certify “Sales App Read-Only Role” (which contains 50 entitlements) as a single item, rather than listing all 50 entitlements separately for each user. Standard roles in IdentityIQ are explicitly meant to “group access from entitlements… and provision the access based on assignment criteria.” (Managing Roles - SailPoint Identity Services) By using roles to abstract large entitlement sets, you effectively manage entitlements more efficiently at scale. (Keep in mind that defining good roles requires analysis – group entitlements that are commonly assigned together and have a clear business function.)
Entitlement catalog tuning: Ensure your entitlement catalog configuration is tuned for scale. For very large applications (say an app with tens of thousands of entitlements), you might need to adjust the entitlement search settings or use delta aggregation to gradually sync changes (Entitlement List - SailPoint Developer Community) rather than full refreshes frequently. Also, monitor your database indexes – IdentityIQ relies on the DB to quickly fetch entitlements by name, application, classification, etc. Rebuilding indexes or adding custom ones (with SailPoint’s guidance) for any custom attributes can help performance.
Test and monitor: In a large deployment, always test how changes impact performance. If you plan to tag a huge number of entitlements with classifications or add a bunch of new extended attributes, try it in a lower environment first and measure the impact on task runtimes (aggregation, identity refresh, certification generation) and UI response. SailPoint’s benchmark tests have shown IdentityIQ can handle “millions of accounts and more than 10 million entitlements” in extreme scenarios (SailPoint Supports World’s Largest Identity Governance Deployments | Business Wire), but real-world performance will depend on hardware and configuration. Regularly monitor logs and use IdentityIQ’s Health & Diagnostics utilities to catch any slow queries or memory issues related to entitlements.
In summary, keeping your entitlement catalog lean and organized is key: remove what you don’t need, group what you can, and highlight what’s important. This minimizes the performance impact of having a large number of entitlements.
If you find that classifications are not the optimal method for your use case (for example, you need to tag thousands of entitlements with various labels and worry about the overhead), there are alternative ways to organize and enrich entitlements in IdentityIQ:
Extended Entitlement Attributes: IdentityIQ allows you to create custom extended attributes on entitlements (as well as on roles, identities, etc.). An extended attribute is essentially a custom field you define – for instance, you could add an attribute like “Category,” “Business Owner,” or “Risk Level” to entitlements. Extended attributes are flexible: you define the field name, data type, and even provide a set of allowed values. Once created and marked as searchable, these fields can be used to filter and find entitlements throughout the product (How to Add or Edit Extended Entitlement Attributes). Using extended attributes can achieve a similar goal as classifications (labeling entitlements with extra info) without the exact same overhead. The data is stored directly on the entitlement object (ManagedAttribute) rather than as a separate linked object, which can be simpler in some cases. For example, instead of using classifications to denote data sensitivity, you might add an extended boolean attribute “PII_Data” or a string attribute “DataSensitivity=High/Medium/Low” on entitlements. In certifications or reports, you could then include this field to inform reviewers. One SailPoint best-practice guide notes that “in IdentityIQ, you can use classifications or extended attributes to flag entitlements or roles that are especially high-risk items” (Best practices: Avoiding certification fatigue - Compass) – meaning extended attributes are an equally valid approach to tagging. The advantage of extended attributes is scalability and customization: you can have multiple different attributes for different purposes (whereas classifications is one set of tags), and they integrate with IdentityIQ’s search/indexing if configured. Just be sure to mark them as Searchable when configuring, so that the system indexes them for queries (How to Add or Edit Extended Entitlement Attributes).
Naming conventions and metadata: Sometimes the organization of entitlements can be improved by how they’re named and described. This isn’t a technical feature per se, but using a consistent naming scheme for entitlements can serve as an implicit categorization. For instance, prefix entitlements with a category code (e.g., “SAP_FIN_*” for finance-related SAP permissions). This makes it easier to search by name and identify groups of entitlements by eye. It also avoids needing a separate tag in some cases. Along with naming, ensure the entitlement descriptions are filled out meaningfully (IdentityIQ supports descriptions for entitlements). Good descriptions improve the searchability and understanding of entitlements for both administrators and business users. (There is a note that entitlement description fields have a size limit of 2000 characters in newer versions (Enhancement: Entitlements Service - SailPoint Developer Community), so keep them concise but informative.)
Application and attribute hierarchy: Organize entitlements by application and by entitlement type where possible. IdentityIQ’s data model groups entitlements under their source application and the specific attribute on that application. For example, in Active Directory you might have entitlements under the “Group” attribute vs. “Role” attribute. In databases, you might have “Role” vs “Profile” entitlements on the same source. By splitting one physical system into multiple logical applications or account schemas in IdentityIQ (if applicable), you can partition entitlements into more manageable sets. Each application in IdentityIQ will have its own Entitlement Catalog. If a single application connector is pulling in an extremely large number of entitlements of different types, consider if they can be split. (This is not always applicable, but in some cases an IIQ “application” can be configured to only pull a subset of entitlements – e.g., one app for AD Security Groups, another for Distribution Lists, instead of one app with both.)
Use Roles or Access Profiles for logical grouping: As mentioned, roles can bundle entitlements, which not only helps with assignment but also with organizing the entitlements. You might create roles corresponding to functional access packages. In the Entitlement Catalog, you could then focus on managing roles at a higher level while the raw entitlements are managed by IT. Additionally, IdentityIQ’s Advanced Analytics and reporting let you query “Which roles contain this entitlement” and “Which entitlements are in this role,” giving you a way to navigate the entitlement space more logically. (IdentityIQ does not have a direct concept of “entitlement categories” out-of-the-box besides classifications, so roles can serve as one way to categorize by grouping entitlements that belong to a common function or application module.)
Use populations or queries for virtual grouping: IdentityIQ’s Advanced Analytics or Population queries can also be used to virtually group entitlements without permanently tagging them. For instance, you could create a query that finds all entitlements matching certain criteria (by name pattern, by extended attribute value, by application, etc.). While this is more for analysis and reporting, it can help you manage and review subsets of entitlements on the fly. It doesn’t affect performance directly, but it aids searchability – administrators can quickly pull up “all entitlements of type X” with a saved query rather than scrolling through thousands of catalog entries.
Summary of classification vs alternatives: If your goal is to label entitlements for risk or compliance purposes, classifications are the built-in feature to do that, and they integrate nicely with the UI (showing an icon next to sensitive entitlements) and certification filters. They are best used sparingly for broad flags (e.g. “Confidential Data” access). If you find you need a more granular or extensive tagging system (many categories or data points per entitlement), extended attributes are a robust alternative – you can add multiple custom fields to entitlements and make them searchable and reportable. Extended attributes won’t automatically show an icon in the UI, but you can still surface their values in reports or even customize the interface if needed. In terms of performance, a simple extended attribute (especially one that’s indexed) is very lightweight – essentially just an extra column in the entitlement table – whereas classifications entail maintaining a many-to-many mapping under the hood. For large-scale usage (thousands of entitlements with tags), extended attributes may scale more cleanly.
Finally, consider combining approaches: use classifications for the most critical flag (e.g. a binary “Sensitive” vs “Non-sensitive” classification), and use extended attributes for secondary categorizations (like functional area, data domain, etc.). This way you get the benefit of the built-in sensitive-data warnings without trying to force-fit too much meaning into the classification feature. Always align whichever method you use with your governance processes – e.g. if the aim is to make certifications easier, ensure your tagging (classification or otherwise) ties into how you scope and display certification items. By following these practices, you can efficiently manage a large number of entitlements in IdentityIQ with minimal performance impact and maximum clarity for users.
Hope this helps.
Hi @langn
I’ve used classifications before but I had 5 values. What king of classification you have in mind?
Tagging 100 of 1000 of entitlements is fine, this is not the limit that Sailpoint is mentioning, it’s the number of classification levels that should be kept reasonably small.
Regards
Alek
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.