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:
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. 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. |
The owner of a record is defined on the Permissions tab of the Table wizard:
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.
Make sure to set the record ownership field appropriately for the intended use of the table. Some examples of possible ownership field values are:
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. |
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.
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.
Related articles |