TERM | DEFINITION |
| Admin Section | AKA the Admin User Interface, accessed by user accounts with system administrative rights enabled. The Admin section is found on the top part of their screen by clicking the System icon (which is invisible to those without these access rights). |
Action (Activity) | A workflow button that allows users to create objects and assessment objects, as well as to export data from an activity that occurs within an application. An action appears in its own Activity page section, with a clickable button displaying a selected form for users to enter and save object data. |
Action (Transition) | A workflow button that allows administrators to add an automated process to an object moving through its workflow states. These processes include (but aren’t limited to) messaging, role management, and clearing fields/roles/relationships. |
Activity | Within an application, activities determine the data an end user will create and edit. Activities show as header menu tabs, and often correspond to one or more object types. Each activity will have its own set of views and actions, and access is determined by roles saved to that activity. |
All Access | In the user account settings, All Access grants a user full permission to all object types and their related objects within the organization. A user with these settings enabled can view all objects and their data without an administrator adding them to a role, or adding one or more object types to the role, then configuring the workflow permissions. |
Anchor | An object type used to create data definitions, allowing users to select which relationships and references a data visualization or assessment can be drawn from. |
Application | A composite of all the key elements within Core (e.g., object types, object type groups, fields, forms, roles) that determines what data a user can directly access. Applications hold activities where users can complete tasks (actions) and view information (views). |
| Archived State | A default workflow state category, assigned when each new object type is created. However, this category can be assigned to another state if required. Once archived, administrators can choose if archived data appears in reports, in relationship or form reference elements, or in the organization's search results via additional settings in reports, forms, or roles. |
Assessment | A function with Core that allows users to collect, review, and assess data – done by evaluating business activity (e.g., an audit or investigation) continuously, from a particular point in time, or from different dimensions. Assessments function similarly to object types (e.g., components, workflows, objects) and can be added to applications, reports, and object type groups, etc. |
| Attachments Field | A field that allows users to upload files and/or URLs to an object. This field accepts most standard file types (e.g., images and documents), but there are some restrictions. Users can search uploaded attachments by file name, content keywords, and upload date. |
Component | Any object type element that can be added to a configurable form, including a field, relationship, reference, formula, or role that can be saved to an object type that can then be added to a configurable form. |
Confidential Login | A Core function that uses a single user account to generate a link that multiple users can use to access Core, often to submit incidents. Users with the link don’t need to provide login credentials but may only view the form/activity selected in the settings. |
| Concatenation | A Core feature that pulls field values (including the Location property and its address components) to automatically populate the object’s Name and/or Description. Concatenations are set on the object type by way of data definitions and captures vital object information, while keeping object names and descriptions consistent across the org. |
Condition | A set of requirements that must be met before an object is transitioned to a new workflow state and an action is performed. Conditions are created on an object type’s workflow triggers. |
| Configurable Forms | The standard and navigation forms that administrators create and customize for users to enter or view Core data (e.g., fields, relationships, and comments). |
| Creation | The first state in every object type's workflow and is automatically created. It cannot be deleted, nor can its name or color be edited, however, any added triggers, transitions, or actions can be edited or deleted. |
Creation state | An initial state required on each object type's workflow that can’t be deleted, but permits editing of its name, description, color, triggers, and transitions. Each object begins in the creation state and can’t be saved until it has successfully transitioned to another state in its workflow. |
Data Definition | A collection of object types (e.g., relationships, references) that a data visualization or assessment will draw its data from, depending on the anchor or assessment's focus object type. |
| Date & Time Field | A pop-out calendar that allows users to select a set date and/or time in a format of their preference. From this calendar, type or use the arrows to select a year, select a month from the arrows or the dropdown menu, and click to select a day. |
Data Path | Part of a data definition, the data path displays all the relationships and references saved to the selected anchor or focus object type, so you choose which object types data is drawn from. |
Default form | An auto-created form that displays all the components (except roles) added to an object type. Default forms cannot be edited (so they shouldn’t be used to add system data), but configurable forms control the object components a user sees. |
| Email Settings | An admin component where you can edit the default email messages, as well as create and edit custom email templates. When the Messaging action is created on a workflow transition and an object moves to the next specified state, an email is sent to users within one or more selected roles. The email’s contents are based on the template selected when creating the action. |
Explicit permissions | A method of user access that enables object visibility, based on what’s specifically assigned to a user, rather than granting them global access. Before a user can see any objects, the role must be added as a component on the object type and configurable form, then the user must be selected in the role field appearing on the form. Users and roles with explicit permissions may also be granted inferred permissions, so they can view objects related through relationships or references. |
| Expression | A text-based formula that determines what a concatenation displays. To specify which field data is populated, administrators edit a plain text field, select a data definition and an object type within it, then add one or more properties/fields to create variables (in triple brackets) for that expression. |
Field | A space where a user can input data. Fields belong to an object type but can also be displayed on a standard form. They include plain text, numeric, date and time formats, as well as select lists (i.e., dropdown menus) and attachments. |
| Form Canvas | An area on the configurable form builder that lets users decide form content layouts in Core. With the form canvas, sections and form elements are dragged-and-dropped into the interface. Sections (i.e., form areas) are added by clicking + Section on the form canvas. Then within those sections, users can drag and drop form elements (e.g., fields, relationships, formulas). |
| Form Element | A feature (e.g., fields, relationships, formulas) that can be added to a standard form by dragging and dropping it from the Form Elements palette and onto a section in the form builder. Open and close the palette by clicking the System icon in the top-right section of the form canvas. Elements already added to the canvas appear in the palette with green to the left of their names. |
| Form Header | The top section of a form, displaying key information like the configured name, description, and workflow state. By default, when creating a new object, each standard form has a header of Create a New [Object Type name]. Once the object is created, the header is replaced with the form’s Name property value and no description (sub-title) is displayed. |
| Form Priority | The level of importance assigned to a form, via a numeric value that determines which form displays to a user, should they have access to multiple forms on a given object type. |
| Form Section | An area on the standard form canvas where you can drag and drop form elements (e.g., fields, relationships, formulas). Sections are added to forms by clicking + Section on the form canvas. Once a section has been added to a form, you can:
|
Formula | A component that compiles numeric and variable values to assess data insights, such as Incident Severity, Estimated Damage, or Likelihood the Incident Will Recur. Formulas can display object data as a number, label (e.g., Low, Medium, High), or both a number and labels, all with optional colors. Variable data can be created from any field with a numeric value (including select lists). They can also be added directly to an object type, or from object type fields added through a relationship or reference. |
| Global Permissions | Users are granted access to all the records (objects) for the object type(s) added to that role via global permissions. Users with global permissions do not need to be added to an object to view it, nor do they need to be granted inferred permissions. However, their role's workflow permissions for each state determines what they can do with the objects (e.g., create, read, edit). |
| Inferred Permissions | A setting that enables users with access to an object to also see some/all of its related or referenced objects. Inferred permissions ensure users within a particular role (with explicit permissions) are indirectly given the appropriate information access they need when interacting with related objects. |
Inferred permissions | Additional permissions on a role that allows administrators to select which additional objects, connected through relationships or references, a user has access to without directly granting permission through the role field on a form. This ensures users within a particular role with explicit permissions are indirectly given the appropriate access to the information they need when interacting with related objects. |
Monogram | One to three letters, with or without a color, which represent and help users quickly identify object types throughout the system. |
| Numeric Field | A field that limits form input to numeric characters. These fields can also be configured to display trending data when added to a standard form on an object type. |
Object | A record saved to an object type (i.e., the record category). For example, Incident is the object type, while Accident (e.g., a slip and fall) is the object. |
Object type | The category of the data collected (e.g., Incident, Employee Record, Witnesses, Vehicles). Once a record is saved to an object type, it becomes an object. Object types can be configured to control the specific user access, manage field visibility and completion, and set the data collection process. |
Palette | A pop-up window that typically displays on the right-side of the Admin section when users are editing object types. |
| Permissions | Settings that grant access to specific objects based on the object types added to the user’s role. |
| Plain Text Field | A field type that allows users to enter a single line or multiple lines of plain text or rich text formatting, depending on the field’s settings. |
| Properties | A set of default fields assigned to all object types – which can’t be modified in the admin interface. The Form Elements Properties section allows users to add and display an object's default information, including:
|
| Pull Data Value | A workflow action (driven by a trigger) that automatically copies values from fields, the Location property, and/or relationships – before inserting them into the current object as it moves to the next workflow state. For example, to create an incident object from an activity, this action would automate the process by copying over important field, location, and relationship information. |
| Read-only | A form setting that prevents a specific field from being modified, while staying visible to end users. |
References | The inverse connection between a destination and source object type. For example, if a relationship called “Incident Report Writer” was created on the Incident object type, using a group saved with the Employee Record object type, the system automatically adds a reference to an Employee Record form showing incidents a specific employee may have created. |
Relationship | A function that connects two or more object types together when object types are added to an object type group. For example, to track employees creating Incident objects, users can add the Employee Record object type to a group called “Employees,” then create a relationship on Incident using the Employees group and name it “Incident Report Writer” to indicate who created the report. |
| Reports | Documents (aka Data Visualizations) that display data from a selected anchor (e.g., tables, pie charts, and heat maps) and free form text. Each new report requires a data definition selected as the report focus. Each element added to the report canvas requires a data series to further filter the available object data. Only administrators can create reports, but end-users can view and star reports, apply filters, view historical data, and export report data from a view or form action. |
| Required Components | Settings that prevent an object from moving to the next workflow state until a give field/relationship is populated. When marked as required, the address search bar is highlighted in yellow on the user’s form interface. If the property is configured to display as Map Only, the map border highlights in yellow. |
Roles | A feature that controls the data a user can create, edit, delete, view, or manage on object types. When users are added to a role, they’re bound by the permissions configured on the role, which include global, explicit, or inferred permissions. |
| Select List | A dropdown field type that allows users to select one or more options. A single select list lets users only select one option from the field, while a multi-select list lets users select multiple options from the field. Single select lists with five options or fewer can also be configured to display trending data when added to a standard form on an object type. |
| Set Field Value | An action on a transition that autocompletes a Date & Time field (e.g., completed date, deadline) or a Select List field (e.g., low-medium-high priority). This includes multi-select lists, which auto-fill pre-defined option or options. Set Field Value can be altered in the Edit Trigger palette under Type. |
| Single Sign On (SSO) | An authentication method that enables users to securely authenticate with multiple applications and websites by using just one set of credentials. Resolver Core uses SSO for system access, so customers can log in with their existing credentials without typing in their password. |
| Standard Form | A form type for administrators to specify displayed form elements and the fields users should fill out on object types, as they work in activities, reports, or tasks, depending on the current object workflow state. A standard form is the main way that users interact with object data, and that form display is set based on priority, workflow permissions, and so forth. |
States | The various stages of the data collection process (e.g. Create, Triage, Review, Investigate, Close) that are saved to a workflow. You can create multiple states, but you must have at least two states on an object type to successfully save new objects. |
| Table | A type of report component that displays data in columns based on the report settings selection. Users can click on any of the report data to display a form selected by an administrator. Table data can be exported to a Word or Excel file from a view. |
| Transition | A workflow element defining the state an object will move to once a form trigger has been clicked. For example, a Create trigger can be set to transition the object to the Triage state. Users can also add actions to transitions that email users within selected roles, or automatically add the currently logged in user within a selected role to access an object once it has transitioned. |
Trigger | The workflow event that prompts an action and the object’s movement from one state to another. Triggers are either timed to automatically prompt an action nightly or appear as form buttons. The state an object moves to is determined by the transition saved to the trigger. For example, clicking Create on a new Incident will move that object from the Creation state to Triage. |
| User | Every person accessing a Core organization must have their own username and password to log in. User accounts are then added to User Groups and Roles, where administrators can define which users can view, edit, create, and manage certain elements and objects. |
| User Groups | A collection of Core users saved to a group (e.g., Employees or Managers) for the purposes of quickly adding those users to roles. Through the User Groups feature, it’s best practice to group certain users together to quickly add that group to a role, rather than adding each user individually to roles. Once a user group has been created, you can add the user group to roles. If you add new users to a group that was previously added to a role, those users will automatically be added to the role. |
| User Roles | A feature that controls the data a user can create, edit, delete, view, or manage on object types. When users are added to a role, they’re bound by the role’s configured permissions – including global, explicit, or inferred permissions. While users can be added directly to roles, it's best practice to compile roles in a user group and add users to that group. |
| Value | Data entered or selected in a field. For example, Name is the field, but the data entered in that field (i.e., that person’s name), is the value. |
| Variable | A value on which the calculations are performed from a select list, numeric field, another formula, or workflow state. Variables are also used with Concatenations and email templates. Because formulas use data that can change, all variables must be assigned a name (e.g., LIKELIHOOD for the Likelihood field) that maintains valid calculations, even if the values change. If creating a variable using a field, formula, or state from relationship or reference object types, users must select a variable sub-type to specify how the data from multiple objects is compiled, calculated, and displayed. |
Visibility | The Edit Form Section settings that give administrators the option of always displaying a section and its elements on a standard form, or only displaying the section once specific formula values (ranges) or select list options are set in another form section. For example, when creating a new incident object, the Witness Details section is hidden from the form unless the end-user chooses Yes from the Witnesses? dropdown menu. |
Workflow | The settings that allow administrators to control the data flow, as well as define what data is displayed, where it’s displayed, and to whom it’s displayed through applications, activities, search results, data visualizations, and assignments. Workflows are comprised of states, triggers, transitions, conditions, and actions. Each object type must have a workflow. |
| Workflow State | The various stages of the data collection process (e.g., Create, Triage, Review, Investigate, Close). Users can create multiple states but must have at least two states to save an object. The Creation, Draft, Active, and Archived states are automatically created on every object type. When object types are added to roles, users must configure the workflow permissions for each state. Once created, workflow states can be used as variables in formulas and workflow conditions. |