Exercise 03: Defining User Access

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)

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

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

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

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:
  • Drop-down list displays the applications that the User can access:
    
    
    
    

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)

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

<&nbsp>

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

Exercise

This exercise contains four parts:

• In Part 1, you define a new Access Profile.
• In Part 2, you define a new Team.
• In Part 3, you define a new User and edit your User Profile.
• In Part 4, you control access to the records in the MyOrders application by assigning Application Roles to Users.

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.

---

Previous

Next