Help

Page tree

Record Ownership

Record ownership creates a distinction between records owned by a user and other records in the system. Every record has a defined owner, which is generally a single person who manages the record. Record permissions for View/Edit Own and View/Edit Other—the latter referring to records not owned by the user—are set independently in the Group Permissions wizard. Record ownership is therefore a powerful permission filter built into the system, providing separate permission settings for records a user owns and those they do not. 

Record ownership affects end users and power users in different ways. End Users, who access the system via the End User Interface, can only edit records that they own, although they may still view records that other people own. Power Users, who can use the Power User Interface, can potentially edit any record in the system, regardless of ownership, if they are granted the appropriate group permissions. If you have additional end user access requirements, please consult with your support representative.

Example

 In a knowledgebase with sensitive contract management records, you'll probably have groups with differing permissions:

  • The Account Executives group may have permission to Edit Own and Edit Other for the Contract Amount field.
  • The Account Manager group may have Edit Own but not Edit Other permissions for the Contract Amount field.
  • The Support Representative group may have only View Other permission for the Contract Amount field.

These permissions are set in the Group Permissions wizard for each individual group. To edit them, edit the group permissions, go to the Tables tab, edit permissions for the table, and go to the Field Permissions tab.

Contract Amount field permissions for a group

This scenario would allow the Account Executives to edit the field in their own contracts and to manage the amounts of other contracts, while the Account Managers could only edit the field in their own contracts. The Support Representatives who access the system with the End User Interface would be able to view the contract amount but not edit the value.

Defining a Record Owner 

The owner of a record is defined on the Permissions tab of the Table wizard:

  1. Select a field in the "Field used to define ownership" drop-down.
  2. Select a field of the same type in the "Matching field in People table" drop-down.

    Contract table ownership fields

The two fields must contain the same value to grant record ownership. For example, if the ownership field is Creator Login, and the matching field is Login, the values stored in these fields must match or the system won't recognize the logged in person as the record owner. 

Use a unique field to define ownership. For example, instead of using the Full Name field, use ID or login.

Ownership can also be transferred between users. For example, in the Tasks table a record is owned by the currently assigned person, so ownership changes when the assigned person changes.

Selecting the Ownership Field

Make sure to set the record ownership field appropriately for the intended use of the table. Some examples of possible ownership field values are:

  • In the Service Request table, the ticket submitter should own the record, so the Submitter Login or Customer Login field could be used and matched to the user Login. This allows, for example, the ticket submitter to edit or close their own tickets but not the tickets of other submitters.
  • For a Projects table, the owner of a project might be the project manager, so the PM Login field could be used and matched to their user Login. You might use this ownership setting to give the project manager full Edit Own control over project records. You could also give other team members Edit Other permissions to the project, but you could restrict the fields they're able to edit.
  • Background tables that are only visible to admin users, such as the Approvals table, typically use Creator Login to define ownership. This ensures that administrators own the records and are the only users able to make changes.

Best Practice Tip

For most tables, use individual ownership to define who can edit a record. You typically shouldn't use a field such as Primary Team, which is shared by many users. If you use a shared field or a non-unique field, records may be owned by more than one user, which may cause problems. For example, one user might delete a record that another user created, or edit a record to which they aren't assigned.

Email Based Record Ownership

You might want to use the incoming email address field as the matching field to define record ownership. However, this can cause parsing issues when the system matches the fields and different names are used for the same address, such as "John Smith <john.smith@aaa.com>" and "John G. Smith <john.smith@aaa.com>."  To resolve this issue, the Store Sender's Address section of the Record Mapping tab in the Inbound Email wizard enables you to store the email address and the name in separate fields. 

Store address and name separately

When this option is chosen, the system parses email record ownership in cases where the recognition is based on the email address, which prevents errors due to name-sensitive email recognition. The system also recognizes that the email forms "AAA <aaa@aaa.com>" and "aaa@aaa.com" are synonymous.