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.
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 Value field.
- The Account Manager group may have Edit Own but not Edit Other permissions for the Contract Value field.
- The Support Representative group may have only View Other permission for the Contract Value field.
For each group, these permissions are set on the Field Permissions tab of the Table Permissions wizard, located within the Group Permissions wizard.
This scenario would allow the Account Executives to edit the field in their own contracts and to manage the values of other contracts, while the Account Managers could only edit the field in their own contracts. The Support Representatives who access the system via the End User Interface would only be able to view the value of contracts but not edit the value.
Defining a Record Owner
The owner of a record is defined on the Permissions tab of the Table wizard:
- Select a field in the "Field used to define ownership" drop-down.
- Select a field of the same type in the "Matching field in People table" drop-down.
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 will not recognize the logged in person as the record owner.
The field used to define ownership should ideally be unique: instead of using the Full Name field, use a unique field such as Login or ID.
Ownership can also be transferred between users. For example, in the Tasks table a record is owned by the currently assigned person, but 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 Support Case or 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 may delete a record that another user created or edit a record to which they aren't assigned.
Email Based Record Ownership
You may 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 <email@example.com>" and "John G. Smith <firstname.lastname@example.org>." 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.
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 <email@example.com>" and "firstname.lastname@example.org" are synonymous.