Difference between revisions of "Record Level Visibility"

From AgileApps Support Wiki
imported>Aeric
imported>Aeric
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
==About {{PAGENAME}} ==
==About {{PAGENAME}} ==
In general, anyone whose role gives them access to an object can see any of the records it contains. But with ''Record Level Visibility'' you can specify who is allowed to see each record, one by one. With no visibility criteria specified, everyone who can access the object can see the record. But with visibility criteria specified, only users who match the specified criteria can see it. Users who not match the specified criteria do not see the record in list views, search results, or reports. And if they happen to have the URL that goes directly to that record, they get a "record not found" error when they visit that URL.
In general, anyone whose role gives them access to an object can see any of the records it contains. But with ''Record Level Visibility'' you can specify who is allowed to see each record, one by one. With no visibility criteria specified, everyone who can access the object can see the record. But with visibility criteria specified, only users who match the specified criteria can see it. Users who do not match the specified criteria do not see the record in list views, search results, or reports. And if they happen to have the URL that goes directly to that record, they get an error when they visit that URL.


:'''Note:'''<br> A record that is not visible does not appear in reports, views, or search results. So two people running the same report can get different results, depending on which records are visible to them.
:'''Considerations:'''
:* A record that is not visible to a particular user does not appear in reports, views, or search results.  
:* It also does not appear in the SQL browser, and cannot be reached using REST APIs.
:* Since such record does not appear in reports, two people running the same report can get different results, depending on which records are visible to them.
:* To see records in an object, a user must be granted access to an application that contains that object.
:: At that point, they are assigned a Role in the application, which gives them access to the records it contains, except under special circumstances.
:: One of those special circumstances is the addition of visibility controls to a record, which could make the record invisible to that user.
:: ''Learn more:'' [[Record Access Permissions]]


===How it Works===
===How it Works===
When Record Level Visibility every object has an additional setting that specifies the kind of criteria that can be specified on an individual record. You can choose one of several options as a basis for that criteria: The user's team, the user's role, user IDs, or the value in one of several kinds of custom [[User Fields]] that can be defined on the User object.  
When Record Level Visibility is enabled, every object has an additional setting that specifies the kind of criteria that can be specified for individual records. You can choose one of several options as a basis for that criteria: The user's team, the user's role, user IDs, or the value in one of several kinds of custom [[User Fields]] that can be defined on the User object.  
:[[File:RecordVisibilityObjectProperty.png]]
:[[File:RecordVisibilityObjectProperty.png]]


Once the criteria type has been selected, every record displayed for that object has an additional "Visiblity" section in the sidebar. A user who has [[Control Visibility permission]] can then put controls in place to determine who can see the record, and who cannot.
Once the criteria type has been selected, every record displayed for that object has an additional "Visiblity" section in the sidebar. A record that is restricted to a particular team would look something like this:
:[[File:RecordVisiblitySidebar.png]]
:[[File:RecordVisiblitySidebar.png]]
Only users who have [[Control Visibility permission]] see the '''Change Settings''' option, which allows them to put visibility controls in place: 
:[[File:RecordVisiblityTeamChooser.png]]


{{Tip|For a VIP client in the hospital scenario, it would be possible to set up a team or role named VIP. Then, when visibility is set, the visibility section of the sidebar would display "VIP", and people on that team (or with that role)–and only those people–can see the record. Other possible labels include "Top Secret", or "Reserved".}}
{{Tip|For a VIP client in the hospital scenario, it would be possible to set up a team or role named VIP. Then, when visibility is set, the visibility section of the sidebar would display "VIP", and people on that team (or with that role)–and only those people–can see the record. Other possible labels include "Top Secret", or "Reserved".}}
Line 24: Line 34:
# Click '''Additional Record-Level Criteria'''
# Click '''Additional Record-Level Criteria'''
# Choose the type of visibility restrictions that can be specified when viewing a record:
# Choose the type of visibility restrictions that can be specified when viewing a record:
#* '''Teams -''' When viewing a record, one or more teams can be selected. To see the record, a user must belong to one of the selected teams.
#* '''Teams -''' When viewing a record, one or more teams can be selected. To see the record, a user's primary team must be one of the selected teams.
#* '''Roles -''' When viewing a record, one or more roles can be selected. To see the record, a user must have one of those roles.
#* '''Roles -''' When viewing a record, one or more roles can be selected. To see the record, a user must have one of those roles.
#*: '''Important:'''<br>Specifying visibility criteria for a record in one app automatically makes the record invisible in all other applications.<br>(Because, even if two roles have the same name in different applications, they are not actually the same role.)<br>If an object is shared among multiple applications, then, it is wise to use a different form of visibility control.
#*: '''Important:'''<br>Specifying visibility criteria for a record in one app automatically makes the record invisible in all other applications.<br>(Because, even if two roles have the same name in different applications, they are not actually the same role.)<br>If an object is shared among multiple applications, then, it is wise to use a different form of visibility control.
Line 33: Line 43:
#*: To see the record, a user must have a matching value in that field.
#*: To see the record, a user must have a matching value in that field.
#*: The kinds of fields that can be chosen include:
#*: The kinds of fields that can be chosen include:
#*::* Checkboxes
#*::* Lookup fields
#*::* Lookup fields
#*::* Picklists
#*::* Picklists
Line 50: Line 61:


=== Setting Visibility Criteria on a Record ===
=== Setting Visibility Criteria on a Record ===
When viewing a record, click in the ''Visibility'' section to specify who can see the record. The operation of the selection dialog depends on the type of visibility criteria that has been defined on that object, but in all cases you can add one or more entries and/or delete existing entries.
When viewing a record, click in the ''Visibility'' section to specify who can see the record. The operation of the selection dialog depends on the type of visibility criteria that has been defined on that object:
:* In most cases, a "chooser" dialog appears that lets you specify visibility controls--generally a selector-dialog that lets select one or more entries, and/or delete existing entries.
:* In cases where a [[User Field]] is the visibility criteria, and the field is a text field or a numeric field, then you can specify one or more values, and/or delete existing values.
:* If the field is a checkbox, you specify "0" for off/unchecked, or "1" for on/checked.


{{Warn|<br>When you restrict visibility, it is entirely possible to cut yourself out of the loop. In some cases, that is the desired and intended behavior. But if you restrict visibility to a team you don't belong to, restrict it to a list of users that does not include yourself, or restrict it to a role you do not have, then at that point you can no longer see the record, even if you own it. (But an admin can still see it, and re-set visibility.)}}
{{Warn|<br>When you restrict visibility, it is entirely possible to cut yourself out of the loop. In some cases, that is the desired and intended behavior. But if you restrict visibility to a team you don't belong to, or you restrict it to a list of users that does not include yourself, or to a role you do not have, then at that point you can no longer see the record, even if you own it.  


You can even make the record invisible to ''everyone'' (except an admin), by assigning it to a Team that has no members, to a Role no one is attached to, to users who not have access to any application that contains the object, or by specifying a custom field value that no one matches.


In all of those cases, an admin who has Global View permission can still get to the record, but is invisible to everyone else.}}
<noinclude>
<noinclude>


[[Category:Data Permissions]]
[[Category:Data Permissions]]
</noinclude>
</noinclude>

Latest revision as of 17:57, 13 October 2015

About Record Level Visibility

In general, anyone whose role gives them access to an object can see any of the records it contains. But with Record Level Visibility you can specify who is allowed to see each record, one by one. With no visibility criteria specified, everyone who can access the object can see the record. But with visibility criteria specified, only users who match the specified criteria can see it. Users who do not match the specified criteria do not see the record in list views, search results, or reports. And if they happen to have the URL that goes directly to that record, they get an error when they visit that URL.

Considerations:
  • A record that is not visible to a particular user does not appear in reports, views, or search results.
  • It also does not appear in the SQL browser, and cannot be reached using REST APIs.
  • Since such record does not appear in reports, two people running the same report can get different results, depending on which records are visible to them.
  • To see records in an object, a user must be granted access to an application that contains that object.
At that point, they are assigned a Role in the application, which gives them access to the records it contains, except under special circumstances.
One of those special circumstances is the addition of visibility controls to a record, which could make the record invisible to that user.
Learn more: Record Access Permissions

How it Works

When Record Level Visibility is enabled, every object has an additional setting that specifies the kind of criteria that can be specified for individual records. You can choose one of several options as a basis for that criteria: The user's team, the user's role, user IDs, or the value in one of several kinds of custom User Fields that can be defined on the User object.

RecordVisibilityObjectProperty.png

Once the criteria type has been selected, every record displayed for that object has an additional "Visiblity" section in the sidebar. A record that is restricted to a particular team would look something like this:

RecordVisiblitySidebar.png

Only users who have Control Visibility permission see the Change Settings option, which allows them to put visibility controls in place:

RecordVisiblityTeamChooser.png

Thumbsup.gif

Tip: For a VIP client in the hospital scenario, it would be possible to set up a team or role named VIP. Then, when visibility is set, the visibility section of the sidebar would display "VIP", and people on that team (or with that role)–and only those people–can see the record. Other possible labels include "Top Secret", or "Reserved".

Automatic Auditing

  • Record-visibility selections made by users are automatically added as entries in the Audit Log.
  • Changes to a record's visiblity criteria are automatically recorded in the Field Audit Log, as well.

Working with Record Level Visibility

Lock-tiny.gif

Setting Up Record Level Visibility

  1. Go to GearIcon.png > Customization > Objects
  2. Click the object that needs the restricted visibility option
  3. Click Additional Record-Level Criteria
  4. Choose the type of visibility restrictions that can be specified when viewing a record:
    • Teams - When viewing a record, one or more teams can be selected. To see the record, a user's primary team must be one of the selected teams.
    • Roles - When viewing a record, one or more roles can be selected. To see the record, a user must have one of those roles.
      Important:
      Specifying visibility criteria for a record in one app automatically makes the record invisible in all other applications.
      (Because, even if two roles have the same name in different applications, they are not actually the same role.)
      If an object is shared among multiple applications, then, it is wise to use a different form of visibility control.
    • Users - When viewing a record, one or more users can be selected. Only the selected users can see the record.
    • Custom User Field
      When you choose this option, you also specify which User Field to use.
      When viewing a record, one or more values can be specified for that field.
      To see the record, a user must have a matching value in that field.
      The kinds of fields that can be chosen include:
      • Checkboxes
      • Lookup fields
      • Picklists
      • Global Picklists
      • Text Fields
      • Numeric Fields
      Other field types cannot be chosen (mostly because it makes little sense to do so).

Warn.png

Important:
If you change an existing criteria setting to something different, all existing record visibility-restrictions are removed. If, for example, you change the criteria from Teams to Roles, and a record was previously restricted to the operations team, that record becomes immediately visible to everyone. (A warning dialog is issued to make sure such a change does not happen inadvertently.) Before making such a change then, it is advisable to make a list of all records that currently have a visibility restriction.

Determining Who Can Control Visibility

Users who have Control Visibility permission can create and modify visibility settings--assuming they can see the record in the first place. In the Role Settings, you specify each object for which a user in that role has that capability.

RecordVisibiltyRolePermission.png

Notepad.png

Note:
Administrators who have the Global View permission can always see the record, regardless of its visibility restrictions. If the admin's role gives them Control Visibility permission, then the admin can also modify the record's visibility--for example, to undo an inadvertent change that rendered the record invisible to the record owner.

Setting Visibility Criteria on a Record

When viewing a record, click in the Visibility section to specify who can see the record. The operation of the selection dialog depends on the type of visibility criteria that has been defined on that object:

  • In most cases, a "chooser" dialog appears that lets you specify visibility controls--generally a selector-dialog that lets select one or more entries, and/or delete existing entries.
  • In cases where a User Field is the visibility criteria, and the field is a text field or a numeric field, then you can specify one or more values, and/or delete existing values.
  • If the field is a checkbox, you specify "0" for off/unchecked, or "1" for on/checked.

Warn.png

Warning:
When you restrict visibility, it is entirely possible to cut yourself out of the loop. In some cases, that is the desired and intended behavior. But if you restrict visibility to a team you don't belong to, or you restrict it to a list of users that does not include yourself, or to a role you do not have, then at that point you can no longer see the record, even if you own it.

You can even make the record invisible to everyone (except an admin), by assigning it to a Team that has no members, to a Role no one is attached to, to users who not have access to any application that contains the object, or by specifying a custom field value that no one matches.

In all of those cases, an admin who has Global View permission can still get to the record, but is invisible to everyone else.