What criteria can be used to segregate data? 

Data can be segregated based on:

• Request Type
• The following HR fields:
  • Country
  • Function
  • Sub-Function
  • Business Area
  • Division
  • Company

HR data listed above is based on the submitter’s HR information at the time the request was last submitted or reassigned to a new submitter.

Can we use HR fields for Data Segregation if we are not sending HR data? 

No, if your organization does not send HR data or does not include a specific HR field, you will not be able to use that field (Country, Function, Sub-Function, Business Area, Division, or Company) to create Data Segregation Policies.

Can policies be automatically assigned to user groups? 

No, policies cannot be automatically assigned based on groups (e.g., all users in the Finance department). After creating and saving a policy, you must manually assign users in the Users tab by searching for and selecting them. If new users should have the same policy, they must be manually added. Once assigned, users will immediately have access to the data and request types defined in the policy.

If a user is assigned multiple Policies, how does it affect their access? 

If a user is assigned multiple policies, their access is additive, meaning they will have access to all data permitted by each policy combined.

For example, if one policy grants access to COI requests from China and another grants access to Engage requests from Canada, the user will be able to see COI and Engage requests from both China and Canada.

Both countries and request types are additive, ensuring that policies do not override each other or act as separate conditions. Instead, they work together to expand the user’s visibility based on the assigned rules.

Why do some users see all request type tabs in the "View All Requests" page, even when a policy restricts request types?

This can happen when a user is assigned multiple policies with the View All Requests privilege, and not all of them include request type restrictions.

If even one of those policies allows access to all request types (by not setting any request type restrictions), the system assumes the user should see all request tabs in the View All Requests page.

However, the user will only see requests in tabs they actually have access to. For restricted tabs, they will see a “No requests” message instead of an Access Denied screen.

Best Practice:

To limit which request tabs a user can see, make sure all policies assigned to that user include the same request type restrictions.

How do Privileges and Policies Work Together?

Access to the "View All Requests" page is determined by both user privileges and assigned policies.

• If a user has the “View All Requests” privilege, their actual visibility will still be limited by the rules in any assigned policy.
• If a user does not have the “View All Requests” privilege, but a policy is assigned to them that grants limited access, the user will still be able to access the page, but will only see the data permitted by the policy.

Summary:

User privileges determine access to the feature, while policies determine access to the data within that feature.

Why am I seeing an error when trying to create or reactivate a policy?

You may encounter this error if your organization has reached the Amazon Verified Permissions (AVP) limit for policy templates.

“Policy creation failed. Amazon Verified Permissions (AVP) has reached its maximum template limit. No new policies can be created until existing policies are removed or deactivated. To resolve this, deactivate unused policies or contact the Lextegrity support team if you have any concerns on this.”

What does this limit include?

The AVP system has a limit of 100 policy templates per tenant. Each privilege rule within a policy counts as one template.

For example:
If a single policy includes 5 privilege rules, it uses 5 of your 100 available templates.

How can I resolve this?

• Deactivate policies that are no longer in use.
• Avoid unnecessary duplication by reusing existing policies where appropriate.

See: How to Edit, Activate/Inactivate, or Delete a Policy

Why do I still see all policies when I use the search bar on the Policy Management page?

The search bar is designed to help you quickly find matching policies by bringing relevant results to the top of the list.

Even when you enter a search term, the full list of policies will still be displayed—but the matching results will always appear first, followed by the rest of the policies in alphabetical order.

How does country-based policy filtering work for ACOI and related COI requests?

Access to Annual Conflict of Interest (ACOI) requests and their related Conflict of Interest (COI) requests is controlled based on the ACOI’s attributes, not each individual COI’s.

Because ACOIs and COIs have a parent-child relationship, visibility into COIs is determined through their connection to the associated ACOI.

Example Scenario:

If a user submitted an ACOI request in Country A, and that ACOI has three related COIs submitted in Countries A, B, and C:

The user will only see the ACOI and related COIs if they have a policy granting access to Country A.

If they do have access to Country A, they will be able to see the entire ACOI request, including all related COIs, even if some of those COIs were submitted under different countries.