Q. What’s the difference between an object type and an object?
A. In general terms, an object type is the category of data that’s being collected, whereas an object is the record saved to that object type. For example, if you created an Incident object type, the record saved to it, called “Accident”, would be the object.
Q. Why do I need to add fields, relationships, formulas, or roles to an object type?
A. When fields, relationships, formulas, or roles are added to an object type, they become components. Components need to be added so they can later be selected to appear on the configurable forms you create for the object type, which then controls what kind of data is collected from users.
Q. Why do I have to select an object type group when creating a relationship?
A. Object type groups allow administrators to group relevant data from multiple object types together via relationships without having to create relationships for every object type.
For example, if you wanted to keep track of the people who were witnesses on Incident objects, without an object type group, you would need to create individual relationships on Incident for the Employee Record, Visitor, and Vendor object types. However, if you create an object type group called “People” and add the Employee Record, Visitor, and Vendor object types to that group, you can use the group to create a relationship called “Witnesses” that allows you to create and draw data from all three of those relevant object types via a single relationship on Incident.
Q. I’m an administrator. Why aren’t the applications I created showing up in the left navigation menu?
A. Although administrators can access the application and activities settings, all users, including administrators and those with All Access settings enabled, will not be able to see an application in the left navigation menu until their role has been added to an activity on the application. Note that adding a role to one activity within an application will not grant access to all the activities saved to the application. Roles must be added to each activity individually to grant access.
Q. I added my role to an activity. Why isn’t the application or the activity appearing in the left navigation menu?
A. If you’ve successfully added your role to an activity, you’ll need to log out then log back in before it’ll appear in the left navigation menu.
Q. How come I can’t create/edit/view/delete certain objects? I added the correct object type to my role.
A. Check your role’s workflow permissions for the object type and confirm you have the correct permissions for each state. Even if you’ve added the object type to your role, you may not have been granted Create, Read, Edit, Delete, Manage, or trigger permissions while an object is in a particular state. If your role has explicit permissions, confirm that you have the appropriate inferred permissions enabled and that another user with Manage permissions has granted you access to existing objects by adding you to the role field on a form.
Q. What’s the difference between global permissions and explicit permissions on roles?
A. Both global and explicit permissions control how users can interact with certain object types and their objects. Global permissions allow users within the role automatic access to the objects from the object types added to the role, but an administrator can restrict what the user can do with the objects at each state by configuring the workflow permissions.
On the other hand, explicit permissions grant users within a role access to specific objects from the object types added to the role only after:
- The role has been added as a component on the object type;
- The role has been added to a configurable form for the object type, which will appear as a field on the form; and
- Another user from a different role with Manage privileges enabled for the same object type has added the user to the role field on the form to grant the user access to that specific object.
If the user with explicit permissions is working with relationships or references, he or she can be indirectly granted access to certain objects provided the appropriate inferred permissions have been granted (see the section below for more information on inferred permissions). Administrators can further control how users with explicit permissions interact with permitted objects by configuring the role’s workflow permissions.
Q. What are inferred permissions?
A. Inferred permissions allow users with explicit permissions to access certain objects through relationships or references without being provided direct access to those objects through the role field on a configurable form. In other words, inferred permissions indirectly allow users with explicit permissions to interact with certain objects.
For example, an administrator has granted the Incident Investigator role explicit permissions on the Incident and Employee Record object types by adding those object types to the role. This role is then added to the Incident object type, with inferred permissions granted through the Initially Reported By relationship, which is associated with the Employee Record object type. These inferred permissions will now allow the investigator to view existing Employee Record objects through the Initially Reported By relationship on Incident without another user granting the investigator access to each Employee Record object individually.
Q. If a user has been added to more than one role, which role’s permissions take precedence?
The role with the most permissions enabled will take precedence.
Q. If a user has been added to more than one role, what determines which configurable form is displayed throughout Core?
Configurable forms selected for relationship tables take precedence. After that, the most recently created forms take precedence.