AgileApps Support Wiki Pre Release

Exercise 03: Defining User Access

From AgileApps Support Wiki
Revision as of 13:04, 16 December 2022 by Wikieditor (talk | contribs)

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



New User Jane Low.png

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 drop-down 2.PNG

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



Access Control.png<&nbsp>Custom Access Criteria Builder.png

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



Account Controls.png

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.


Previous

Next