CSA-C01 key terms

A single hosted deployment of the platform with its own database, URL, and configuration, isolated from every other customer instance. All tables, records, users, and customizations a candidate works with live inside one instance.

The left-hand filterable menu listing applications and modules that a user is permitted to open. Its contents are driven by roles assigned to the user, so two users on the same instance may see different menus.

A grid display of records from one table, with columns, sorting, filtering, and paging controls. Users can personalize columns, and the view can be exported, printed, or acted on in bulk.

The arrangement of fields, sections, and related lists shown when a single record is opened. Layout configuration controls what appears and in what order, separately from the underlying table columns.

Per-user adjustments to list columns, form layout, and default filters that affect only the signed-in user's experience. Personalization is stored per user and does not change what other users see.

A container that records configuration changes made in one instance so they can be exported and applied to another, such as moving work from development to production. Only records tracked as customizations are captured.

The structural definition that stores a collection of similar records, similar to a database table. Each table has a name, a label, and a set of fields, and can extend another table to inherit its fields.

A single defined attribute on a table, with a type such as string, integer, reference, or date/time. Each field maps to a column in the underlying database and has its own properties and constraints.

The metadata layer that defines every table and field, including type, length, default value, and attributes. Editing a dictionary entry changes the schema itself rather than a single record's data.

One row of data in a table, made up of values for that table's fields. Records are what users create, view, edit, and delete, and each has a unique system identifier.

A unique 32-character identifier automatically assigned to every record on every table. It is used internally for references and lookups and stays stable even if other field values change.

A field that stores the sys ID of a record on another table, creating a link between the two. The value displays as a readable name but is stored as a pointer to that record.

A field whose permitted values come from a defined list of options rather than free text entry. Each option has a stored value and a display label, and the list can be filtered per record.

A record representing a person who can sign in to the instance, holding credentials, contact details, and assigned roles. Users appear on the User table and can be internal staff or external requesters.

A collection of users that can be assigned roles, records, and work as a unit. Groups simplify administration and are commonly used as assignment targets for tasks and approvals.

A named permission set that grants access to applications, modules, and specific operations on records. Roles are assigned to users or groups and are checked by access control rules.

A rule that evaluates whether a user may read, write, create, or delete records on a table or field. Rules can combine role, condition, and script checks, and the most specific rule wins.

A condition set applied to a list or query to limit which records are returned. Filters combine field, operator, and value into clauses joined by AND/OR logic and can be saved for reuse.

The text representation of a filter's conditions, using caret-delimited operators and values. It can be copied between filters, used in scripts, and passed as a URL parameter to pre-filter a list.

A saved visualization of data from one or more tables, such as a list, bar chart, pie chart, or trend line. Reports can be shared with users or groups and can be scheduled for distribution.

A client-side rule that makes fields mandatory, read-only, or visible based on conditions on the current form. It runs automatically when the form loads or when the condition becomes true or false.

JavaScript that runs in the user's browser to control form behavior, such as validating input, setting field values, or reacting to field changes. It executes before the form is submitted to the server.

Server-side JavaScript that runs when records are queried, inserted, updated, or deleted, either before or after the database operation. Before rules can modify the record; after rules handle side effects.

A reusable server-side JavaScript class or function library that other scripts can call. It keeps shared logic in one place and is commonly invoked from business rules, scheduled jobs, and UI actions.

A button, link, or context menu item on a form or list that runs a script or navigates when clicked. Visibility and behavior are controlled by conditions, roles, and client or server script.

A legacy graphical process model that moves a record through activities such as approvals, tasks, and notifications based on transitions and conditions. It runs on the server and is triggered by events on a table.

A newer process-building tool that combines triggers, actions, and data logic into flows that can be tested and reused. It supports subflows and is the preferred tool for new automation on the platform.

A process step that pauses work until designated approvers respond, recording their decision and comments. Approvals can be tied to users or groups and can require any one or all approvers to agree.

A requestable offering in the service catalog, with a form, price, and fulfillment process. Submitting an item creates a request and one or more requested items that drive downstream tasks.

A question on a catalog item's order form, similar to a field but defined on the item rather than the table. Variable values are stored with the request and can drive approvals, tasks, and pricing.

A repository of articles organized by category and access controls, used to share solutions and guidance. Articles move through workflow states such as draft, review, and published before users can find them.

An automated email or message sent when a specified event or condition occurs on a record. It defines recipients, subject, and body, and can be triggered by record changes or by a scheduled job.

A script or report execution configured to run automatically at set times or intervals. Jobs run on the server without a signed-in user and are commonly used for recurring maintenance and reporting.

A temporary staging table that holds raw rows loaded from a data source before they are transformed into target records. Staging lets you inspect and clean data before committing it.

A definition describing where import data comes from, such as a file, URL, or external system, and how to load it. It feeds rows into an import set for later transformation.

The set of field-to-field mappings and rules that converts rows in an import set into records on a target table. It controls matching, coalescing, and what happens when a match is found.

A transform map setting that uses one or more fields to detect an existing target record instead of always inserting a new one. Matching rows update the existing record; unmatched rows can be inserted.

A rule that automatically sets the assigned-to user or group on a new or updated record based on conditions. It reduces manual triage and is often combined with groups and business rules.