Controlling access to requests

You can define access to requests so that the details of certain requests are not disclosed to a particular group of users.

For example, if you use AR System as the outsource help desk for several companies, you can assign access to requests so that only the company that submitted the request can see it.

Related topics

Assigning-permissions-to-access-objects-and-requests

Creating-users-groups-and-roles

Define the groups or roles that have access to a request through the Request ID field (field ID 1). If a group or role does not have access to that field, the group or role has no access to the request, even if it has access to other fields in that form.

You can grant access to members of explicit groups or roles. For example, you can give managers access to all requests. You can also grant access to members of implicit groups.

For example, submitters can see their own requests but not those submitted by other users. For more information, see Controlling-access-to-requests-by-using-implicit-groups-Row-level-security.

The following figure lists the questions that you can ask to determine the access that users have to requests in AR System.

 Accessing requests
221_controlling access to requests.png

Action

Reference

Understand how limited access to requests on a per-group or per-user basis works by using row-level security.

Control access to requests at a user level and group level by using the request ID field with implicit groups.

See examples to understand how to set up permissions by using Assignee Group access and dynamic group access to provide conditional access to requests.

Understand how to configure parameters to control access to hierarchical groups. 

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*