Exercise 03: Defining User Access
From AgileApps Support Wiki
Introduction
What is a User?
- An AgileApps User is a person who can:
- Access the platform
- Run applications
- View or modify data, as specified by the Userâs privileges
- When an Administrator adds a User to the Tenant:
- A record is added to the database (the Users Object)
- An AgileApps User is a person who can:
Create a User - Overview
To create a User, an Administrator must provide:
- An Access Profile for the User
- Access Profile defines the operations that a user can perform on a Tenant
- A Primary Team for the User to belong to
- A Team determines which records are visible to Users on the Team
- A Team determines which data is shared with other Users
- A User can belong to more than one Team
- The Initial Application that the User will see on login
- A User can (later) have access to multiple applications
- The Userâs Application Role(s) in the (Initial) Application
- A User can have multiple Application Roles in an application
- An Application Role determines the Userâs ability to view and modify application data
- An Access Profile for the User
Access Profiles
- An Access Profile is a way to group permissions together and easily apply them to many Users across the Tenant
- Defines administrative privileges
- Can specify IP Address login location
- Global record permissions that apply to all Objects in all applications
- Administrative Permissions (all or subset of)
- Three pre-built (system) Access Profiles :
- Administrator
- Regular User
- Portal User Profile
- An Access Profile is a way to group permissions together and easily apply them to many Users across the Tenant
Teams
- Teams are collections of Users (or Teams) that work together and share data
- Two predefined Teams for a Tenant:
- MyTeam (when you create a Tenant, you were added to this Team by default)
- Portal Users and Customers (for external customers of the Service Desk application)
- Hierarchical structure to facilitate data sharing
- A Child Team takes on the permissions of its Parent Team
- Team Data Sharing Policies can be created to manage data visibility between Teams (New Policy button)
- Only Users with the User Management permission (allowed by their Access Profile) can manage Teams
Principle: Every record belongs to a Team
- Example: if there is an âEastCoastâ Team and a âWestCoastâ Team
- Each Team uses the same Objects, in the same application
- But each Team works on a completely different set of records
- Initial Team ownership is that of the Team member who created the record
- Example: if there is an âEastCoastâ Team and a âWestCoastâ Team
Sharing Data with Other Teams
- Team Data Sharing Policies allow to see records owned by other Teams
- Define one or more Team Data Sharing Policies, each of Sharing type:
- One-Way Sharing - Team âAâ sees Team âBââs records, but not vice versa
- Two-Way Sharing - Teams âAâ and âBâ see each othersâ records
- Sharing Mashup - Multiple Teams specified, all can see each othersâ records
- Option Include Child Teams: Child Teams are automatically covered by the policy
- Option Grant to Specific Role: Restrict the policy to a specific Application Role in the target Team
- For each policy, specify view, update, and delete permissions for one or more Objects
Initial Application
- Every Tenant has the default Service Desk application
- Administrators/developers can create other applications
- Default initial application comes from your Company Settings, but you can change it when creating a new User
- What the User sees:
Application Roles
- Define Application Roles that match your organization's operations
- If you have Sales Representatives in your organization, then create an Application Role named âSales Repâ
- Two Application Roles were created by the System: Agent and Manager
- Application Roles determine:
- The records a User can access
- The actions a User can take on those records
- Applies to all records in an Object
- For each Application Role:
- Specify create and delete permissions for each application Object on the Tenant
- Specify view, update, delete permissions for records owned by others inthe Userâs Team
- For each User
- A User can have different Application Roles for different applications
- A User has one or more Application Role(s) in a single application
- If multiple Roles in a single application, the User chooses which Application Role is in force at any given timeďż˝(requires for âSwitch User Rolesâ enabled in Company Information)
- Define Application Roles that match your organization's operations
Custom Access Criteria
- An alternative to Application Roles
- For record-by-record permissions based on conditional expressions
- Use to define sophisticated, data-level security
- For example, all records with Amount > $500 visible only to a senior role
- For each action (add, update, delete, list view, record view) click Edit to define a conditional expression
- For a User, the action is allowed when the expression evaluates to TRUE
- An alternative to Application Roles
Proxy User Login
- Lets you login as another User without logging out first
- You gain full access to all actions available to the other User
- Each action performed during a Proxy Login is audited and logged
- For Administrators (or Support representatives):
- You can diagnose User issues by logging in via proxy
- For Developers
- You can see how your application updates appear to other Users
- Proxy Login Access is enabled/disabled in the Userâs Access Profile
- Under the Administration Permissions > Account Controls section
- Lets you login as another User without logging out first
Exercise
This exercise contains four parts:
Note that these entities (Access Profiles, Users, Teams, Application Roles) are set on a tenant-basis, meaning that you can access them from any application on your tenant.