AgileApps Support Wiki Pre Release

Difference between revisions of "Exercise 03: Defining User Access"

From AgileApps Support Wiki
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
==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
<br><br>[[File:New_User_Jane_Low.png|900px]]<br><br>
===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:<br><br>[[File:Application_drop-down_2.PNG|600px]]<br><br>
===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
<br><br>[[File:Access_Control.png|700px]]  [[File:Custom_Access_Criteria_Builder.png|700px]]<br><br>
===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
<br><br>[[File:Account_Controls.png|500px]]<br><br>
==Exercise==
This exercise contains four parts:
This exercise contains four parts:
:* In Part 1, you define a new Access Profile.  
:* In Part 1, [[Part 1: Define an Access Profile|you define a new Access Profile.]]
:* In Part 2, you define a new Team.  
:* In Part 2, [[Part 2: Create a new Team|you define a new Team.]]
:* In Part 3, you define a new User and edit your User Profile.
:* In Part 3, [[Part 3: Create three new Users and edit your User Profile|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.
:* In Part 4, [[Part 4: Assigning an Application Role to a User|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.
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.


Visit the following pages to see the steps:
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
:* [[Part 1: Define an Access Profile]]
:{| border="0" align="left" cellpadding="5" cellspacing="1"
:* [[Part 2: Create a new Team]]
|
:* [[Part 3: Create three new Users and edit your User Profile]]
[[A Step-by-Step Tutorial for Creating a Sample Application in the AgileApps Cloud|Previous]]
:* [[Part 4: Assigning an Application Role to a User]]
|}
:{| border="0" align="right" cellpadding="5" cellspacing="1"
|
[[Part 1: Define an Access Profile|Next]]
|}

Latest revision as of 13:07, 16 December 2022

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 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