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:
    
    
    
    

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