Autologyx Docs

Appearance

Knowledgebase terminology index ​

This file is built from the saved terminology store.

.docx merge fields ​

.docx merge fields are placeholders used in Autologyx document templates to insert the contents of stored Microsoft Word (.docx) files during dynamic document assembly. Introduced in Autologyx Catalyst 1.13, they are configured by referencing document fields that hold reusable document fragments, allowing a single merge field to embed a full .docx file into the generated output. This capability is used when building adaptable templates for legal or operational documents that are assembled from standard building blocks, and it matters because it enables configuration admins and end-users to produce complete, context-specific documents without manual copying, pasting, or reformatting.

.embedded ​

.embedded is a merge-field suffix used in the Autologyx platform when configuring image merge fields in generated documents. It is added after a standard document type merge field and an attached-file index to instruct Autologyx to embed the selected attached document directly into the generated output. This suffix is used in document generation configurations where content from an attachment must be inserted into the final document rather than referenced separately. It matters because it enables configuration admins to control how attachment content is rendered in generated documents, helping end-users receive completed documents that already include the required embedded file content.

1 time completion ​

In Autologyx, 1 time completion is an account type for users who do not sign in to the platform and instead complete assigned tasks directly from links provided in email notifications. This account type is used when configuring users and permissions, particularly for scenarios where external or occasional participants need to perform a specific action without full platform access or standard authentication. It matters because it defines a streamlined interaction model for end-users while helping Configuration Admins and Super Admins control access appropriately, ensuring that users can complete required work without being set up as regular logged-in Internal or External users.

1 time completion account type ​

In Autologyx, the 1 time completion account type is a restricted user account intended for users who only need to complete a single task or interaction and do not participate in ongoing platform administration or access control. It is used in user account management and has important platform-wide limitations: existing Internal, External, Config admin, and Super admin accounts cannot be changed to 1 time completion, although a 1 time completion account can be converted to one of those other account types. This account type is excluded from user group membership lists, cannot be assigned object class permissions, and is not available in record access user searches, which means it cannot be used for standard permission assignment, assignee configuration, or record-level access management. For Configuration admins and Super Admins, this distinction matters because selecting the correct account type determines whether a user can be included in groups, permissions, and access settings across the platform.

1 time completion user ​

A 1 time completion user is an Autologyx user account type for people who only need to complete tasks occasionally and do not sign in to the platform. In Catalyst, these users must still have an account, but they interact with assigned work through email notifications that contain direct task links rather than through the standard login experience. Configuration admins use this account type when assigning both manual and automated tasks to external or infrequent participants, with the important constraint that a manually assigned task for a 1 time completion user cannot include additional assignees. This account type matters because it enables controlled participation in workflows without full platform access, and it is also treated differently in platform configuration such as user group permissions, where permissions for logged-in users do not apply to 1 time completion users.

1,000 events per broadcast every 5 seconds ​

In Autologyx, the 1,000 events per broadcast every 5 seconds limit is a WebSocket service throughput control that governs how real-time updates are grouped and delivered to connected clients. It is used in the platform’s WebSocket event stream for updates related to Object Records and other supported real-time activity within the environment defined by the client’s authentication token. Under this limit, Autologyx processes and sends up to 1,000 events in a broadcast window every five seconds, or sooner when that event count is reached. This matters to developers and integrators because it defines the delivery cadence and batching behaviour of live updates, which directly affects client-side subscription design, message handling, performance expectations, and scaling decisions when building integrations or user interfaces that depend on real-time event delivery.

100 concurrent connections per client ​

In Autologyx, the 100 concurrent connections per client limit is the WebSocket service capacity allocated to a single client, defining how many active real-time connections that client can hold at the same time. This limit applies when developers and integrators connect to the platform’s WebSocket service to receive real-time events, including updates related to Object Records, using an authentication token tied to a specific environment. It matters because it sets a clear scaling boundary for solution design, integration architecture, and operational configuration: teams must ensure their applications, user sessions, and connection management patterns stay within this per-client threshold so real-time event delivery remains efficient and aligned with the platform’s broadcast processing limits.

1:1 ​

1:1 ratio ​

In the Autologyx Relational Modeller, a 1:1 ratio describes a parent/child relationship in which each parent record is associated with exactly one record in a given direct child object class, and each of those child records relates back to that single parent. This relationship type is used when configuring object classes and defining parent/child structures in the data model, particularly where related information should exist as a single dedicated record rather than as a collection. It matters because it determines how records are structured, linked, and managed in the platform, helping configuration admins and Super Admins design clear, controlled object relationships that support the intended record model.

1:N ​

In the Autologyx Relational modeller, 1:N (one to many) defines a relationship where a single parent object class can be linked to multiple child object class records. It is used when creating the relational model in system configuration to set the ratio between object classes, such as one Employee related to many Employee Contracts. This relationship type matters because it determines how data is structured and connected across the platform, ensuring object classes reflect real business relationships and enabling administrators to configure parent/child models that support the correct record hierarchy and associated processes.

1TC (One Time Completion) users ​

INSUFFICIENT_EVIDENCE

1TC users ​

In the Autologyx platform, 1TC users are a protected user category that cannot be assigned to Permission Sets. This restriction is enforced by built-in safeguards in access-management features such as the Record Access actor, where Permission Sets are used to control who can access records and actions. For Configuration Admins and Super Admins, this distinction matters because it affects how access models are designed and maintained: 1TC users must be excluded from Permission Set assignment, helping preserve secure separation in user administration and preventing invalid or non-compliant access configuration.

About The Theme ​

INSUFFICIENT_EVIDENCE

access control ​

Access control in the Autologyx platform is the framework used to manage which users and groups can view or act on records and related platform resources, typically through configuration such as Record Permission Sets and group assignments. It is used by administrators and integrators when assigning, updating, or removing User Groups, including through API endpoints that manage group IDs within record-level permissions, and it affects how permissions are inherited, changed, and tracked in object history. Access control matters because it allows organisations to scale permission management consistently, enforce security and compliance requirements, and ensure that the right people have the right level of access across automated processes and case work.

Access denied ​

Access denied message ​

An Access denied message is the Autologyx notification shown when a user attempts to open a page or feature that their assigned role or permission set does not allow them to access. It is encountered when navigating directly to restricted platform areas, such as administration or Sequencer pages, even if the user enters the URL manually rather than using the left-hand menu. This message matters because it confirms that role permissions are being enforced correctly after changes to roles, permission sets, or related configuration, helping end-users understand why access is blocked and helping configuration admins and Super Admins validate and troubleshoot security and access control settings.

Access Denied page ​

The Access Denied page is the platform page shown when a user attempts to open a restricted area of Autologyx without the required permissions. In the documented system configuration context, it is specifically presented when someone tries to access the Theme configuration page without a Super admin account. This page is used around protected administrative URLs and settings areas to enforce role-based access control, clearly signalling that the current account cannot open the requested page. For Super Admins and configuration admins, it matters because it confirms that sensitive system configuration functions are limited to the correct account type and helps distinguish a permissions issue from a problem with the URL, login process, or page availability.

access tokens ​

Access tokens are short-lived authentication credentials used in Autologyx to authorise secure communication between the platform and external services or embedded applications. In practice, they are generated and managed through Authentication Objects in Administration, where configuration such as client credentials supports creating and refreshing tokens for integrations including Catalyst and DocuSign. Autologyx uses access tokens in API request headers and passes them to application iframes, automatically renewing them before expiry and updating message data so authenticated sessions continue without interruption. Access tokens matter because they are the mechanism that keeps integrations connected, forms and embedded components functioning correctly, and external service calls authorised during runtime.

account activation page ​

The account activation page is the Autologyx page opened from the unique link in a user’s activation email, where a newly created user completes account setup by providing a password. It is used during user onboarding after an administrator creates the account in Administration > Users, and its availability depends on outbound mail being configured so the activation email can be delivered. This page matters because it is the step that enables a created user to activate access to the platform and move from account creation to signing in and using their Autologyx account.

Account Base URI ​

Account Base URI is the base URL used by Autologyx Catalyst as the starting point for DocuSign API calls, and it is configured in the relevant DocuSign authentication and API setup used by the platform. It is especially important for configuration admins, developers, integrators, and super admins when setting up a DocuSign developer account, selecting the correct host for a dev, test, or live system, and when migrating authentication objects between systems. Because the Account Base URI commonly differs between DocuSign environments, it must match the target environment exactly and be used with the correct API Account ID; otherwise, API calls from Catalyst will be directed to the wrong endpoint and DocuSign integrations will not function correctly.

account creation email ​

The account creation email is the onboarding email that Autologyx sends when a user is given a Standard or Super admin account, providing the user with the information or access path needed to activate and begin using their account. It is used as part of user setup and account provisioning in platform administration, and it distinguishes full platform accounts from a 1 time completion user, who does not receive this email and instead accesses work through a task link in Catalyst. This matters to Configuration admins and Super Admins because the presence or absence of the account creation email reflects the user’s account type and determines how that user first accesses Autologyx.

account in Catalyst ​

INSUFFICIENT_EVIDENCE

account setup ​

Account setup is the process an invited user completes after receiving an activation email to finish activating their Autologyx account and become able to sign in and use the platform. In Autologyx, this term is used in user activation and administration contexts, particularly in the User List, status column, Status section, and User details page, where it explains the meaning of user states such as Created, Pending, and Active. A user in Pending status has received the activation email but has not yet completed account setup, while completion of account setup is the step that moves the account toward active use. This matters to Super Admins monitoring onboarding progress and to end-users completing access, because it shows whether access has been fully activated or whether further action is still required.

account Status ​

Account status is the user lifecycle state in Autologyx that shows whether a user account has been created, is awaiting activation, or is active, and it is managed from the Edit user page and through Single sign-on flows. In user administration, selecting to send an activation email changes the account status to Pending, while choosing to send it later sets the status to Created, which means the account exists but has not been activated; the Status section on the Edit user page displays this stage. In Single sign-on, a matching non-active account is automatically changed to Active on the user’s first successful SSO login, and the activation date is set to that first login date. Account status matters because it controls whether a user can access the platform, how activation is completed, and how administrators track and manage user onboarding.

account statuses ​

In Autologyx, account statuses indicate the stage of a user account in the setup and sign-in lifecycle and are used by Configuration admins and Super Admins when managing users in Administration, including the Create user page and Users list. The platform uses three statuses: Created, meaning the user account exists but has not been activated; Pending, meaning the activation email has been sent but the user has not yet completed activation; and Active, meaning the user has activated the account and logged in. These statuses matter because they show whether a user can access the platform, help administrators confirm whether activation steps have been completed, and support troubleshooting of onboarding issues such as activation email delivery and account activation progress.

account type ​

Account type is the mandatory classification assigned to every Autologyx user account that defines the user’s broad level of platform access and how the account is intended to be used. It is shown in the Users list alongside status and roles, and Autologyx provides five account types, including Super Admin, Config Admin, 1 time completion, Service External, and Service Internal. Account type is especially important during user administration and platform setup because it determines whether a user can access restricted administration and system configuration areas, whether they can be assigned configuration roles, and how specialist accounts such as one-time completion users and service accounts behave within the platform.

Accounts with full platform access ​

Accounts with full platform access is a user account type in the Autologyx platform used when configuring authentication methods by account type. In the system configuration API, it is one of the accepted payload keys that administrators can target to define which sign-in method applies to users who have unrestricted access across the platform, distinct from External users, Internal staff accounts, and Config Admin users. This matters because it allows Configuration admins, Super Admins, and developers or integrators to enforce the correct authentication controls for the most privileged platform users, supporting secure access management, SSO alignment, password reset behaviour, and other account-type-specific authentication rules.

Action menu ​

In Autologyx, the Action menu is the contextual options control attached to a selected record or item, used to open the actions available for that specific object in the current page or component. It is used in operational areas such as the Users list, where selecting Edit from the Action menu opens the Edit user page for the chosen user, and in the document upload/view component, where the Action menu at the end of each attached document provides document-specific actions such as delete or download. The Action menu matters because it is the standard way to access item-level actions across the platform, helping administrators and end-users quickly manage records and documents from the place where they are working.

Actions ​

In the Autologyx platform, Actions is the rightmost column on list pages that provides a kebab menu of item-specific commands for the record in that row. The options shown in this menu vary by the list page, the type of item being displayed, and the user’s role permissions; for example, on Task Group Templates it is used to access functions such as Edit or Delete for a template when permitted. Actions matters because it is the standard place users, configuration admins, and super admins go to manage existing items directly from a list, making it central to day-to-day administration and configuration workflows.

Actions column ​

The Actions column is a fixed column on Autologyx list pages that provides row-level controls for working with individual items. It remains present when column configuration mode is enabled and is treated differently from other visible columns: the Add columns insertion icon is shown to the right of other columns but not to the right of Actions, and the Actions column cannot be removed or repositioned. This matters because users can rely on it as a permanent access point for item-specific operations, while administrators and end-users configuring list views must understand that it is excluded from normal column layout changes.

Actions menu ​

In Autologyx, the Actions menu is the per-item menu shown on list rows, related-record components, and similar record or configuration views that provides the operations available for that specific item. It is used throughout administration, system configuration, and workspace areas for actions such as Open, Edit, Delete, View usage, Resume or Pause, Complete, Generate and download document, and membership actions such as Add as member or Promote to owner. The options shown in the Actions menu are controlled by account type, role permissions, permission sets, ownership, and the context of the object, record, task, sequence, template, or user group being viewed. This menu matters because it is the main place from which users carry out item-level work and administration in the platform, and understanding which actions appear there is essential for configuring permissions, managing objects and records, and navigating efficiently between list pages and edit or open views.

Show 24 more pages

Activate your user account page ​

The Activate your user account page is the Autologyx page opened from the activation link in a user’s activation email, where a person completes the steps required to activate their account and gain access to the platform. It is used as part of the user activation flow configured through user activation rules, and is relevant to both end-users completing first-time access and configuration admins designing the onboarding experience. In practice, this page sits between the activation email and access to the user’s full account, and is closely related to the Standard authentication page and the Autologyx landing page. It matters because it is the controlled entry point for account activation, ensuring users follow the intended activation journey defined in platform configuration.

activated ​

In Autologyx, activated describes the status of a Service Account when it is enabled for use, represented in API responses as "status": "active". This status is used in service account administration and integration workflows, particularly when creating, retrieving, or updating Internal Service Accounts and External Service Accounts through platform APIs such as POST and PATCH calls. A newly created Service Account is automatically activated, so active is the expected initial status returned by the platform. This matters to Super Admins, Configuration admins, and Developers / Integrators because the account’s active status determines whether it is available for authentication and for use in connected configuration and automation scenarios, including those involving account type and sequencer auth object setup.

activation date ​

Activation date, also described here as the first SSO login date, is the timestamp Autologyx records when a user with a matching but non-active account signs in successfully through Single sign-on for the first time. In this SSO account-activation flow, the user’s account status changes to Active and the activation date is set to that initial SSO login date before the user is taken to the landing page. This term is used in user administration and Single sign-on configuration contexts, and it matters to Configuration admins and Super Admins because it marks the exact point an inactive account became usable through SSO, helping them understand account state changes and validate expected behaviour in relation to SSO settings and access outcomes.

activation email ​

An activation email is the Autologyx system email sent to full user accounts—such as Internal, External, Config admin, and Super admin accounts—to start account setup by providing a unique activation link to the account activation page. It is used when creating users in the User List, when editing an unactivated user, through configurable user activation rules, and through delayed activation features in the platform and API. Sending the activation email moves a user from Created to Pending, while delaying it keeps the user in Created until administrators are ready for access to be enabled; administrators can also resend it, and if the username is changed before activation, Autologyx automatically sends a new activation email with a new token. This matters because the activation email controls when a user can complete setup and begin using the platform, supports staged onboarding and process preparation, and is not used for service accounts or for users expected to access Autologyx through single sign-on.

Show 3 more pages

An activation link is the time-limited URL sent to a newly created full-account user in an activation email so they can open the Activate your user account page and complete account setup in Autologyx. It is used as part of the user activation experience defined by user activation rules and is relevant to configuration admins and Super Admins who control how long the link remains valid, as well as end-users who need it to activate their account and access the platform. This matters because the activation link is the mechanism that connects account creation to first-time sign-in, and its validity period directly affects onboarding, access, and authentication flow.

Active ​

active integrations ​

Active integrations are the integrations in an Autologyx environment that have already been enabled and are currently available for use. In the centralised integrations management area under System Configurations → Integrations, Configuration admins and Super Admins can view which integrations are available and which ones are already active, helping them distinguish configured connections from integrations that are not yet enabled. This matters because active integrations determine which external systems and services can participate in Autologyx processes, allowing administrators to control the platform’s connected capabilities, organise integrations by category, and manage when to enable existing options or request new integrations.

Active status ​

Active status is the user account status in Autologyx that indicates the user has completed account activation and has logged in. It is used in user administration, including on the Edit user page and alongside other account statuses such as Created and Pending, to show the current lifecycle state of a user account. This status matters to Configuration admins and Super Admins because it confirms that the account is fully activated and usable, helping them distinguish users who can access the platform from those who still need to complete activation.

Activity log panel ​

The Activity log panel is a record-level panel in the Autologyx platform that displays the activity history for a record. It is used wherever a record’s related information is shown alongside other panels such as Tasks, Templates, and Record access, and in object class configuration it is specifically referenced as one of the places where the field marked as the Identifier is displayed at the top of the panel. This matters to both configuration admins and end-users because the panel provides a consistent context header for record activity, helping users immediately recognise which record they are viewing while reviewing its historical actions.

activity logs ​

Activity logs in Autologyx are the record-level history view that shows events directly related to an object record, including actions such as field value updates and record owner changes. They are used in the Workspace as the Activity log tab or side-panel view on a record, and are also reflected by platform actions such as Update Record actors and API Call actors, whose changes are recorded against the relevant record and user credentials. Activity logs matter because they provide a clear audit trail of what has happened to a record, help users and administrators understand sequence-driven and manual changes, and support access-controlled visibility of record history through record permissions; by contrast, transient data such as Local Variables is not written to activity logs.

Show 3 more pages

Actor Completed ​

Actor Completed triggers ​

Actor Completed triggers are sequence triggers in Autologyx that fire when a preceding actor finishes, allowing the next configured step in a Sequence to start automatically. They are used in workflow configuration to chain actors together so that one actor’s completion drives downstream processing. In the context of the API Call actor, this distinction is important because a Test Call executes the API request for validation and debugging but does not activate any downstream Actor Completed triggers in the Sequence. For configuration admins and developers, understanding Actor Completed triggers is essential when designing, testing, and troubleshooting orchestrated process flows, because normal runtime behaviour depends on these triggers to move work from one actor to the next.

actor menu ​

In Autologyx, the actor menu is the palette of available sequence actors used while designing or configuring a sequence. It is used within sequence configuration alongside the sequence workspace, where actors such as DocAuto and Document Picker are selected from the actor menu and dragged onto the workspace to build the sequence flow. This matters because the actor menu is the starting point for adding functional steps to a sequence, enabling configuration administrators to assemble, organise, and maintain process logic efficiently within the platform.

actor Properties ​

Actor Properties is the properties dialog for a sequence actor in Autologyx, opened by right-clicking an actor and selecting Properties. It is used in sequence configuration to view and edit the actor’s settings, including core details such as the Name field used to label the actor, and it applies across actor types such as Create task, API Call, DocAuto, and Document Picker actors. For configuration admins and Super Admins, Actor Properties is important because it is the primary place to configure and maintain individual actor definitions within a sequence, ensuring each actor is correctly identified and set up for the process design.

actors ​

In Autologyx, actors are the configurable building blocks used within a Sequence to perform specific actions, process data, and connect workflows to internal logic or external services. Users add actors from the Actors panel in the Sequencer by dragging them onto the workflow canvas, then configure each actor to define how that step behaves. Actors are used across automation design for tasks such as making API calls, storing or transforming data with the Local Variable Actor, iterating through items with Loop actors, and invoking AI services through integrations such as OpenAI, Azure OpenAI, and AWS Bedrock. Actors matter because they define the executable steps in a workflow: choosing the right actor and configuring it correctly determines how data moves through a sequence, how systems integrate, and how business processes are automated end to end.

Show 4 more pages

Actors panel ​

The Actors panel is the left-hand toolbox in the Autologyx sequence configuration interface that lists available actors and lets users add them to a Sequence by dragging and dropping them onto the Sequence canvas. It is used when building or editing workflows, including when inserting components such as the API Call Actor and Local Variable Actor. The Actors panel matters because it is the primary point for selecting and placing the functional building blocks of a sequence, enabling configuration admins and other users designing processes to assemble workflow logic efficiently and consistently.

Add / Replace ​

Add / Replace is the setting used when configuring automatic document generation in the Sequencer to control how a newly generated document is stored in a Document type field on a record. In this context, Add appends the generated document to the selected field, while Replace removes the existing document from that field and stores the new one instead. This option is used as part of the trigger configuration for document generation, alongside the selected Document Field source or Field from Document Picker, and it is especially important when working with document type fields that are intended to hold generated outputs from a DocAuto actor or Document Template. Choosing the correct option determines whether documents accumulate in the field or are overwritten, and Replace should be used where the target field allows only a single file.

Add as dropdown menu ​

Add as dropdown menu is the role-selection control used when granting record access in the Autologyx platform. It is available from the Give access flow on a record’s Record access tab, where the Add people function lets users choose how the selected person should be added, such as as an Owner. This menu matters because it determines the access role assigned to the person being added, which directly affects how they are represented in the record’s owner or assignee lists and counters and what level of participation they have on the record.

Add as member ​

Add as member is an action in the User Group membership management interface that adds selected non-member users to a user group as standard members. It is available from the Actions menu for each user listed under the Non members filter, and it can also be applied in bulk by selecting multiple users and using the Add as members button. This action is used by administrators when configuring group membership, and it matters because it determines which users are included in the group without assigning owner-level control, supporting accurate access, participation, and group administration within the Autologyx platform.

Add as members ​

Add as members is the button used on the Edit User group page in Autologyx administration to add selected users to the current user group as standard members. It becomes available after one or more users are selected, typically from the Non members view or member selection list, and performs the group membership update for those selected records. This control is important for Configuration admins and Super Admins because it is the primary way to populate and maintain user groups, which in turn determines who is included in the group before any further role changes such as promoting a member to owner, demoting an owner to member, or removing someone from the group.

Add as members button ​

The Add as members button is a control in the User Group configuration area of the Autologyx platform that bulk-adds selected users to the current user group. It is used from the group’s membership management view, where administrators can select multiple users—typically from the non-members list or filtered user results—by ticking their checkboxes and then clicking Add as members to add them in one action. This button matters because it streamlines group administration, especially when configuring access for large numbers of users, and supports efficient setup and ongoing maintenance of user group membership by reducing repetitive individual additions.

Add as owner ​

Add as owner is an action available when managing a user group in Autologyx that assigns an individual non-member to the group as an owner rather than as a standard member. It is used from the Actions menu for each user listed under the Non members filter, and it applies the change on a per-user basis from the group’s membership management area. This matters because owners have elevated responsibility for the user group, so configuration administrators and Super Admins use Add as owner to control who can manage and oversee the group’s membership and administration.

Add assignees ​

Add assignees, also shown as Manage assignees, is the action used in User Group Permissions to assign specific users or groups to a permission set within the Autologyx platform. Configuration admins and Super Admins use this option from the Permissions tab, typically after creating a new permission set, to define exactly who the set applies to rather than relying only on default permissions such as Everyone. This matters because assignees determine which members or owners receive the access and capabilities granted by that permission set, making Add assignees a key step in controlling and maintaining user group access configuration.

Add Assignees panel ​

The Add Assignees panel is the Autologyx interface opened from the “+” action when configuring assignees, and it is used to select individual users to add as assignees within the platform’s assignment and permission configuration flows. It sits alongside related assignee management features such as the Manage Assignees panel and group-based assignment options, giving configuration administrators, Super Admins, and end-users a direct way to choose specific users rather than relying on user groups. This panel matters because it is the point at which named users are explicitly added to an assignee list, which affects who is included in the configured access or responsibility model for the relevant class or item.

Add button ​

The Add button is the action on the Create task screen that creates a manual Task for the current Object record in the Autologyx workspace. End-users use it after configuring the task details and reviewing the task properties and instructions, and selecting it commits the new task to the Object record rather than cancelling the setup. This button matters because it is the final control that turns task configuration into an actual tracked work item on the record, enabling users to add manual tasks directly from the task panel as part of record-level work management.

Add columns ​

Add columns is the action used in the Child Object Classes form builder component to choose which class fields are shown as columns on the child component within a record or task form. When a configuration administrator selects the required fields and clicks Add columns, the platform saves that column configuration for the component. This control matters because it determines how related child records are presented to end users, helping administrators configure clear, relevant table-style layouts that expose the right information in the form.

Add columns button ​

The Add columns button is the action used in column configuration on Autologyx list pages to add the columns selected in the column selection list to the current page layout. It is used after choosing the required columns and before clicking Save changes, as part of configuring which fields are shown and in what order on a list page. This button matters because it is the step that applies selected columns to the configurable list view, enabling users to tailor list pages to display the information most relevant to their work.

Add field panel ​

The Add field panel is the configuration panel in Autologyx used to create a new field on an Object class and to select fields when configuring Object class relationships or record list columns. It opens when an administrator clicks the + icon, and its available sections change according to the selected field type; in Object class relationship configuration it is divided into Record properties and Class fields. The panel enforces completion of mandatory settings before the Add action is enabled, and after a field is saved it remains open so additional fields can be added efficiently. This matters to Configuration admins and Super Admins because it is the primary interface for defining what data an Object class captures, exposing related data in relationships, and controlling the fields available across key platform configurations.

Add fields ​

Add fields is an option presented when creating an Object class in Autologyx that takes the user directly to the Edit Object class page so the new class’s fields can be configured. It is used in the object class creation flow, where selecting Add fields opens the first tab of the Edit Object class page to define the required fields for that Object class. This matters because object fields determine the structure of the class and the information it can store and use in create and edit views, making Add fields a key step for configuration admins and Super Admins who are setting up object classes correctly.

Add people function ​

Add people is the record access interface in Autologyx that is displayed after a user selects the Give access button on a record. It is used within the Record access area to add people to the record’s access and assignment lists, including assigning users as assignees or owners through the available add options. This function matters because it is the entry point for managing who can work on, view, or take responsibility for a record, and it updates the owner and assignee information shown in the related lists and counters.

Add permission set button ​

The Add permission set button is the action control in Autologyx used to create a new permission set within permission-management areas of the platform. It is used when configuring User Group Permissions and when adding Class permissions on an object class, typically from the Permissions tab or Class permissions tab. Selecting this button starts the setup of a new set of access rules that can then be assigned to users, user groups, assignees, owners, or other relevant roles depending on the configuration area. This matters because permission sets define who can access or act on platform objects and processes, making the button a key entry point for administrators who need to establish, extend, or manage security and operational access in Autologyx.

added column sorting ​

Added column sorting, also referred to as column sorting, is an Object records list display setting in Autologyx that applies a sort order to the columns shown in a records view beyond the default column configuration. It is used where records are presented in lists, including object record pages configured through the Display tab, and it determines how newly created or existing records are positioned in that list. This matters because list order directly affects how users find, review, and validate records: for example, when no added column sorting is enabled and the default column configuration is in use, a newly created record is added to the top of the list, whereas enabling column sorting changes the list to follow the configured sort rules instead.

Additional Authorization Headers ​

Additional Authorization Headers are a configuration option on an Autologyx Authentication Object that lets administrators define multiple key-value pairs to be included as HTTP headers on API calls made with that authentication configuration. They are used when setting up integrations, including Generic OAuth 2.0 and provider-specific authentication templates, alongside fields such as Client ID, Client Secret, Token URL, and Refresh URL. This matters because some external services require extra authorization or vendor-specific header values in addition to standard authentication settings, and configuring them on the Authentication Object ensures those headers are applied consistently wherever that object is used.

Additional colours ​

Additional colours are the configurable theme settings in Autologyx used to define interface colours beyond the core and form colour groups, and are managed on the Colours tab of the Configure Theme page. In practice, this section includes settings such as Navigation panel background colour, which controls the background colour of the main menu on the left-hand side of the platform, and works alongside other colour control fields such as Primary colour, Secondary colour, and Section content background. Additional colours matter because they allow Configuration admins and Super Admins to refine the visual presentation of the user interface, align the platform with organisational branding, and improve the consistency and usability of key navigation and content areas.

additional instructions ​

In the Autologyx platform, additional instructions are the optional guidance entered when assigning a manual task to provide the recipient with extra context or direction for completing that task. They are used as part of the task creation mechanism when creating manual tasks, including tasks assigned to 1 time completion users, and are displayed at the top of the task form when the user opens the task. Additional instructions matter because they let configuration admins and task creators communicate task-specific requirements, clarifications, or next steps directly within the task experience, helping end-users complete work correctly and consistently without changing the underlying form design.

Additional Parameters ​

Additional Parameters are optional authentication settings in an Autologyx Authentication Object, stored in the configuration as a JSON object and injected into the authentication request when the platform requests or refreshes access tokens. They are used primarily with the Generic OAuth 2.0 template to supply setup-specific values that are not covered by the standard pre-configured fields such as Client ID, Client Secret, Token URL, or Refresh URL. This matters to configuration administrators and integrators because Additional Parameters let an authentication setup be tailored to provider-specific requirements without changing the core template, helping ensure the external service receives all required request values for successful authentication.

additional permission sets ​

Additional permission sets are configurable permission entries on an Object class that extend access beyond the primary class permissions in Autologyx. Used in System Configuration when editing an Object class on the Data Model tab, they are available as Class additional permission sets and Record additional permission sets, and are managed from the kebab or Actions menu. These settings let configuration administrators define extra permissions for the Object class itself, for Object records, and for tasks associated with those records, making them important when designing precise access control for actions such as assigning, deleting, or managing owners and assignees without changing the core permission model for the class.

Admin email signature ​

Admin email signature is the company-level email signature text configured in Company details within the Administration tab of the Autologyx platform. It is used as a merge-field value in outgoing messages, including standard message templates, so administrators can insert a consistent signature block into communications without rewriting it in each message. This matters because it centralises control of signature content, supports consistent branding and contact information across communications, and allows configuration admins and Super Admins with the appropriate Company Details edit permission to update the signature once and have that standard content available wherever the merge field is used.

admin managed add ins ​

Admin managed add ins are the centrally controlled add-ins repository or deployment area used by Autologyx administrators to make integrations such as the Catalyst Word Add in available to users across the platform. This is used during platform and Microsoft 365-style add-in configuration by Super Admins, Configuration admins, or other System Administrators with the appropriate permissions, who configure the add-in and publish it through the admin managed add ins so end users can access it without individual installation. It matters because it provides governed, organisation-wide distribution of supported add-ins, ensuring the right tools are enabled consistently, securely, and under administrative control.

Administration ​

Administration is the Autologyx platform area used by Super Admins and configuration administrators to manage global platform settings and access to core system features. It is accessed from the main navigation and contains functions such as managing users, roles and user groups, configuring authentication and user activation rules, maintaining authentication objects and single sign-on settings, and other one-time system-wide configuration items. Administration matters because it controls who can access the platform, which administrative areas each user can use, and how shared configuration is applied across all applications in the system.

Show 4 more pages

Administration Sections ​

Administration Sections are the areas within the Autologyx Administration section used to manage system-wide environment settings and user governance. They are accessed from the left-hand navigation menu by Super Admins or users whose role grants administration permissions, and they present the available administration areas as links or tiles, such as Company details, User groups, Standard authentication, Single sign-on settings, Authentication objects, and single or multiple page configuration. In practice, these sections are where configuration administrators control who can access the platform, how authentication is handled, and key organisational settings, separate from Workspace activity and solution building in System configuration. They matter because access to specific Administration Sections determines which parts of the platform a user can manage and therefore governs essential operational, security, and organisational setup in Autologyx.

Administration tab ​

The Administration tab is the area of the Autologyx platform used to control organisation-level configuration and access to key administrative settings. It is primarily used by Super Admins and configuration administrators, and it is where role-based permissions are enabled for functions such as Authentication Objects, Single sign on settings, and Company Details. Access to related pages and actions is governed by permissions granted under the Administration tab, including the ability to view, create, edit, and maintain authentication and sign-on configuration. This matters because it is the central point for managing security, identity, and company-level settings, ensuring that only authorised users can configure platform behaviour and maintain critical administrative data.

Administration tab of System permissions ​

INSUFFICIENT_EVIDENCE

Administration tiles ​

Administration tiles are the clickable option cards shown on the Administration landing page in Autologyx that group key configuration and management areas into sections and provide direct actions for each area. They are used by Configuration admins and Super Admins to open administration functions such as Company details, Roles, Authentication Objects, single sign-on settings, mail service credentials, and outbound mail setup, with tile buttons such as Configure for single-page settings and Manage for areas that open a listing where records such as Users and Roles can be created, edited, or deleted. The set of tiles displayed depends on the permissions in the user’s Role, with broader access and additional tiles available to Super Admins. Administration tiles matter because they are the main entry point for platform administration, determining how authorised users navigate to and perform setup, maintenance, and governance tasks across the Autologyx environment.

Administration/ Authentication objects ​

Administration/ Authentication objects is the Autologyx administration area where authorised users manage Authentication Objects, which store and control the credentials and connection settings used to integrate external services with the platform. It is accessed from the main navigation under Administration, where the Authentication objects list provides the entry point to create and edit these records. This area is used by Super Admins and configuration administrators when setting up integrations such as DocuSign, because the authentication object created here is required for the platform to authenticate securely with the external provider and enable the related service configuration to function correctly.

Administration/ Elements ​

Administration/ Elements is the administration area in the Autologyx platform where Super Admins create, configure, and manage Elements. Accessed from the main navigation as Administration > Elements, this area provides the Elements list and actions such as Create and Import, and is used to define an Element project, supply required Element parameters, and configure integration settings such as config.json, Enable, and Git repository connection details including repository URL, username, and token. This area matters because Elements are configured and maintained here before they can be used in the wider platform, making it a core workspace for configuration admins responsible for preparing and controlling Element availability within the Catalyst system.

Administration/ Users ​

Administration / Users is the administrative area in Autologyx where Super Admins and other configuration administrators access the Users list to create and manage user accounts. Reached from the main left-hand menu, this section is used to add new users, review existing accounts, and work with user settings and lifecycle details that connect to related functions such as the Create user page, account type selection, account status management, activation email handling, and account activation. It matters because it is the central control point for granting platform access, defining how individuals sign in and interact with Autologyx, and maintaining accurate user administration across the environment.

Adobe oAuth 2.0 (Client Credentials flow) ​

Adobe oAuth 2.0 (Client Credentials flow) is a supported Authentication object provider in the Autologyx platform used to store and manage the credentials required for server-to-server authentication with Adobe services using the OAuth 2.0 client credentials grant. It is configured in the Authentication objects area by users with the appropriate administrative permissions and the provider-specific technical details, alongside other supported providers such as Box and Generic OAuth 2.0 options. This provider matters because it supplies a reusable, centrally managed authentication configuration that Autologyx can use when making API calls to Adobe-connected services, helping configuration admins, super admins, and integrators standardise external service access and maintain secure, consistent connection settings across the platform.

AI Actors ​

INSUFFICIENT_EVIDENCE

AI engines ​

AI engines are the selectable AI models available within Sequencer for use in Autologyx automation steps that generate or process content with AI. They are used when configuring Sequencer actions and are surfaced through platform integrations such as the AWS Bedrock actor, Bedrock provider, and OpenAI: GPT actor, alongside model settings including max tokens, temperature, and standard controls. AI engines matter because they determine which model executes a task, directly shaping how a configured workflow behaves and enabling administrators and end-users to choose the most suitable model for each automation scenario.

AI models in Sequencer ​

INSUFFICIENT_EVIDENCE

Alias ​

In Autologyx, an Alias is the unique technical identifier for a form or object class field, initially auto-populated from the field Label when the field is created but editable at that stage; unlike the label, it does not automatically change later if the label is updated. Aliases are configured when building task forms, standalone forms, and object class fields, and they must be unique within the relevant scope, with object class field aliases also subject to a 50-character limit. The Alias is used wherever the platform needs a stable field key rather than display text, including merge fields, task responses, API requests and responses, document templates, and data and analytics outputs such as reporting. This makes it essential for administrators, integrators, and reporting users because a well-chosen alias ensures consistent field mapping, reliable integrations, and clear downstream data usage even when visible field labels are duplicated or changed.

Show 1 more pages

All complete tasks ​

In Autologyx, All complete tasks is a Delete Target option used when configuring the Set Task actor to remove only the finished tasks for a selected task template within a record. It is used in task-management automation where administrators need to clean up completed task instances without affecting active or pending work. This option matters because it lets configuration admins precisely control task deletion scope, helping maintain accurate record history and task lists while avoiding the removal of outstanding tasks that still require action.

All completed tasks ​

In Autologyx, All completed tasks is a selection option used when configuring the Set Task Actor to target previously created tasks for a specific task template on the record that triggers the actor. When this option is selected, every task matching that template that is already in a completed state is included in the action, such as deletion, while outstanding tasks are left unchanged. This matters to configuration administrators and Super Admins because it provides precise control over task housekeeping and process behaviour, allowing completed task history for the selected template to be cleared without affecting active work.

all following rules ​

In Autologyx, all following rules is the filter-combination option used in Loop actor configuration to require every configured filter rule to be satisfied before an item is included in the loop. It is used when defining multiple filters for the Loop actor, alongside the alternative any following rules setting, and it applies AND logic across the rule set. This matters because it gives configuration admins precise control over which records or items are processed by the loop, helping ensure that only items matching the full set of required conditions are selected and presented for downstream automation or user interaction.

All outstanding tasks ​

All outstanding tasks is a delete option in the Set Task actor that removes every incomplete task associated with the selected task template on the specific record that triggered the actor. It is used when configuring sequence logic in System Configuration, including scenarios such as withdrawing a client from onboarding and clearing unfinished work without deleting completed task history. This option matters because it lets configuration and super administrators precisely clean up active tasks at record level, ensuring automations remove only open tasks for the chosen template while leaving completed tasks and unrelated tasks unchanged.

All tasks ​

In Autologyx, All tasks is a Delete Target option in the Set Task actor that deletes every task in a record for the selected task template, regardless of status. It is used when configuring a Delete action, alongside more targeted options such as All complete tasks, All outstanding tasks, and the most recent task variants. This option matters because it performs a full removal of all matching tasks for that template within the record, making it the broadest task-deletion scope and an important setting when designing or administering workflow behaviour.

Allow Selecting Individual Members ​

Allow Selecting Individual Members is a field configuration option for User type Class fields and related User type fields in Autologyx that lets end users choose specific users from within a selected User Group instead of using the group only as a whole. It is used when configuring object class fields that support user group selection, and when enabled the field presents available User Groups and then allows the end user to pick the individual members who should be included. This setting matters because it gives configuration admins finer control over how user-based selections work and gives end users a more precise way to assign or involve the right people for a task, review, or process step; when used without Allow Syncing Group Members, the selected group acts as the source from which individual members are chosen.

Allow Syncing Group Members ​

Allow Syncing Group Members is a configuration option for User Groups on User Type and User Type Class fields that lets end users select a whole group as one entity instead of selecting users individually. It is enabled on the field definition in object class configuration and is then used in create and edit views, where available groups are shown in the field, can be expanded to show members, and include a Sync group members toggle. This setting matters because it controls how group-based assignment and selection behave in the user interface: administrators use it to determine whether users can work with groups directly, and end users use it to add a complete group in a single action, either on its own or alongside individual-member selection when both options are enabled.

allowed domains list ​

INSUFFICIENT_EVIDENCE

ALX ID ​

ALX ID is the system-generated unique identifier assigned to a record when it is created, and it is also used as the default Identifier for an Object class when no other field has been designated for that purpose. In Autologyx, ALX ID is shown across record forms and properties, in Records lists, in child and relational record selection controls, and as the unique ID shown for document templates in template lists. It matters because it provides a consistent, platform-level reference for locating, distinguishing, sorting, and displaying items, especially in configurations where no business field has been set as the primary Identifier or where users need a reliable internal ID to work with records and templates.

Show 1 more pages

Analysts ​

Analysts are users such as analysts and solution designers who build or extend applications and workflows in the Autologyx platform. In the documentation, this role is used in the Getting Started guidance as the audience for the Building applications (Analysts) path, which is intended for people designing processes or planning new applications rather than carrying out day-to-day operational work or managing global platform setup. This matters because it directs configuration-focused users to the documentation most relevant to application design and workflow construction, helping them start with the correct guidance for shaping how work is structured and delivered in Autologyx.

Analytics Database ​

The Analytics Database is an Autologyx data layer that consolidates operational and historical platform data into a single analytics-ready store through an ETL process, and is built on ClickHouse. It is used by organisations with the feature enabled to connect standard BI tools to Autologyx data for reporting, trend analysis, and deeper examination of platform activity over time. In practice, it brings together information that would otherwise be split across sources such as the Resource Database and History Events Database, giving administrators, analysts, compliance teams, and integrators a unified view for audit trails, performance monitoring, and business insight. This matters because it links day-to-day process execution with long-term outcomes, making Autologyx data easier to query, govern, and use for informed decision-making.

Analytics Database API ​

AND conditions ​

any following rules ​

In Autologyx, any following rules is the logical matching option used when combining multiple filters in Loop actor configuration, so that the filter set passes when at least one of the defined rules is met. It is used where configuration admins build Loop actor filter criteria, alongside the alternative all following rules option, to control how items are selected for processing within a loop. This matters because it broadens the match condition from requiring every filter to match to allowing a single qualifying condition, which directly affects which records, cases, or items the loop includes and therefore how the workflow behaves for both administrators configuring automation and end-users interacting with its results.

API ​

API in the Autologyx platform is the application programming interface used to exchange data and automate actions between Autologyx and other systems. It is used when integrating external applications, passing data captured in Catalyst forms to third-party services, and performing platform operations that are not configured directly in the user interface, such as assigning Object Class record permission sets through Record Access actors or the API. For developers, integrators, and platform administrators, the API matters because it provides the controlled mechanism for connecting Autologyx to wider business processes, moving data into and out of applications, and supporting advanced configuration and automation scenarios across records, forms, and permissions.

API Account ID ​

API Account ID is the DocuSign account identifier used in Autologyx API configuration as part of the URL for outbound API calls from Catalyst. It is used alongside the Account Base URI in DocuSign Authentication Objects and related integration settings to ensure requests are directed to the correct DocuSign account. This value is especially important for configuration admins and integrators when setting up a DocuSign connection and when performing system migrations, because the API Account ID can differ between environments and must be updated or mapped correctly for calls to succeed against the intended account.

API actor names ​

API actor names are the displayed names of the API actors included in a Sequence in the Autologyx platform. They are shown in the Sequences list as a dedicated column when a Sequence contains one or more API actors, allowing configuration administrators and Super Admins to quickly see which integrations or API-driven steps are part of that Sequence without opening its design. This matters when reviewing, comparing, and managing Sequences, because the API actor names provide an immediate view of the external or automated actions configured within a process and help identify where API calls are being used.

API Actors ​

API Actors are sequence components in the Autologyx platform that execute external API interactions as part of workflow automation, using configured authentication objects to obtain and refresh access tokens securely without exposing sensitive credentials to users. They are used within Sequences and related Task Group Template designs to connect Autologyx to external providers and services, such as document management or eSignature platforms, and are surfaced in administration and list views through fields such as API Actor Names and # of API Actors. API Actors matter because they are the mechanism that enables secure, reusable integrations inside process automation, allowing configuration admins, developers, and super admins to build, monitor, and manage API-driven workflow steps consistently across the platform.

Show 1 more pages

API Call (JSON array output) ​

API Call (JSON array output) is a Loop actor data source in Autologyx that lets a workflow iterate over each item in an array returned by a previously tested API Call. It is used when configuring Loop actor behaviour for integrations that return lists of records, such as matters, documents, or other external data, and the platform exposes the API response in the Loop configuration through the JSON Explorer so administrators and developers can select the correct array and apply filters to control which items are processed. This matters because the Loop actor depends on a valid tested API response and the correct array path to drive item-by-item automation reliably, enabling precise processing of external datasets while isolating failures to the current iteration only.

API Call actor ​

The API Call actor is an Autologyx Sequencer actor used to send HTTP requests to external systems and services from within a sequence, making it a core tool for integrations, automation, and advanced workflow design. It is added from the Actors panel and configured in the configuration panel, where administrators and integrators define request details such as the endpoint, method, parameters, data type, authentication, and file handling, including support for form data, binary data, multipart requests, and document retrieval. The actor is commonly used to send or retrieve data, trigger external processes, synchronise systems, download files, work with providers such as DocuSign and iManage, and interact with Autologyx itself when no native actor is available. It also works closely with Authentication Objects and downstream actors such as Local Variable, Document Picker, and Update Record, because its outputs can be reused to drive later steps in a sequence.

Show 10 more pages

API Call Actors and Debugging ​

API Call Actors and Debugging describes the use of the API Call Actor within a Sequence to diagnose and resolve integration or workflow issues by making and reviewing HTTP requests to external systems or Autologyx endpoints during execution. In Autologyx, this term is most relevant when configuring and testing API Call actors in the Actors panel and when examining related runtime information such as API test call history, activity logs, and downstream behaviour including Actor Completed triggers. It matters because the API Call Actor is a core integration mechanism in the platform, so understanding how to use it for debugging helps configuration admins and developers validate request and response handling, isolate failures in connected services, and confirm that sequence logic and integrations are operating as intended.

API Call document ​

An API Call document is a document output made available by a preceding API Call actor and exposed in the Autologyx platform as a selectable source in the Document Picker actor. It is used when a sequence has already retrieved or generated a document through an API integration and that document then needs to be selected, stored, or passed into later steps in the workflow. In the Document Picker actor’s Source field, “API Call document” is available when the sequence context includes a prior API-based document source, alongside other source types such as Document Field and DocAuto Actor. This matters to configuration admins and developers because it is the mechanism that connects externally retrieved documents, such as signed files returned from an integration, into standard Autologyx document handling so they can be captured and used consistently within the case or task process.

API Call logs ​

API Call logs are the platform records for API interactions in Autologyx, used by developers, integrators, and administrators to review the details of requests and responses when testing or working with API-based integrations. They are surfaced in API testing and related call history views, including the API Call test log, where response body information is available to provide a more complete record of each call. API Call logs matter because they support integration validation, troubleshooting, operational review, and auditability by giving users a clear view of how API calls executed and what data was returned.

API Call name ​

In Autologyx, the API Call name is the unique identifier assigned to an API Call Actor within a Sequence. It is configured as part of the actor setup and must be unique within that Sequence so each call can be clearly distinguished from others. The platform stores this name as backend metadata and uses it in debugging and log review, making it an important reference when troubleshooting integrations, tracing execution, and interpreting API-related history and activity across the platform.

API Call Output ​

API Call Output is a data source in the Autologyx platform that exposes the response returned by an API Call actor for use in the next step of a workflow. It is used in configuration, particularly when a Local Variable actor is placed immediately after an API Call actor, allowing the variable to be populated from values in the API response. This is important for configuration admins and developers because it enables external system data to be captured, mapped, and reused by downstream actors, supporting scenarios such as setting variables, creating new owners, and passing integration results through a process without manual input.

API Call template ​

An API Call template is a preconfigured Sequencer template in Autologyx that provides the structure for building API-based actions, and in the iManage integration it is surfaced as a dedicated template tailored specifically for iManage when that integration is enabled. Configuration admins and developers use this template in the Sequencer to add and configure iManage-connected steps without creating the API call pattern from scratch, aligning the step with the platform’s integration framework and the relevant iManage integration settings. It matters because it speeds up configuration, standardises how external API interactions are added to journeys, and helps ensure iManage-related automation is implemented consistently within Autologyx.

API Call test log ​

The API Call test log is the Autologyx log view used when testing API call configurations, showing the details and results of a test execution so developers and configuration admins can validate integrations and troubleshoot issues before or during deployment. It is used alongside API Call logs and API Test Call History, particularly when working with API-based actions such as the iManage API Call actor, and includes response content with formatted, beautified responses to make output easier to inspect. This matters because it gives users a clear record of how a configured API call behaved, helping them confirm request and response handling, identify errors quickly, and refine API configurations with greater speed and accuracy.

API calls ​

API calls are Sequencer actors used in Autologyx to connect workflows to third-party systems and to move or transform data within the platform, including copying data between object classes, extracting values from JSON responses, and triggering downstream processing when records are created or updated. They are configured in sequence design alongside other actors such as Send Message and Local Variable, where admins and integrators define the request URL, parameters or body, authentication object, and dynamic values using constants, local variables, and merge fields. API calls matter because they enable secure system integration, real-time workflow automation, and data-driven sequence logic, allowing records, child records, messages, documents, and external services to work together as part of a single automated process.

Show 11 more pages

API configuration ​

API configuration is the platform configuration that defines how an Autologyx integration connects to an external service, including which authentication object it uses and the service-specific connection details such as host selection, API Account ID, and Account Base URI. It is used by configuration administrators, Super Admins, and developers when setting up or changing integrations and is especially important during system migrations, where API configurations can be mapped to the correct authentication objects for each environment. This matters because the API configuration determines which account and endpoint the platform uses, ensuring integrations point to the correct test or live service and operate with the intended credentials.

API endpoints ​

API endpoints in Autologyx are the defined web service routes that developers and administrators use to programmatically interact with platform features, including the newer endpoints introduced for managing User Groups within Record Permission Sets. These endpoints are used in integrations, automation, and administrative configuration to assign or unassign User Groups, work with group IDs, and update access control without relying on manual UI actions. They matter because they provide a precise, scalable way to manage permission changes, preserve compatibility with existing user-based endpoints, and support consistent control over how permissions are applied and inherited across records and groups.

API for delaying user account activation ​

API for Groups in Record Permission Sets ​

API for Groups in Record Permission Sets is the Autologyx platform capability that allows groups to be assigned to Record Permission Sets through API-driven configuration, extending record-level access management beyond manual setup in the user interface. It is used when configuring or automating security and access controls for records, particularly in environments where permissions must be applied consistently at scale across teams, roles, or organisational units. This capability matters because it enables configuration admins, super admins, and integrators to manage record access more efficiently, support repeatable deployment and provisioning processes, and align Record Permission Sets with broader group-based access models used elsewhere in the platform, including related permission set and assignment configurations.

API Keys ​

API Test Call History ​

API Test Call History is the log view used with the API Call Actor in Autologyx to display the history of test calls made while configuring and validating an API integration. It is accessed from the actor configuration by selecting Show Log, which opens the API test call history window, and is intended for configuration administrators and developers or integrators who need to review previous test executions during setup and troubleshooting. This history matters because it provides a dedicated place to inspect and compare test-call activity when refining API Call Actor configuration, supporting faster debugging and more reliable integration behaviour before the actor is used in live processes.

Append assignees ​

Append assignees is a Record Access actor configuration option in Autologyx that adds the selected assignees to an existing record permission set without replacing current access assignments. It is used when configuring record-level access in areas such as the Record Access actor and related permission set assignment settings, where administrators choose a permission set and then specify assignees from Users, User groups, or a Field value. This option matters because it lets Configuration Admins and Super Admins extend access to additional users or groups while preserving existing assignees, making it the correct choice when access must be broadened without disrupting permissions already granted on the record.

append option ​

Append option is a Record Access actor configuration setting in Autologyx that adds additional owners or assignees to a record’s access permissions without removing the users, groups, or field-based assignments that are already in place. It is used by configuration administrators and Super Admins when defining record ownership updates by user selection or by field, and is available alongside other action types such as remove, set if empty, and override. This option matters when you need to extend access incrementally, preserve existing ownership, and avoid replacing current assignees, while also ensuring that each configuration for a permission set uses a single action type rather than mixing append with override.

Append task assignees ​

Append task assignees is a Task Assignment Actor setting in Autologyx that adds the users selected in the actor to the task’s assignee list without replacing the default assignees defined in the sequence properties. It is used when configuring task assignment behaviour in a sequence, specifically within the Task Assignment Actor, and works alongside other assignment methods such as assigning by users or by field. This setting matters because it lets configuration administrators extend the set of people responsible for a task while preserving the baseline assignment model defined at sequence level, ensuring the right users are included for delivery, oversight, or collaboration.

Applicable to object classes ​

Applicable to object classes is a searchable multi-select field used when creating or editing a Task Group Template in Autologyx to specify which object classes the template can be associated with. This setting is used by configuration administrators and Super Admins in task group template configuration, where it controls the scope of the template by linking it to one or more object classes in the platform’s data model. Defining applicable object classes matters because it ensures the template is available only in the correct business contexts, supports accurate template selection in task group template lists and related configuration areas, and helps maintain consistent, relevant task setup across different object types.

Application ​

application iframe ​

An application iframe, or iframe, is the embedded runtime container in Autologyx where an Element’s code executes within a form, receiving message data passed from Catalyst. It is used when configuring Elements, including passing values entered in Element properties or Element Details into the embedded application so the Element can render and behave correctly in the user interface. This matters to developers, integrators, and configuration admins because the application iframe is the mechanism that connects Element configuration to the live embedded experience, including ongoing updates such as refreshed access tokens and updated message data during form use.

Applied AI ​

Applied AI is the Autologyx platform’s set of AI-provider integrations and related capabilities that bring generative AI functions directly into workflows and processes. In product documentation and platform configuration, it appears as a distinct integration category alongside standard business system integrations, where administrators can view, request, enable, and manage providers such as OpenAI: GPT, OpenAI: Embeddings, Azure OpenAI, and AWS Bedrock through centralised integrations management. Applied AI matters because it provides the foundation for AI-powered automation features, including capabilities such as embeddings in Sequencer, and allows configuration admins, super admins, and developers or integrators to activate the services required to embed advanced AI functionality into Autologyx solutions.

Apply filter ​

Apply filter is the action control in the Autologyx list page filter editor that runs the currently defined filter conditions against a list and refreshes the page to show only matching items. It is used on list pages after the user has completed the filter fields, and it is enabled only when every condition is fully defined. This control matters because it is the point at which filter criteria are executed, allowing end-users to narrow large result sets to the records they need and helping configuration admins understand the expected behavior of page controls within filtered results workflows.

appropriate permissions ​

INSUFFICIENT_EVIDENCE

approval workflows ​

In Autologyx, approval workflows are configurable process controls that route critical documents and decisions through defined approval steps using authorised approvers. They are used when designing and managing complex processes, typically by Configuration admins and Super Admins, and are configured in conjunction with User type fields and related field configurations to identify and assign the correct approvers. Approval workflows matter because they enforce the correct approval channels within a process, helping ensure that actions requiring authorisation are reviewed and approved by the right users before the work can proceed.

ascending or descending order ​

  • Mostly relevant to: End-users, Configuration admins
  • Closely related concepts: sorting, Records list

In the Autologyx platform, ascending or descending order is the sort direction applied when arranging records in a Records list by a selected field. It is used with the sorting feature to organise data values from low to high or earliest to latest in ascending order, or from high to low or latest to earliest in descending order, across supported field types such as integer, date, text, single select, phone, and e mail. This matters to end-users and configuration admins because choosing the correct sort order makes lists easier to review, prioritise, and navigate, helping users find the most relevant records quickly and present data in a consistent, task-focused sequence.

Assign all ​

Assign all is a class permission in Autologyx object class configuration that gives a user the ability to assign any task within that object class, and it automatically enables the related View all and Complete all permissions for the same class. It is used by configuration administrators and Super Admins when defining class permissions for users who need broad operational control over work in a class. This permission matters because it expands task management access beyond assignment alone, ensuring the user can also see and complete all tasks in that class, so it should be granted only where full class-level task handling is required.

Assign all permission ​

INSUFFICIENT_EVIDENCE

Assign User Groups ​

Assign User Groups is the Autologyx API operation used to add one or more User Groups to a Record Permission Set by submitting a list of group IDs. It is used by developers, integrators, configuration admins, and Super Admins when configuring access control through API endpoints that manage the groups assigned to permission sets. This operation matters because it determines which groups receive the access defined by the Record Permission Set, enabling administrators and integrations to apply permissions consistently and at scale without manual assignment.

assigned User Groups ​

Assigned User Groups are the User Groups currently linked to a Record Permission Set in Autologyx, defining which groups receive the access rules and permissions configured in that set. This term is used when viewing or managing Record Permission Set membership, including through the API endpoints introduced for groups in Record Permission Sets, where administrators and integrators can check which groups are assigned, add new group assignments, or remove existing ones using group IDs. Assigned User Groups matter because they are the direct connection between permission configuration and the users who inherit it, so maintaining the correct assignments is essential for accurate access control, controlled permission changes, and reliable automation in platform administration and integration workflows.

assignee avatars ​

Assignee avatars are the visual icons shown on a permission set in Autologyx to represent the users and user groups assigned to that set when configuring class permissions for an object class. They are used in the Object class editor, including the Permissions tab and Manage assignees side panel workflow, where they appear on newly created or updated permission sets to provide an immediate view of who has been assigned. In this display, user groups are shown first with square avatars and individual users are shown with round avatars. Assignee avatars matter because they give Configuration Admins and Super Admins a fast, at-a-glance way to verify assignee composition while adding, removing, and reviewing access for object classes and related record permission settings.

Assignees ​

Assignees are the users or user groups assigned to a class permission set, record permission set, or specific task in Autologyx, and they receive the access or capability defined by that assignment immediately. They are managed in places such as Object Class Permissions, the Manage assignees panel, the Record access tab, and task-related configuration, where administrators or authorised users add or remove assignees to control who can work with object classes, records, and tasks. Assignees are distinct from Owners: a record has a single Owner but can have multiple Assignees across one or more permission sets. This matters because assignee configuration is a core mechanism for granting operational access, controlling who can view or act on records and classes, and ensuring work is available to the correct users and groups.

Show 6 more pages

Assignment of stages ​

Assignment of stages is the section on the Create task screen for a Manual Task on an Object record where the user assigns responsibility for completing the task stages to one or more users. In this section, the task creator searches for and selects the users who are expected to complete the task, linking stage execution to specific people in the workspace. This is used when creating a manual task for an object record and is important because it determines who receives and performs the work, ensuring the task is directed to the correct users and that stage ownership is clear for both end-users and configuration administrators.

Associate Child Records With Existing Parent Records ​

Associate Child Records With Existing Parent Records is the Autologyx capability used to link an already existing child record to a parent record within a relational record structure, so that related work, data, and context are connected without creating a new child record. It is used in the workspace when working with relational records, alongside actions such as creating child records from a parent and interacting with associated child records through the parent record. This matters to end-users because it lets them bring existing related records into the correct parent-child relationship for easier navigation and management, and to configuration admins because these relationships shape how records are organised and presented across the platform.

Associate with Catalyst record ​

Associate with Catalyst record is an action in the Autologyx iManage integration that links an iManage folder to the current Catalyst record from within the iManage component. It is used when viewing the iManage area on a record, where a user can right-click a folder and select Associate with Catalyst record to assign that folder directly to the record. This matters because it establishes the record’s iManage folder assignment in the place where users manage document locations, helping end users connect the correct workspace or folder to a record and enabling configuration admins to support a streamlined document management experience within the default iManage screen.

associated child records ​

Associated child records are records linked to a parent record through a parent/child relationship defined in the Autologyx Relational modeller. In the workspace, they are used when interacting with relational records via the parent record, where users can view a child record summary, open child records in a flyout, and recurse through child and grandchild records from the parent context. For this to work, configuration admins must model the relationship and add the relevant child object classes to the parent object class create/edit view, and users must have permission to view each object class involved. Associated child records matter because they let users navigate and work with related data in context, making complex relational structures accessible directly from the parent record.

asynchronous processing status ​

Asynchronous processing status is the platform status returned for a submitted operation that Autologyx accepts immediately and completes in the background, particularly when using the hierarchical record creation endpoint. It is used through the transaction status link provided in the initial response, which integrators call to monitor whether the request is waiting to be processed or has moved through subsequent processing states. This status matters because it is the mechanism developers and integration services use to track completion of long-running requests, coordinate follow-up actions, and handle API workflows correctly when the result is not available in the original response.

Attachment option ​

In Autologyx, an Attachment option is the selectable item shown to a user when a document is available to be included with an outgoing message. It is used in message-sending steps, such as when a Send Message Actor is connected to a Document Picker actor in a workflow, where generated documents are presented as attachment choices that the user can tick for inclusion in the email. This matters because it is the point where documents produced elsewhere in the process, including automatically generated documents from templates, become available for delivery to recipients, ensuring the correct files can be attached as part of the configured communication flow.

audit trails ​

Audit trails in the Autologyx platform are the recorded history of actions and changes captured as historical events, providing a traceable record of activity such as permission changes and field level updates. They are used through the platform’s historical event data, including the History Events Database within the Analytics Database, where administrators and compliance teams can review past activity, query operational changes, and analyse how users, user groups, and configuration settings have been modified over time. Audit trails matter because they support governance, security, and operational oversight by making it possible to track who changed what, understand the sequence of platform activity, and validate that processes and access controls are being managed correctly.

Auth Object ​

An Auth Object, also called an Authentication Object, is a configured authentication resource in Autologyx that an API Call actor uses to apply stored credentials when making an external API request. It is selected in the API Call actor’s Authentication setting, where choosing Auth Object enables you to pick from the Authentication Objects already configured in the system; this is also the option used in integration setups such as DocuSign API calls. An Auth Object matters because it determines which credentials the platform uses for the request, affects how the action is recorded in the Activity Log under the associated user, and can influence downstream platform behaviour when API calls update Autologyx records and trigger record-based Sequences.

Authentication ​

Authentication in Autologyx is the platform capability and configuration used to control how users sign in and how system-to-system communications prove identity when accessing protected resources. It is managed in the Administration area as part of environment-wide identity, sign-on, and communication settings, including Authentication Objects used by integrations. Authentication is also used directly in configuration of the API Call actor, where the Authentication field determines whether a request uses a configured Auth Object or no authentication, making it a core dependency for secure external API connections. This matters to Super Admins, configuration administrators, and developers because correct authentication setup governs access to shared platform services, enables integrations to connect successfully, and ensures requests are sent with the appropriate security context.

Authentication client credentials flow ​

Authentication client credentials flow is the OAuth 2.0 authentication method used in Autologyx to let the platform obtain an access token for calling external APIs as an application rather than as a signed-in user. In Autologyx, it is used when configuring an Authentication Object, including the Microsoft oAuth 2.0 (Client Credentials flow) provider, where configuration admins and integrators supply values such as Tenant, Client ID, Client Secret, and Scope so API calls can be authorised correctly. This flow matters because it provides the credentials Autologyx needs to connect securely to Microsoft services and other supported endpoints, and it is a key part of setting up, testing, and operating integrations that run in the background without user interaction.

authentication configuration ​

Authentication configuration in the Autologyx platform is the set of settings and selectable options that define how users and user types authenticate to the system, including the authentication methods available through authentication method management and related Authentication Objects. It is used in administrative and integration contexts where Configuration admins, Super Admins, and developers review or control sign-in behaviour, including through enhanced OPTIONS responses that expose supported authentication settings. This matters because it gives platform owners clearer visibility and tighter control over how access is secured, governed, and aligned with organisational security and compliance requirements.

authentication enforcement logic ​

Authentication enforcement logic is the Autologyx platform behavior that applies the configured authentication method rules for each User Account Type, determining whether a user can sign in with username and password, Single Sign On (SSO), or both. It is used in system configuration when administrators manage authentication methods by user account type, and it is executed during login attempts and password reset processes to ensure each account follows the correct access policy. This matters to Configuration Admins and Super Admins because it governs how internal staff accounts, external users, Config Admin users, and other accounts with full platform access are authenticated, helping enforce security requirements, maintain consistent access control, and align user sign-in experience with organisational identity management settings.

Authentication Error ​

Authentication Error is an Autologyx error shown when a service that relies on stored authentication details cannot log in because the credentials in the associated Authentication Object are incorrect. In the platform documentation, this term is used in Outbound mail setup, where it is returned during mail configuration and testing to indicate that the username, password, or other authentication details entered for the mail service are invalid, distinct from a Connection error caused by host, port, or TLS settings. This matters to Configuration Admins and Super Admins because it identifies that the fix is to review and correct the authentication configuration rather than the network or transport settings, helping restore successful outbound email setup and operation.

Authentication menu ​

INSUFFICIENT_EVIDENCE

authentication method management ​

Authentication method management in Autologyx is the configuration and API-supported control of which login methods are permitted for different user types. It is used in authentication configuration, particularly through the enhanced OPTIONS response, which exposes detailed field information so administrators and integrators can programmatically inspect and set the allowed login methods defined in Authentication Objects. This matters because it gives Configuration Admins, Super Admins, and developers a consistent way to enforce the correct sign-in experience for each class of user, align platform access with security and identity requirements, and automate authentication setup through integrations and configuration tooling.

Authentication Methods ​

Authentication Methods are the platform configuration options that define how Autologyx verifies identity when connecting to external systems or services. In Autologyx, they are used within system configuration and in integration setup such as the API Call actor, where administrators select the appropriate method for a chosen source when configuring actions like Sequencer file download. This matters because the selected authentication method controls how securely and successfully Autologyx can access external resources, and it must align with the source system, account type, and overall system configuration used by configuration admins, super admins, and developers or integrators.

authentication methods by user account type ​

Authentication methods by user account type is the Autologyx system configuration capability that lets administrators define and enforce which sign-in methods are permitted for each category of user account, such as internal staff, external users, full-platform accounts, and configuration administrators. In the platform, this is used in system configuration and exposed through API-based configuration introduced in version 11.2.0, enabling organisations to align authentication controls with the access profile and security requirements of different account types, including SSO and other supported authentication options. This matters because it allows precise authentication enforcement logic across the tenant, helping configuration teams and security stakeholders apply stronger controls to sensitive account types, maintain consistent access policies, and support compliant, role-appropriate access to the platform.

Authentication Object API Keys ​

  • Mostly relevant to: Super Admins, Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
  • Closely related concepts: Autologyx Catalyst, Object classes

Authentication Object API Keys are a feature in Autologyx Catalyst that provides a secure way to create, manage, and use API keys within the platform’s object model. Used by super admins, configuration admins, and developers or integrators, these keys support controlled access for integrations and platform interactions that require key-based authentication. As an object-based capability, API Keys fit into the broader Autologyx approach to configuration and administration, making them easier to govern, maintain, and audit. They matter because they give teams a standardized, secure mechanism for enabling external connectivity while supporting operational control, security oversight, and compliance requirements.

authentication object expiry notification email template ​

  • Mostly relevant to: Configuration admins, Super Admins, Information Security / Compliance / Analytics
  • Closely related concepts: Document Templates, merge fields

INSUFFICIENT_EVIDENCE

Authentication Objects ​

Authentication Objects are reusable administration records in Autologyx that securely store the credentials and authentication settings needed for the platform to connect to external services and other supported providers. They are created and managed in Administration > Authentication objects, then selected wherever authentication is required, including API Call actors in Sequencer, outbound mail configuration, AI and ML integrations, and provider-specific setups such as Microsoft and DocuSign. A single Authentication Object can be referenced by multiple API calls or configurations, giving administrators and integrators one central place to test, update, monitor usage, track expiry, and control provider access. This matters because it reduces duplicated credential management, protects sensitive connection details, and ensures that changes to authentication settings are applied consistently across every workflow and integration that uses the object.

Show 31 more pages

Authentication objects list ​

The Authentication objects list is the administration page in Autologyx that displays the set of configured Authentication Objects and serves as the starting point for managing them. Used by Configuration Admins and Super Admins in the Authentication Objects area, it is where you locate a specific authentication object before opening it to view or update its configuration. This list matters because it is the central navigation and management point for authentication setup in the platform, enabling administrators to find the correct object and maintain the credentials or connection details that support authenticated integrations and API use.

Authentication Objects permissions ​

Authentication Objects permissions are the role-based administration permissions that control access to Authentication Objects in the Administration tab of the Autologyx platform. These permissions are typically available to Super Admin account types or to users assigned a role that explicitly grants Authentication Objects access, and they determine whether a user can view and use the Actions menu options for managing authentication providers and related configuration, including editing object details. This matters because Authentication Objects govern key platform integrations such as providers and API Actors, so assigning these permissions correctly ensures that only authorised administrators can maintain authentication configuration and make changes that affect how users and services connect to Autologyx.

authentication requirements ​

Authentication requirements are the organisation-level settings in Autologyx that define how users must authenticate to access the platform. They are configured by privileged administrative roles, alongside single sign-on setup, within the platform’s administrative configuration areas and form part of the broader security and access-control model. For Configuration Admins and Super Admins, these settings matter because they determine the sign-in standards users must meet, support alignment with enterprise identity policies, and help ensure access to Autologyx is controlled consistently across the tenant.

Authentication Security ​

authentication sequences ​

Authentication sequences are the reusable authentication configurations in Autologyx that define how the platform sends credentials and related authentication data when connecting to external services. They are used in integrations and connector setups, and work with authentication objects such as API keys, including options such as sending credentials in a header or query string and storing sensitive values in Vault. Authentication sequences matter because they provide a centralised way to manage authentication behaviour across the platform, so changes to an underlying authentication object are automatically applied wherever the sequence is used, improving consistency, security, and ease of maintenance for administrators and integrators.

Authentication success! ​

Authentication success! is the confirmation message shown in the Autologyx platform when a configured authentication object or connection test completes successfully. It is used in administration and integration setup screens such as Outbound mail setup and when creating or editing Authentication Objects, including configurations for services like DocuSign. This message confirms that the supplied connection details, credentials, and token exchange settings are valid and that Autologyx can authenticate with the target service. For configuration admins and Super Admins, it is an important validation checkpoint because it indicates the integration is ready for use; if this result is not returned, the configuration can still be saved in some cases, but the connected function, such as sending mail or accessing an external service, will not operate correctly until authentication is successfully validated.

authentication token ​

An authentication token is the one-time-use UUID generated by an API request and used to establish a WebSocket connection to the Autologyx platform. In practice, developers and integrators obtain this token before connecting so the WebSocket session is authenticated for the environment defined in the token and can receive real-time events related to Object Records. This token matters because it is the required entry point for secure, environment-specific WebSocket access and enables external systems to subscribe to live platform activity without using standard request-response polling.

authorised approvers ​

Authorised approvers are the users designated in Autologyx approval workflows to review and approve specific steps, ensuring that critical documents, requests, and decisions pass through the correct people before the process can continue. This concept is used when configuring workflow approval stages, including configurations that use User type fields to identify the permitted approver from registered users. For configuration admins, authorised approvers matter because they enforce routing and control within a process, helping ensure approvals are assigned to the right individuals and that governance requirements are built directly into workflow design.

Authorization Objects API Keys ​

Authorization Objects API Keys are Autologyx Catalyst configuration objects used to generate and manage encrypted API keys for securing access to external or platform-integrated APIs. Used by configuration administrators, Super Admins, and developers in the API Keys dashboard, these objects define how a key is presented to the target service by selecting an authentication method such as Send in header or Send in query string. API keys created through this feature are stored in Vault to protect sensitive credentials and support secure, controlled integration setup. This matters because it gives platform teams a central, secure way to configure API authentication, protect secrets, and ensure that only authorised systems and services can connect to the resources used by Autologyx processes.

Auto User Creation ​

Auto User Creation is a Single sign on setting in Autologyx that automatically creates an internal user account the first time a person signs in through the configured identity provider, when that person does not already exist in the platform. It is configured by Super Admins and configuration administrators in the Administration area as part of Single sign on settings, where it is shown as the option to Automatically create user. The setting is also visible on the Single sign on settings list page in the Auto User Creation column, where an enabled setting is indicated with a green tick. This matters because it controls whether new users can be provisioned seamlessly at first login through SSO, reducing manual user administration and ensuring access can be established as part of the sign-in process.

Autologyx Catalyst ​

Autologyx Catalyst, often shortened to Catalyst, is the Autologyx operations platform for legal and compliance work, providing the core environment where organisations design, run, and manage workflow-driven solutions. It is used across the platform knowledgebase and in-application help, and underpins day-to-day user work in Workspace as well as solution build and administration activities such as configuring object classes, record and task forms, standalone forms, relational data structures including parent and child records, sequences and Sequencer automation, actors, administration settings, and integration features such as API keys and the Analytics Database API. It matters because it is the product context for all user, configuration, security, and integration capabilities in Autologyx: understanding Catalyst means understanding where records are created and managed, how automation is configured, and how the platform is extended, secured, and reported on.

Show 7 more pages

Autologyx Catalyst 1.11 ​

Autologyx Catalyst 1.11 is a specific platform release of Autologyx documented in the Release Notes 1.11 page, which consolidates the functional changes, new capabilities, and platform improvements introduced in that version. It is used by configuration admins, Super Admins, and developers or integrators to understand what has changed before upgrading, enabling features, or updating integrations, including areas such as AWS Bedrock integration, Azure OpenAI integration, Creation Endpoints, delayed account activation, Hierarchical Records, Microsoft OAuth in Outbound Mail Setup, multipart data support in API Call, ROPC flow authentication, and WebSockets. This release reference matters because it provides the version-specific baseline for planning deployments, validating compatibility, adjusting configuration, and ensuring that teams use the correct features and implementation patterns available in Autologyx Catalyst 1.11.

Autologyx Catalyst 1.13 ​

Autologyx Catalyst 1.13 is the version 1.13 release of the Autologyx platform, documented in the Catalyst release notes and used by configuration administrators, Super Admins, and developers to understand the capabilities, changes, and operational impact introduced in that platform update. It is referenced when planning upgrades, validating configurations, updating integrations, and adopting new or changed functionality across core platform areas such as Authentication, Object Changes, Sequencer and AI models, the Loop actor, the Set Task actor delete option, dynamic document assembly with .docx merge fields, the file upload component, test user account setup, and iManage integration. This release matters because it defines the feature set, improvements, and behavior changes available in that version, which directly affects how workflows are configured, how integrations are implemented, and how administrators govern and support the platform in production.

Autologyx Catalyst 1.14 ​

Autologyx Catalyst 1.14 is the 1.14 release of the Autologyx platform, documented in the platform’s release notes and used as the reference point for the features, fixes, and behavioural changes introduced in that version. It is relevant across administration, integration, and end-user contexts because it groups the updates that affect authentication security, document record handling, error-handling reliability, real-time workflow behaviour, and user interface improvements. In practice, configuration admins, Super Admins, developers, integrators, and business users use Catalyst 1.14 release information to understand version-specific functionality, assess the impact of platform changes, plan configuration or integration updates, and align operational processes with the capabilities and improvements delivered in that release.

Autologyx Catalyst 1.2 ​

INSUFFICIENT_EVIDENCE

Autologyx Catalyst 1.5 ​

Autologyx Catalyst 1.5 is the 1.5 platform release of Autologyx and is used as the reference point for the features, enhancements, and configuration options introduced in that version across the product. It is documented in the Release Notes 1.5 area and covers updates relevant to platform setup and solution design, including Authentication Objects, API Keys, Create Task Actor, Documents in Sequencer Elements, relational support, the Templates Panel, the Word Add-in, and the Task Assignment actor. For configuration administrators, Super Admins, and developers or integrators, Catalyst 1.5 matters because it defines the version-specific capabilities available when configuring workflows, sequencing tasks, assigning task owners and assignees, and integrating external systems, making it the key release baseline for understanding what functionality can be used in a given Autologyx environment.

Autologyx Catalyst 1.9 ​

Autologyx Catalyst 1.9 is a named platform release of Autologyx documented in the Release Notes 1.9 and used by configuration admins, Super Admins, and developers or integrators to identify the feature set, fixes, and platform changes delivered in that version. It is referenced when reviewing release documentation, planning upgrades, validating environment capabilities, and aligning configurations or integrations with version-specific functionality such as the API for delaying user account activation, Authentication Objects, new Jinja filters for date and time manipulations, and the Viewer panel. This release designation matters because it provides the version boundary for understanding what capabilities are available in an environment and for managing change, compatibility, and rollout activities across the platform.

The Autologyx Catalyst logo is the platform’s default branding image shown across the Autologyx application until it is replaced by an organisation’s own logo in theme configuration. It is used throughout the user interface, including the login page, the top of the main menu, and the forgotten password screen, and is managed by configuration administrators and Super Admins when creating or updating a theme on the Configure Theme page, specifically through the Media tab alongside related colour settings. This matters because replacing the default Autologyx Catalyst logo applies consistent organisational branding across key entry points and navigation areas of the platform, helping ensure a branded and recognisable user experience.

Autologyx Catalyst platform ​

Autologyx Cross Platform views ​

Autologyx Cross Platform views are read-only database views in the Autologyx platform that expose data from the Event History and Resource tables without allowing any schema or data changes. Used in database-view and analytics scenarios, they provide a consistent way to inspect and compare platform data across different companies or environments, which is particularly valuable for reporting, compliance review, due diligence, and integration use cases. For configuration admins, developers, and security or analytics teams, these views matter because they give controlled access to operational data in a non-destructive format, supporting cross-platform analysis while preserving the integrity of the underlying Autologyx data model.

Autologyx ID ​

Autologyx ID is the platform’s built-in fallback identifier for an object class record in Autologyx. It is used when no object class field is configured with the Use as identifier setting, in which case the Autologyx ID becomes the active identifier for records of that class. In configuration, this behavior is relevant when editing object class fields in the Data Model tab and the Edit field panel, particularly if an administrator turns off Use as identifier for a field. Although it functions as the record identifier in that scenario, the Autologyx ID is not shown in the Fields list, so configuration admins and Super Admins need to understand its role to avoid confusion about how records are identified when no visible field is designated as the identifier.

Autologyx ID Number ​

Autologyx ID Number is the platform-generated identifier automatically available for an object class record in Autologyx. In object class configuration, it is used as the default value for the property that requires a designated field when no other object class field has been assigned through the Add field panel. This matters because it ensures every object class has a reliable built-in identifier for record recognition and system use, even if administrators do not configure a separate field for that purpose.

Autologyx internal ​

Autologyx internal is a supported provider type for Authentication objects in the Autologyx platform. It is used by Configuration admins and Super Admins when creating or managing entries in the Authentication objects list, alongside other supported provider types such as DocuSign, Adobe, Box, and Generic OAuth 2.0 options. In practice, selecting Autologyx internal identifies the Authentication object as one that uses Autologyx’s own internal authentication mechanism rather than an external third-party provider. This matters because the provider selected for an Authentication object determines how credentials and connection details are configured, and ensures the object is set up correctly for the service or integration it is intended to support.

Autologyx internal authentication object ​

An Autologyx internal authentication object is an Authentication Object configured in the Autologyx platform to store a username and password that Autologyx uses for authentication. It is used by Configuration admins and Super Admins in the Authentication objects list and related administration settings when managing credentials for platform integrations or services that rely on stored login details. This object matters because changing the username and password to a different user does not take effect immediately; there is a delay before Autologyx starts using the new credentials, which is important to account for when updating access, troubleshooting authentication behaviour, or planning credential rotations.

Autologyx landing page ​

The Autologyx landing page is the default destination a user reaches in the Autologyx platform after successfully activating their account through the activation link. In practice, it serves as the user’s first in-platform entry point after activation, transitioning them from the Activate your user account page and authentication flow into their usable Autologyx experience. This matters to end-users because it confirms that account activation is complete and provides access to the platform, and it matters to configuration administrators because user activation rules directly affect whether users are routed through the activation process and then delivered to this landing page as part of a successful onboarding journey.

Autologyx Record ​

An Autologyx Record is the platform’s core data item representing an individual business object instance within a workflow, such as the current item a user is viewing or a Sequence is processing. It is used throughout the platform user interface and automation layer: end users interact with record fields directly in the record view, for example by clicking a saved phone number to launch Click to Call, while configuration admins and integrators reference the current record and its related parent or child records in actors, merge fields, and Jinja expressions such as {{record.field\ owner\ code}}. This matters because the record is the primary source of contextual data for tasks, automation, API interactions, and variable resolution, so understanding how to read and reference an Autologyx Record is essential for presenting the right information to users and driving correct workflow behaviour.

Autologyx Sequencer ​

Autologyx Sequencer is the platform context in which Jinja2-based logic is used to manage values during configured execution steps, particularly for API calls and local variables that need to persist across loops and blocks. It is used by configuration administrators and developers when building sequence logic that performs dynamic calculations, maintains counters, evaluates conditions, or carries running totals through multiple iterations. In practice, Sequencer sits alongside Document Templates as an Autologyx environment where namespaces, local variables, and merge-style data handling are applied to control how data is processed during execution. It matters because it enables more advanced, stateful automation logic within configured workflows, allowing implementers to build reliable multi-step behaviour without losing variable state between iterations.

automated document workflow ​

automated notifications via the Sequencer ​

Automated notifications via the Sequencer are configurable email reminders in Autologyx that are used with Authentication Objects that have an Expiry Date, enabling the platform to alert users or administrators when a credential or authentication configuration is nearing expiration. This is used in conjunction with the expiry date feature and its filter for Authentication Objects, including Generic ROPC Authentication Objects, and is configured through the Sequencer by Configuration Admins or Super Admins. It matters because it helps prevent authentication failures and integration disruption by ensuring expiring credentials are identified and acted on before they stop working.

automated workflow route ​

An automated workflow route is the path a record or task follows through Autologyx processing, determined by the sequence configuration that uses information captured on a form to direct work into the correct automated steps. It is used when designing intake and other record creation forms in the Catalyst form builder, especially in the Create and edit view, where configuration admins define mandatory questions and conditional logic needed to capture the routing data that sequences depend on. This matters because the automated workflow route controls how work is classified, progressed, and handled by downstream automation, so the fields that drive routing must be designed and completed correctly to ensure records enter the intended process path.

Automatic ​

Automatic is a Task creation mechanism setting on a task template that marks the task for use within a Sequence in Autologyx. When a task template is set to Automatic, it becomes available for selection in the Sequence designer and related task template pickers, including task group template configuration, whereas templates set to Manual are excluded from those lists. This setting is used by Configuration admins and Super Admins when creating task templates and designing sequences, and it also determines how responsibility is assigned: for Automatic tasks, the user or users who will complete the task are defined in the Sequence setup rather than on the task template itself. The setting is especially important for task types such as Complete self-contained form and Update object record, because only Automatic templates of those types appear in the designer, with Update object record templates further limited to the object class configured on the template.

Show 1 more pages

Automatic Document Generation ​

Automatic expiry notifications ​

Automatic expiry notifications are Autologyx system-generated email alerts tied to Authentication Objects, which monitor their own lifecycle and use the credential expiry timestamp to notify users or administrators when an authentication credential is approaching or has reached expiry. This capability is used in environments where Authentication Objects are configured and managed, and it relies on system email configuration to send the notifications correctly. For Configuration Admins and Super Admins, automatic expiry notifications matter because they help maintain uninterrupted access to integrated services, reduce manual monitoring of credential validity, and support timely renewal or replacement of expiring authentication details.

Automatic Generation Of Documents Via The Sequencer ​

INSUFFICIENT_EVIDENCE

Automatic Task creation mechanism ​

The Automatic Task creation mechanism is the Autologyx task-template mode used to generate and manage tasks automatically within a workflow sequence for a record, rather than creating them manually. It is used in task templates that are referenced by sequence actors such as Create Task and Set Task: Create Task creates the task from the automatic task template at the required point in the workflow, while Set Task is used with the same mechanism to recreate a previously completed task or delete a task. This matters to Configuration Admins and Super Admins because it defines how repeatable, workflow-driven task creation is configured, ensuring tasks are created, reset, or removed consistently as records progress through the platform.

Automatically create user ​

Automatically create user is a Single sign-on (SSO) configuration option in Autologyx that creates a new Autologyx user account automatically when a person authenticated by the configured SSO provider signs in for the first time and does not already have a matching account in the system. It is used in the SSO setup for internal user access, including provider-specific configurations such as Okta, and the setting is visible in the SSO configuration where auto user creation status can be reviewed. This setting matters to Configuration Admins and Super Admins because it controls whether valid SSO users can be onboarded seamlessly at first login instead of receiving an access denied message, and in supported SSO flows the new account is created as an active internal user.

Automatically create user switch ​

The Automatically create user switch is a setting in a Single sign-on (SSO) configuration in Autologyx that controls whether a user account is created automatically when a person authenticates through the configured identity provider. It is used by Configuration Admins and Super Admins on the Administration tab when editing a Single sign-on setting, alongside related SSO options such as Client ID, Client Secret, Redirect URI, enabled status, and the role assigned to created users. This setting matters because it determines whether access can be provisioned directly from the SSO flow, reducing manual user administration and ensuring new users can enter the platform with the intended role assignment.

AutomaticTask templates ​

INSUFFICIENT_EVIDENCE

automation platform ​

Available Use ​

Available Use is an Element configuration setting in the Autologyx platform that controls where an Element can be used on system forms. It is configured when editing an Element in the Elements section of the side panel, where administrators select the system form contexts in which that Element is available. This setting matters because it determines the placement and reuse of Elements across forms, helping Configuration Admins and Super Admins ensure that only the appropriate Elements are presented in the correct parts of the platform.

available user ​

In Autologyx, an available user is a user who is currently eligible to be selected for work on a specific record, most commonly when creating or reassigning a Manual Task. This term is used in task assignment interfaces and related administration scenarios where users need to search for, view, or select people who can take ownership of an action for that record. Availability is significant because it reflects the platform’s assignment rules and permissions for that context, ensuring tasks are directed only to users who can validly work on the item. For configuration admins, access to see and choose available users is tied to permissions such as View Users, while for end-users it determines which assignees can be chosen during task handling.

avatar ​

In Autologyx, an avatar is the visual identifier shown for assignees in a permission set, helping administrators quickly recognise whether the assignee is an individual user or a user group. Avatars are used in the User Group Permissions area when configuring who is included in a permission set; they are displayed for Owners and for non-default permission sets, and when a user group is added to a user group permission set, the user group avatar is shown first. Selecting a user group avatar opens details such as the group description and member count, and the avatar shape distinguishes group avatars from user avatars. This matters because avatars provide an immediate, visual way to verify the assignees attached to permissions and reduce errors when configuring access and ownership.

avatar dotted circle ​

In the Autologyx platform, the avatar dotted circle is a visual indicator shown on a user’s avatar to identify that the account is a 1 time completion user. It is used in task assignment and task creation contexts, including when selecting or creating work for users through mechanisms such as Create task. This indicator matters because it lets end-users and configuration admins immediately distinguish temporary, one-time completion accounts from other user types, helping ensure tasks are assigned to the correct kind of user and that user setup aligns with the intended completion model.

AWS Bedrock actor ​

The AWS Bedrock actor is an Autologyx AI actor that connects the platform to Amazon Bedrock so users can run multiple foundation models through a single actor configuration. It is used wherever actors are configured and selected for AI-powered automation, including Sequencer, and supports model choices from providers available through Bedrock such as Amazon, Anthropic, Meta, Mistral, and OpenAI. This matters because it gives configuration admins and developers a unified way to manage model access and selection for different workloads, performance targets, and cost profiles, while allowing end-users to use Bedrock-backed AI capabilities in Autologyx processes without switching between separate provider-specific integrations.

AWS Bedrock integration ​

AWS Bedrock integration is an Autologyx Catalyst 1.11 actor that connects the platform to Amazon Bedrock, exposing AI models from providers including Amazon, Anthropic, Meta, and Mistral through a single configurable actor. It is used in Catalyst workflows by configuration admins and developers to add model-driven steps without building separate integrations for each provider, and it sits alongside other actor-based AI options such as the Azure OpenAI actor. This integration matters because it gives teams a standard way to select and use different foundation models for specific workflow tasks while managing that capability within Autologyx’s actor and configuration framework.

Azure environment ​

In Autologyx, an Azure environment is the Microsoft Azure tenant and associated application configuration that underpins Microsoft OAuth 2.0 connectivity for platform services, particularly outbound mail using Microsoft Office 365 Exchange (Graph) with client credentials. It is used when configuring the Microsoft Client Credentials Authentication Object and outbound mail setup, where the Azure application, permissions, and email-sending capability must be correctly configured so Autologyx can authenticate and send mail through Microsoft services. This matters to Configuration Admins, Super Admins, and Developers/Integrators because the Autologyx mail service depends on the Azure environment being set up correctly for secure integration and successful email delivery.

Azure OpenAI actor ​

The Azure OpenAI actor is a dedicated Catalyst actor that connects the Autologyx platform to Microsoft Azure-hosted OpenAI services, allowing workflows to use supported GPT and embedding models directly within Catalyst. It is used in Catalyst workflow design and platform configuration, where administrators and integrators set up the actor to provide secure, scalable, enterprise-ready access to Azure OpenAI capabilities tailored to business needs. This matters because it gives organisations a standard Autologyx integration point for bringing advanced AI functions such as language generation and embeddings into operational workflows, alongside other actor-based integrations, so solutions can be configured and executed consistently within the platform.

Azure OpenAI Integration ​

INSUFFICIENT_EVIDENCE

Backend failure alerts email address ​

Backend failure alerts email address is a field in Autologyx Outbound mail setup where administrators specify up to 10 recipient email addresses, separated by commas or semicolons, to receive system notifications when the platform cannot send email due to outbound mail configuration problems such as changed account settings, connection issues, or authentication errors. It is used by Configuration admins and Super Admins when configuring or maintaining the platform’s mail service, alongside settings such as the From email address and mail service authentication method. This setting matters because it ensures the right people are alerted immediately to delivery failures, enabling prompt correction of outbound mail issues and helping maintain reliable system-generated communications.

Basic condition ​

A Basic condition in Autologyx is the simplest form of conditional logic used to control what content is shown or inserted in document templates and email bodies by evaluating field values with an If / Else structure. It is configured in the Templates tab and in the Word Add In when building template content, and can use operators such as equals, in, not in, and similar comparisons to determine which output is produced. Basic conditions matter because they let configuration admins create dynamic templates that automatically adapt to case data, while giving end-users generated documents and emails that reflect the correct wording, clauses, or content for each scenario.

beautify icon ​

The beautify icon is the control used in Autologyx JSON fields to automatically format entered JSON into a structured, readable layout. It is used on record forms wherever a JSON type field is presented, allowing end-users and configuration admins to quickly reorganise raw or compact JSON without changing the underlying data. This matters because formatted JSON is easier to read, review, and maintain when entering, validating, or troubleshooting structured field content in the platform.

beauty JSON icon ​

In Autologyx, the beauty JSON icon is a control shown on record forms for JSON fields that formats the field content into a more readable structure. It is used directly in the record form interface when viewing or editing JSON data, helping users present complex default values or other JSON content in a clear, structured layout instead of raw unformatted text. This matters because it makes JSON fields easier to read, review, and work with during data entry and configuration, reducing effort when handling structured data in the platform.

Bedrock provider ​

INSUFFICIENT_EVIDENCE

bin icon ​

In the Autologyx Relational modeller, the bin icon is the delete control shown against object classes in the relational model when they are editable and can be removed from the model. It is used by configuration administrators while editing the relational model to identify which object classes can be deleted, in contrast to a padlock icon, which marks locked object classes that cannot be removed. This matters because it gives an immediate visual indication of whether a structural change is permitted, helping administrators manage object classes safely and understand which parts of the model are available for modification.

binary and multipart document support ​

Binary and multipart document support is a document-handling capability in the Autologyx Sequencer, introduced with Autologyx Catalyst 1.5, that enables the platform to work with both single binary file payloads and multipart document payloads within automated flows. It is used where Sequencer-based integrations, Catalyst-driven document actions, or manual document automation need to receive, process, or pass documents in formats commonly required by external systems and services. This matters to developers, integrators, and configuration administrators because it expands the range of document exchange patterns Sequencer can support, allowing document-centric automations to be designed and configured to handle richer file transfer and submission scenarios without custom workarounds.

binary and multipart documents support ​

Binary and multipart documents support is a Sequencer capability in the Autologyx platform that allows steps in a sequence to work with document payloads as raw binary content or as multipart/form-data, enabling files to be passed, submitted, and processed in integrations that require specific document formats. It is used when configuring document handling within Sequencer-driven workflows, particularly alongside Binary Data mode, Form Data, API Call actor parameters, Document Picker actor outputs, and the Files section. This matters to configuration admins and developers because it expands how documents can be exchanged with external systems, giving precise control over file transmission formats and supporting workflow designs that depend on uploading, relaying, or transforming documents as part of automated process execution.

Binary Data ​

Binary Data is a request body format used in the Autologyx API Call actor to send raw file content or other non-text binary payloads directly to an external service. It is selected when configuring an API call, alongside other body types such as Form Data, Multipart Data, JSON Data, and XML Data, and is used when the target endpoint expects the request body itself to be the file or binary stream rather than structured fields or multipart attachments. This matters to configuration admins and developers because choosing Binary Data determines how Autologyx constructs the outbound request and ensures that integrations handling documents, images, or other raw content receive the payload in the format their API requires.

Binary Data mode ​

Binary Data mode is an API Call actor option in the Autologyx platform that is used when a step needs to send or receive a single document as raw binary content rather than as form fields or multipart payloads. It is used in Sequencer when configuring integrations that handle one document directly, providing a simpler document exchange pattern than broader binary and multipart document support. This matters to developers and configuration administrators because it determines how document data is passed through an integration step, affects how parameters and payloads are configured, and provides the correct mode when an external endpoint expects one document without additional form-data structure.

blue icon ​

In Autologyx forms, the blue icon is a visual indicator that a field or section is part of Conditional Visibility logic. It appears on any field used to control whether a section is shown, and on any section whose display is governed by configured conditions. When you hover over the icon, Autologyx identifies that the item has relations, helping form designers and end-users quickly recognise which parts of a form are linked by conditional logic. This matters because it makes form behaviour easier to understand, troubleshoot, and maintain when configuring Section Properties, Field Properties, and related visibility rules.

Box oAuth 2.0 (Client Credentials flow) ​

Box oAuth 2.0 (Client Credentials flow) is a supported Authentication object provider in the Autologyx platform that stores the credentials and connection settings needed to authenticate server-to-server requests to Box using the OAuth 2.0 Client Credentials grant. It is configured by administrators in the Authentication objects area and then selected wherever Autologyx components, such as API-driven integrations, API Actors, or Sequencer steps, need to call Box securely without an interactive user sign-in. This provider matters because it centralises Box authentication in a reusable platform configuration, enabling consistent, controlled access to Box services across automations and integrations while reducing the need to embed credentials directly in individual implementations.

In the Autologyx platform, the breadcrumb menu is the navigation trail shown at the top of a page that lets users move back to a higher-level location in the workspace. It is used within record pages and forms to provide quick navigation to related list or parent views; for example, when manually creating an Object record, selecting Records in the breadcrumb menu returns the user to the Records list. This matters because it helps users keep track of where they are in the application and move efficiently between detail pages, forms, and record lists without restarting their navigation path.

Breadcrumbs in the Autologyx platform are the navigation trail shown at the top of a record page or modal, used to display the current record context and provide direct navigation back through related locations such as the Records list, a parent record, or a grandparent record. They are used prominently when working with relational records, including creating child records from a parent and moving between associated child and parent records, and were refreshed in Autologyx Catalyst 1.2 to be more functional and user friendly. Breadcrumbs matter because they make record hierarchy and page context immediately clear, reduce confusion when working across linked records, and let end-users and configuration admins move quickly to the correct record location without losing their place.

Building applications ​

Building applications is the Autologyx documentation path for analysts, solution designers, and other users who design, build, or extend applications on the platform. It is used in the Getting Started guidance as the recommended starting point for people planning a new application or shaping process design, helping them navigate the documentation by role and responsibility rather than by technical feature area. This matters because it directs configuration-focused users to the material most relevant to application design and extension work, while distinguishing that work from related areas such as Performing Work for records, tasks, and documents, Delivery for implementation and rollout activity, and Platform admin for users, permissions, and system-wide setup.

Building Applications Analysts ​

built in testing feature ​

Built in testing feature is the validation capability available when configuring Authentication Objects in Autologyx that lets administrators and integrators test an authentication setup before saving or committing it to a live configuration. It is used during setup of provider connections, including Generic OAuth 2.0 and provider-tailored configurations, alongside fields such as Token URL, Refresh URL, Client ID, Client Secret, Additional Parameters, and Additional Authorization Headers. This feature matters because it allows users to confirm that the authentication details are working as expected at configuration time, helping them identify setup issues early and ensuring external service integrations are correctly connected before they are used in processes or deployments.

business days ​

In Autologyx, business days are the working-day basis used by Jinja date and time manipulation filters to calculate deadlines, elapsed working time, and projected dates while excluding non-business days from the count. This is used in template expressions and configured logic through the **business days**=True parameter on filters such as delta days, shift date, and shift datetime, for example when calculating the number of business days between two dates or adding and subtracting working days from a date or timestamp. It matters to configuration admins and developers because it changes how schedules, turnaround calculations, milestone dates, and dependency-driven deadlines are produced in documents and automations, ensuring that date-based outputs align with operational working schedules rather than simple calendar-day arithmetic.

business\ days=True ​

business days=True is a boolean parameter used in Autologyx Jinja date and datetime filters to tell the platform to calculate or shift using business days rather than calendar days. It is used in filters such as delta days, shift date, and shift datetime, where setting the parameter to True changes the result of date interval calculations and date movements to business-day logic; for example, {{ "2024 04 12"|delta days("2024 04 12", business days=True) }} returns 1, because the calculation is inclusive of both the start and end date. This setting matters to configuration admins and developers because it directly affects deadline, turnaround, and schedule calculations in templates, documents, and automated workflows, ensuring that date-based outputs align with operational business-day rules instead of simple elapsed calendar days.

By field ​

By field is an assignment option in Autologyx that selects users dynamically from a user-type field on the current record instead of choosing named users directly. It is used in actor configuration such as the Record Access actor and Task Assignment actor, where administrators tick the By field option and then choose from the available user fields associated with the sequence’s object class. This matters because it lets record ownership, record access, and task assignment follow the data held on each record, supporting reusable configurations that automatically route work and access to the correct users as record values change.

By users ​

By users is a selection method in Autologyx actors that lets an administrator assign ownership or task assignees by explicitly choosing named users from the platform user list, rather than deriving users from record data. It is used in configuration screens such as the Record Access Actor when setting, overriding, or appending record owners, and in the Task Assignment Actor when defining task assignees or task ownership. In practice, the administrator selects the option and starts typing to find and add the required users. This matters because it gives precise, fixed control over who receives access or responsibility, making it the appropriate choice when assignments must be set directly to known users instead of being populated dynamically by a field.

call types ​

Call types are the HTTP request methods that an Autologyx authentication object is configured to permit for a specific external integration, such as DocuSign. They are selected when creating or editing the authentication object used by the integration, with common options including GET, POST, and PUT. In the Autologyx platform, call types define which kinds of API operations the integration is allowed to perform through that authentication configuration, so choosing the correct set is essential to ensure the connected service can execute the required actions while keeping the integration scope aligned to its intended use.

Cancel ​

Cancel is the control used in Autologyx to abandon a current change and return to the previous state without applying unsaved updates. It is used in column configuration mode on list pages, where clicking Cancel exits configuration and discards any unsaved column changes after confirmation, and in related prompts such as when removing a column tied to conditional logic, where Cancel retains the column instead of proceeding with the removal. This matters to end-users and configuration admins because it provides a safe way to stop an action, preserve the existing configuration, and avoid committing unwanted changes to columns, fields, and dependent form behaviour.

canvas ​

In Autologyx, the canvas is the main central workspace in the form builder and related configuration designers where components are placed and arranged to define what users see and interact with. Configuration admins and Super Admins use the canvas when configuring object class create/edit and summary views, standalone forms, task forms, and parts of the relational modeller, working alongside the side panel to drag and drop sections, fields, elements, properties, and child object class components into position. The canvas matters because it is the primary design surface for structuring form layouts and relationships: it shows the live composition of the form or model, controls where components are added, and reflects constraints such as components becoming unavailable in the side panel after placement or certain object classes not being removable in the relational model.

Show 2 more pages

Card view ​

Card view is an alternative display for Object records in the Records list on the Autologyx workspace, shown as individual cards instead of rows in the traditional list view. It is configured per Object class in the Display settings alongside Create and edit view and Summary view, and determines which fields are presented on each record card; the Object class Identifier is automatically included and shown in the top-left area of the card. End users access Card view by switching the Records list display, then use each card’s open icon to open the record in edit view, and saved documents clicked from Card view can open directly in the Viewer panel. Card view matters because it controls how records are scanned, identified, and opened in daily work, while giving configuration admins a dedicated display layer for presenting the most useful record information in a compact, visual format.

Show 4 more pages

cascading sequences ​

Cascading sequences are a configuration pattern in Autologyx used to propagate actions across related object classes by triggering one sequence from another, typically through Relation Lookup and Sequence Runner actors. They are used when records in a parent-child relationship need consistent updates across the hierarchy, such as aligning record ownership or assignees for parent, child, and grandchild records. This matters to configuration admins and Super Admins because some cross-record access and assignment outcomes cannot be achieved within a single sequence on one object class; cascading sequences provide the mechanism for applying those changes throughout connected records in a controlled, scalable way.

Catalyst ​

Catalyst, also referred to as Autologyx Catalyst, is the core Autologyx platform used to design, run, and manage structured operational processes, combining workflow, data, documents, integrations, and user access in a single environment. It is the product context in which users log in, land on the landing page, work with records and tasks, complete forms, interact with sequences in Sequencer, and use connected capabilities such as single sign-on, authentication objects, document handling, and API-based integrations. For configuration admins and super admins, Catalyst is where application structure, object classes, permissions, user groups, account types, and platform settings are defined and maintained; for developers and integrators, it is the platform that passes data into elements, exposes APIs, and supports access tokens and external services. Understanding Catalyst matters because it is the container for the entire Autologyx operating model: how work is presented, secured, automated, integrated, and completed across the platform.

Show 15 more pages

Catalyst Add in ​

Catalyst Add in, also referred to as the document automation Word Add in or Word Add in, is the Microsoft Word-based template design component of Autologyx Catalyst used to create and maintain document automation templates for the platform. It is used by end-users and configuration administrators when building document templates that integrate with Autologyx data structures, including relational model support introduced in Catalyst 1.5, and it sits alongside broader document handling capabilities used in Sequencer. This matters because the add-in is the primary authoring environment for manual document automation in Autologyx, enabling template designers to produce documents that correctly reflect platform data relationships and support more advanced, maintainable document generation configurations.

Catalyst administrators ​

Catalyst administrators are the Autologyx administrators responsible for setting up and managing the platform before end users are activated, particularly when using delayed account activation through the user creation API. In this context, administrators can create user accounts in a non-active state, such as Created or Pending, and defer the activation email until business processes, workflows, and related configuration are fully prepared. This role is especially relevant to Configuration admins and Super Admins because it gives them direct control over when users become active, supports planned rollout of new processes, and helps ensure users enter the platform only after the required configuration is complete.

Catalyst APIs and Variables ​

Catalyst APIs and Variables are system configuration features in the Autologyx platform used to inject dynamic data and service-driven values into configured experiences such as document templates, document automation, DocuSign integrations, and record-based sequences. Found within the System Configuration area alongside merge fields and related automation settings, they enable configuration admins and developers or integrators to connect templates and workflow steps to platform data, relational records, and external or Catalyst-managed API outputs. This matters because they allow solutions to generate accurate documents, populate fields automatically, and drive consistent behaviour across automated processes without hard-coding values into individual templates or sequence steps.

Catalyst application ​

INSUFFICIENT_EVIDENCE

Catalyst automation framework ​

Catalyst build ​

A Catalyst build is a specific Autologyx platform instance used to host and run a configured environment, and it is an administrative scope for platform-level resources such as service accounts. In configuration and integration tasks, the build is the boundary within which key technical objects are created and limited—for example, each Catalyst build supports one Internal Service account and up to five External Service accounts. This matters to Super Admins, configuration administrators, and developers because build-level limits and account assignments determine how integrations, authentication, and automated platform interactions are set up and managed within that instance.

Catalyst data model ​

The Catalyst data model is the structural framework in Autologyx that defines how application data is organised, primarily through Object Classes and the relationships between them. It is used when designing and configuring Catalyst applications, including task forms, stand alone forms, required outcomes, sequences, role permissions, and Document Templates, because these components depend on a clear underlying data structure. For Configuration Admins and Super Admins, understanding the Catalyst data model is essential to setting up Object Classes correctly, ensuring application components use data consistently, and enabling the platform to support the intended process design.

Catalyst dev environment ​

Catalyst Elements ​

Catalyst Elements, also referred to as Elements, is the Autologyx framework for building custom front-end applications, commonly used on landing pages. It is used by developers and integrators who need tailored user interfaces within the platform experience, and it works particularly well with WebSockets to present real-time updates for Object Record activity without requiring users to refresh the page. This matters when configuring responsive, interactive experiences in Autologyx, because Elements enables custom UI delivery while supporting live data updates within the environment defined by the authentication token.

Catalyst form builder ​

The Catalyst form builder is the form design component in Autologyx Catalyst used to create and structure intake and other record creation forms. It is used by configuration admins when defining how class fields are presented to users, including arranging fields into sections with up to three columns and applying the available field types and display logic in the form design experience. This matters because the same builder is used across these form scenarios, so understanding it is essential for creating consistent, usable data-entry forms that capture the right information and support effective process configuration.

Catalyst formbuilder ​

Catalyst formbuilder is the Autologyx design workspace used by configuration and super admin users to build and maintain user-facing forms and record displays across the platform. It is used to create the three record displays, standalone forms for record creation, and task template forms, including self-contained task forms, and it provides a main canvas for arranging components alongside side panels for selecting elements and configuring their properties or options. The formbuilder is central to how object class fields, child object classes, and display layouts are presented in Create and edit, Summary, Card, and other record display contexts, making it a core tool for defining how users capture, view, and interact with information in Autologyx.

Catalyst forms ​

Catalyst instance ​

A Catalyst instance is a single deployed Autologyx environment for an organisation, containing that organisation’s platform configuration, company-level settings, and operational assets such as sequences. In the Autologyx platform, it is referenced in administrative and configuration contexts, including the Company details page, where instance-specific information is maintained and used by platform features such as password reset communications, and in system configuration guidance that describes instance-level limits such as the number of sequences supported. This term matters to Configuration admins and Super Admins because many settings, limits, and behaviours are applied at the instance level, so understanding the Catalyst instance is essential when managing branding, administration, and platform configuration.

Catalyst instance URL ​

Catalyst instance URL is the full web address of your Autologyx Catalyst environment and is used when configuring integrations that need to identify or trust that specific tenant, such as a DocuSign Authentication Object. In platform configuration, it is entered anywhere an external service must be told which Catalyst instance is making requests or receiving callbacks, including origin or allowed domain settings and related authentication fields. This matters because the URL ties the integration to the correct Autologyx environment, ensuring authentication flows, redirect handling, and cross-system communication are registered against the right instance and function correctly.

Catalyst Knowledgebase ​

Catalyst Knowledgebase, also referred to as the Knowledgebase, is the official documentation and help resource for Autologyx Catalyst. It is used across the platform by end-users, configuration administrators, and Super Admins to find practical guidance on using Catalyst, navigating the interface, working with records and task forms, managing workspace and system configuration, carrying out administration tasks, and accessing help and support information. The Knowledgebase matters because it provides the central reference point for understanding platform features, following supported ways of working, and completing configuration and operational tasks consistently within Autologyx Catalyst.

Catalyst Landing page ​

  • Mostly relevant to: End-users, Configuration admins
  • Closely related concepts: Catalyst

The Catalyst Landing page is the introductory entry page for Catalyst in the Autologyx platform, used to welcome users and provide orientation through help content and links to articles about the user interface and navigation. It is encountered by end-users as the starting point for accessing Catalyst and by configuration administrators when setting up or reviewing the guidance presented at the start of the experience. This page matters because it establishes the first touchpoint for Catalyst, helping users understand where they are in the platform, how to navigate it, and where to find supporting information.

Catalyst login support ​

Catalyst login support is an optional single sign-on configuration setting in the Autologyx Administration area that enables users to sign in to the Catalyst platform through an external identity provider such as Azure AD or Okta. It is used in the SSO setup page alongside related options such as logout URL and automatic user creation, and is disabled by default until an administrator explicitly turns it on. This setting matters because SSO access to Catalyst will not work unless Catalyst login support is enabled, making it a required step for configuration admins and Super Admins who are setting up or maintaining federated user authentication for the platform.

Catalyst platform ​

  • Mostly relevant to: Configuration admins, Super Admins
  • Closely related concepts: Elements

The Catalyst platform, also referred to as Autologyx Catalyst or simply Catalyst, is the core Autologyx platform environment in which automation capabilities are delivered and extended. In platform documentation it is used as the base system that features such as Elements enhance, allowing configuration and administrative users to tailor the platform to specific business needs rather than relying on a fixed, one-size-fits-all setup. This matters to Configuration Admins and Super Admins because Catalyst is the platform they configure, extend, and manage to deliver business automation outcomes across the organisation.

Catalyst record ​

A Catalyst record, often shortened to record, is the core business item in the Autologyx platform that users open and work with in record views, and that configuration admins design through the Create/edit record display form builder. In the iManage integration context, the Catalyst record provides the business context that links a specific iManage location to that item, so users can open a record and access the related iManage documents directly within the Autologyx interface. This matters because integrations, embedded components, and record-specific settings such as folder assignment all operate against the record, making it the unit that connects user work, on-screen data, and external systems such as iManage.

Catalyst record views ​

Catalyst record views are the screens in the Autologyx platform where users open and work with individual Catalyst records. They are used as the primary in-context interface for viewing record details and, with integrations such as iManage, for accessing related external content directly from the record without leaving Autologyx or opening additional tabs. Record views matter because they bring together the information, actions, and connected systems needed to complete work on a specific record, making them a key focus for both end users performing tasks and configuration admins designing how record-based work is presented in the platform.

Catalyst system ​

In Autologyx, the Catalyst system is the deployed instance of the platform that an organisation configures and uses to run its processes, data model, tasks, users, and branded experience. The term is used throughout administration, system configuration, form and element development, and user-management documentation to describe the specific environment in which features such as Elements, task templates, object classes, sequences, themes, roles, and permission-driven access are created and managed. It matters because many configuration limits, naming rules, integration links, and administrative actions are defined in the context of a particular Catalyst system, so admins, developers, and end-users need to understand it as the operational boundary for how their Autologyx implementation is structured, customised, secured, and presented.

Show 4 more pages

Catalyst system URL ​

Catalyst system URL is the base web address of the client’s Autologyx Catalyst environment, exposed in the platform as the {{client.url}} merge field. It is used in sequence objects such as Send Message actors, API calls, and Variables, where Autologyx automatically replaces the merge field at runtime with the configured client URL. This matters to configuration admins and developers because it provides a reliable way to insert the current environment’s address into templates and workflow logic, supporting dynamic links, environment-aware integrations, and reusable document or messaging content without hard-coding system-specific URLs.

Catalyst UI ​

Catalyst UI, also referred to as Catalyst, is the Autologyx user interface through which end-users complete work and configuration admins interact with platform features such as Create/Edit forms, display forms, Object Class forms, task lists, records, and document handling. It is used across core workflow and records experiences, including form entry, task execution, real-time task list updates, document selection, and related platform interactions. Catalyst UI matters because it defines the usability, consistency, and efficiency of day-to-day work in Autologyx, with updates to layout, text editing, form behaviour, and visual consistency directly affecting how users enter data, view records, and navigate platform capabilities.

Catalyst version 1.10.0 ​

Catalyst version 1.10.0 is the Autologyx platform release that introduced restricted visibility of users in the Users and Groups area of Administration. From this version onward, who can see user records is controlled by platform roles and permission configuration, including Super Admins, Config Admins, custom permission sets, and the visibility scopes used across permission sets such as Everyone, Members, and Owners. This change affects how users are exposed in administration screens and in related platform features such as dropdown autocompletes and filters, making it important for administrators to understand when configuring access, assigning permissions, and troubleshooting why particular users are or are not visible to end-users and administrators.

Catalyst Word Add in ​

The Catalyst Word Add-in is the Microsoft Word integration for Autologyx Catalyst that is used to create and configure document templates by inserting merge fields from Catalyst object classes directly into a Word document. It is used in document template creation and Word Add-in configuration, where administrators enable support, register and deploy the add-in as an admin-managed add-in, and control which users have access with the appropriate permissions. The add-in also supports related object classes through relational support, helping users build dynamic templates that can be used in workflows. It matters because it replaces manual document assembly with a structured, accurate template authoring experience, making document automation faster to configure, easier to maintain, and more reliable for end-users generating documents from Catalyst data.

Show 1 more pages

Catalyst Word add in support ​

Catalyst Word add in support is a Single sign on setting in Autologyx that enables the Catalyst Word Add in integration for users. Configuration admins and Super Admins use this option in Administration > Single sign on settings when creating or updating a registration, where it appears as the toggle labeled Enable Catalyst Word add in support. When enabled, it provides users with the Word sidebar used to work with document templates, including object class field merges and other template functions that support document generation by the system. This setting matters because the Word Add in uses its own permissions and can be configured separately from Catalyst login support, allowing administrators to use the same directory registration for both user sign in and the Word Add in when required.

Catalyst workflows ​

Catalyst workflows are the executable automation flows built and run in Autologyx Catalyst to orchestrate business processes, user tasks, and system integrations. They are used throughout the platform as the container for actors, including integrations such as the Azure OpenAI actor and API Call actor, so configuration admins and developers can design how data, decisions, and external services are combined into a single automated process, while end-users interact with the resulting steps and outcomes. Catalyst workflows matter because they are the primary way intelligence and automation are embedded into Autologyx, providing the structure for controlling execution, configuring connected services, and maintaining scalable, secure, and adaptable process automation.

ccs file ​

INSUFFICIENT_EVIDENCE

Centralised integrations management ​

Centralised integrations management is the Autologyx capability that provides a dedicated area in Catalyst for administering platform integrations from a single location. It is used in System configuration → Integrations, where Super Admins and configuration administrators can view which integrations are available and which are already active, and manage integration setup within the platform’s integrations framework. This matters because it gives administrators a clear, central point of control for integration visibility and activation, making it easier to govern connected services, maintain configuration consistency, and manage the platform’s available integration options efficiently.

Checkbox ​

In Autologyx, a Checkbox is a task form field type used to capture a single binary choice, such as confirming, agreeing, affirming, or opting out, and it is displayed on the form with its label positioned to the right of the box. It is configured by form builders within task forms and used by end-users when completing tasks. Checkbox fields matter because they provide a simple, explicit way to record yes/no decisions in a structured format, and when a Checkbox is marked as required, the task cannot be submitted until the user selects it, making it an effective control for mandatory acknowledgements, confirmations, and declarations.

Checkboxes in Catalyst ​

In Autologyx Catalyst, checkboxes are a form field type used to capture a single yes/no choice for one option on a record or task form. They are configured in the Catalyst form builder when designing intake forms and other record-creation experiences, where each checkbox represents one discrete option rather than a multi-select list of choices. This matters to configuration admins because the checkbox field should be used only when the user needs to confirm or decline a single option, and alternative field types such as a drop down list should be used where multiple choices are required; using the correct field type also supports clear form behaviour and reliable conditional logic for end-users.

Checklist Of Things To Set Up ​

Checklist Of Things To Set Up is the standard setup checklist used in Autologyx to capture the configuration items that are common across all applications in the platform. It is used in the Building Applications guidance for analysts and configuration administrators as a practical reference when preparing a new application, helping teams identify the shared platform elements that should be established before application-specific design is completed. This matters because it provides a consistent starting point for application build work, reduces omissions in core configuration, and supports a more repeatable and controlled approach to setting up Autologyx applications.

child class component ​

In Autologyx, the child class component, also referred to as the child listing or child record component, is the user interface element used when working with relational records to display and manage child records associated with a parent record. It is used in record views and related workflows where users need to see existing child records, associate them, or create new ones, and it can include controls such as the Create button and other child lookup and selection features. This component is permission-aware: its visible controls, messages, and even the display of the child class name change according to the user’s view class, list records, create records, and edit records permissions. It matters because it governs how end users interact with related data and how configuration admins design secure, effective parent-child record experiences within create and edit views, flyouts, and action-driven workflows.

child component ​

A child component is a user interface section on a parent record page in Autologyx that displays and manages related child records for a specific object class, such as Employees or Employment Contracts. It is used in the main content window when working with relational records, where users can view existing child records, select them to show the child record summary in the side panel, and use the Create button or Create record button to add a new related record, typically opening the create or edit record display form in a fly out modal. Child components are important for both end-users and configuration admins because they are the primary way related records, including grand child relationships, are created and maintained from the parent context, and their behaviour is tied to object class design, page layout, breadcrumbs-based navigation, and the user’s permission to create or edit records in the parent object class.

child lookup controls ​

Child lookup controls are the user interface controls on a parent record form that let users find, add, or remove associated child records in a relational record setup. In Autologyx, they are used when working with child record selectors and related record sections to manage links between an existing parent record and its child records without creating a new parent. They matter because they determine whether end users can maintain parent-child relationships directly from the form, and their visibility depends on the form state and the user’s permissions: when a parent record is opened in read-only mode, such as when the user has view-only access, the child lookup controls are hidden along with the Create button, preventing changes to associated child records.

child object class component ​

The child object class component is a formbuilder component used on an object class create/edit view to display and access records from a related child object class defined in the relational model. It is available in the side panel only when the current object class is configured as a parent, and configuration admins add it to the form so users can see a related records panel labelled with the child object class name, open associated child records, and work with those records from the parent context. This component matters because it is the platform feature that exposes parent-child relationships in the workspace: it depends on the relational modeller configuration, is removed from the parent view if that child relationship is deleted from the model, and shows up to five child records, making correct model design and form configuration essential for effective navigation and management of associated records.

Child Object Classes ​

Child Object Classes are object classes configured in the Relational modeller as children of a parent object class and then exposed in the parent object class’s create/edit view so related records can be created, viewed, and managed from the parent record. In Autologyx, they are used in system configuration when defining parent/child relationships in the relational model and in Formbuilder, where a dedicated Child Object Classes section appears for parent object classes and lets administrators drag available child classes onto the form and configure how child records are presented. This matters because it connects the data model to the user interface: once a relationship is saved, the parent record can surface related child records, support relational data entry and display for end users, and make those related records available for search, summaries, document merges, messaging, and sequence automation across the hierarchy.

Show 6 more pages

child record component ​

In Autologyx, a child record component is a configurable user interface component used to present records that are related as child records to a parent record within a view. It is used in record display and configuration contexts where related records need to be shown as a structured list, and it supports customization of list header widths and the content shown in the list. This matters because it allows configuration admins to control how child record information is presented to end-users, improving usability and ensuring that related record data is displayed in a way that fits the object model and the needs of the process.

child record control ​

INSUFFICIENT_EVIDENCE

child record selector ​

In Autologyx, the child record selector is the interface used on a parent record to find, choose, and associate related child records according to the relationship defined in the relational model. It is used when working with relational records, and its presentation differs depending on whether the parent:child ratio is configured as 1:1 or 1:N. The child record selector matters because it controls how users link existing child records to a parent record in the workspace, ensuring relationships are created in line with the configured data model and supporting accurate record structure for both end-users managing records and configuration admins designing the relationship behaviour.

child record summary ​

Child record summary is a sidebar tab in the Autologyx workspace that shows summary details for the currently selected child record when working with parent/child relationships. It is used from a parent record view, where clicking a child record in a child component highlights that record and opens or updates the Child record summary in the side panel when the option is enabled in the View menu. The tab provides a quick way to review child record information without leaving the parent record and includes a control to open the child record in the main window using the configured create/edit view for that object class. This matters because it lets end-users inspect and move between related records efficiently while keeping the parent context visible, which is essential when managing associated records through relational views.

Child Record Summary side tab panel ​

The Child Record Summary side tab panel is a user interface panel in Autologyx that displays key information for a selected child record alongside the main record view. It is used when working with presented child records and related record information, giving end-users quick access to important details without navigating away from the current context. This matters because it speeds up review of linked records, improves visibility of child record data during case handling, and supports configuration decisions around child record components, Child Object Classes, and the record properties that should be surfaced to users.

child records ​

In Autologyx, child records are records in a child object class that are related to a parent record through a configured relationship in the relational model. They are used across the platform wherever relational records are surfaced, including parent record create and edit views, relation lookups, sequencer triggers and conditions, and document templates or Jinja2 logic that reads data from related records. Users can create, associate, view, and manage child records directly from the parent record when permissions allow, and configuration admins can expose child object classes on parent forms after the relationship has been defined in the Relational modeller. Child records matter because they structure one-to-many business data, give parent records access to related information, enable automation when child records are added or removed, and support reporting and document generation that depends on data held in related records.

Show 3 more pages

child search control ​

In the Autologyx platform, the child search control is a user interface element used on a parent record to work with associated child records in parent/child relationships. It is typically available when interacting with child records via the parent, including create and edit views that display related records, and it supports two core actions: locating an existing child record and adding a new child record to the parent. This control matters because it streamlines management of related data from a single parent context, helping end-users quickly find or attach the correct child records and enabling configuration admins to design relational record experiences that are efficient and consistent.

children records ​

Children records are records related beneath a current record in Autologyx’s relational model, representing the subordinate items returned when a relation lookup is configured to search for Children rather than Parent records. They are used in sequence configuration, particularly with the Relation Lookup actor and Sequence Runner, where an administrator defines a parent record class and evaluates its associated child records, such as Employment Contracts linked to an Employee. This matters because child record matching controls whether downstream sequence steps run, allowing configurations to respond differently when there are no child records, a single child record, or multiple child records, and enabling precise automation based on the existence and number of related records.

Class field list view ​

The Class field list view is the configuration screen in Autologyx where administrators see the fields defined for an object class in a single list, including each field’s Field ID. It is used when reviewing, identifying, and managing class-level field definitions that underpin Document Fields and other data structures tied to Object classes. This view matters because it gives configuration and Super Admin users a clear reference point for the fields available on a class, and the display of the Field ID in the list makes it faster and more accurate to distinguish similarly named fields, align configuration changes, and work consistently across related platform components.

Class fields ​

Class fields are the fields defined on an Object class that store the business-specific data for records of that class in Autologyx, distinct from standard Record properties such as system metadata. They are used throughout the platform wherever record data is configured, displayed, filtered, created, or consumed: in create/edit views and Form Builder layouts, in child object class displays, in records list column configuration and filters, in relationship and lookup configuration, in document merge fields such as the Catalyst Word Add-in, and in APIs that create hierarchical records where the supplied fields correspond to the object class configuration. Class fields matter because they determine what information users capture and see for each record, how administrators shape the user experience for different object classes, and how developers and integrators map application data into Autologyx records and related processes.

Show 2 more pages

class id ​

In Autologyx, the class id is the identifier for the object class context in which an Element is running, and it is used alongside the record id to tell embedded Element code which class and record the current page relates to. It is relevant when configuring or developing Elements for pages such as object class create, edit, view, display, summary, and standalone forms, where the platform can pass page context into the Element, including through the application iframe and related message data or parameter objects. The class id matters because it lets integrations and custom Element logic target the correct object class, build the right endpoint or form behaviour, and distinguish class-based forms from the Landing page, where both class id and record id are undefined because no object class record context exists.

class or record permissions ​

INSUFFICIENT_EVIDENCE

Class owner ​

In Autologyx, a Class owner is a user assigned as an owner of an object class within System configuration. Class owners are shown in the Object classes list in the Owners column, where the platform displays the avatar of the single owner, or the avatar of the oldest owner together with a count of additional owners when more than one owner is assigned. This matters to Configuration admins and Super Admins because class ownership identifies who is responsible for a given object class, making it easier to manage and govern object class configuration at a glance.

Class Permission Sets ​

Class Permission Sets are Autologyx configuration objects used to grant permissions for a class of items or capabilities, and are managed by administrators to control access at scale. They are used in platform configuration, particularly in the class permission set itself and its Manage Assignees panel, where admins can assign either individual users or User Groups to apply the same permissions across multiple users at once. This is part of Autologyx’s group-based permission system and complements related controls such as list permissions and group support in Record Permission Sets. Class Permission Sets matter because they simplify administration, make access control easier to maintain as teams change, and ensure permissions are automatically applied or revoked for all users in an assigned group when group membership or assignments are updated.

Class permissions ​

Class permissions are the object-class-level permission sets configured on an Object Class in Autologyx to control what assigned users or user groups can do in relation to the class itself, all object records in that class, and tasks assigned to those records. They are managed in the Object Class editor on the Permissions tab, in the Class permissions sub-tab, which is the default section shown when editing permissions, and are typically configured by Super Admins or Object Class Owners. Class permissions matter because they define the baseline access and operational capabilities for a class, determine which assignees can work with that class through permission sets, and form a core part of the platform’s access model alongside Record permissions.

Show 3 more pages

Class User Field ​

A Class User Field is an object class field type in Autologyx that stores selectable users and, when configured with user groups, controls how those group members are presented and maintained for end users. It is configured in the Selection Options of an object class field, where administrators define the available users or groups and related behaviour such as allowing individual member selection, syncing group members, aliases, and default values. This field matters because it determines how user-based choices are exposed in forms and records, directly affecting assignment, routing, and data consistency across the platform; administrators should also monitor edit warnings if a previously available user has been deleted so the field configuration remains valid.

classes ​

In Autologyx, a class is a configurable record type that defines the structure and behaviour of records in the platform. Classes are used when adding fields such as JSON fields for display and capture in record forms, and they are also used in automation and relationship modelling, including Sequencer features such as the Relationship Created trigger, which operates on classes configured in the Relational modeller as relational entities. For Configuration Admins and Super Admins, classes matter because they are a core part of platform design: they determine how data is organised, how records are presented to users, and how parent and child record relationships can be recognised and acted on by workflows and triggers.

Click to Call ​

Click to Call is an Autologyx end-user feature that lets users initiate a phone call directly from an Autologyx Record by selecting a saved phone number in the browser interface. It is used wherever phone numbers are stored on records and is available through the web experience across supported browsers and devices, including desktop, laptop, and mobile. Click to Call matters because it removes the need to manually copy or re-enter contact numbers, helping users contact record-based parties faster and making communication workflows in Autologyx more efficient.

Click To Call On Autologyx ​

ClickHouse integration ​

ClickHouse integration, also referred to as the Catalyst ClickHouse integration, is the Autologyx capability that connects platform data to ClickHouse so users can browse historical events and work with database views through a consistent, read-only data access experience. It is used in analytics and reporting scenarios around database views, including Autologyx Cross Platform views, Event History tables, and Resource tables, and is relevant to information security and compliance teams, developers and integrators, and configuration administrators. This integration matters because it provides a structured way to explore and analyse operational data at scale, helping teams create insightful views and support data-driven oversight without changing source records.

ClickHouse views ​

ClickHouse views are configurable database views in the Autologyx platform that let administrators and analytics-focused users create tailored perspectives of platform data, including historical records, so they can examine the same underlying information from different angles. Introduced as part of Autologyx Catalyst 1.8, they are used in reporting and data exploration scenarios where configuration admins or super admins need custom snapshots to identify patterns, trends, and operational detail more effectively. ClickHouse views matter because they make platform data easier to navigate and analyse without changing the source data, supporting deeper insight for compliance, security, and analytics use cases.

client credentials ​

Client credentials are the OAuth 2.0 credentials used in Autologyx to authenticate an integration directly with an external provider, without relying on an individual user sign-in. In the platform, they are used when configuring Authentication Objects and integrations through Catalyst, including the Generic OAuth 2.0 template introduced to support connections with virtually any provider that accepts the client credentials grant. This matters to configuration admins and developers because client credentials provide a standard way to establish secure system-to-system access, simplify integration setup for custom or non-standard providers, and enable the Autologyx integration framework to connect services consistently across different external applications.

client credentials flow ​

Client credentials flow is the OAuth 2.0 server-to-server authentication method used in Autologyx when the platform connects to an external service without a signed-in user, allowing a configured application identity to obtain access tokens and call protected APIs. In Autologyx, it is used through integrations such as the Microsoft authentication object and related API-driven components, including actors that make outbound API requests. This matters to developers, configuration administrators, and super admins because it enables secure background automation, supports service-account style integrations for business processes, and determines how authentication is configured, tested, and maintained for external system connectivity.

Client ID ​

Client ID is the unique identifier of an external application or identity provider configured in Autologyx authentication settings and authentication objects. It is used when setting up integrations such as Single Sign-On, Microsoft authentication objects, and iManage authentication objects, where Autologyx must identify the application during the authentication process alongside related credentials such as a Client Secret or other required parameters. This field is mandatory in relevant configuration screens, which makes it a core value for configuration admins, super admins, and integrators because the correct Client ID is required for Autologyx to connect to the target service and complete authentication successfully.

Client ID field ​

The Client ID field is the value in an Autologyx authentication object where you enter the external application’s client identifier so Autologyx can authenticate against that service. In the DocuSign configuration flow, this field is populated with the DocuSign Integration Key when creating or editing the authentication object used by the platform. This field is used by configuration administrators and developers during setup of Authentication Objects in Administration, alongside related connection and token settings such as the Host field and access token details. It matters because it links the Autologyx authentication configuration to the correct registered app in the external system, enabling the integration to authenticate successfully and use the intended service connection.

Client Secret ​

Client Secret is the confidential key issued for an application during app registration and used in Autologyx authentication and single sign-on configuration to identify the application securely alongside the Client ID. It is entered in authentication objects and Single sign-on settings by configuration administrators, Super Admins, and integrators when connecting Autologyx to external identity providers or services that use client credential-based authentication. In the platform UI, the value is treated as a protected secret and displayed masked with asterisks, reflecting its sensitive nature. This setting matters because it is required for saving mandatory authentication configurations and for establishing trusted, secure integration between Autologyx and the external authentication service.

Client Value team ​

INSUFFICIENT_EVIDENCE

collaborative workspace ​

collapse icon ​

In the Autologyx Relational model canvas, the collapse icon is the control shown on a parent object class that lets configuration admins collapse its displayed child object classes in the visual model. It is used while creating and editing parent/child relationships in the relational model, where expanding and collapsing nodes helps manage the layout of object classes and their connections on the canvas. This matters because it makes complex relational models easier to navigate, review, and configure by reducing visual clutter and allowing admins to focus on the parts of the model they are working on.

colour control fields ​

Colour control fields are the mandatory input fields on the Autologyx Configure Theme page, within the Colours tab, where configuration administrators enter hex colour values to define the platform theme. These fields are used for theme settings such as core, form, and additional colours, including items like the primary colour, secondary colour, navigation panel background colour, and section content background. Each colour control field only accepts valid hex values and will automatically revert to the previous valid value if left empty or if an invalid entry is entered, ensuring that theme settings always remain complete and usable. They matter because they directly control the visual styling applied across the platform and enforce valid configuration when creating or updating a theme.

Colours tab ​

The Colours tab is the section of the Configure Theme page in Autologyx where configuration administrators define the system-wide colour palette used across the platform. It is used when creating or editing a theme and requires colours to be entered as hexadecimal values in colour control fields grouped into Core colours, Additional colours, and Form colours. These settings control specific interface elements such as the Primary colour for radio buttons, Create and Add actions, and menu tile gradients, the Navigation panel background colour for the main left-hand menu, and the Section content background for object record forms and task forms. This tab matters because it determines the visual styling and consistency of the Autologyx user interface, allowing administrators to align the platform with organisational branding and improve clarity across navigation and forms.

Column configuration ​

Column configuration is the control used on Autologyx list pages to choose and arrange which columns are shown in tabular views such as the Records list and other lists that surface tasks or template data. It is accessed from the page controls on a list page, where users and configuration admins can add useful fields to the view, including Object class fields and operational columns such as task-related counts exposed for Task templates. This matters because column configuration lets users tailor list pages to show the most relevant information for their role, improving navigation, review, and day-to-day work, while also supporting administrators who configure lists so that key data is visible and usable across the platform.

Column configuration button ​

The Column configuration button is a list-page control in the Autologyx platform that lets users add available columns to a table view, such as the Document templates list, so they can display additional metadata beyond the default listing. It is used when viewing configurable lists and works alongside list controls such as filtering and pagination to tailor how records are presented. Any columns selected through this button persist for the user, which makes it an important usability feature for both end-users and configuration administrators who need quick access to fields such as Created, Created by, or Description without changing the underlying template or system configuration.

Column configuration control ​

Column configuration control is the control on Autologyx list pages that opens column configuration mode, where users customise the visible columns and their display order for that specific list view. It is used on list pages to add or remove columns, rearrange them by dragging column headers, save changes, cancel edits, or reset the page to its default setting; the Actions column is fixed and cannot be removed or repositioned. This matters because it lets end users tailor each list page to show the most relevant information in the most useful order, improving navigation and day-to-day working without affecting other list pages.

column configuration function ​

The column configuration function is the list customisation feature in the Autologyx platform that controls which columns are shown on a records list and how record data and class fields are presented in tabular views. It is used in list-based configuration and administration areas, including records lists and related object class screens, and uses the same add field panel structure found elsewhere in the platform, where fields are organised into categories such as Record properties and Class fields. For configuration admins, this function matters because it determines how information is exposed to users in operational and setup lists, making it easier to tailor views for specific object classes, forms, and relationship configurations so the most relevant data is visible and manageable.

In Autologyx, the column configuration link is the control on a list page that lets users choose which optional columns are displayed for that list, so they can tailor the page to show the information most useful for their role. On the User Group List, this link is used to add column headers such as Members, Owners, Created, Created by, Last edited, and Last edited by. This matters because it allows configuration admins, super admins, and other authorised users to adjust list views for faster administration, clearer oversight, and more efficient review of records without changing the underlying data.

column configuration mode ​

Column configuration mode is the editing state used on Autologyx list pages to customise which columns are shown and the order they appear in. It is accessed from the column configuration control, including the Add columns button and column selection list, and lets users remove columns with the X control on each column header, reposition columns by drag and drop, save changes, cancel edits, or reset the view to the default setting. The Actions column is fixed and cannot be removed or moved. Warning modals are shown for actions such as cancelling changes or resetting to default so users can confirm before the list layout is changed. This mode matters because it allows end users to tailor list views to the information they need most, improving efficiency and consistency when working across records and tasks.

column headers ​

Column headers are the labels shown at the top of each column on Autologyx list pages, identifying the data displayed in the list and acting as the reference points for column configuration. They are used when working with the column configuration controls, where users can add columns, adjust which headers are visible, and manage page-specific layouts using options such as Save changes, Reset to default, and Cancel. Column headers matter because they define how information is organised and presented on each list page, helping users tailor views to the tasks they perform while preserving the default settings for that page when needed.

Column ratios ​

Column ratios are the layout setting used in Autologyx to control the relative width of columns within a Section when configuring a form or display. They are selected in the Components panel and Display tab while creating or editing views, including create and edit views, summary views, card views, standalone forms, and task templates, and the available ratio options depend on how many columns are configured for that section. This setting matters because it determines how space is distributed across the section, helping configuration administrators and Super Admins design clear, usable page layouts that present fields and content in the correct visual balance for each display type.

column selection list ​

In Autologyx, the column selection list is the pop-up list used on list pages during column configuration to display the available table columns that are not currently shown. It is opened from the Add columns button and works alongside the column configuration control, column headers, Save changes, Cancel, Reset to default, and the warning modal that appears when changes are not saved. This list matters because it is the primary way users and administrators add hidden columns back into a table, allowing each list page to be tailored to the information they need to view while preserving control over the current column layout and default settings.

columns ​

In Autologyx forms, columns are the layout containers within a section that organise fields into vertical positions across the form. Configuration admins use columns when designing record and task forms, including changing the number of columns in a section and selecting which column to remove when simplifying a layout. Columns matter because they can contain fields that participate in conditional logic, such as a controlling field that shows or hides another section, so changing or removing a column can directly affect form behaviour as well as presentation. In the form designer, Autologyx highlights when a column contains a field involved in conditional logic, helping administrators identify dependencies before making layout changes.

Combine option ​

The Combine option is a setting on the Document Picker actor in Autologyx that lets a sequence gather all files from a specified path instead of selecting a single document. It is used when configuring document handling within a sequence, particularly where sequence connections and downstream steps need a complete set of files from one location. This matters because it changes how documents are collected and passed through the workflow, allowing administrators to design processes that work with grouped file sets and helping end-users ensure all relevant documents are included in the sequence.

Combine results ​

Combine results is a Document Picker actor configuration option in the Autologyx sequence workspace that causes the picker to accumulate documents produced earlier in the same process path and pass them forward as a single set for use by downstream actors. It is enabled through the Combine results checkbox in the Document Picker’s actor Properties and is commonly used with documents generated or retrieved by actors such as DocAuto and API-based document retrieval steps. When turned on across successive Document Pickers, later actors such as Update Record, Send Message, or Create Task can work with the combined collection of documents; when turned off, only the documents selected by the immediately preceding picker are passed on. This feature matters because it controls how document outputs are grouped, stored, reviewed, and attached later in the workflow, making it an important setting for configuration admins designing multi-document process paths.

Comfortable ​

Comfortable is a row density setting available to end users in My account that controls how list and table content is spaced across Autologyx listing pages. Selecting Comfortable applies a taller layout, with row height set to 40px and header height set to 43px, creating more visual separation between items than more compact density options. This setting matters because it changes how much information is visible on screen at once and how easy listings are to scan and interact with, allowing users to tailor the interface to their preferred balance of readability and information density.

Communication ​

Communication is the Administration area in Autologyx where platform-wide communication settings are managed, alongside related controls for authentication and shared environment behaviour. It is used by Super Admins and configuration administrators to access and configure items such as outbound mail setup, Microsoft client credential mail integration, company details, single sign-on settings, and user activation rules. This area matters because it controls how the platform sends messages, supports sign-in and access-related communications, and applies shared communication and identity settings consistently across the environment.

Compact ​

Compact is the row density setting in Autologyx that displays list pages with the smallest spacing, using a 30px row height and a 33px header height. It is selected from the row density options on the My account page, where users can choose how densely information is shown across the platform. When Compact is saved, the setting is applied to all listing pages, allowing users to see more rows on screen at once. This matters because it changes the visual density of lists and helps users tailor the interface to their preferred working style when reviewing large volumes of items.

Company details ​

Company details is an Administration configuration page in Autologyx where Super Admins, or users whose role includes the Edit permission for Company Details, maintain the organisation’s contact information for a nominated user or generic contact. It is accessed from the left-hand Administration menu under Communication, and the values entered on this page are exposed as merge fields for use in message templates. This matters because it provides a centrally managed source of company contact data used in platform communications, and access to view and edit it is controlled through roles and permissions alongside related administration settings such as Standard authentication and outbound mail setup.

Company details page ​

The Company details page is a configuration page in a Catalyst instance that stores the organisation-specific information used by the Autologyx platform in user-facing account processes. In the standard authentication configuration, the details shown when a user selects the "Forgot your password?" link on the login page are taken from this page. This makes the Company details page important for Configuration admins and Super Admins because it controls the company information presented to users during password reset interactions and helps ensure that authentication-related communications reflect the correct organisation context.

Complete all ​

Complete all is a class permission in Autologyx object class configuration that allows a user to view and complete every Task for records in that object class that are available under their Workspace, without granting the ability to delete those Tasks. It is configured alongside other class permissions such as View all, Edit all, Assign all, and Delete all, and when Complete all is enabled, View all is automatically enabled. This permission matters because it determines whether operational users can action Tasks across all relevant records in a class, not just the records they own, which is essential when configuring shared team workflows, task coverage, and role-based access for users such as handlers or other workspace-based processing teams.

Complete all tasks ​

Complete all tasks is an Object Class Permission set capability in the Autologyx platform that allows a user to complete any task within the relevant object class without needing to be the specific assignee for that task. It is used when configuring object class permissions and is referenced in task template and task completion rules alongside other ways a user can complete a task, such as being a Super Admin, being the owner of the object class, or being the task assignee. This permission matters because it controls who can progress manual or automatically generated work across an object class, giving configuration administrators a way to grant broad operational task-completion rights where required.

Complete button ​

Complete field ​

The Complete field is used when creating a Manual Task in the Create task screen, within the Assignment of stages section, to select the user or users responsible for completing the task. In Autologyx, this field defines the task’s assigned completers and controls who the task is presented to, alongside users who can view it through elevated role or permission rules. Users with Super Admin, Standard, or one time completion account types can be selected in this field, and up to 100 users can be assigned to a single manual task. This field matters because it determines task ownership at creation time, supports accurate work allocation, and ensures the right users are targeted to complete the task on the relevant object record.

Complete self contained form ​

Complete self contained form is an Autologyx task type used in Task Templates to define a standalone user form, from a single field to a complex multi-field response, including how the task is presented and how it is created through the task creation mechanism. It is configured in the task template Response Configuration and is especially important because, unlike Update object record tasks, Complete self contained form templates can be shared across multiple object classes and, when set to Automatic, are available in the Sequence designer for all object classes. This makes it the most versatile task type for configuration admins and Super Admins who need reusable task templates, consistent form-based user interactions, and flexible task design across applications.

Show 2 more pages

Complete standalone form ​

In the Autologyx platform, Complete standalone form is a task type used to create a task whose purpose is to have a user complete a form independently of updating existing object records. It is used when configuring task assignment and template selection, including scenarios such as assigning work to 1 time completion users, where only task templates with the Task creation mechanism set to Manual are available for this task type. This matters because it determines the kind of task being created, which task templates can be selected during configuration, and how end-users interact with the task in the Catalyst system as a form-based activity rather than a record-update action.

components ​

In Autologyx, components are the individual building blocks used to compose a standalone form, specifically sections, instructions, and fields placed on the canvas during form design. Configuration admins use components when creating and structuring forms within object class configuration, where they control the form’s layout, guidance, and data capture points. Components matter because they define both the user experience and the information collected by the form, and they are also subject to platform limits, with each standalone form supporting up to 200 components.

Components panel ​

The Components panel, also referred to as Components or the side stack, is the selection area in the Display tab’s edit display screen where configuration admins build an Object class form layout. Used alongside the central canvas in the Create and edit view, it lists the available components that can be dragged and dropped into the form, typically organised into Layout, Fields, and Properties sections. The panel is kept in sync with Object class field changes, so newly added fields appear there, deprecated fields are removed, and updated field labels are reflected in the panel or form. This matters because it is the primary source for adding and arranging content on a display, ensuring administrators can configure accurate, current form layouts efficiently.

conditional branching ​

Conditional branching is workflow logic in the Autologyx platform that routes processing down different paths when defined conditions are met, allowing a process to execute different actions, sequences, or task updates according to data, state, or business rules. It is used when configuring workflow automation and related actions so that process behaviour can vary within a single design, including in complex automation scenarios where features such as task handling must integrate with existing workflow logic. Conditional branching matters because it enables configuration admins and developers to build flexible, rule-driven processes that adapt to operational outcomes, reduce manual intervention, and keep workflow behaviour aligned with specific case or record conditions.

conditional logic ​

Conditional logic in Autologyx is a form-configuration feature that changes what users see or can complete according to values entered in earlier fields, allowing admins to show or hide relevant fields, sections, and columns in task template forms, object class create/edit, summary and standalone forms. It is configured in the form builder and standalone form editing areas, where it is used to create more dynamic record-creation and task forms that present only the questions needed at each step. Conditional logic matters because it simplifies the user experience, keeps forms focused and efficient, and supports accurate completion of dependent form content; it also has configuration impact, as changing or removing fields, sections, or columns that participate in conditional rules triggers warnings and removes the related logic, so controlling fields should be designed carefully and typically marked as required.

Show 5 more pages

Conditional Logic controlling field ​

A Conditional Logic controlling field is the form field whose value is evaluated to determine whether other fields or sections are shown, hidden, or otherwise affected by conditional logic in an Autologyx record or task form. It is used when configuring conditional logic rules in forms, where administrators define behavior that depends on user input in a specific field. This field matters because it drives dynamic form behaviour for end-users and is a dependency within the form configuration: changing its properties, moving or removing related columns or sections, or deleting the controlling field itself can affect the conditional logic that relies on it and alter how the form behaves.

conditional logic icon ​

In Autologyx, the conditional logic icon is the visual indicator shown on a form layout element, such as a column, to show that it contains a field or section that is controlled by conditional logic. It is used in the form designer when configuring record and task forms, helping configuration admins identify which columns include conditionally displayed content and distinguish them from columns with no logic applied. This matters because it makes form maintenance safer and faster: when reviewing or removing columns, the icon highlights where show or hide rules are in effect so you can avoid disrupting fields or sections that depend on conditional logic.

Conditional Logic in Forms ​

Conditional Logic in Forms is the form builder capability in Autologyx that makes record and task forms dynamic by showing, hiding, enabling, disabling, or otherwise changing form behaviour according to values entered elsewhere in the same form. It is used when configuring Record and Task Forms in the Form Builder, alongside form components, fields, sections, columns, and other layout elements, to control how users interact with Object Records and Tasks. This matters because it helps configuration administrators and Super Admins create clearer, more efficient forms, guide users through only the fields and actions relevant to their inputs, and safely maintain existing forms by understanding the impact that changing or removing fields, columns, or sections can have on established conditional rules.

Conditional Visibility ​

Conditional Visibility is a form configuration feature in Autologyx that controls whether a section is shown or hidden according to values entered or selected in other fields on the form. It is configured in the Form builder from the Conditional Visibility control at the bottom of Section Properties, where administrators define rules that use form fields as condition inputs. This feature is used in record forms, task forms, standalone forms, object class displays, and task template form configurations to present additional sections only when they are relevant. Conditional Visibility matters because it lets configuration and super admins create cleaner, more dynamic forms, reduce unnecessary content for end users, and ensure that the form layout responds correctly to earlier answers.

Show 3 more pages

conditional workflows ​

conditionally displayed ​

In Autologyx, conditionally displayed describes a section on a record or task form that is shown only when conditional logic tied to one or more controlling fields is met. This is used in form configuration where selections or inputs in a field determine whether another section becomes visible to end-users, and it also appears in on-screen warning messages that identify sections affected by that logic. This matters because conditionally displayed sections directly control the form experience for users and must be considered carefully by configuration admins when changing or removing sections or fields, as those changes can affect dependent sections and the behaviour of related conditional logic.

conditionally displayed sections ​

Conditionally displayed sections are form sections in Autologyx that are shown or hidden dynamically by conditional logic tied to a user’s selection or input in a controlling field. They are used in record and task forms, where fields within a section or column can determine whether a later section becomes visible, allowing forms to present only the content that is relevant to the current response. This matters to configuration admins because removing or changing a controlling field or the column that contains it can affect any sections that depend on that logic, and Autologyx highlights those impacted sections in warning messages so the form design can be updated safely. It also matters to end-users because conditionally displayed sections shape the form experience by revealing additional sections only when specific answers require them.

conditions ​

In Autologyx, conditions are the rules used in form conditional logic to control whether sections or fields are shown according to the value of another field. They are configured within record and task forms, where a field can act as the controller for conditionally displayed sections or other form elements. Conditions matter because they determine how dynamic form behaviour works for users and they create a dependency between the controlling field and the logic it drives; if a field that is used in conditional logic is removed, Autologyx warns that the associated conditions will also be deleted.

Config Admin account ​

A Config Admin account is an Autologyx user account type that grants configuration-level access to User Group administration without requiring a Role assignment. In practice, it is used in the User Groups and Users areas of the main navigation, where a user who is both a User Group Owner and has a Config Admin account can open and edit that group, manage members, create and maintain permission sets, view usage, and delete the group; a User Group member with a Config Admin account can access and view the group but cannot edit or delete it. This account type matters because it controls whether User Group Owners receive direct administrative navigation and configuration capabilities for the groups they own, providing delegated administration below the unrestricted system-wide access of a Super admin account.

Config admin account type ​

Config admin account type is an Autologyx user account type for internal users who need controlled access to Administration and System configuration features. It is used on user accounts as the account type that can be assigned Roles, and those Roles determine which configuration and administrative areas the user can access, such as User Groups, Object classes, standalone forms, sequences, and task template-related setup. This account type matters because it provides a structured way to delegate platform configuration work without granting full Super admin access, letting organisations promote internal users from Internal to Config admin, assign up to 25 Roles, and give them only the permissions required to perform specific configuration tasks.

Show 6 more pages

Config Admin users ​

Config Admin users are a user account type in the Autologyx platform used for configuration and administrative work, and they are referenced in platform controls that distinguish how different classes of users can sign in and what actions they can perform. In system configuration, Config Admin users are one of the accepted account-type keys when defining permitted authentication methods by user account type, allowing authorised administrators to enforce specific login routes for these accounts separately from external users, internal staff accounts, and accounts with full platform access. They also appear in permission handling, such as when a Config Admin user tries to create a sequence without the required permissions and receives clearer feedback. This matters because Config Admin users often need tightly controlled access in governance or regulated environments, so correctly configuring their authentication methods and understanding their permission boundaries helps protect administrative access and ensures configuration tasks are performed by the right users with the right level of control.

Config Admins ​

Config Admins are an Autologyx user account type for users who need standard platform access plus controlled administrative and configuration capabilities through assigned roles and permissions. They are used when organisations want to delegate specific build and configuration tasks—such as creating or editing object classes, sequences, task templates, relational models, and accessing selected protected administration areas—without granting full Super Admin access. In practice, a Config Admin’s capabilities are determined by role permissions, permission sets, and in some cases dedicated API-granted permissions such as users.list for user visibility. This matters because Config Admins provide a secure separation between full system administration and day-to-day configuration work, allowing Super Admins, configuration teams, and integrators to assign only the access needed for implementation and ongoing platform maintenance.

Show 3 more pages

config.json ​

In Autologyx, the config.json file is the configuration file used by an Element and forms part of the Element project. It is used when creating and configuring Elements in the Administration area, where authorised users define how the Element is set up for use on the platform. This file matters because Elements rely on config.json for their configuration, making it a core artefact for developers, integrators, and configuration administrators who build, maintain, or deploy Element functionality in Autologyx.

config.json file ​

In Autologyx, the config.json file is the configuration file used to define and update how an Element looks and behaves. It is maintained in the Element’s Git repository alongside related files such as the ccs file, and changes to an Element’s presentation or functionality are made by editing this file rather than through the Element edit page in the platform. This matters to developers, integrators, and configuration administrators because config.json is a key part of Element package management and is the source-controlled location for implementing and maintaining Element configuration.

configuration areas ​

configuration fields ​

Configuration fields are the editable settings within an Autologyx configuration item, such as an Authentication Object, that store the values used to define and connect that item to the selected provider or setup option. They are used in administration screens when Configuration Admins and Super Admins create or update platform integrations and related authentication settings. These fields matter because their contents are tied to the current configuration context: when an administrator switches focus to other configuration fields while editing an Authentication Object, existing data in those fields is cleared, so understanding how they behave is essential to preserving valid setup information and avoiding unintended loss of configuration values.

configuration is not over written ​

In Autologyx, "configuration is not over written" describes the behavior of System Migrations for mapped Authentication Objects: when an object such as a DocuSign authentication configuration is matched between environments, the migration preserves the existing configuration in the target system instead of replacing it with values from the source system. This is used during promotion between environments such as dev and live, particularly for API and authentication settings that are environment-specific. It matters to Configuration Admins and Super Admins because it protects live credentials and connection details from being changed by a migration, so these settings must be reviewed, maintained, and configured separately in each environment.

configuration migrations ​

configuration modal ​

The configuration modal is the dialog used in Autologyx to view and edit the settings for a configurable platform element, such as a configured actor within the Sequencer. It is used by configuration administrators and Super Admins when opening an item’s setup to review selected resources, options, and field values, and it is a key point for identifying and correcting invalid configuration data. In practice, the configuration modal matters because it presents broken or missing references directly in context—for example by highlighting invalid fields in red and showing which option is missing—so administrators can fix issues before saving and keep workflows and actors correctly configured.

configuration panel ​

In Autologyx, the configuration panel is the actor-specific setup interface that opens when a user selects Configure for an actor, such as an API Call actor or Local Variable actor. It is used in system configuration to define and edit the fields that control how that actor behaves, including core properties such as an API call definition or a variable’s name and type. The configuration panel matters because it is the primary place where configuration admins and developers translate process design into executable settings, ensuring each actor is correctly defined and behaves as intended within the platform.

configuration tabs ​

Configuration tabs are the administrative tabs available when configuring a User group in Autologyx, used to manage that group’s membership and its permissions. In practice, these tabs provide the controls for adding and maintaining group members and for defining what the group can access or administer within the platform. They are primarily relevant to Configuration admins and Super Admins because they are the entry point for setting up how user groups are structured and what capabilities those groups have, including permission-related settings that govern platform access and administration.

Configure ​

Configure is the action used in Autologyx to open the settings for an item so it can be set up or edited. It is used in multiple parts of the platform, including Administration tiles for single-page settings and the context menu of sequence actors such as the API Call actor, DocAuto actor, and Document Picker actor, where users right-click the item and select Configure to open its configuration panel. This matters because Configure is the standard entry point for defining how platform components behave, such as selecting templates, authentication, and processing options, making it a core interaction for administrators, super admins, and developers who manage system settings and build or maintain automated processes.

Configure record ownership ​

Configure record ownership is an option in the Record access configuration modal for a Record Access actor that enables the actor to set or manage ownership of records within an Autologyx sequence. It is used in system configuration when defining how record access is applied, alongside the separate option to configure record permission set assignment, and can be enabled independently or together on the same actor. This matters because record ownership determines which user or role is established as the owner of the record, supporting the correct routing, control, and administration of access as part of sequence design and platform configuration.

Configure record permission set assignment ​

Configure record permission set assignment is a Record Access actor configuration option in Autologyx that controls how record permission sets are assigned to a record as part of a sequence. It is used in the Record Access actor setup, alongside record ownership configuration, and is available only when the sequence’s object class has at least one record permission set defined. When enabled, configuration administrators can specify how access is applied using assignment methods such as append, override, or remove, and target users through options including by field, by users, and user groups. This matters because it lets administrators automate and govern who can access a record at different points in a process, ensuring the correct users and groups receive the required permissions through platform configuration rather than manual intervention.

Configure task assignees ​

Configure task assignees is a Task Assignment Actor setting in Autologyx that enables the actor to set the users assigned to a task during sequence execution. It is used in system configuration when designing or updating a Task Assignment Actor, typically alongside options such as Override task assignees, Append task assignees, By users, By field, and Set task owner. This setting matters because it controls whether the actor actively manages task assignment for that step, allowing configuration administrators and Super Admins to replace or supplement assignees that were defined in the Sequence Properties and ensure work is routed to the correct users for that task.

Configure Theme page ​

The Configure Theme page is the Autologyx system configuration page used to define and manage the platform’s visual theme. Accessed by selecting Theme, it opens on the Media tab and is the central location where configuration administrators and Super Admins work with theme settings such as branding assets and colour-related options across the available theme tabs. This page matters because it controls how the Autologyx interface is presented to users, allowing administrators to apply consistent organisational branding and interface styling across the platform.

configured actor ​

A configured actor, often shortened to actor, is an actor step that has been set up in a sequence to use a specific platform resource such as a user, user group, permission set, or another actor-specific option. In Autologyx, configured actors are used in the Sequencer and edited through the configuration modal, where administrators define the resources and settings an actor needs to run correctly. This matters because an actor depends on those configured references remaining valid: if a referenced resource has been deleted or is no longer valid, Autologyx flags the actor in the Sequencer with a warning icon, highlights the broken fields in red in the configuration modal, shows the missing or invalid option, and blocks saving until the issue is corrected. For Configuration Admins and Super Admins, understanding configured actors is essential to maintaining reliable sequences and avoiding hidden configuration errors in large or complex workflows.

Configuring An Element ​

Configuring an Element is the process of defining how an element behaves and is presented when used on an Autologyx form. In the platform, elements are the reusable building blocks of forms, and configuration is where administrators set the properties, options, and behaviour that control how the element functions for end users in a workflow. This is used within Elements administration when creating or maintaining form components, and it matters because the element’s configuration directly determines the data captured, the user experience on the form, and how consistently that element can be reused across processes.

Configuring Outbound Mail ​

Configuring Outbound Mail is the administration activity in Autologyx used to set up and manage how the platform sends outbound email communications from your environment. It is used in the Communication area of platform administration and is typically handled by Configuration Admins or Super Admins as part of broader outbound mail setup and company communication settings. This configuration matters because it controls the platform’s ability to deliver system-generated emails reliably and from the correct organisational context, supporting user notifications, process communications, and other email-driven interactions across the platform.

Configuring Outbound mail setup with Microsoft client credentials ​

Configuring Outbound mail setup with Microsoft client credentials is the Autologyx administration task for enabling platform-generated outbound email through Microsoft Office 365 Exchange using Microsoft Graph and an OAuth 2.0 client-credentials authentication object. It is used in the platform’s outbound mail setup area when administrators select the Microsoft mail service option, define the Azure environment, provide the required mail service connection details such as host and port, associate the Microsoft Client Credentials Authentication Object, and specify operational settings such as the backend failure alerts email address. This configuration matters because it establishes how Autologyx securely authenticates to Microsoft to send system and process emails, ensuring reliable delivery of notifications and alerts while aligning outbound mail with enterprise Microsoft identity and messaging configuration.

Configuring Relationships In Object Classes ​

Configuring Relationships In Object Classes is the administration activity in Autologyx where configuration and Super Admin users define and maintain the relationships between object classes within the platform’s data model. It is used in the Object Class Relationships area of System Configuration to control how different object classes are connected, which in turn governs how records can be associated, structured, and managed across the system. This matters because correctly configured object class relationships provide the framework for consistent data organisation, support the intended links between business objects, and ensure the platform behaves as expected when users work with related records and processes.

confirmation modal ​

connected actor ​

connecting triggers ​

Connection error ​

Connection error is an outbound mail configuration error in the Autologyx platform that indicates the mail server connection details are invalid, specifically when the host, port, or TLS settings are incorrect. It is encountered in Outbound mail setup, including when configuring or testing mail settings, and is relevant to Configuration admins and Super Admins responsible for enabling platform email delivery. This error matters because Autologyx relies on a valid outbound mail connection to send system and user-facing messages, so incorrect connection settings will prevent email from being sent until the server details are corrected.

connection testing ​

INSUFFICIENT_EVIDENCE

connector ​

In Autologyx, a connector is the visual link used in Sequence Design to join an Object class to a Task template object. Configuration admins create a connector by selecting the Object class in the object class area and dragging it onto the Task template object until the target is highlighted and the link can be dropped. This connection is used when designing a sequence to define how the task template is associated with the relevant object class, making the connector an essential step in structuring sequence behaviour and ensuring the correct relationship between sequence elements.

Constants ​

Constants are reusable, database-stored configuration values in Autologyx that are defined in the Resource Database and referenced throughout the Sequencer to supply fixed or environment-specific values without hard-coding them into sequence logic. They are used in areas such as API Call URLs and parameters, Local Variable values, Send Message recipients, subjects and message bodies, and AI actor inputs, and can also be inserted from context menus alongside record fields and Variables. Constants matter because they reduce manual configuration, simplify migration between environments such as test and production, and allow administrators to update a value in one place so every referenced use is updated automatically at runtime.

contains conditional visibility ​

Contains conditional visibility is a form-builder indicator in the Autologyx platform that marks a section configured with Conditional Visibility rules. It is shown in the form design experience, identified by the blue icon and accompanying hover text, so configuration admins can quickly see which sections have display logic applied through Section Properties or related conditional logic settings. This matters because it helps administrators locate and manage sections whose visibility changes at runtime, supporting accurate form behaviour, easier maintenance, and faster troubleshooting when configuring record or task forms.

Content Disposition ​

Content Disposition is the required header-style field used for each part in a multipart request configured in the Autologyx API Call actor. It defines how that individual part is presented in the request payload and identifies the part using parameters such as name; for file parts, it is also used to indicate that the part contains a file. In Autologyx, Content Disposition is used when configuring multipart data, including text parts and file parts, alongside an optional Content Type for each part. It matters because multipart requests depend on correctly structured request parts, and an incorrect or incomplete Content Disposition prevents external APIs from recognising the submitted fields or files as intended.

Content Type ​

In Autologyx, Content Type is an optional field used in the API Call actor’s multipart configuration to define the media type of an individual request part, such as a text value or file attachment, when building multipart requests. It is used alongside Content Disposition for each part in Multipart Data, including file parts and text parts, so external services can correctly interpret the content being submitted. This matters to configuration administrators and developers because setting the correct Content Type ensures integrations that accept multipart payloads, such as document-signing or file-upload endpoints, receive each part in the expected format and process the request successfully.

context_id ​

In Autologyx, context_id is the security token carried on a document object that binds that document to a valid platform context. It is used wherever document objects are passed between actors or referenced in automation, including Loop actor outputs and downstream actions such as Send Message, Doc Auto, or API Call integrations that consume document metadata. This field matters because it protects document handling by ensuring document references are valid within the originating context and cannot be forged through merge field manipulation, making it an important value for developers, configuration admins, and compliance-focused users who configure, transmit, or validate document-based workflow data.

controlling the display of another section ​

In Autologyx, controlling the display of another section describes a form configuration where the value entered or selected in one field is used in conditional logic to show or hide one or more other sections on a record or task form. This is used when building or maintaining forms, especially in section and field configuration, and is surfaced in platform warning messages when an administrator removes a section that contains a field driving those display rules. It matters because these controlling fields are dependencies for conditionally displayed sections, so changing or deleting them can affect form behaviour, disrupt the user journey, and require related conditional logic to be reviewed and updated.

Copy Trigger ​

Copy Trigger is a Sequencer configuration action in the Autologyx platform that duplicates an existing trigger definition so it can be reused elsewhere in the sequence without recreating its settings manually. It is used from the trigger context menu in sequence configuration, where an administrator right-clicks a configured trigger and selects Copy Trigger, typically followed by Paste Trigger to place the copied trigger in the required location. This matters to Configuration Admins and Super Admins because it speeds up trigger setup, helps preserve consistent trigger behaviour across sequence actors, and reduces configuration effort when building or correcting sequences.

Copy URL ​

  • Mostly relevant to: Configuration admins
  • Closely related concepts: Forms list

Copy URL is an action in Autologyx that copies the direct link to a form so it can be reused outside the current page. In the context of standalone form configuration, it is available alongside the displayed form URL and also from the Actions menu in the Forms list or form details area. This option matters to configuration admins because it provides a quick, consistent way to capture and share the exact form address for distribution, testing, embedding in process documentation, or use in related configuration activities without manually selecting or reconstructing the link.

Core colours ​

Core colours are the primary theme settings on the Configure Theme page, grouped as a dedicated section on the Colours tab, and used by configuration and super administrators to define the platform’s main brand colours for key interface elements. In this section, administrators set foundational colours such as the Primary colour, which drives prominent UI components including radio buttons, Create and Add action buttons, and the gradient shown on the right side of tiles in the System Configuration and Administration menus. Core colours matter because they establish the base visual identity of the Autologyx platform and control the appearance of high-visibility, frequently used interface elements across the application.

corresponding record ​

In Autologyx, the corresponding record is the specific data record that each generated document belongs to when you use the Templates panel to create documents for selected records. The platform uses this record as the destination context for saving the generated file into the designated field on that same record, ensuring the document is automatically attached to the correct item rather than stored separately or manually filed. This matters to end-users because it keeps generated documents organised and accessible from the record they relate to, and to configuration admins because the document-save behaviour depends on the correct field setup for each record type.

Country selector ​

In the Autologyx platform, the Country selector is a task form field input type that provides users with a searchable, alphabetical single-select drop-down list of countries. It is used when configuring task form fields in Form Builder, alongside settings such as Label, Description, Default value, and Conditional Visibility, and is especially suited to collecting country information for address details and application forms. This field matters because it standardises country entry, improves usability for end users through quick search and selection, and helps configuration admins design forms that capture consistent, structured location data.

Create ​

Create is the action used across Autologyx Administration and System configuration areas to add a new item in a configuration category, such as a task template, authentication object, user, role, or single sign-on setting. It is shown as a button on tiles and settings pages where the signed-in user’s role includes permission to create records in that area, and is commonly paired with Manage, which opens the list view for editing or deleting existing items. For Configuration admins and Super Admins, Create is important because it is the entry point for establishing new platform components and maintaining system setup, while its visibility also reflects the user’s access rights within each administration section.

Create A Child Record From The Parent Record ​

Create A Child Record From The Parent Record is an Autologyx relational-records action that lets a user add a new child record directly from an existing parent record, automatically establishing the relationship at the point of creation. It is used in workspaces where parent and child records are managed together, alongside related capabilities such as associating existing child records and interacting with child records through the parent. This matters because it streamlines data entry, preserves the correct record hierarchy, and helps end-users and configuration admins ensure related information is created and managed in the right business context without leaving the parent record.

Create A Document Template ​

Create A Document Template is the configuration activity used by Configuration Admins and Super Admins to add a new document template to the Autologyx platform so it can be used for document generation. It is accessed from the Working With Document Templates area alongside the document templates list and related editing functions, and forms the starting point for defining templates that support both manual document generation and automatic generation through the Sequencer. This matters because a correctly created template establishes the reusable structure and content source for documents produced in Autologyx and underpins downstream configuration such as template maintenance and MS Word add-in setup.

Create a Role ​

Create a Role is the administration task in Autologyx used to define a new role that groups a set of user permissions for assignment to users. It is used in the Roles and Permissions area by Configuration Admins and Super Admins when setting up access models, separating responsibilities, or supporting different teams with distinct platform capabilities. Creating a role matters because roles are the primary mechanism for controlling what users can view, configure, and do across the platform, helping administrators apply permissions consistently, simplify user management, and maintain clear governance over access.

Create A Task Group Template ​

Create A Task Group Template is the system-configuration activity in Autologyx used by Configuration Admins and Super Admins to define a reusable task group template that can be applied consistently across processes and work items. It is used within the Task Group Templates area of System Configuration, alongside related actions such as editing existing templates, and provides the controlled setup for how grouped tasks are structured before they are used operationally in the platform. This matters because creating task group templates standardises repeatable task arrangements, improves administrative consistency, and supports efficient configuration by allowing the same predefined group of tasks to be reused wherever that task structure is required.

Create An Element ​

Create An Element is the administration activity in Autologyx where configuration users define a new element for use on forms. Used from the Elements area of platform administration, this process establishes the element’s core structure and settings so it can be added to forms, capture or display the required information, and behave correctly in the user experience. Creating an element matters because elements are the building blocks of forms: getting creation right ensures forms are designed consistently, support the intended process requirements, and can then be configured and edited effectively as the solution evolves.

Create and edit view ​

Create and edit view is the object class display used in Autologyx to define the form that users interact with to create new Object records and update existing ones. It is configured on the object class Display tab by administrators, where they design the layout with sections, instructions, fields, properties, conditional visibility, and 1, 2, or 3-column arrangements, and can also include related child object classes when relationships have been configured. In the workspace, users access this view when creating a record through the configured form or when opening an existing record from the records list, including by double-clicking it for editing. This view matters because it controls the structure, usability, and data capture experience for record creation and maintenance, and determines how record information is presented and edited across the platform.

Show 1 more pages

Create and edit view display ​

Create and edit view display is the record form view in the Autologyx platform where users enter, update, and review record data during creation and editing. It is used in form design and record configuration, including in the Form builder where configuration admins choose which Record properties and Class fields are shown so end users see the right information at the right time. This display also provides the context for presenting related or child record information, such as through child record components and summary panels, making it an important part of controlling data visibility, usability, and the overall record-editing experience.

Create button ​

The Create button is the standard Autologyx user interface control used to start creating a new item from a list or component, such as a role, user group, object class, task group template, record, or child record. It is typically shown at the top left of list pages and can also appear within related-record components on a parent record, where selecting it opens the relevant creation page or modal for the chosen object type. This button is governed by role permissions, so it is displayed only when the user has Create access for that area, removed when Create permission is not granted, and disabled when a configured system limit for that item type has been reached. It matters because it is the primary entry point for adding new configuration items and operational records, and its presence, absence, or disabled state immediately indicates whether creation is available in that part of the platform.

Show 2 more pages

Create permission ​

Create permission is a role-based permission in the Autologyx platform that allows a user to create new items in a configured area, such as task templates, and is typically surfaced through the Create button on the relevant list page. It is configured by administrators in roles and permissions and is often paired with Edit permission, although Edit can be granted on its own for maintenance activities such as updating Sequence design or properties after a Sequence already exists. This permission matters because it directly controls whether users can start creating new records or configuration items, whether the create entry point is visible in the interface, and whether an in-progress creation can be saved if the permission is removed from the user’s role.

Create permission under User Groups ​

Create permission under User Groups is a system permission configured on the Administration tab of System permissions that allows a Config Admin, when granted through their Role, to create new User groups in Autologyx. This permission is used in the User group area of administration and directly controls access to the Create button shown at the top left of the User group list. It matters because creating User groups is restricted to Super Admins or Config Admins with this specific permission enabled, making it a key control for managing who can set up group structures that support actions such as assigning owners and members.

Create record button ​

The Create record button is the action on a Records list that starts manual record creation in Autologyx. Used by end-users in workspace lists, including parent or child record lists in relational scenarios, it opens the create/edit view or create record form configured for the relevant Object class. This button matters because it is the standard entry point for adding new records directly from a list, and its behaviour depends on Object class configuration, making it important for configuration admins who design record creation forms and for users who need to create records efficiently in the correct class and context.

create record form ​

The create record form is the data-entry screen opened from the Create record button when a user manually creates a new Object record in Autologyx. This form is defined in the relevant Object class and controls the create/edit view presented in record create mode, including the fields and structure used to capture the new record’s information. It is used by end-users when adding records in the workspace and by configuration admins when setting up how records are created for a given class. The create record form matters because it determines the user experience and required input at the point of record creation, directly shaping how Object records are captured and standardised in the platform.

Create record permission ​

Create record permission is the Object class permission in Autologyx that allows a user to add new records for that Object class. It is used when records are created through forms, including forms accessed from the Forms tab or through an externally hosted form URL, where the user is prompted to sign in before submitting a new record. This permission matters because it controls who can initiate new entries in a specific Object class, helping configuration administrators and Super Admins govern data creation while ensuring end-users can only add records where they have been explicitly authorised.

create records permission ​

Create records permission is the permission that allows a user to create new records for a specific object class in the Autologyx platform. It is applied at class level and is used anywhere users can add records, including relational record controls such as child class components, child lookup controls, child record selectors, the Create button, Actions menu options, and create/edit views. In parent-child record scenarios, this permission is required on the child object class to create a new child record for association, and it works alongside edit records permission on the parent object class when the relationship is being updated. This permission matters because it directly controls whether users can add new data, affects which creation actions and messages are shown in the interface, and is a key setting for configuration admins and super admins when defining secure, role-based access for end-users.

Create response form ​

Create response form is the action in Autologyx task template configuration that opens the Form builder to create the response form for a task. It is used from the Response configuration tab on the Create task template page, including task types such as Complete self contained form and Update object record, where administrators define the form that users complete when responding to the task. This action matters because the response form controls what information a task captures and enables form design features such as conditional visibility, making it a key step for Configuration admins and Super Admins when configuring how task responses are presented, structured, and submitted in the platform.

create sequence permissions ​

Create sequence permissions are role-based permissions in Autologyx that allow a user to create sequences in the Sequencer, the platform’s workflow engine where automated processes are built and run. These permissions are assigned through user roles and are typically relevant to configuration administrators and super administrators who control access to workflow design capabilities. In practice, create sequence permissions determine who can add new workflow definitions in the Sequencer, helping organisations separate process authoring from other administrative or operational activities and maintain controlled governance over how automation is introduced into the platform.

create SSO permission ​

Create task ​

INSUFFICIENT_EVIDENCE

Create task actor ​

The Create Task actor is a Sequencer actor used to create a task for a record from an Automatic task template at the required point in a workflow. It is configured in the sequence canvas by selecting the actor and choosing the task template; when executed, it creates the corresponding task if one does not already exist, and if no template is selected the sequence stops at that actor to prevent unintended processing. The actor is used in sequence design and task automation, often together with the Task Assignment actor to set task owners or assignees before creation, and with the Set Task actor for any later re-creation or deletion of tasks from the same template. It also supports task-driven workflow logic through events such as Task created and Task completed, and can make documents available for review when used with related actors such as Document Picker. This matters to configuration admins and Super Admins because it provides controlled, template-based task creation, improves consistency in automated workflows, and ensures tasks are introduced at the correct stage of a process.

Show 5 more pages

Create task button ​

The Create task button is the control in the Autologyx workspace that starts manual task creation for a specific Object record. It is used in the Tasks tab of an Object record, where it is displayed when the conditions for creating a manual task are met, and selecting it opens the create task process for that record. This button matters to end users because it is the entry point for adding ad hoc work directly against a record, enabling tasks to be created when no existing task is present or when additional manual work needs to be initiated from the record itself.

Create Task Configuration window ​

Create Task outgoing trigger ​

In Autologyx, the Create Task outgoing trigger is the configuration on a Create Task actor that determines when downstream sequence processing should continue after a task is generated. It is used in task-creation workflow design and is referenced by related actors such as Set Task Actor, which can trigger onward processing when the original Create Task outgoing trigger is set to "When Task Created". This setting matters to configuration administrators because it controls the timing of subsequent automation steps, ensuring that follow-on actions run at the correct point in the task lifecycle and that task-driven process orchestration behaves as designed.

Create Task panel ​

The Create Task panel is the Autologyx interface used when adding a new task to a case or workflow, where users define the task’s initial details and set assignment options such as selecting individual assignees or User Groups. It is used by end-users when creating work and by configuration-focused users who need to understand how task assignment behaves at the point of creation. This panel matters because it is one of the primary places where responsibility for a task is established, directly affecting who receives and can act on the task as soon as it is created.

Create task screen ​

The Create task screen is the task-entry interface in the Autologyx Workspace Tasks tab that opens when a user starts creating a manual task for an object record, typically from the Add or Create task action. It is used by end-users to enter the task details before saving, and it includes the controls needed to complete or cancel task creation. This screen matters because it is the point at which a manual task is defined and added to the record’s task list, and its use directly affects task visibility and follow-up work, since created tasks are only visible to selected users, Super Admins, object class owners, and users with the Tasks/View all permission.

Create task template page ​

Create Tasks ​

Create Tasks is the object-class permission in Autologyx that allows a user to manually create tasks for object records from the task creation interface, such as the Create task screen opened from the Create task or Add controls. It is used when working with records in a supported object class and controls whether a user can add manual work items directly against those records. This matters because task creation is restricted to users with the correct authority: Super Admins, Object class Owners, and users whose permission set for the object class includes Create Tasks. Configuring this permission correctly ensures that manual tasks can be raised by the right users while maintaining governance over who can add operational work to object records.

Create user page ​

The Create user page is the administration screen in Autologyx where Super Admins create user accounts manually for other individuals. It is accessed from Administration / Users in the main left-hand menu and is used as the starting point for setting up a person’s account details and account type within the platform. This page matters because it is the entry point for adding new users to an Autologyx environment, enabling administrators to control who can access the platform and to begin the activation process that supports account setup and ongoing user management.

create/edit display view ​

In Autologyx, the create/edit display view is the object class screen layout used when users create a new record or edit an existing one in the platform UI. Configured at the object class level, it determines which fields are shown during record maintenance and is used for data capture directly within the object’s standard interface, distinct from standalone forms configured on the Forms tab. This view matters because any fields that must be completed or updated as part of the record lifecycle—such as image merge fields used in generated documents—must be present on the create/edit display view if users are expected to supply that data there, and the view must be used at the correct point in the process so required values are available before downstream actions such as document generation.

Create/Edit for Authentication Objects ​

Create/Edit for Authentication Objects is an administrative permission in Autologyx that allows a user to create and modify Authentication Objects in Administration / Authentication objects. This permission is required for tasks such as setting up a DocuSign Authentication Object, which stores and manages the authentication details Autologyx uses to maintain authorised connections to external services, including refreshing access tokens and supplying them for API requests. It matters because without this enabled permission, even users involved in configuration cannot create or update the authentication configuration needed for integrations to function.

Create/Edit forms ​

Create/Edit forms are the forms in the Autologyx Catalyst UI used to create new records and update existing records, providing the primary data-entry experience for users working with platform objects and processes. They are used wherever a user is asked to enter or amend information, and are configured by administrators as part of the platform’s form design alongside related form types such as display forms and Object Class forms. In practice, Create/Edit forms determine how fields are presented for input, including text-field behaviour and formatting options such as Markdown support, which directly affects usability, consistency, and the quality of data captured across the platform.

Create/Edit permission for Single sign on ​

Create/Edit permission for Single sign on is a role-based permission in the Administration tab that allows a user to create and edit Single sign on settings in Autologyx. It is used when configuring authentication options for the platform, including accessing the edit screen for an existing Single sign on setting and updating mandatory configuration details such as the setting name. This permission matters because it controls which non–Super Admin users can manage Single sign on configuration, helping organisations delegate authentication administration securely while restricting access to a sensitive area of platform setup.

create/edit permissions for single sign on ​

Create/edit permissions for single sign on is a role-based permission in Autologyx that grants access to configure and maintain single sign-on settings from the Administration tab. It is used to control which users, in addition to Super Admins, can open the single sign-on configuration page and manage items such as authentication setup and related access options for user sign-in. This permission matters because it limits sensitive identity and access configuration to authorised administrators, helping organisations govern who can change how users authenticate into the platform.

create/edit record display form ​

In Autologyx, the create/edit record display form, also called the create/edit view, is the record form used to create a new record or update an existing one for a specific object class. It is shown where the user is performing the task, such as in the main content window or in a fly out modal when creating related child records from a parent record. This form is a core part of relational record workflows because it presents the fields and controls needed to enter, review, and save record data in context, while respecting object class configuration and the user’s permission to create or edit records. For end users, it is the primary interface for entering and maintaining record information; for configuration admins, it is an important concept when designing how record creation and editing should be presented within parent, child, and grandchild navigation flows.

Create/edit record display form builder ​

The Create/edit record display form builder is the configuration interface used by Catalyst form designers to define and update the layout and components shown on a Catalyst record view. It is used when creating or editing the display form for a record, including adding integration-driven sections that surface connected system functionality directly within the record experience. For example, when the iManage integration is active and enabled, a new Integrations section becomes available in the builder so the iManage component can be added to the form. This builder matters because it controls how record information and embedded integrations are presented to users, allowing configuration admins to tailor record views to business processes and ensure connected services are available in the right place.

Create/Edit record form ​

In Autologyx, the Create/Edit record form is the interface used to add a new record or update an existing one, presenting the record’s fields in an editable layout for data entry and maintenance. It is used by end-users when creating or updating records and by configuration admins when designing experiences that include text, JSON, multiline, and Markdown-enabled fields. Within these forms, Markdown content can be viewed either as source code for editing or as rendered text for easier reading, and multiline and Markdown textboxes expand to the full width of their containing column to provide more working space. This matters because the Create/Edit record form directly affects how record data is entered, reviewed, and updated, and it determines how field content is displayed and edited during everyday work in the platform.

Create/Edit record view ​

The Create/Edit record view is the record form in Autologyx used to create a new record or update an existing one, presenting the fields, controls, and related components needed to capture and maintain record data. It is used by end users when entering or changing information and by configuration admins when validating how record structures and related elements are presented in the user interface. This view commonly works alongside features such as child record controls and record access panels, making it a key part of how users manage record content and relationships. It matters because the Create/Edit record view directly affects data entry accuracy, usability, and the effectiveness of record-based processes across the platform.

create/edit relational model ​

Create/edit relational model is a system permission in Autologyx that allows a user to create and modify the platform’s relational model through the Relational modeller. It is configured when creating or editing a Role, where it appears in the Data Model tab under System permissions, and is primarily used by configuration administrators and super admins who manage system configuration. This permission is important because it enables controlled access to relational model design without assigning the broader Super admin account type, helping organisations limit high-level access while still allowing specific users to work in the relational modelling area. To use it effectively, the user also needs the edit permission for Object classes in the same Data Model area, and some System configuration menu items remain restricted for standard account users even when this permission is enabled.

create/edit view ​

Create/Edit View is the configurable record form for an Object class in Autologyx that defines how users create a new record and open an existing record for editing. It is configured by administrators on the Object class Display tab alongside Card View and Summary View, and is used throughout the workspace when a user selects Create record, opens a record from the Records list, or works with related records. In relational models, the parent object class’s Create/Edit View is also where child object classes are added so users can view, create, and associate child records from the parent record. This view matters because it is a prerequisite for manual record creation, controls the editing experience presented to end users, and determines whether key relational interactions are available in the record interface.

Show 5 more pages

Created ​

Created is used in Autologyx in two distinct places: as a user account status and as an Object Record property. In user administration, Created means the user has been added to the platform but their activation email has not yet been sent, which is particularly relevant when delayed account activation is enabled and helps administrators distinguish pre-activation accounts from Pending or Active users in the status column. In template configuration, Created is the record creation timestamp exposed as the Object Record property {{ record.created at }} with a Date/time value, alongside related properties such as ID and Modified. This matters because it enables administrators to understand whether a user account has progressed to activation and to use the record creation date in merge fields, templates, and record-based configuration.

Created at ​

Created at, also shown as Record Created at, is the system date and time stamp automatically assigned to a Record when it is first created in Autologyx. It is used where record-level metadata can be referenced in platform logic, including Sequence commencement conditions, so configuration admins can evaluate when a record entered the platform and use that timestamp in date/time-based rules. This matters because it enables precise control over process initiation and filtering by record creation time, helping ensure Sequences start only for records created within the required timeframe and supporting consistent record management alongside related metadata such as Modified at and Record ID.

Created by ​

Created by is a filter field used on Autologyx list pages to restrict results to items created by specific platform users. In the list page filter editor, it is added as a filter condition and used with user-based operators such as is one of, allowing one or more users to be selected and then applied through the filtered results control. This matters to end-users and configuration admins because it helps narrow large result sets to the records entered by particular people, making it easier to review ownership, track user activity, and find relevant work quickly.

Created date/time ​

Created date/time is a system field in Autologyx that stores and displays the exact date and time a record was created. It is used as a property on record and task forms and can also be included in object class display configuration alongside fields such as ALX ID and Updated date/time. In create and edit views, this field is not shown with a value while a new record is being created and is only populated once the record exists, after which it provides a fixed creation timestamp for that record. This matters to both configuration admins and end-users because it helps identify when a record entered the platform, supports sorting and display design, and distinguishes the original creation point from later changes recorded in Updated date/time.

Created status ​

Created status is the user account state in Autologyx that indicates the account record has been created but the user has not yet been activated. It is used on the Edit user page in the account Status field and in user activation flows controlled through the platform and API, including delayed account activation. A user remains in Created status when an activation email is not sent at account creation; the created date and time are recorded, and only activation emails can be sent while the account is in this state. Sending an activation email to a user in Created status moves the account to Pending, after which the normal activation process continues. This status matters to Configuration admins, Super Admins, and Developers / Integrators because it allows user accounts to be provisioned in advance, held inactive until the correct point in an onboarding process, and managed consistently across manual administration and API-driven integrations.

Creating a sequence ​

Creating a sequence is the configuration activity in Autologyx where an administrator defines a new sequence that will control how work is initiated and progressed within the platform. It is used in the Sequences area of System Configuration, alongside related tasks such as setting sequence properties, designing the sequence flow, and defining commencement conditions. This matters because a sequence is the core structure that determines the stages, behaviour, and entry rules for a process, so creating it correctly establishes the foundation for how users interact with that process and how work is managed through the Sequencer.

Creating A User Group ​

Creating a User Group is the administrative task of defining a named collection of users in Autologyx so they can be organised, managed, and granted access consistently across the platform. It is used in the Administration area under User Groups, alongside related functions such as the user group list, editing a user group, editing user group permissions, and configuring users and groups visibility. This matters to Configuration Admins and Super Admins because user groups provide the structure for controlling permissions and visibility at scale, making it easier to apply access rules to multiple users, maintain governance, and support secure, efficient platform configuration.

Creating The Theme ​

  • Mostly relevant to: Configuration admins, Super Admins
  • Closely related concepts: About The Theme, Theme

INSUFFICIENT_EVIDENCE

Creation Endpoints ​

INSUFFICIENT_EVIDENCE

Credential expiry timestamp ​

Credential expiry timestamp is the exact date and time recorded for an Authentication Object credential in Autologyx, used to identify when a token, password, or similar stored authentication value will expire. It is used in authentication object management and in automatic expiry notification emails, where the system includes the object name and precise expiry timestamp so administrators can see the deadline for renewing or replacing the credential. This matters to Configuration admins and Super Admins because it supports timely maintenance of integrations and connected services, helping prevent authentication failures caused by expired credentials and ensuring system email configuration can deliver those alerts effectively.

current record ​

In Autologyx, the current record is the record that directly initiates or is in scope for a running action, trigger, or actor configuration, providing the default data context for processing. It is used when configuring actors such as Sequence Runner, where actions can be applied either to the current record itself or, through Relation Lookup, to related records in a selected parent or child object class of the same object class context. This distinction matters to configuration admins because it determines which record a sequence operates on, affects how trigger parameters and connected actors are resolved, and ensures automation targets the intended object within a workflow.

custom permission sets ​

Custom permission sets are additional user group permission sets in the Autologyx platform that extend the default Owners, Members, and Everyone sets to provide granular control over what specific users, departments, or groups can view and do within a user group. They are configured in User Group Permissions by Super Admins and eligible User Group Owners, and each user group can have up to 10 permission sets in total. Custom permission sets are closely tied to list permissions and visibility controls, determining where users and groups can be seen and selected across the platform, including task ownership and assignment, Object Class and Record ownership, permission set assignment, User Type Class fields, default task assignees in Sequences, user group management, and dropdown filters and autocompletes. They matter because they let administrators tailor access and visibility to operational and compliance requirements without relying only on the broad default permission sets.

customer success team ​

The customer success team is the Autologyx service team that supports customers during implementation and ongoing use of the platform, particularly in areas such as process design, configuration, and testing. In Autologyx documentation, it is referenced as a source of practical guidance within Autologyx Catalyst and related in-application help, including from the landing page experience. This matters to Configuration admins and Super Admins because the customer success team helps them set up and refine workflows correctly, accelerate delivery, and ensure the platform is configured to support operational goals effectively.

data integrity measures ​

Data model ​

In the Autologyx platform, the Data model is the configuration area that defines and manages the application’s groups of records, known as Object classes. It is used during application setup and ongoing administration to create, edit, and delete these Object classes, and it also appears in role configuration where Data model permissions control whether a user can view existing classes, edit them, or access create actions. This matters because the Data model provides the structural foundation for how information is organised in the platform, and access to it determines who can shape that structure, maintain it over time, and expose the right record types to users through roles and permission sets.

Data Model tab ​

The Data Model tab is the section within System permissions on a Role where Autologyx configuration permissions for the platform data structure are set, including permissions such as Object class Edit and create/edit relational model. It is used when creating or editing Roles to control which configuration administrators can access and change Object classes, their fields, permission sets, and relational models. This tab matters because it is a core access-control point for data-model configuration: users need the appropriate permissions enabled here, often alongside the correct account type such as Config admin, to perform structural changes in System configuration and related modelling areas.

Data Type ​

In Autologyx, Data Type is a configuration setting that defines the structure of the data used by a platform component or field. In the API Call Actor, it is used to specify how the request payload is structured, and this field must be set to the Document data type. This matters to configuration administrators and developers because the selected data type determines how payload content is represented and processed by the platform, ensuring the API call is configured with the correct input format for successful integration behaviour.

database limits ​

INSUFFICIENT_EVIDENCE

Database views ​

Database views in Autologyx are cross-platform, read-only database views introduced with Autologyx Catalyst that expose Autologyx data for use in external database management and analytics tools without allowing changes to schema or source data. They are used when organisations need a structured snapshot of platform data, including records from any Object class and core fields such as Record ID, Record Identifier, and Record Creation Datetime, while also providing visibility into Event History and Resource table data. Database views matter because they make Autologyx data easier to access, compare, and analyse across systems and business contexts, supporting reporting, compliance, due diligence, integrations, and other administrative or technical use cases while preserving the integrity of operational data.

Date / Time picker ​

In Autologyx, the Date / Time picker is a Task Form field type used by configuration admins to capture date-only or date-and-time values through a guided calendar and time selection control. It is configured in the form builder alongside other field settings such as input type, default value, label, and description, and is presented to users on task forms as a calendar widget for dates or as a combined calendar and clock control for date-and-time entry. The field supports three input types, allowing admins to choose the format that matches the business data being collected. This matters because it standardises how temporal information is entered, improves usability for end users, and helps ensure task form data is captured in the correct structure for process execution and downstream use.

date manipulations filter ​

In Autologyx, the date manipulations filter is a Jinja filter used in templates and document generation to adjust date values by applying offsets such as adding or subtracting days, including support for business-day scheduling where configured. It is used by configuration admins and developers when building dynamic documents, notifications, or other template-driven outputs that need dates to be recalculated from milestone, event, or process dates. This filter matters because it allows date logic to be handled directly in the template layer, making generated content more accurate, reducing manual date calculations, and ensuring working-day rules can be reflected consistently across platform outputs.

date range filter ​

A date range filter is a Jinja date and time manipulation filter in the Autologyx platform that checks whether a supplied date falls within a defined start and end period. It is used in template-driven logic such as document generation and other configured automations where dates from tasks, documents, or workflow data must be validated against project timelines, creation windows, or deadline periods. For configuration admins and developers, this filter matters because it enables precise date-based conditions directly in templates, helping ensure that generated content, routing decisions, and automated actions respond correctly to time-bound business rules.

Date/Time field type ​

In the Autologyx Catalyst form builder, the Date/Time field type is a form field used to capture both a calendar date and a specific time value within record and task forms, including intake and other record-creation forms. Configuration admins add this field when designing forms that need users to enter or confirm scheduled events, such as meeting confirmations, and it is configured alongside other Catalyst field types in the create and edit experience. This field matters because it ensures date and time information is collected in a structured format that supports accurate form completion, consistent data entry, and downstream use in form design and process configuration.

date/time manipulations filter ​

The date/time manipulations filter is a Jinja filter in the Autologyx platform used in configuration and document-generation templates to transform date and timestamp values by applying ordered date and time adjustments, such as adding or subtracting calendar days or business days to calculate projected delivery dates, deadlines, and dependency-driven target dates. It is used wherever template logic needs to derive new date values from existing workflow, task, or document data, and it matters because it lets configuration admins and developers generate consistent, automated scheduling and output dates directly within templates without external processing, while supporting mixed operations and sequencing for precise date calculations.

Date/Time Picker field type ​

The Date/Time Picker field type is a form field available in the Autologyx form builder for Complete self contained form response configurations, used to capture a date, a time, or a combined date and time from the user. Configuration admins add this field when designing create response forms and other task response forms that require structured temporal input, such as recording a consent date or a document expiry date. It matters because it standardises how date and time values are entered, makes forms easier for users to complete, and ensures the process captures the exact type of time-based information required by the task design.

DateTime ​

DateTime is a field type in the Autologyx platform used to store and output a combined date-and-time value. It is used in merge fields, document templates, and other places where record data is rendered, and is referenced in template syntax as {{ record.field datetime }}. DateTime values can be formatted with filters, for example {{ record.field datetime | datetime('%H:%M') }}, to control how the value is displayed in generated content. This matters to configuration admins when defining and formatting data for templates and automated outputs, and to end-users because it ensures timestamps such as submission, update, or event times are presented consistently and in the required format across documents and platform views.

days between dates ​

Days between dates is a date calculation capability available through Autologyx Jinja filters in Catalyst, used in templates and merge-field expressions to return the number of days separating two date values. It is used when configuring document generation, workflow content, and other dynamic outputs that rely on Jinja merge fields, allowing configuration admins and developers to derive elapsed time directly from platform data without external processing. This matters because it supports precise date-driven logic and content, such as calculating deadlines, ageing, durations, and service intervals, making automated documents and configured experiences more accurate and easier to maintain.

Decimal ​

Decimal is a Number field type in the Autologyx Catalyst form builder used on intake and other record creation forms to capture numeric values that include fractional or non-whole-number amounts. Configuration admins select Decimal when designing forms that require precision beyond whole numbers, in contrast to the Integer field type, which is used for whole numbers only. This matters because choosing the correct numeric field type ensures users can enter the intended values and that record data is structured correctly for downstream use in the platform.

dedicated section ​

In the Autologyx form builder, a dedicated section is a form section created specifically to contain Elements, so they are grouped in a clearly named and separate area of a record, task, standalone, or Object Class form. It is used during form configuration when adding Element components, with the section header typically given a clear label if it will be shown to users. This matters because isolating Elements in their own section improves form structure, makes the purpose of those components easier for users to understand, and supports cleaner, more maintainable form design for configuration admins.

Default ​

Default is the standard row density setting available in a user’s My account preferences on the Autologyx platform. It is used in the row density preview and applies to listing pages after the user saves their preference, setting rows to 35px and headers to 38px. Default matters because it provides the baseline display format for list-based views, helping users control how much information is visible on screen and choose the layout that best suits their working style.

default column configuration ​

default confirmation ​

  • Mostly relevant to: Configuration admins
  • Closely related concepts: Enable, Forms list

In Autologyx, default confirmation is the standard post-submission message shown to a user after they submit a standalone form when no redirect has been configured. It is used in standalone form setup within system configuration, specifically when the Redirect option is left disabled. This matters to configuration admins because it controls the user’s end-of-process experience: using the default confirmation keeps the user on a built-in confirmation view, while enabling a redirect sends the user to a different destination after submission.

default iManage screen ​

In the Autologyx iManage integration, the default iManage screen is the standard iManage interface that opens when a task, form, or component is configured to use iManage but no specific iManage location has been set. It is encountered by end-users when launching or interacting with iManage from within a workflow, and it is relevant to configuration admins when defining whether users should open a preselected workspace, folder, or other iManage location. This matters because it determines the fallback user experience for iManage-enabled steps: when no explicit destination is configured, users are taken to the default iManage screen instead of a targeted iManage location.

default permission sets ​

INSUFFICIENT_EVIDENCE

default setting ​

In Autologyx, the default setting is the predefined column header layout for a specific list page, defining which columns are shown and their standard arrangement when the list is reset or first presented. It is used on list pages through the Column configuration control, where users can enter column configuration mode to add, remove, and reorder columns, then either save their changes or use Reset to default to restore the original view for that page. This matters because it provides a consistent baseline for working with list data, helps users return to a known layout after making changes, and supports efficient navigation by ensuring each list page starts from an intended default view.

default task assignee(s) ​

Default task assignee(s) are the user or users preconfigured on a sequence so that tasks created by that sequence are automatically assigned to the same people when the sequence runs. In Autologyx, this setting is used when configuring a sequence that is activated from a main sequence, such as in Sequence Runner actor scenarios for relational records or sub processes, where a consistent assignee or escalation group is required across all generated tasks. This matters to configuration admins because it standardises task routing, reduces the need to set assignees individually in each task template, and ensures work created by the child sequence is immediately directed to the correct person or group.

Default task assignees ​

Default task assignees are the users configured at sequence level who are automatically assigned whenever that sequence creates a Task, providing a default ownership mechanism when no Task Assignment actor sets assignees explicitly. In Autologyx, this setting is used in Sequence properties during sequence creation and editing, through the Manage default task assignees panel, where configuration admins and Super Admins can add or remove users and see the assignee count and avatars. Default task assignees matter because, by default, a created task has no assignees unless assignment is defined elsewhere, so configuring them ensures tasks generated by the sequence consistently reach the correct users. This setting is also important when designing task-based workflows across object classes and task templates, and it has a specific limitation: 1-time completion users cannot be selected as default task assignees when creating a sequence.

Show 1 more pages

default task assignees counter ​

The default task assignees counter is the numeric indicator shown in Sequence properties alongside the Manage default task assignees control in the Sequencer tab that displays how many users are currently configured as default task assignees for the sequence. It updates immediately as users are added or removed in the Manage default task assignees panel, and corresponding avatars shown on the main content page are updated to match. This counter matters to Configuration Admins and Super Admins because it provides a quick, visible check of assignment configuration during sequence design, helping confirm that the intended default assignee setup is in place without opening the full assignee list.

Default task assignees in Sequences ​

Default task assignees in Sequences are the preconfigured users or user groups selected in a Sequence to receive ownership of tasks created by that Sequence. This setting is used in Sequence configuration wherever task assignment defaults are defined, and it relies on the platform’s user and group list visibility rules: only users and groups a person is permitted to list through view and related list permissions are available in the selection controls, with users always able to list themselves. This matters to Configuration Admins and Super Admins because the available assignee options in Sequence design are directly shaped by users-and-groups visibility settings, user group permission sets, and custom permissions, which determine whether the correct people or groups can be found, selected, and consistently assigned during automated workflow execution.

Default User Group Permissions ​

Default User Group Permissions are the built-in permission sets applied within an Autologyx User Group to define what key group roles can do by default. In the User Group Permissions area, Super Admins and User Group Owners use these default sets to control baseline access for roles such as Owners and Members, with the Owners permission set fixed and not editable, while other default permissions can be amended and additional permission sets can be created. These defaults matter because they establish the standard access model for the group, ensuring consistent control over user capabilities before any custom permission sets are added or adjusted.

Default value ​

Default value is a pre-populated value configured for a field in Autologyx so that a suggested starting value is shown when the field is displayed on task forms, record forms, and record views. It is used by configuration administrators and Super Admins when defining form fields and object class fields, and it matters because it speeds data entry, promotes consistency, and reduces manual input while still allowing users to change the value where the field supports override. Default values are available on supported field types such as text, integer, decimal, checkbox, single select, email, phone, date, date/time, time, document, URL, and JSON, while some field types have different configuration rules, for example single select supports a default value and multi select does not.

delay activation parameter ​

INSUFFICIENT_EVIDENCE

delayed account activation ​

Delayed account activation is an Autologyx feature that lets administrators create user accounts without making them active immediately, so the activation email can be sent at the right point in the onboarding or rollout process. It is used when creating users in the platform and through the API introduced for this purpose, and is documented in Autologyx Catalyst release notes including Catalyst 1.11. This capability matters to Configuration admins, Super Admins, and Developers or Integrators because it gives precise control over when access begins, allowing teams to prepare account setup, business processes, and organisational coordination in advance before the user transitions to an Active state.

Delete ​

Delete, also described as the Delete action, is an option in the Set Task Actor used by configuration admins to remove tasks for the current record and selected task template, regardless of whether those tasks are complete or incomplete. When Delete is selected, the actor presents additional single-select options to target exactly which tasks to remove: all tasks, all outstanding tasks, all completed tasks, the most recent task, the most recent outstanding task, or the most recent completed task. This action is used in sequence configuration to control task lifecycle and clean up or reset task states, ensuring that only the intended task instances remain associated with a record.

Delete action ​

Delete action is an option in the Set Task actor configuration that removes tasks created from a selected Task Template within an Autologyx workflow. It is used when configuring task-handling logic in sequences, where the Action dropdown now includes Delete alongside Re create, and it works with delete target selections such as all tasks, complete tasks, outstanding tasks, or the most recent matching task. This matters to configuration admins because it allows workflows to manage the full lifecycle of tasks, clean up redundant or obsolete assignments, reset process state when conditions change, and prevent conflicting tasks from accumulating over time.

Delete all ​

Delete all is an object class permission in the Autologyx platform that allows users to use the Delete action from the Actions menu on all records of that object class, permanently removing those records from the system. It is configured in Object class configuration as part of class permissions and is relevant to administrators who define access for records, as well as end users who work with record lists and actions. This permission matters because it grants broad destructive access across every record in the class, so it must be assigned deliberately; it also depends on View all, as Edit all and Delete all cannot be applied without the View all permission.

Delete all permission ​

Delete all permission is a class permission used in Autologyx permission sets to control whether a user can delete all records of a specific Object class. It is configured in the Object class permission settings when editing permission sets and is relevant to configuration administrators and Super Admins who define what actions users can perform on Object records. This permission matters because it grants broad destructive access within that class, so it must be assigned carefully to prevent unintended deletion of Object records and to ensure permission sets accurately reflect operational roles and governance requirements.

Delete permission ​

Delete permission is a role permission in Autologyx that controls whether a user can access a configuration list page in order to remove items from it. It is used in role and Permission Set configuration by Configuration Admins and Super Admins, and its effect is visible in the relevant list page, the Actions menu, the left-hand navigation, and direct URL access. When Delete permission is enabled for an area such as Sequencer, the user can open the list and delete records; when it is disabled and no Create or Edit permission remains for that area, the list page is removed from the menu and direct navigation shows an Access denied message. This matters because changing Delete permission directly changes both what administrative content a user can see and whether they can carry out destructive actions within that part of the platform.

Delete Target ​

Delete Target is the setting shown after you choose the Delete action in the Set Task actor configuration, and it defines exactly which tasks for the selected Task Template are removed from a record. In Autologyx, this dropdown provides targeted deletion options such as All tasks, All complete tasks, All outstanding tasks, Most recent task, Most recent complete task, and Most recent outstanding task, allowing administrators to control task cleanup with precision. It is used when designing processes that need to remove obsolete, completed, outstanding, or conflicting tasks as process conditions change, and it matters because it determines the scope of task deletion, helping keep records accurate, prevent duplicate or contradictory assignments, and ensure task state aligns with current workflow logic.

deleted users handling ​

Deleted users handling is the Autologyx merge field behaviour that protects personal data when a referenced user account has been deleted from the platform. In user-type merge fields used in Document Templates, Sequencer actors such as API Call, Send Message, and Local Variable, Related records merge fields, and other supported merge field contexts, a deleted user record returns only its identifier while all other user properties are anonymized for privacy. This matters when configuring templates, integrations, access-aware logic, or reporting that reads user objects, because deleted users remain referentially usable for indexing and record relationships, but name, email, phone, and other profile values are no longer available and must not be relied on in downstream outputs or processing.

Delivery ​

Delivery, shown in Getting Started as Performing work (Delivery), is the role-oriented path for delivery teams and implementation support users who use the Autologyx platform to support rollout, adoption, and day-to-day operational execution rather than to build applications or administer the platform. It is used in the Getting Started guidance to direct users whose responsibilities focus on implementation support and operational delivery toward the most relevant documentation path. This matters because Autologyx organizes onboarding by role and responsibility, helping delivery users quickly find the instructions and concepts they need to work effectively with records, tasks, and documents while staying distinct from analyst activities such as designing workflows and administrator activities such as managing global setup and access.

delta\ days ​

delta days is a Jinja date/time manipulation filter in the Autologyx platform that calculates the number of days between a source date and a comparison date within templates and configuration expressions. It is used wherever Jinja filters are supported, particularly by configuration administrators and developers who build dynamic workflows, documents, and rule-driven logic that depend on elapsed calendar days or working days. The filter accepts a comparison date and an optional business days parameter, allowing the calculation to return either inclusive calendar-day counts or inclusive business-day counts; because the calculation includes both the start and end dates, the result is 1 when the two dates are the same. This matters because it enables precise, reusable date-based calculations directly in platform configuration, helping teams implement deadlines, service windows, and business-day-aware automation without external code.

demote to member ​

Demote to member is an action in the User group Members list Actions menu that changes a user’s group role from Owner to Member without removing them from the group. It is used when editing a User group in Autologyx administration, alongside related actions such as Promote to owner and Remove from group, and is available to users with the necessary administrative permissions. This action matters because it lets Configuration admins and Super Admins adjust group governance and access responsibilities while keeping the user in the group, making it a key control for maintaining the correct ownership structure and membership status within User groups.

deprecated fields ​

Deprecated fields are object class fields that have been removed or retired from use and are no longer available in display configuration within Autologyx. In the Edit Object class area, under the Display tab and across the create, edit, and view display layouts, deprecated fields are automatically removed from any form where they were previously placed and from the Components panel, so they cannot be selected or shown in the configured interface. This matters to Configuration Admins and Super Admins because changes to object class fields are propagated into display configuration automatically, keeping forms and available components aligned with the current field definition and preventing outdated fields from remaining in user-facing layouts.

descendent object classes ​

In the Autologyx Relational modeller, descendent object classes are the object classes that sit below a selected object class in the relational hierarchy as child classes and any further levels beneath them. They are used when editing the relational model, because structural actions on a parent object class apply to its descendents as part of the same branch: moving a parent moves all descendent object classes with it, and deleting a parent deletes all descendent classes in that branch. This matters to Configuration admins and Super Admins because changes to one object class can affect an entire hierarchy, so understanding descendent object classes is essential when maintaining relationships and safely updating the platform’s relational model.

Description ​

Description is the field configuration setting in Autologyx Form Builder used to add instructional text that displays immediately below a form field input on the task form. Configuration admins use Description when defining task form fields alongside settings such as Label, Default value, Input type, Conditional Visibility, and form sections, to provide users with guidance on what to enter or how to complete the field. This matters because it improves form usability and consistency by giving clear, in-context instructions exactly where the user needs them, helping ensure accurate data capture and a better task completion experience.

Description field ​

In the Autologyx platform, the Description field is an optional text field used in configuration screens such as the Sequence Runner actor configuration to store additional information about the item being set up. It sits alongside core identifying and operational settings, including the Name field and other properties, and gives configuration admins and Super Admins a place to record supporting context that does not belong in the primary name or functional settings. This matters because it helps administrators document the purpose, usage, or internal notes for a configured component, making configurations easier to understand, review, and maintain over time.

designated field ​

In Autologyx, a designated field, also referred to as a target field, is the specific field on a corresponding record where generated documents are automatically saved when users create documents from pre defined templates in the Templates panel. It is used during template-driven document generation to determine the exact storage location for output files against the selected records. This matters because it ensures generated documents are filed consistently in the correct place, making them easier for end-users to organize, retrieve, and work with, while allowing configuration admins to control how document outputs are stored within the platform.

destination URL ​

In Autologyx, the destination URL is the web address configured in Standalone form settings as the target location users are sent to after a standalone form uses the Redirect URL feature. It is used by configuration administrators when setting up standalone forms to connect form submission or completion with the next step in an external or existing workflow. This setting matters because it controls the user journey after the form interaction, helping ensure a seamless handoff from the standalone form to the required page, system, or process.

dev system ​

In the Autologyx platform, a dev system (development system, or dev Catalyst system) is the non-production environment used to configure, integrate, and test solutions before they are promoted to a live system. It is used by configuration administrators, Super Admins, and developers or integrators when validating API behaviour, external service connections, and platform configuration in a safe environment. The distinction between dev and live systems is especially important during System Migrations, where items such as Authentication Objects are mapped by name between environments rather than overwritten, allowing each system to retain environment-specific settings such as different API endpoints or host accounts. This matters because it enables teams to test integrations fully in development while preserving the correct production configuration in live.

different routes for subsets of Records ​

In Autologyx, different routes for subsets of Records describes a sequence design pattern in which conditional logic is applied to field values and task outcomes so that only Records matching defined criteria follow a particular path through a Sequence. This is configured within Sequence conditions, including Sequence commencement conditions and conditions applied to the next item in the Sequence, using Record data such as Fields, Object class fields, Single select field values, and functions such as PREVIOUS FIELD VALUE. It is used by configuration admins and Super Admins when building processes that must branch for different categories of Records—for example, triggering different Tasks or states when a Risk level changes to a specific value. This matters because it allows a single Sequence to handle multiple business scenarios in a controlled, maintainable way, ensuring the right actions are applied to the right Records at the right point in the workflow.

different user types ​

direct child ​

In Autologyx, a direct child is an object class that sits immediately below another object class in the relational model, with a direct parent-child relationship and no intermediate object class between them. Direct children are used in configuration areas that depend on the platform’s object hierarchy, especially the Relational Modeller and the Child Object Classes form component, where only object classes that are direct children of the current object class can be selected. This matters because direct-child relationships determine which related records can be surfaced, created, or managed from a parent record or task, and they ensure form and data-model configuration aligns correctly with the defined 1:N or 1:1 structure of the application.

Disable Submit ​

Disable Submit is a form configuration option in Autologyx that removes the Submit button from a standalone form. It is used when editing a form within an object class, typically from the Forms tab as part of form design and maintenance by configuration administrators and Super Admins. This setting matters because it changes how users can interact with the form at runtime by preventing direct submission from that form, which is important when controlling completion behaviour, user actions, and the intended flow for forms that are in use.

Disable/Enable ​

Disable/Enable is the control used by configuration administrators and Super Admins to turn an Element off or on within the Autologyx platform. In the Elements configuration area, editing an Element and setting it to Disabled removes that Element from all forms where it could otherwise be displayed; enabling it makes the Element available again for use on those forms. This setting is important when maintaining system forms and related configurations because it provides a direct way to control whether an Element is presented to users across the platform without deleting the Element itself.

discovery request ​

Display card view ​

Display card view is the Object class configuration area in Autologyx used to define how records of that object are presented in a card-style layout. It is available as one of the view configuration tabs on the Edit Object class page, alongside the create/edit view and summary view, and is used by configuration administrators and Super Admins when setting up or refining an Object class. This configuration matters because it controls the information and structure shown when records are displayed as cards, helping ensure users see the most relevant object fields in a clear, consistent format across the platform.

display form design ​

Display form design is the configuration area in Autologyx used to define how a form is presented to users, including the behaviour and editability of fields in the displayed form. It is used by configuration administrators when setting up or refining user-facing forms, particularly standalone forms and other form-based interactions where the layout and field settings affect the user experience. This matters because display form design controls how information is shown and whether users can change it; for example, the Read Only option introduced in Catalyst 1.6 allows specific fields to be displayed without being editable, giving administrators more precise control over form behaviour and helping ensure forms are presented in the intended way.

display form designers ​

Display form designers are users who configure display forms in Autologyx, defining how fields are presented and controlled for end users within a workspace or process experience. This role is used when setting up or maintaining display forms, including configuring field accessibility such as marking fields as read only through the Read only option. Display form designers matter because their configuration determines how information is displayed, which fields users can interact with, and how consistently forms support the intended process and user experience across the platform.

display forms ​

Display forms are the Autologyx Catalyst UI forms used to present record or document information to users, with configurable field behaviour that controls how data is shown and whether individual fields are editable or read-only. They are used in the user interface wherever configured record details need to be displayed, and are designed by configuration administrators using display form designers as part of form and field setup for document type and object record experiences. Display forms matter because they shape the end-user view of information, support consistent and usable layouts such as multiline text presentation, and allow administrators to enforce field accessibility settings so users can view the right data in the right format without making unintended changes.

Display tab ​

The Display tab is the Object class configuration area in Autologyx where administrators define how Object records are presented and interacted with across the platform. Used within System configuration when editing an Object class, it controls the record display views—including the create/edit view, card view, and summary view—and relies on fields created for that class to build those layouts. The Display tab is also central to relationship configuration, because parent classes need an enabled create/edit view to allow child Object classes to be added and displayed, and child display fields are configured there. This matters because the Display tab directly determines how users create records, how records appear in the Workspace, and which display configurations can be maintained by users with the appropriate class permissions, making it a core part of both record usability and Object class setup.

Show 2 more pages

Displays ​

Doc Auto ​

DocAuto actor ​

The DocAuto actor is a Sequence Actor in Autologyx that generates documents during workflow execution from configured document templates, processing template content such as merge fields, IF statements, and other Jinja features for the current record. It is used in sequencer-based automation, typically after a task, message, API, relation lookup, or record update event, and is commonly paired with a Document Picker actor, which can use the generated output by selecting DocAuto Actor in its Source field, and then pass that document onward to actors such as Update Record or Send Message. The DocAuto actor matters because it enables automatic document generation as part of an application’s operational flow, ensures template-driven documents are created with record-specific data at the right point in the sequence, and supports downstream handling such as storing, combining, or sending generated documents.

Show 3 more pages

DocAuto Actor (source option) ​

In Autologyx, DocAuto Actor is a Source option used when configuring a Document Picker actor to supply documents generated by the DocAuto actor. The DocAuto actor is the platform component responsible for automatic document generation within a workflow, and selecting DocAuto Actor in the Document Picker’s Source field makes those generated documents available for users or downstream steps to select and use. This matters to configuration admins because it links document generation to document selection, ensuring the workflow presents the correct auto-generated outputs at the point they are needed.

DocAuto Actor source ​

DocAuto Actor source is a source option used when configuring a Document Picker in an Autologyx sequence to take its input document directly from a DocAuto actor. It is used in document automation flows where a DocAuto actor generates a new document and a downstream Document Picker must reference that generated file for further processing, field extraction, attachment handling, or add/replace actions. This source matters because it links the output of automatic document generation to the next step in the workflow, ensuring the sequence uses the newly created document rather than requiring a separate document selection or manual intervention.

Document ​

In Autologyx, a Document field is a field type used in record data and merge fields to represent a list of documents, returned with their URLs. It is used when configuring merge field output, where the syntax {{ record.field document }} exposes the field’s document list for use in templates and other formatted outputs. This matters to configuration admins because Document fields handle file-based content differently from scalar field types such as DateTime, Enum, or JSON: they provide document references rather than simple values, which affects how the data is inserted, formatted with filters, and presented in generated content.

document attached to the field ​

Document Automation ​

Document Automation in the Autologyx platform is the capability for generating documents from configurable templates by merging workflow, record, and API-sourced data into dynamic output used throughout a process. It is used in System Configuration when working with Document Templates, merge fields, Catalyst APIs and Variables, and Jinja/Jinja2-based template logic, and is supported by tools such as the Catalyst Word Add in for converting flat documents into reusable dynamic templates. Document Automation matters because it enables consistent, scalable production of documents inside workflows, supports advanced scenarios such as sequences for relational records and loop-driven content, and requires correct template design, including whitespace control, to ensure the generated documents are accurate, well-formatted, and ready for downstream use.

Document data type ​

INSUFFICIENT_EVIDENCE

Document Field source ​

Document Field source is a source option used in Autologyx document automation when a workflow needs to use an existing document stored in a record field rather than generate a new one. It is selected in configurations that use a Document Picker actor without a Document Generation actor, allowing the platform to take the document from a configured document field and pass it into the next step of the process. Configuration admins use this setting when designing Sequencer-based document handling and must choose the specific document field that acts as the file storage location. This matters because it determines where the workflow retrieves the document from, ensures the correct file is included in downstream actions or tasks, and must align with task template and workflow configuration when the document is intended to be surfaced in a task.

Document field type ​

A Document field type is an Object class field in Autologyx that is configured to store uploaded document files against a record. It is used by configuration administrators when defining or editing fields for an Object class in the Data Model, including from the Fields list and the Add field or Edit field panels. This field type matters because it controls how many files a record can hold for that field, and that limit affects platform behavior for new configuration outcomes only: increasing the maximum number of files allowed does not change existing records, so administrators must account for this when designing or updating document-handling data models.

Document Fields ​

Document Fields are Object class fields of type Document that store one or more uploaded files on a record in Autologyx, with configuration controls such as default values and a maximum file count of up to 100 files per field. They are used across record forms and views for end-user upload and access, in Document Templates and merge fields to insert file content or images into generated documents, and in Sequencer and integrations where actors such as Document Picker and API Call use files held in the field for onward processing, messaging, or external system submission. Document Fields matter because they provide the platform’s standard mechanism for attaching, displaying, filtering, automating, and reusing document assets throughout workflows, ensuring documents captured on records can be surfaced clearly to users and consistently consumed by automation and integrations.

Show 4 more pages

document generation ​

Document generation in the Autologyx platform is the process of producing a finished document from a document template by merging template content with data held on object class records, including document type fields, relational data, images, and formatted values. It is used when end users manually generate documents from the side panel and when configuration admins design automated generation through sequencing, object class setup, and template configuration in the Catalyst Word Add in. Document generation matters because it turns structured platform data into consistent, ready-to-use outputs such as letters, forms, and branded documents, and its success depends on correct template design, the availability of source data before generation runs, and the use of supported features such as embedded content and Jinja date and time filters to control how information is rendered.

document handling in Sequencer ​

Document handling in Sequencer is the capability in Autologyx Catalyst that enables Sequencer steps to work directly with documents, including binary and multipart files, as part of an automated process. Used when configuring or running sequences that need to create, pass, or process document content, it extends manual document automation by allowing document payloads to move through workflow actions alongside records and task activity, including scenarios such as using a Create task actor with attached or generated files. This matters because it lets configuration admins design end-to-end automations that include document-centric work without leaving the Sequencer, and it gives end-users a smoother experience when tasks and process steps depend on document input or output.

Document manual generation ​

Document manual generation is a document template setting in Autologyx that controls whether users can generate a document manually from that template, rather than only through automated process activity. It is used in document template administration, where Configuration Admins and Super Admins can view its current status in the Document templates list and enable or disable it when editing a document template. This setting matters because it determines how a template can be used operationally, giving administrators control over whether a template is available for direct, user-initiated document creation and helping them configure templates appropriately for different business scenarios.

document metadata ​

Document metadata in Autologyx is the structured descriptive information returned with a document or file record, such as the attributes associated with documents retrieved through platform APIs. It is used in document and records functionality and is exposed to developers and integrators through endpoints including GET /api/object records/files/, which returns document metadata alongside file-related data. This matters because it allows integrations, custom interfaces, and automation to identify, classify, display, and process documents consistently, and supports features such as document display, filtering, and alignment with document-related configuration across the platform.

document object ​

A document object, also called the standard document object structure, is the JSON representation Autologyx uses to identify and pass a file through a workflow. It is used wherever the platform exposes or consumes documents as structured data, including document-based Loop actor items from the Document Picker and Document type variables, and it can be inspected or referenced in tools such as JSON Explorer and JSON Path fields. A document object always includes the document’s id, name, size, uuid, mimetype, and context_id, where context_id is the security token that binds the document to a valid platform context and prevents forged document references. This structure matters to configuration admins and developers because it is the format required to reliably select, iterate, reference, and attach documents in actors such as Send Message and API Call, and to work with document values in loop and local variable configurations.

Document Picker ​

Document Picker is a sequence actor in the Autologyx platform that selects one or more documents and passes those selected document objects to the next connected actor in the sequence. It is used in workflow configuration wherever downstream steps need to work with documents directly, including API Call actors for multipart file uploads, Loop actors to iterate over each selected document as a Loop Item, Local Variable actors to reference the selected document and its metadata, and Send Message actors to attach the document to an email. This matters to configuration admins and developers because the Document Picker is the standard mechanism for making document content and document metadata available to later steps, enabling document-driven automation, integrations, and communications within a sequence.

Document Picker (source option) ​

Document Picker is a Source option in the DocAuto actor configuration that sets document generation to use a Document Picker source within a workflow. It is used when configuring the DocAuto actor in sequence design, alongside other source options, to control how the actor obtains the document input it needs to generate output documents. This matters to configuration administrators because the selected source option determines how automatic document generation is driven in a process and ensures the DocAuto actor is aligned with the intended document selection method for that workflow.

Document Picker actor ​

The Document Picker actor is a Sequence actor used in the Autologyx sequence workspace to select documents from a defined source and pass them to later steps in a sequence. It is configured to pick documents produced by a DocAuto actor, returned by an API Call actor such as a GET request, or stored in a record document field, and makes those files available for downstream actions such as Update Record, Send Message, and API Call actors that send files as attachments or multipart payloads. Each Document Picker can handle multiple documents from its selected source, and the Combine results option allows it to gather documents from earlier points in the sequence path so several Document Picker actors can contribute a single set of files. This actor matters because it is the standard mechanism for moving, grouping, and reusing documents through automated processes, which directly affects how documents are generated, retrieved, attached, and stored across a workflow.

Show 6 more pages

Document Records Enhancements ​

document template list ​

The document template list is the system configuration view that displays the available document templates in Autologyx and serves as the main landing page for managing them. It is used by configuration administrators and Super Admins within the Document templates area to review existing templates and return to the full set of templates after actions such as editing a document template. This list matters because it provides the central point from which document templates are accessed and administered, supporting efficient template maintenance as part of overall system configuration.

Document template setup ​

Document template setup is the editable configuration for an individual document template in Autologyx, accessed from the Document templates list by opening a template row for editing. It is used by configuration administrators and Super Admins to maintain the settings and details that define how a document template is represented and managed within the platform, alongside related list information such as Template File Name, usage visibility, and column configuration. This setup matters because it is the point at which template definitions are maintained, enabling administrators to keep document templates organised, identifiable, and correctly configured for use across the system.

Document Templates ​

Document Templates are reusable Microsoft Word .docx-based templates configured against an Object class in Autologyx to generate record-specific documents using merge fields, conditional logic, images, relational data, and other Jinja-based templating features. They are managed in System Configuration under an Object class’s Document Templates tab, created and edited directly or with the Word add-in, and used either manually from a record’s Templates panel or automatically in workflow through the Sequencer’s DocAuto actor and related integrations such as DocuSign. Document Templates matter because they turn Object class and related record data into consistent, automated outputs at scale, reducing manual drafting, supporting complex document assembly, and ensuring documents are generated as part of controlled business processes.

Show 27 more pages

Document templates list ​

The Document templates list is the configuration view within an Object class where administrators access and manage the document templates defined for that class in Autologyx. It is opened from the Document templates tab and serves as the central list users return to after creating a template, with template file name and description available as list fields. This list matters because it provides the primary place to review existing templates in context of the Object class, navigate template records, and work with template-related controls such as the Actions menu and column configuration when configuring document generation.

Document templates tab ​

The Document templates tab is the section within an object class in System configuration where configuration admins and Super Admins create, view, and edit the document templates associated with that class. Templates defined here are used to generate documents for records in the object class, either manually from the record side panel or automatically through the sequencer, and they can include merge fields for record data and be used with document generation tools such as the Catalyst Word Add in. This tab matters because it is the control point for managing the templates available to users, ensuring the right documents can be produced consistently for the correct record type, with template names, files, and descriptions maintained as part of the object class configuration.

document type fields ​

Document type fields are object class fields used to store files against a record in Autologyx. They are configured on an object class and then used across the platform wherever documents need to be uploaded, generated, selected, updated, or retrieved, including file upload components, document templates, manual document generation, Sequencer workflows, Document Picker and Update Record actors, and integrations that return signed or generated files. In record views and lists, document type fields show attached files and can be filtered with options such as Is empty and Is not empty to identify records with missing or completed document content. They matter because they define where documents are saved on a record, enable downstream actions such as merge field image use and automated document storage, and give administrators precise control over how business documents are captured, replaced, cleared, displayed, and managed throughout a workflow.

Show 3 more pages

document type merge field ​

A document type merge field, also referred to as a standard document type merge field, is an Autologyx merge field used in generated documents to reference a document held against a workflow item through a configured document type. It is used in document templates as the base field for inserting or extending document-related content, including image merge field syntax where an attached file index and the .embedded suffix are added to display a selected embedded document in the generated output. This matters because it provides the core link between document-type data stored in the platform and the content rendered in generated documents, allowing configuration admins to design templates that pull the correct document assets and enabling end-users to produce documents that include the expected referenced or embedded files.

Document Type source ​

Document Type source is a Local Variables configuration option in the Autologyx platform that sets the variable’s static value in the context of a selected Document Type, allowing document-related merge fields to be resolved from that document definition rather than only from the current record. It is used when configuring Local Variables that will be consumed by Document Templates or other document-generation features, including scenarios that use record-based merge fields and loop item values. This matters to configuration admins because the chosen source controls which merge fields are available and how values are populated during document creation, helping ensure templates receive the correct document-specific data.

Document type variable ​

A Document type variable is an Autologyx variable whose value uses the same structured schema as the platform’s document object, allowing document data to be stored, passed, and referenced consistently within a workflow. It is used in configuration and actor logic wherever a process needs to work with a document as a structured value rather than as separate fields; for example, in Loop actor document-based loops, the item structure matches the document object held in a Document type variable. This matters to configuration administrators and developers because it provides a standard way to access document properties in local variables and actor configurations, making integrations and workflow logic easier to design, map, and maintain.

document upload/view component ​

In Autologyx, the document upload/view component is the interface element used on fields that hold documents, combining document upload with in-place viewing and document-specific actions. It is used wherever a document is attached to a field, including areas that use the viewer panel, and provides access to actions such as delete or download through the action menu shown for each attached document. This component matters because it is the primary way end-users add, review, and manage saved documents during work, and it is also important for configuration admins because its behaviour and placement affect how document handling is presented across task completion pages and record-editing experiences.

document viewer ​

In Autologyx Catalyst, the document viewer is the in-app capability for opening and reading documents directly within the platform, typically through the document viewer panel. It is used by end-users while working in Catalyst to access document content without downloading files first, keeping document review inside the active workflow. This matters because it streamlines document handling, saves time, and supports collaboration by making documents immediately accessible in context as users progress work in the platform.

document viewer panel ​

The document viewer panel, also called the viewer panel, is a Catalyst interface component that displays documents directly within the Autologyx platform so users can open and review files without downloading them first. It is used in Catalyst wherever document handling forms part of a task or workflow, providing an in-context viewing experience alongside the work being completed. This matters because it streamlines document-based activities, reduces unnecessary file downloads, and helps end-users work more efficiently by keeping document review inside the same application experience.

DocuSign API Key ​

A DocuSign API Key in Autologyx is a supported provider type for an Authentication object, used by configuration administrators and Super Admins to store the credentials and technical connection details required for Autologyx to authenticate with DocuSign when making API calls. It is configured in the Authentication objects area of platform administration alongside other provider-specific authentication methods, and is referenced by platform integrations and automated processes that need to interact with DocuSign. This matters because a correctly configured DocuSign API Key enables secure, reusable connectivity to DocuSign services, allowing implementers to support document and e-signature related integrations without embedding provider credentials directly into process design or runtime configuration.

DocuSign auth object ​

A DocuSign auth object is the Autologyx configuration item used to supply DocuSign authentication details to an API Call actor when a workflow needs to interact with the DocuSign API. It is selected as part of configuring DocuSign-related API calls, such as monitoring the status of an envelope or retrieving a signed document for storage in Autologyx. For configuration admins and integrators, this object matters because it centralises the connection credentials used by those API calls, ensuring the workflow can authenticate correctly to DocuSign and perform the required envelope and document actions consistently.

DocuSign Authentication Object ​

A DocuSign Authentication Object is an Autologyx authentication object configured in Administration > Authentication objects to manage the connection between the platform and a DocuSign account for API-based actions. It stores the DocuSign connection details needed by the integration, including values such as the User ID, and handles token management by using refresh tokens to obtain new access tokens and attaching the current access token to request headers for DocuSign API calls. It is used when configuring DocuSign integrations such as API calls to create envelopes, where the API call is set to use an Auth Object and the specific DocuSign authentication object is selected. This matters because it provides the authenticated context required for Autologyx to communicate with DocuSign reliably across environments, and is a core setup step for configuration admins and integrators implementing or maintaining DocuSign connectivity.

DocuSign Envelope ​

A DocuSign Envelope in the Autologyx platform is the DocuSign transaction container created and managed through configured API calls, holding the documents, recipients, and signing workflow for a signature request. It is used in Catalyst integrations when administrators or developers configure an API Call actor with a DocuSign Authentication Object, Account Base URI, and API Account ID to create an envelope, store its envelope ID in local variables or Record Fields, and then query DocuSign endpoints to track overall envelope progress and individual recipient status. This matters because the envelope is the core object that links document generation, recipient routing, and status monitoring, enabling Autologyx workflows to initiate e-signature steps and reliably monitor completion across the signing process.

DocuSign envelope ID ​

A DocuSign envelope ID is the unique identifier returned when the Autologyx platform creates a DocuSign envelope, and it is typically captured into a local variable using the DocuSign action output, for example {{output.envelopeId}}. In Autologyx, this value is used in workflow sequences and integrations that need to monitor or retrieve the envelope after creation, especially when checking envelope status through API-driven steps such as API Actors or update logic. It matters because it provides the link between the Autologyx process and the specific DocuSign transaction, enabling the platform to track the correct envelope, apply status-based conditions, and drive the next steps in the workflow.

DocuSign with Catalyst ​

DocuSign with Catalyst is the Autologyx document automation and eSignature integration used when configuring document templates that combine DocuSign delivery and signing with Catalyst APIs and variables to populate document content dynamically. It is used within System Configuration, particularly in the document template, merge field, and APIs and Variables areas, where administrators and integrators define how documents are generated, populated, and presented in the user experience. This matters because it enables configured solutions to produce consistent, data-driven documents and signature workflows, ensuring that template content, variable mapping, and signing behaviour are aligned with the broader automation design of the platform.

domain ​

downstream Actors ​

In Autologyx, downstream Actors are any Actors that occur later in the same Sequence than the point at which a value, such as a Local Variable, is defined, and they are the Actors that can consume that value through Jinja expressions. This term is used when configuring Sequences, especially in scenarios involving Local Variable Actors, API calls, conditions, and message or integration steps that depend on data calculated or retrieved earlier in the flow. Downstream Actors matter because variable and output availability in Autologyx is sequence-dependent: a Local Variable does not exist until the Sequence reaches the Actor where it is created, so only subsequent Actors can reference it. Understanding which Actors are downstream is essential for designing working automations, avoiding invalid references, and ensuring values are available where they are needed for triggers, message content, and API request construction.

drag and drop interface ​

In Autologyx, the drag and drop interface is a core feature of the Sequencer that lets configuration users build and organise sequences visually by placing and arranging sequence components within the design workspace instead of defining them through code or complex manual setup. It is used when creating and editing sequences, including intelligent pathways and flows that involve Sequence Actors, triggers, messaging, and integrations with third-party systems. This matters because it gives Configuration Admins and Super Admins a faster, clearer way to configure process logic, understand sequence structure, and maintain automation more efficiently within the platform.

drag and drop module ​

In Autologyx, a drag and drop module is a configurable page module that can be placed on any Landing Page to provide specific user-facing functionality within the page layout. It is used when configuring Landing Pages, where administrators add the required module to make capabilities available to end users. In the documented context, the File upload component is delivered as a drag and drop module, meaning it is added to a Landing Page as a modular element rather than being available automatically. This matters because the module must be included in the page configuration for users to access that function, making it an important part of how Landing Page features are enabled and presented in the platform.

drag and drop tool ​

The drag and drop tool in Autologyx is the visual interface used in the Relational modeller to define relationships between object classes by selecting a parent object class and adding one or more child object classes. Configuration admins and Super Admins use it when designing or updating data structures that support parent/child levels, including one-to-one and one-to-many relationships rooted in a root parent object class. This matters because the relationships created in the tool determine how parent records and child records are organised and presented across the platform, including in create and edit views, and provide the structural foundation for how related business data is captured and managed.

In Autologyx, a drop down list is a display option for a single select field in the Catalyst form builder, used on record and task forms to present predefined choices in a compact control. Configuration admins set this on the field’s display settings when designing create and edit views, choosing it instead of radio buttons when there are several options and screen space needs to be preserved. This matters because the way options are presented affects form usability and clarity: drop down lists keep forms cleaner when a field has more than a few values, and they can include an initial prompt option to guide users to make the correct selection.

Dropdown autocompletes and filters are Autologyx interface controls that let users search, narrow, and select users or user groups anywhere the platform provides a user or group picker. They are used across areas such as task ownership and assignment, object class and record ownership, permission sets, user type class fields, default task assignees in sequences, and user group management. What a user can see in these dropdowns is governed by list permissions, including users.list permission and related Users and Groups visibility settings, so only permitted users and groups are returned for selection and filtering. This matters because it directly controls who end-users can find and assign, and it gives configuration admins and Super Admins a key mechanism for enforcing visibility rules, access boundaries, and correct operational choices throughout the platform.

A Dropdown list in the Autologyx platform is a single-select form field component used when configuring forms, including Standalone Forms, to present users with a predefined set of options from which only one value can be chosen. It is used during form design alongside other field types, such as radio buttons, as part of the platform’s form components and elements. Dropdown lists matter because they standardise data capture, guide users to valid entries, and help configuration admins control how information is collected and stored across workflow-driven processes.

Due Date ​

Due Date is the task deadline in Autologyx that defines when a task is expected to be completed and is used to drive task status and user behaviour across the platform. It is set when a task is created, including from task templates and manual task creation on object records, where users can choose No due date, a specific date, or in some template configurations a time frame from task creation. The Due Date is shown with the task and works with the task lifecycle to determine whether a task remains Outstanding or becomes Overdue once the deadline passes without completion. It also affects access to task completion links for 1-time completion users, because links become inactive when a dated task passes its due date, while tasks with no due date remain active until completed. For configuration admins and integrators, the Due Date is also relevant in permissions and automation because it can be updated through PATCH API calls on tasks associated with records.

Duplicate values warning modal ​

The Duplicate values warning modal is a validation dialog shown in the Autologyx platform when a user attempts to create or save a Record with a field value that already exists on another Record where uniqueness is enforced. It is used during record entry and editing alongside the field-level error message, helping end-users identify that the entered value conflicts with an existing record and preventing the save until the duplication is resolved. This matters because it supports data integrity in object classes that use settings such as Force unique value, and it is important for configuration admins to understand when designing fields, default values, and class user field behaviour so that users receive clear validation when duplicate data is entered.

dynamic content ​

Dynamic content in Autologyx is content inserted into document templates at runtime using Jinja merge fields, so the final output is populated with data specific to the case, task, or process context. It is used when configuring document templates and related merge fields, allowing templates to adapt automatically instead of relying on fixed text. This matters because it enables configuration admins to build reusable, data-driven templates and ensures end-users receive generated documents that reflect the correct live information for each workflow instance.

Dynamic document assembly ​

Dynamic document assembly is an Autologyx document-generation capability that lets you build modular output documents by embedding full .docx files into Document Templates through a single merge field, so separate document fragments can be combined into one finished document at runtime. In the platform, it is used in template configuration and document-generation workflows, particularly by configuration admins designing reusable templates and by end-users producing assembled documents from those templates. Introduced as an improvement in Autologyx Catalyst 1.13, it matters because it makes document creation more modular, easier to maintain, and better suited to assembling complex documents from standardised components without manually rebuilding content in each template.

Dynamic Prompt Customisation ​

Dynamic Prompt Customisation is the ability to build AI prompts in Autologyx using merge fields so that values from records are inserted into the prompt at runtime, creating context-specific input for each transaction or case. In practice, this is used when configuring the OpenAI: GPT integration and GPT actors within workflows, where administrators and developers define prompt text that pulls in record data through the platform’s merge-field mechanism. This matters because it allows prompts to reflect live business data without manual rewriting, making AI-driven steps in actors and sequenced processes more accurate, reusable, and scalable across different records and process scenarios.

dynamic submit button control ​

Dynamic submit button control is an Autologyx standalone forms capability that lets configuration admins control the behaviour and presentation of the form’s submit action as part of the form design. It is used when building standalone forms alongside Elements to create more immersive, dynamic form experiences, giving designers finer control over how and when users complete and submit a form. This matters because it improves the usability and responsiveness of standalone forms, helping admins configure form interactions that better match the intended user journey and business process.

dynamic templates ​

Dynamic templates, also called document automation templates, are Word-based documents in Autologyx that have been converted from static files into reusable workflow assets using the platform’s templating language and Jinja merge fields. They are created and maintained through Document Automation, including the Catalyst Word Add in, and are used within workflows to generate documents that reflect workflow data and process context. Dynamic templates matter because they enable consistent, automated document production across the platform, align document logic with the same templating approach used in the Sequencer, and help end-users and configuration admins standardise document generation as part of case and workflow execution.

Edit A Document Template ​

Edit A Document Template is the configuration activity in Autologyx used to modify an existing document template so it continues to generate the correct document content, structure, and data mappings for business processes. It is used from the document template management area within System Configuration, alongside the document templates list and related actions such as creating templates and configuring Word add-in integration. This matters to Configuration Admins and Super Admins because document templates drive both manual document generation and automatic document generation through the Sequencer, so keeping a template up to date ensures generated documents remain accurate, consistent, and aligned with current workflow and business requirements.

Edit a Role ​

Edit a Role is the administration action used to change an existing role’s configuration in Autologyx, including the set of permissions that role grants to users. It is used in the Roles and Permissions area by configuration administrators and Super Admins when refining access, aligning responsibilities, or updating how users interact with platform features. This matters because roles control user permissions across the platform, so editing a role directly changes what assigned users can view, access, and manage, making it a key mechanism for maintaining secure, accurate, and operationally appropriate access control.

Edit all ​

Edit all is a class permission used in Object class configuration to grant a user edit access across all records in that Object class in the Workspace. It is configured alongside other class permissions and is relevant to administrators defining role-based access for object records and their display views. In practice, this permission allows users to see the display views for all records in the class and, when combined with the required View all permission, supports the broader ability to work across every record rather than only assigned or limited items. Edit all matters because it controls platform-wide record edit capability at the class level, shaping what users can access and maintain across an entire Object class; however, it does not create an obvious change for tasks in the user interface, because tasks are not editable there.

Edit condition modal ​

The Edit condition modal is the configuration dialog in Autologyx that opens when a user selects an existing condition in a form’s conditional logic setup, and it is used to review and edit the condition details. In the context of record and task forms, the modal is especially important when changes to a field’s properties cause a condition to become invalid or impossible to satisfy, because it displays the specific reason the condition can no longer be met. This helps configuration admins diagnose and correct issues affecting Conditional Visibility, validation behaviour, and dependencies involving field types such as single select, multi select, and numeric fields, ensuring forms continue to behave as intended for end-users.

Edit design ​

Edit design, also shown as Sequence design, is the Sequence action in Autologyx that opens the design screen for a selected sequence so configuration administrators and Super Admins can build and modify the workflow structure. It is accessed from the Actions menu or by opening a sequence from the Sequences list, and presents the sequence canvas where you add, remove, and organise task templates, task group templates, and sequence actors such as API calls and Send messages. Edit design matters because it is the primary configuration area for defining how a sequence runs, what activities it contains, and how the workflow is assembled for operational use.

edit display screen ​

INSUFFICIENT_EVIDENCE

Edit field panel ​

The Edit field panel is the configuration panel used in the Autologyx platform to modify an existing field on an object class from the fields list in the Data Model tab. It presents the same sections and components as the Add field panel, allowing configuration administrators and Super Admins to review and update field settings in a consistent interface. After saving, the panel remains open and a success message is shown, enabling continued review or further changes, and it can also display duplicate value messaging for the field. This panel matters because it is the primary place for maintaining object class field definitions, helping administrators keep data structures accurate, usable, and aligned with system configuration requirements.

Edit mode ​

Edit mode is the editable state of an item or configuration screen in the Autologyx platform, used when a user needs to make and save changes rather than only view information. It is encountered across operational and administration areas, for example when opening a record from a list page, editing an Object class, or updating a Sequence, and access depends on the user having permission to edit the item. In Edit mode, change controls and configuration tabs become available, such as the Permissions tab on an Object class, and actions such as moving Sequencer actors, clearing changes, and saving updates are enabled only after entering this state and making modifications. Edit mode matters because it separates safe viewing from controlled editing, helping users understand when changes can be made and ensuring configuration updates are applied deliberately.

Edit Object class page ​

The Edit Object class page is the configuration screen used after creating an Object class in Autologyx to define and manage how that class is structured and presented. It is accessed immediately after Object class creation, including when an administrator selects Add fields, and provides the tabs and controls needed to configure fields, class permissions, and display settings such as summary view, card view, column ratios, components, conditional visibility, and the availability of the Create button. This page matters because it is where configuration admins and Super Admins shape both the data model and the user experience for objects of that class, ensuring the right information is captured and displayed correctly throughout the platform.

Edit Object class permission ​

Edit Object class permission is a platform permission that allows a user to open an Object class in System Configuration and edit its assigned Permission sets. In Autologyx, it is used when navigating to an Object class and selecting Edit from the Actions menu, and access is granted either through a role with the Edit permission for Object classes enabled on the Data Model tab or through a permission set that explicitly includes Edit Object class permission. This permission matters to Configuration admins and Super Admins because it controls who can change which users or roles are authorised to interact with an Object class, making it a key part of governing data model access and administration.

Edit object classes ​

Edit object classes is an Autologyx permission that allows a user to modify object class configuration and related assets for a class. It is used in system configuration tasks such as editing standalone forms from an object class’s Forms tab and creating or editing document templates, which are defined against specific object classes. This capability can be granted through a Super Admin account, a Config admin account with a role that includes the permission, or a permission set that allows editing a specific object class; in some contexts, the owner of the object class can also edit it. This permission matters because object classes define key structural and template-driven behaviour in the platform, so controlling who can edit them is essential for safe configuration and effective administration.

edit object model permission ​

The edit object model permission is a role permission in the Autologyx platform that grants access to work with the object model configuration, including Object Classes within the Relational modeller. It is used when defining or maintaining the platform’s structured data model and is typically relevant to configuration-focused administrators such as Configuration admins and Super Admins. This permission matters because object model components underpin how business entities and their relationships are represented across the platform, so users who configure data structures need this access to view and update those model definitions as part of platform setup and ongoing administration.

Edit panel ​

INSUFFICIENT_EVIDENCE

Edit permission ​

Edit permission is a role-based permission in Autologyx that allows a user to modify existing items in areas of the platform where editing is controlled by permissions, including Sequence configuration under the Sequencer tab. It is used by Configuration admins and Super Admins when maintaining system configuration, such as opening and changing Sequence properties or Sequence design, and it can be assigned on its own or alongside Create permission depending on whether a role is intended for maintenance or full design activity. This permission matters because it takes effect immediately when a role is updated and directly determines whether users can access edit actions, continue to work with existing configuration items, or receive access denied outcomes when attempting restricted changes.

Edit permission against Object Classes ​

Edit permission against Object Classes is a role-based system configuration permission in Autologyx that allows a user to edit all Object Classes in the platform. It is used in Object Class administration areas, including the Edit screen and the configuration tabs such as Fields, Forms, Display, and Document Templates, where Object Class names, fields, layouts, and related settings are maintained. This permission matters because Object Classes define the structure and behaviour of records, so granting it gives a user broad control over how records are configured and presented across the platform; users with this permission, Super Admins, and Object Class owners can edit an Object Class.

Edit Permission for Company Details ​

Edit Permission for Company Details is a role-based permission in Autologyx that grants access to the Company details page in the Administration area for users who are not Super Admins. When this permission is enabled on a role in the Administration tab, users assigned that role can open and maintain the organisation’s company details, including the details of a nominated user or a generic contact. This permission matters because it controls who can manage core administrative contact information in the platform, allowing configuration admins to delegate maintenance of company details without assigning the broader access that comes with a Super admin account type.

edit permission for Object classes ​

Edit permission for Object classes is a system permission on the Data Model tab that allows a user to modify Object classes in Autologyx, including accessing an Object class and using the Edit action to manage its permission sets. It is assigned through a user’s Role, and related Object class editing capability can also be granted through an additional permission set using the Edit Object class permission. This permission is used in system configuration and data model administration, and it is also a prerequisite for users who need to create or edit a relational model, because relational modelling access requires Object class editing rights as well. For configuration admins and super admins, this permission matters because it controls who can change core data model elements and associated class permissions, helping ensure that only authorised users can update the platform’s structural configuration.

Edit permission for Single sign on ​

Edit permission for Single sign on is an Administration-tab permission in Autologyx that allows a user to modify existing Single sign on settings. It is used when configuring access to authentication settings in the platform and is specifically required, alongside Super Admin access, to open and edit an existing single sign on configuration from the Single sign on settings area, such as by selecting the setting and choosing Edit. This permission matters because it controls who can maintain and update identity and login configuration, helping administrators delegate SSO management without granting broader platform-wide administrative access.

Edit properties ​

Edit properties, also shown as Sequence properties, is the sequence-level configuration option in Autologyx used to update a Sequence’s core metadata from the Sequences list Actions menu. It is available to Super Admin users and users with the appropriate Edit Sequences permission, and allows them to change the Sequence Name, Description, and Default task assignees without editing the sequence design itself. This distinction matters because a user can be permitted to edit sequence properties even when they do not have permission to edit the design, enabling controlled maintenance of operational details while preserving governance over the sequence structure.

edit records permission ​

In Autologyx, the edit records permission is the access right that allows a user to modify existing records in a specific object class. It is used anywhere a user needs to update a record through the platform’s record editing experience, including relational record workflows where a parent record must be changed to associate child records. This permission is especially important in child class components, child lookup controls, child record selectors, and related Actions menu or create/edit view interactions, because creating or linking child records to an existing parent requires not only create records permission for the child object class but also edit records permission for the parent object class. For end-users, this permission determines whether they can complete record maintenance tasks; for configuration admins, it is a key part of access design to ensure users can update the right records while preserving control over parent-child data relationships.

Edit screen ​

The Edit screen is the configuration interface in Autologyx that opens when an administrator chooses Edit from an item’s Actions menu or double-clicks a row in a list, and is used to view and modify the settings of an existing platform object such as a Single sign-on setting or an Object class. It is encountered from administrative areas including the Administration tab and system configuration lists, and access to it depends on the relevant create or edit permissions for the item being managed. The Edit screen matters because it is the primary place where Configuration admins and Super Admins maintain existing configuration records, update operational settings, and control how platform features behave after initial setup.

edit sequence permissions ​

Edit sequence permissions are role-based access rights in Autologyx that allow Configuration Admin users to open and modify sequences in the Sequencer. Used in the Sequencer area of system configuration, these permissions work alongside create sequence permissions to control which users can maintain the workflow sequences built from object classes, task templates, and sequence actors. They matter because they determine who can update how work is orchestrated across tasks, communications, and participant involvement, helping administrators manage sequence design securely and with the correct level of access.

Edit Sequence properties or design ​

Edit Sequences permission ​

Edit Sequences permission is a role permission in the Autologyx platform that controls a user’s ability to manage Sequence definitions from the Sequences list in System Configuration. Users with this permission see additional options in the Actions menu, including Edit properties, which allows them to update the Sequence name, description, and default task assignees; when combined with Object class Owner status, it also enables operational controls such as Pause and Resume for running or paused Sequences. This permission matters to Configuration admins and Super Admins because it governs who can maintain Sequence configuration and control Sequence behaviour without granting those capabilities to all users.

Edit Task group templates permission ​

Edit Task group templates permission is a role-based permission in Autologyx that controls whether a user can modify Task Group Templates in system configuration. It is assigned within a Role under the Task configuration tab, and users with this permission, along with Super Admins, can open and edit an existing task group template from the Task Group Templates area. This permission matters because task group templates define reusable task structures, so restricting edit access helps organisations control configuration changes, maintain consistency across task setup, and ensure only authorised administrators can update template behaviour.

Edit Task templates permission ​

Edit Task templates permission is a role-based permission in Autologyx that controls whether a user can modify existing Task templates in system configuration. It is used under the Task configuration tab of a Role and, alongside Super Admin account access, determines who can open the Task template edit screen by double-clicking a template row or selecting Edit from the Actions menu. This permission matters because Task templates define the structure and behaviour of tasks, including response form design, field types and input settings, required values, lifecycle and expiry settings, and related configuration such as file upload, numeric, single select, object class, and sequence trigger options.

Edit user page ​

The Edit user page is the administration screen in Autologyx used to view and update selected details of an existing user account. Configuration admins and Super Admins access it from the Users list by selecting Edit from the Action menu or by double-clicking a user record, and use it to review key account settings such as the user’s account type, which is shown with a blue outline, and status information. This page matters because it is the central interface for managing user account configuration and understanding the current state of a user in the platform; however, passwords are not changed here and must instead be reset by the user from the login page.

edit view ​

Edit view is the record interface in Autologyx that opens when a user opens an existing record, providing the configured form together with a side panel that shows record-specific information such as the summary, tasks, and record access tabs. It is used from the Records list, including when a record is opened from Card view, and it complements the create/edit view used when creating a new record. Edit view matters because it is the primary workspace for reviewing and updating record data and related activity, and its layout and fields are defined through the Object class configuration.

Editing A Task Group Template ​

Editing A Task Template ​

Editing a Task Template is the administration activity of modifying an existing task template in Autologyx so that future tasks created from it use the updated setup. It is used in System Configuration under Task Templates by configuration administrators and Super Admins when maintaining how work is initiated, presented, and completed in the platform. This matters because task templates define key behaviour such as the task type and response configuration, so editing a template is the controlled way to keep task-driven processes aligned with current business requirements, user interactions, and record update outcomes.

Editing A User Group ​

Editing An Element ​

Editing An Element is the administration task of opening an existing element definition and changing its configuration in Autologyx. Used from the Elements area by configuration administrators and Super Admins, this activity updates how that reusable element behaves when placed on forms, including the settings that control its structure, presentation, and use within a process. Editing matters because elements are shared configuration components, so changes made to an element can affect the forms and user experiences where it is used; administrators should therefore manage edits carefully to maintain consistency, usability, and correct process behaviour across the platform.

editing records ​

In Autologyx, editing records is the end-user activity of opening and updating an existing record within the platform’s record interface. It is used when working in Card view and related task pages, where users review or amend record data and associated content as part of completing work. While editing a record, platform components such as the Viewer panel can open directly when a user selects a saved document, giving in-context access to documents attached to fields or otherwise linked to the record. This matters because record editing is a core interaction for maintaining accurate case or process data, reviewing supporting documents alongside field values, and completing tasks efficiently from a single workspace.

Editing User Group Permissions ​

Editing User Group Permissions is the administration task of changing the permission set assigned to a user group in Autologyx. It is used in the User Groups area of platform administration alongside creating and editing groups, reviewing the user group list, and managing users and groups visibility. This function matters because user group permissions control what members of a group can access and do across the platform, allowing Configuration Admins and Super Admins to align access with operational roles, enforce governance, and maintain the correct separation of responsibilities as teams and processes change.

Element component ​

An Element component, shown in Form Builder as Element, is a form component that places a configured Element onto a form canvas so it can be displayed in supported areas of the Autologyx platform, including landing pages, object class create and edit views, summary views, and standalone forms. Configuration admins use the component when designing record and task forms by dragging it onto the canvas, while the Element itself is created and controlled separately through the Element create/edit configuration, which defines where it can be used. This matters because Elements let organisations embed specialised functionality into forms and record views, and correct configuration determines where admins can select the Element and how consistently it is presented to end users.

Element create/edit config ​

Element create/edit config is the configuration area for an Element in Autologyx where administrators control the contexts in which that Element is available across the platform. Used when creating or editing an Element, it provides radio-button options to enable the Element for specific form and page areas, including Object classes create and edit views, the summary view, standalone forms, and the landing page. This matters because it determines where an Element can be placed and used in form design, helping Configuration admins and Super Admins ensure that each Element is exposed only in the appropriate locations and behaves consistently across record, task, and standalone form experiences.

Element Details ​

Element Details is the side-panel configuration area shown when a configuration admin selects an Element while designing or editing a form in Autologyx, including object class create and edit view display forms. It is used to view and update the selected element’s properties directly in context on the form canvas, making it the primary place for configuring how that element behaves and is presented on the page. This matters because Element Details provides the control point for form design and element setup, allowing administrators to define the characteristics of each element accurately as they build or maintain platform forms.

Element parameters ​

Element parameters are the configurable values defined for an Element in its Element project, typically in the Element’s configuration file, and supplied when that Element is added to a form or page in the Autologyx platform. They specify the settings and functional options the Element supports, with certain parameters required for the Element to install and operate correctly. Configuration administrators and developers use these parameters when creating, configuring, and deploying Elements through Administration > Elements and in form configuration, making them essential for controlling how an Element behaves, where it is used, and how it integrates into the user experience.

Element project ​

An Element project is the packaged file and folder structure used to create and install an Element in the Autologyx platform. It is used by developers and configuration administrators when building custom Elements under Administration > Elements, and it must include the required project files and exact directory layout expected by the platform, including the configuration file that defines the Element’s attributes and parameters and the entry-point file used when the Element is displayed. This matters because Autologyx validates the Element project during import and installation, and if the required files or structure are missing or incorrect, the Element installation fails.

Element properties ​

Element properties are the configuration input fields for an Element in the Autologyx platform, shown in the element configuration interface and generated from that Element’s parameter objects. They are used when creating or editing an Element to define how it behaves and how it is presented on a form, making them a key part of the Object class create/edit view display form. For Configuration Admins and Super Admins, Element properties matter because they provide the direct mechanism for setting the options, values, and behaviour that control how an Element functions within a configured process or user-facing form.

Element status ​

Element status, shown as Status in the Elements list page and the Elements landing page, indicates the current progress of an Element’s installation in the Autologyx platform. It is used by Configuration admins and Super Admins to understand whether an Element has been successfully installed, is still being processed, or has failed, with statuses such as Installed, Processing, and Failed providing a clear operational view of each Element. This matters because Element status is the primary indicator of whether an Element is ready to be enabled and used in the platform, or whether administrative action is needed to resolve installation issues before configuration can continue.

Elements ​

Elements are custom front-end components developed for an Autologyx Catalyst system and installed from a Git repository so they can be embedded in the platform as reusable formbuilder components. They are used in the Administration area for creation and management by Super admins, and then made available in formbuilder for configuration on landing pages, object class create/edit and summary views, and standalone forms, where admins can drag them onto the canvas and enable them for specific use. Hosted securely in an IFRAME, Elements connect external or custom web content and functionality to Autologyx, including interaction with underlying platform data, allowing organisations to extend the user experience with tailored integrations, visualisations, and third-party capabilities without requiring core product changes.

Show 10 more pages

Elements list ​

INSUFFICIENT_EVIDENCE

Elements list page ​

The Elements list page is the Administration area in Autologyx where configuration and Super Admin users access a structured view of all Elements in the platform. Reached from the main navigation menu under Administration, this page is used to review and manage the installed Elements catalogue through default columns such as the system-generated Element ID and related status information, including states such as Installed, Enabled, Failed, and Processing. It matters because it serves as the primary operational view for identifying Elements, checking their current state, and supporting administration tasks tied to configuring, monitoring, and maintaining Element availability in the platform.

Elements section of the side panel ​

The Elements section of the side panel is the area within a form where users access the Elements that have been made available for that specific form. In Autologyx, it is affected by Element configuration: when a configuration admin switches off an Element’s availability for a form, that Element is removed from the Elements section of the side panel for that form. This matters because the section reflects the active set of Elements that users can work with in context, making Element availability settings a direct control over what is presented in the form interface.

Email ​

In Autologyx, the Email field type is a task form input type used to capture an email address in a recognised format, shown to users with an @ symbol indicator at the end of the field. It is configured in the form builder alongside standard field settings such as Label, Default value, Description, Conditional Visibility, and Alias, and is presented to end-users when completing a task form. The field enforces email-format validation, so users must correct any invalid entry before the task can be submitted. This matters because it helps configuration admins collect correctly formatted contact information and improves form completion quality by preventing submission of invalid email addresses.

email actor configuration ​

Email actor configuration is the set of settings defined within a Send Message Actor in a sequence that control how an outbound email step behaves in the Autologyx platform. It is used by configuration administrators when building or editing Sequence Actors, alongside sequence design and outbound mail setup, to specify the content and operational details of an email action, including elements such as merge fields where supported. This configuration matters because it determines the behaviour of a specific email step in a sequence, and changes are only retained when both the email actor configuration and the parent sequence are saved.

email body ​

In Autologyx, the email body is the main content of an email generated or sent by the platform, and it can be dynamically controlled using conditional logic to show or hide specific content based on field values. It is used alongside document templates and configured in template-authoring contexts such as the Templates tab and Word Add In, where administrators define how messages should adapt to different data conditions using If / Else and nested conditions. This matters because it allows configuration admins to create more accurate, context-specific communications, and helps end-users send emails whose content is automatically tailored to the workflow, case data, or business scenario.

Email type field ​

In Autologyx, an Email type field (also called an Email field) is a field type used in the Catalyst form builder to capture email addresses on intake forms and other record creation forms. It is selected when configuring form fields where users are expected to enter an email address, alongside other specialised field types such as Date/Time and Phone. This matters because choosing the correct field type ensures email data is collected in the appropriate format, supports consistent form design, and helps configuration admins structure record and task forms so information is captured in the right place and in a usable way across the platform.

embedded ​

In Autologyx, **embedded** (used as the .**embedded** property in a merge field expression) is an image-specific value used during document generation to insert the binary content of an image stored in a document type field directly into a Document Template. It is used in image merge fields such as {{record.field\ customer\ logo[0].embedded | img\ width(40) | img\ height(40)}}, where it supplies the image itself and can be combined with image formatting filters like width and height. This matters to configuration admins because **embedded** is the property that enables stored record images, such as logos, signatures, or other uploaded graphics, to render inside generated documents rather than outputting metadata or a reference, and it matters to end-users because it ensures the final document includes the expected visual content in the required layout.

embedded merge field ​

An embedded merge field in Autologyx is a .docx merge field that inserts the full contents of a file stored in a record field directly into a Word document template during dynamic document assembly. It is used in Document Templates with the .embedded suffix, for example {{ record.field[index].embedded }}, where the index selects the specific file from a multi-value field; if the index is omitted, the field returns an empty result. This matters because it allows configuration admins and end-users to build assembled documents that include complete source content, such as clauses or attachments, within the generated output instead of inserting only simple text values, making template design more powerful and reducing manual document preparation.

Embeddings ​

Embeddings in the Autologyx platform are a configurable OpenAI integration used in the Sequencer to generate vector representations of unstructured content for downstream automation and analysis. Configuration users can define parameters such as the model, input format, encoding method, and dimensions, then apply embeddings within workflows that interact with records, tasks, and templates. This matters because embeddings extend Autologyx beyond structured data handling, enabling capabilities such as semantic search, document analysis, and faster review of content like contracts, helping organisations reduce manual effort and improve the effectiveness of workflow-driven processes.

Embeddings in Sequencer ​

Embeddings in Sequencer is the Autologyx capability that uses the OpenAI Embeddings integration within Sequencer to represent text as vectors for semantic search and context-aware automations. It is used when designing and configuring Sequencer-driven automation that needs to find related content by meaning rather than exact wording, helping processes identify relevant information and trigger more contextually accurate actions. This matters to configuration admins, super admins, and developers because it extends Applied AI in the platform beyond generative responses, enabling more precise matching, retrieval, and automation behaviour in workflows that depend on understanding similarity across documents, prompts, or other text inputs.

Enable ​

Enable is the control used to make a configuration item active and available for use in the Autologyx platform. In Administration > Elements, enabling an Element after selecting the system areas where it should be available activates it and allows the configuration to be saved and imported. In standalone form configuration, the Enable toggle turns the form on so it can be used, and it remains inactive until at least one field has been added to the canvas. This matters to configuration admins and Super Admins because creating or editing an Element or form is not enough on its own: the item must be enabled before it becomes usable in the relevant parts of the Catalyst system.

Enable button ​

In the Autologyx platform, the Enable button is the control used when configuring a Theme to mark that theme as active so it can be applied across the application. It is used on the theme configuration workflow, including the Configure Theme page where administrators define settings such as core colours, additional colours, form colours, media, and branding elements like the Autologyx Catalyst logo. This button matters because theme changes do not take effect simply by entering values; administrators must click Enable and then Save to make the configured theme the one used throughout the user interface.

enable integrations ​

Enable integrations is the administrative action of switching an available integration on or off in the Autologyx platform so it can be used by the organisation. It is used in the integrations area of System Configurations, where Configuration admins and Super Admins manage centrally available connections across integration categories such as business tools and Applied AI providers. This setting matters because it controls which approved integrations are active in the platform at any given time, allowing administrators to roll out newly prepared integrations quickly, restrict access when needed, and keep the organisation’s configured integration landscape aligned with operational and governance requirements.

Enable the display ​

Enable the display is the action of turning a configured object-class view on so it is available for use in the Autologyx platform. In the Display tab when configuring displays for an object class, administrators can enable views such as Create/edit and Summary after they have been set up and saved; Card view is enabled by default. This setting matters because a display can be configured but remain unavailable until it is enabled, so enabling the display is the final step that makes the view usable to end users in the relevant create, edit, summary, or card presentation context.

Enable the page ​

Enable the page is the control used when configuring the Autologyx Landing page to switch the current page design from draft or edit state to the live version shown to users. It is used in the Landing page configuration screen, alongside actions such as Preview, Revert, and Save, after changes have been made in the editor. For configuration admins and Super Admins, this setting matters because enabling the page is the step that makes the configured content active in the platform; without enabling and then saving, edits remain unavailable to end users.

Enabled ​

Enabled is the configuration flag on an Element that shows whether that Element is enabled or disabled within the current Autologyx configuration. It is used by Configuration admins and Super Admins on the Elements list page and in Element management to identify the operational status of Elements in a specific configuration. This flag matters because it tells administrators whether an Element is available for use in that configuration, supporting accurate setup, governance, and maintenance of platform capabilities.

Enabled column ​

In the Autologyx Administration area for single sign-on (SSO) configuration, the Enabled column is the status indicator that shows whether an SSO configuration is currently active. When a configuration has been enabled, this column displays a green tick, allowing Configuration Admins and Super Admins to quickly confirm which SSO setup is live in the list of configured providers. This matters because the enabled state determines whether the configured sign-on details, such as login support and redirect settings, are in effect for users, making the column an important at-a-glance control point when reviewing or managing SSO access.

Enabled switch ​

encoding format ​

In Autologyx, encoding format is a configuration setting on the Azure OpenAI actor that defines how input text is represented and processed by the model as part of an integration request. It is used alongside other model configuration options such as model type, vector dimensions, endpoint, temperature, user, and prompt and context fields when administrators or integrators set up Azure OpenAI connectivity. This setting matters because it influences how text is handled within the AI workflow, making it an important part of ensuring the actor is configured correctly for the intended processing, search, and similarity-matching behaviour.

end users ​

End users are the people who interact with Autologyx through runtime experiences such as display forms to view, enter, and update information as part of completing work, rather than configuring the platform itself. The term is used in feature behaviour and access settings to distinguish operational users from configuration admins, for example when field accessibility is configured so that certain fields are read only for end users and cannot be manually modified. This distinction matters because many platform settings, including read-only options on forms, control exactly what end users can see or edit during execution, helping admins design the correct user experience and enforce process controls.

endpoint field ​

In Autologyx, the endpoint field is the configuration setting on an Azure OpenAI actor that specifies the Azure API URL the platform sends requests to. It is used when configuring the actor alongside related settings such as authentication objects, model type, temperature, prompt and context fields, encoding format, vector dimensions, feature enabled, and any user parameter values. This field matters because it directs Autologyx to the correct Azure OpenAI service endpoint, enabling successful communication between the platform and Azure for the configured AI capability.

Enum ​

Envelope ​

An Envelope, also called a DocuSign envelope, is the DocuSign transaction container used in Autologyx when integrating eSignature steps through configured API calls. It packages the documents to be signed, the recipients involved in the signing process, and the status information that Autologyx monitors after creation. In the platform, envelopes are used in DocuSign integration configuration, particularly when administrators or integrators set up API calls to create envelopes and track their progress through signing status updates. This matters because the envelope is the core object that links Autologyx workflows to DocuSign actions, enabling the platform to send documents for signature, authenticate the request through the relevant integration configuration, and retrieve the resulting signed document and completion state.

envelope status ​

Envelope status is the DocuSign-provided state of a specific envelope, returned by a status-check API call and stored in Autologyx so the platform can monitor the progress of documents after an envelope is created. In Autologyx, it is typically captured in a local variable within the same sequence that creates the DocuSign envelope, using the envelope ID and DocuSign authentication details to query DocuSign for the current signing status. This value is then used in trigger conditions, update actor logic, and reporting to drive follow-on workflow actions such as progressing, pausing, or updating a case when the envelope moves through its signing lifecycle. Envelope status matters because it connects external DocuSign activity to internal Autologyx process automation, allowing administrators and integrators to build workflows that respond directly to real-time document-signing outcomes.

environment defined in the token ​

In Autologyx, the environment defined in the token is the platform environment scope carried by the authentication token used to open a WebSocket connection, and it determines which real-time object record events are delivered to that client. This is used in WebSockets and other environment-aware integrations so that environment-scoped updates are broadcast only within the specific environment associated with the token, rather than across other environments. This matters because it enforces separation between environments, keeps event streams contextually relevant to the connected application or Catalyst Element, and supports secure integration, compliance, and analytics by ensuring users and systems receive only the updates for the environment they are authorised to access.

Error Handling Reliability ​

Event History tables ​

Event History tables are Autologyx database views that expose platform event history data directly within a supported DBMS, alongside selected Resource tables, for reporting, analysis, integration, and compliance use cases. They are accessed after login through the database views capability and are provided as Autologyx Cross Platform views, giving users and external tools a read-only perspective of the underlying schema and data. This matters because it allows developers, integrators, and information security or analytics teams to query operational history safely without changing platform data, making Event History tables a controlled interface for downstream analytics, monitoring, and external database-based consumption.

Everyone ​

Everyone is a default User Group permission set in Autologyx that is created automatically for every user group and applies to all logged-in users in the system who are not members or owners of that group; it does not include 1 time completion users who do not log in. It is used in User Group Permissions and visibility configuration to control what non-group users can view and do with the group, alongside the Owners and Members permission sets. This matters because it defines the baseline access for users outside the group, helping configuration admins and Super Admins manage group visibility and interaction consistently without needing to add external users individually, while still allowing separate handling for users who need access through other permission arrangements.

execution queue ​

In Autologyx, the execution queue is the internal processing queue that schedules and runs each Actor as a separate work item within a sequence. It is most relevant when configuring sequences that include parallel branches, merge points, and Trigger logic, because branch evaluation happens independently and queued Actor execution determines the order in which downstream steps are picked up. This matters to configuration administrators and developers because queue timing can affect when a Trigger or merge-point Actor progresses, including scenarios where one branch reaches a checkpoint before another has completed, making correct use of Trigger Gates and related control patterns essential for reliable sequence design.

Exit preview button ​

The Exit preview button is a control in the Form builder preview experience for the Complete self-contained form task type that returns the user from preview mode to the Form builder editing interface. It is used by configuration administrators while creating or updating a response form, allowing them to leave the rendered form preview and resume designing or configuring the form without navigating away from the task template setup. This matters because it supports an efficient build-and-review workflow, letting administrators quickly switch between testing how the form will appear and making further configuration changes.

Expiry date ​

In Autologyx, Expiry date is the date value set on an Authentication Object to indicate when that authentication configuration expires. It is shown in the Authentication Objects list in the Administration tab, where administrators can review configured providers and their current status alongside related details such as usage and permissions. This field matters because it helps configuration and security administrators identify authentication objects with a defined end date, support governance and compliance oversight, and manage authentication settings in line with operational and access control requirements.

Expiry Date feature ​

The Expiry Date feature in Autologyx is a configuration option on Authentication Objects that lets administrators assign an expiry date to selected credential parameters, such as client secrets, when setting up or maintaining authentication. It is used wherever Authentication Objects are configured, including the Generic ROPC Authentication Object, and supports operational oversight by allowing users to filter Authentication Objects by expiry date. This helps Configuration Admins, Super Admins, and security or compliance teams identify credentials approaching expiry, plan renewals, and maintain uninterrupted authentication across platform integrations and automated processes.

expiry date filter for Authentication Objects ​

The expiry date filter for Authentication Objects is an Autologyx filtering capability that lets administrators view Authentication Objects according to their configured expiry date, helping teams identify credentials that are approaching expiration or already expired. It is used where Authentication Objects are managed, particularly for Generic ROPC Authentication Objects that support the ROPC flow, and complements the Expiry Date feature by making credential oversight operationally practical. This matters because it enables Configuration Admins, Super Admins, and security or compliance stakeholders to monitor renewal timelines, prevent authentication failures caused by expired credentials, and coordinate follow-up actions such as renewal workflows or automated notifications through the Sequencer.

expiry notification emails ​

Expiry notification emails are system-generated messages sent by the Autologyx platform to alert administrators that an Authentication Object is approaching or has reached its expiry point. Used as part of authentication configuration and authentication method management, these emails provide a clearer, more consistent prompt to review and update the affected Authentication Object before it disrupts sign-in or connected authentication processes. This matters to Configuration admins and Super Admins because timely action on these notifications helps maintain uninterrupted access, keeps authentication settings current, and supports secure, reliable platform operation.

expiry notifications ​

Expiry notifications are Autologyx platform alerts and related visibility features that highlight when configured items such as Authentication Objects are approaching their expiry date, so administrators can renew or update them before dependent processes are affected. Used in administration and configuration areas alongside usage panels, expiry notifications help Configuration Admins and Super Admins identify expiring credentials or integrations, understand where they are in use, and take action to avoid broken workflows, failed connections, and missed renewals.

Expiry rules ​

Expiry rules are the task lifecycle settings in Autologyx that define when a task expires and populate the task’s Expiry Date. They are configured on a task template in the Lifecycle tab, where the Expiry rules option becomes available when the template is set as a task that should expire, and the resulting expiry date is then shown to end-users in the Tasks list. Expiry rules matter because they control how long tasks remain active, support consistent lifecycle management across tasks created from the template, and give both configuration admins and end-users clear visibility of when a task is scheduled to expire.

expiry timeframe ​

In Autologyx, the expiry timeframe is a Task template setting used when a template is configured as a task that should expire, defining the period after which Tasks created from that template reach expiry. It is set in the Task template configuration by users with permission to edit Task templates, typically Configuration Admins and Super Admins, as part of the broader lifecycle and expiry design for a process. This setting matters because it controls how long generated Tasks remain active before expiry applies, helping administrators align task behaviour with operational deadlines and process rules. Changes to the expiry timeframe in Edit mode affect only Tasks created from the Task template after the template is saved.

External ​

External is an account type in the Autologyx platform used for people who are not employees and do not need additional platform permissions beyond the specific access provided to them. It is configured by administrators as part of user and permission setup, alongside other account types such as Internal, and is relevant wherever authentication requirements, access scope, and landing page behaviour are defined for a user. This distinction matters because it helps administrators give third parties or occasional participants the correct level of access without assigning broader permissions intended for internal staff, supporting a controlled and appropriate user experience across the platform.

External account type ​

External account type is a user account classification in the Autologyx platform for people outside your organisation, such as clients, suppliers, and other third parties. It is selected when creating or editing users in Administration and appears alongside other account types such as Internal, Config admin, and Super admin; external users receive an activation email when their account is created or when activation is sent later, and including a company name is useful for these accounts. This account type also affects platform access and behaviour: for example, the Records list tab is hidden for users with an External account type, and an existing Internal, External, Config admin, or Super admin account cannot be changed to the 1 time completion account type. This distinction matters because it helps administrators correctly identify third-party users, apply the right user setup, and control what those users can access in the workspace.

External Service account ​

An External Service account is a service account type in Autologyx used within a Catalyst build to support integrations with third-party systems and automated services, such as DocuSign webhook handling that updates envelope and signing statuses. It is created and listed in the platform as a user, with the account type shown as Service External, and each Catalyst build can contain up to five External Service accounts. Configuration admins, developers, integrators, and Super Admins use this account type when setting up non-human system access that requires specific class or record permissions to perform integration tasks. This matters because it provides a controlled way to authorize external services in the build while distinguishing them from Internal Service accounts and standard user accounts.

External type users ​

  • Mostly relevant to: End-users, Configuration admins, Super Admins
  • Closely related concepts: activity logs

INSUFFICIENT_EVIDENCE

External user type ​

External user type is a user classification in the Autologyx platform used to identify users who should be managed separately from internal users for administration and access-control purposes. It is configured by platform administrators and Super Admins when categorising user accounts, and is used alongside the Internal user type to provide more precise and flexible user management. This matters because assigning the correct user type helps structure how users are organised across the platform and supports clearer administration of access through related configuration such as user and permission management.

External users ​

External users are a user account type in the Autologyx platform designed for people outside the organisation, such as clients or partners, who need access to specific capabilities and content through permissions granted to their account. This account type is used in user management and in system configuration for authentication controls, where administrators can define which sign-in methods are allowed specifically for external users, separately from internal staff, Config Admin users, and accounts with full platform access. External users matter because they let organisations provide controlled access to third parties while enforcing distinct security and access policies for that audience, supporting clearer user administration and tighter separation between external and internal access models.

Failed ​

Failed is an Element status in the Autologyx platform that shows an error occurred while an Element was being downloaded. This status is used on the Elements list page and in Element management within Administration, where Configuration admins and Super Admins review the availability and installation state of Elements. It matters because it identifies that the Element has not completed download successfully and is therefore not ready to progress to later states such as Installed or Enabled, helping administrators pinpoint download issues and take corrective action before the Element can be used.

Failed files tab ​

The Failed files tab is part of the Autologyx file upload component and displays files that were not processed successfully during an upload. It is used within the upload interface as a dedicated view that lets users open a clear list of failed items and see the reason each file was rejected or could not be processed. This tab matters because it gives end-users immediate visibility of upload issues so they can correct and resubmit files, and it helps configuration admins validate that upload behaviour and file handling rules are working as expected.

FAQs ​

FAQs in the Autologyx platform are the Frequently Asked Questions provided within the Help and Support area to give end-users quick answers to common queries about using the platform. They are used as part of the in-product support experience, alongside general help content, so users can resolve routine issues, understand common tasks, and find guidance without leaving their workflow. FAQs matter because they provide a fast, self-service source of information that reduces the need to seek additional assistance and helps users work more efficiently in Autologyx.

feature enabled ​

field accessibility ​

Field accessibility in the Autologyx platform is the configuration of whether fields on a display form can be edited by end users or are presented as read only. It is used by configuration admins and Super Admins when designing and maintaining display forms, where field-level settings control how users can interact with specific data on a form. This matters because it allows form designers to enforce the intended user experience, protect important values from being changed, and ensure that users can view information that should not be updated while still allowing editing where appropriate.

field alias ​

A field alias in the Autologyx platform is the unique identifier assigned to a form field, used in configuration interfaces where the platform must distinguish one field from another even when multiple fields share the same label. It is used in places such as conditional logic setup, where the field selector displays the alias rather than the field label because aliases are unique and labels are not required to be. This matters to configuration admins because the alias provides a reliable way to reference the correct field when building and maintaining form behaviour, especially in configurations that depend on precise field selection through Field Properties and conditional logic.

field associations ​

Field associations are the links between a field and the Autologyx configuration items that use it, such as object classes and related data model components. In practice, they are encountered when managing fields in System Configuration, particularly when editing object classes or removing fields from the data model. Field associations matter because a field cannot be deleted while it is still associated with any configured item; those associations must be removed first to maintain the integrity of object records, task templates, and other configurations that depend on that field.

field based assignments ​

Field based assignments are a dynamic assignment option in Autologyx that use values held in record fields to determine which users or groups are assigned as assignees for record access or ownership. They are configured in the Record Access actor when setting up record ownership and record permission assignments, alongside direct user and user group assignees. Field based assignments matter because they let Configuration Admins and Super Admins drive access automatically from record data, so assignment rules adapt to each workflow instance without manual updates. In this configuration, the append option adds new field based assignments while keeping existing assignees, and the override option replaces existing assignees with the new field based assignment configuration.

field configurations ​

Field configurations are the administrative settings that define how a field behaves and is presented in Autologyx, including properties such as labels, aliases, and selection rules used to control data capture and user interaction within records and processes. They are used when configuring field types and options in the platform, and their details are also exposed in the Analytics Database so administrators and compliance or analytics teams can review how fields are defined and used across processes. Field configurations matter because they determine the consistency, usability, and governance of data entry in Autologyx, giving configuration admins and super admins precise control over what users can select or enter and supporting audit, reporting, and process optimisation.

field document id ​

In Autologyx, field document id is the Jinja2-accessible identifier for a document field on the current document context, exposed as doc.**field document id** and used in Document Templates and Sequencer logic when you need to read or pass the configured ID of a specific document field. It is referenced in template expressions and local variable assignments, such as when building namespace variables, mapping document metadata, or integrating template logic with downstream processing. This matters to configuration administrators and developers because it provides a stable, system-defined way to reference document field definitions in automation, helping ensure template logic, field mappings, and document-driven workflows remain consistent across records and document configurations.

Field from Document Picker ​

INSUFFICIENT_EVIDENCE

Field ID ​

Field ID is the unique identifier for a field in an Autologyx object class or document field definition, used to distinguish that field in platform configuration and technical integrations. In the Autologyx configuration experience, the Field ID is shown directly in the Class field list view so configuration administrators and super admins can quickly identify the exact field they are working with when reviewing or updating class fields in the configuration modal. It matters because it provides a stable reference point for developers and integrators when mapping fields, validating configuration, and using API calls that depend on the correct field being targeted.

field input types ​

Field input types are the configuration setting that determines how a form field is presented to users and how they enter or select data in Autologyx. Configuration admins use field input types when editing forms for object classes, including standalone forms, from the Forms tab and its elements, where they can change an existing field to use a different input method as part of designing the form layout and content. This matters because the selected input type controls the user experience for data capture on the form, helping admins align each field with the kind of information being collected and ensuring forms are structured appropriately for the process they support.

field level updates ​

Field level updates are changes recorded against specific fields on records in the Autologyx platform, capturing when a field’s value is modified as part of the platform’s historical event tracking. They are used within the History Events Database and surfaced through the Analytics Database alongside audit trails and permission changes, giving administrators and compliance-focused users a record of how data has changed over time at the individual field level. This matters because it supports detailed auditing, reporting, and operational analysis, helping configuration admins and super admins review record change activity, monitor the impact of configuration decisions, and meet governance and compliance requirements.

Field Options ​

Field Options are the configuration settings shown in the side panel when a field is selected on the form design canvas in Autologyx. Configuration admins use Field Options while creating or editing standalone forms to define how an individual field behaves and is presented within the form, alongside related form-building features such as components, elements, dropdown lists, and conditional visibility. This matters because Field Options are the control point for tailoring each field to the form’s design and user experience, ensuring the form captures the right information in the right way.

Field Properties ​

Field Properties are the standard configuration settings available for every field in Autologyx, used when creating or editing fields in forms and object classes. They define the core behaviour and presentation of a field, including required settings such as the field label and optional settings such as description text for user instructions and whether the field is required. Field Properties are accessed in field configuration areas such as the Add field workflow and object class field setup, and they are especially important when forms use conditional logic, because changing the properties of a field that participates in conditional visibility or acts as a controlling field can affect how that logic behaves. For configuration administrators and Super Admins, understanding Field Properties is essential to designing forms that display correctly, guide users clearly, and enforce the intended data-entry rules.

Field Summary ​

Field Summary is the read-only area in the response configuration for an Update object record task that lists the values and fields included on the form. In Autologyx, it is used by configuration admins when defining how object class fields are presented in a task, alongside the Fields section and form builder controls that allow supported field settings such as input type and required status to be adjusted. It matters because it provides a fixed overview of the configured field content, helping admins confirm which values are included in the task while distinguishing between information that is displayed for reference and settings that can be edited during form configuration.

field types ​

Field types are the data-type options used throughout Autologyx to define how information is captured, stored, displayed, sorted, and merged in forms, object classes, task templates, and document generation. Configuration admins select a field type when creating object class fields or response form fields to control the structure and behaviour of a field—for example text, integer, date, single select, email, phone, document, or user—and that choice determines which configuration options are available, how users enter data, and how the platform processes that value. Field types also affect downstream capabilities such as record sorting in ascending or descending order, merge field output and formatting in templates, and the consistency of data used in workflow automation and reporting. Choosing the correct field type is important because it ensures accurate data capture for end-users and reliable platform behaviour for configuration and automation.

Field Types And Formatting ​

Field Types And Formatting in the Autologyx platform describes the rules and options used to control how merge field values are interpreted and rendered when data is inserted into document templates. It is used within merge field configuration for document assembly, where administrators define how record properties and other data sources should be output as text, numbers, dates, images, or other supported formats, and where template authors apply the correct syntax in Document Templates and related Jinja expressions. This matters because the selected field type and formatting determine how information appears in generated documents, ensuring that content is displayed consistently, matches business and branding requirements, and produces accurate output for end-users.

field validation ​

Field validation in Autologyx is the configuration applied to a form field to restrict what values users can enter or select, such as limiting the permitted range for a Numeric field or constraining available options in single and multi select field types. It is used when configuring standalone fields, sections, and task templates, and it directly affects how conditional logic and Conditional Visibility behave because conditions can only be met by values that the field allows. This matters to configuration admins because changing validation on a field that is already referenced in conditional logic can make a condition impossible to satisfy; when this happens, the affected sections are highlighted in red so the configuration can be corrected by updating the validation, amending the condition, or removing the invalid condition.

Field value updated ​

Field value updated is an Activity log entry type in the Autologyx platform that records a change to a record field value. It is used in the record Activity log, including when an Update Record actor updates Object class fields within a sequence, so administrators, compliance teams, and analysts can see that a field was changed as part of platform processing. This matters because it provides a clear audit trail of data changes at record level, helping users trace automated updates, understand how a record was modified over time, and support monitoring, governance, and operational review.

field values ​

Field values are the current data held in Autologyx fields and are used as the inputs for conditional logic across the platform. In configuration, administrators use field values in Basic conditions, If / Else statements, and nested conditions to control whether specific content is shown or hidden in document templates and email bodies. For end-users, field values are the information entered or selected during work execution; for configuration admins, they are the data points that drive dynamic behaviour and content personalisation. Field values matter because they determine how templates and communications adapt to the data in a case, enabling rules-driven output that reflects the specific context of each process.

Fields ​

Fields are the configurable data-entry and data-display elements defined on an Object class in Autologyx and then used across forms, displays, document templates, and automation conditions. Configuration admins use the Fields area when setting up an Object class to create the information structure that other parts of the platform depend on, including Form layouts, Card view and other display views, and sequence conditions that reference Object class field values. In forms, fields can also control conditional logic to show or hide sections and other content based on user input, which makes them central to both user experience and process behavior. Fields matter because they determine what information can be captured, presented, reused, and acted on throughout the platform, and changes to fields can directly affect conditional logic, layouts, and configuration dependencies.

Show 1 more pages

Fields list ​

Fields list is the fixed tabular list of fields within an Object class in Autologyx, used in the Object class configuration area to view and manage that class’s fields. It is shown when creating and editing Object class fields, displays newly added fields at the top, and has five static columns with no column configuration options. Configuration admins and Super Admins use the Fields list to find a field, review updates such as label and identifier changes, and perform management actions such as removing a field from the Actions menu, subject to the required Object class edit permissions on the Data Model tab or equivalent ownership and admin rights. It matters because it is the primary control point for maintaining Object class fields, and changes made there are reflected across records, forms, display views, task experiences, and other places where those fields are used in the platform.

Fields section ​

In Autologyx, the Fields section is the area of the response form configuration panel where configuration admins add and configure form components for a task template. On the Create response form or task response configuration page, this section provides components for creating fields that are independent of the selected Object class, while related Object class fields are provided separately under Object Class Fields. Selecting a component from the Fields section lets an admin place it on the form canvas, set its label, and define its properties so the form captures the information users must enter when completing a task. This matters because the Fields section controls the structure and usability of the response form, allowing admins to design task-specific inputs alongside object-driven fields when configuring Update object record and similar task types.

Fields tab ​

The Fields tab is the section of an Object class edit page in Autologyx where administrators add, configure, and amend the fields used to capture data on records created from that Object class. It is used during Object class configuration alongside other edit tabs such as Display, Forms, and Document templates, and is primarily relevant to Configuration admins and Super Admins with permission to edit Object Classes. This tab matters because it defines the structure of data collected on Object records, directly shaping what information users can enter, how records are maintained, and how the Object class supports downstream forms, screens, and document generation.

File Download ​

file metadata ​

File metadata in the Autologyx platform is the structured information stored about a file, such as its identifying and descriptive properties, and is retrieved through the file metadata endpoint. It is used by developers and integrators when working with document and record data through the API, particularly alongside object records, record lists, and record details, to access file information without retrieving the file content itself. This matters because it supports efficient integration design, enables bulk retrieval of metadata for up to 50 files in a single request, and helps applications display, process, and manage files consistently within document-centric workflows.

file metadata endpoint ​

In Autologyx, the file metadata endpoint is an API endpoint used to retrieve metadata for files, providing a streamlined way for developers and integrators to access file information without retrieving the file content itself. It is used within document and records integrations alongside related APIs such as record details and record list endpoints, where file metadata supports processing, display, and downstream automation based on document and object record information. This endpoint matters because it simplifies how external systems obtain the descriptive attributes needed to identify, classify, and work with files in the platform, improving integration efficiency and enabling reliable use of document-related data across Autologyx solutions.

File parts ​

File parts are the file-type request parts used when configuring multipart data in the API Call actor on the Autologyx platform. They are defined within Multipart Configuration alongside text parts and are used to attach documents selected through a connected Document Picker so that files can be sent as part of an outbound multipart request. A file part includes the required Content Disposition for file transfer and works with the request’s multipart structure and content type settings. File parts matter because they enable integrations to send documents and other binary content correctly to external services, which is essential when building or configuring API-based document exchange workflows in Autologyx.

File upload ​

File upload is a task form field type in the Autologyx platform used to collect documents as part of completing a task. Configuration admins add it in the Form Builder alongside other field settings such as Label, Description, Default value, Conditional Visibility, form sections, and Input type to control how and where users provide files within a task form. This field matters because it enables structured document capture directly in workflow steps, ensuring the required files are gathered in the right place as part of task completion.

File upload component ​

The File upload component is a drag-and-drop Landing Page component in Autologyx Catalyst 1.13 that lets end-users upload files directly into a workflow, including the ability to upload a ZIP file and automatically generate multiple records so that each contained file becomes a document attached to a new record. It is used when designing or using Landing Pages that need to capture large volumes of documents as part of intake or case-related processes, and it integrates with Catalyst’s wider automation framework so uploaded content can immediately feed downstream workflow actions. This matters to both end-users and configuration admins because it simplifies high-volume document intake, reduces manual record creation, and supports faster, more scalable process execution.

File upload field ​

A File upload field is a response form field type in Autologyx that lets end-users attach files as part of completing a task. It is used when configuring task templates, particularly for task types that use a complete self-contained form, where administrators add the field to capture supporting documents or other required attachments directly within the task response. In the task template editor, configuration admins can control how many files the field accepts, up to a maximum of 10, alongside other field settings such as descriptions and required status. This field matters because it enables document collection within the workflow itself, ensuring tasks gather the files needed to progress, review, or complete a process without requiring separate submission steps.

Files section ​

The Files section is a configuration area in the Parameters panel of supported API Call actors in Autologyx where you attach documents from the sequence to an outbound request. It is used when an API Call actor is configured for Form Data and, after a Document Picker, also for Multipart Data or Binary Data, allowing the actor to include one or more selected documents as file inputs in the request payload. This section matters because it is the platform’s standard mechanism for mapping sequence documents into integrations, enabling admins and developers to pass generated or selected files to external services accurately and efficiently as part of document-driven workflows.

filter by User Groups ​

Filter by User Groups is a task-list filtering option in the Autologyx platform that lets users narrow the tasks displayed to those associated with selected User Groups. It is used wherever task filtering is available, particularly in Task Lists that include tasks assigned through User Groups as task assignees, and it complements other task-based filters such as individual assignees and views like Tasks I’m Only an Assignee Of. This matters because it gives end users a faster way to find the work relevant to specific teams or operational groups, and it helps configuration admins validate and support task assignment models that rely on group-based ownership and routing.

Filter conditions ​

Filter conditions are the individual criteria defined in the list page filter editor to control which rows are shown on Autologyx list pages. Each condition targets a field and operator combination, such as filtering by who created an item, and all configured conditions must be satisfied for a row to appear in the filtered results. Filter conditions are used by end-users to narrow large lists to relevant items and by configuration admins when designing or supporting list-based workflows. They matter because they provide precise, repeatable control over list views, helping users quickly find the correct records, refine results by adding more conditions, remove individual conditions when no longer needed, or clear the full set of conditions with Remove all.

Filter editor ​

The Filter editor is the list page control used in Autologyx to create and apply filters that limit which records are shown in a page’s results. It is used on list pages as part of the page controls and is also surfaced in configuration contexts such as editing a User Group, where filter criteria can define the set of items users see or work with. The Filter editor matters because it helps end-users focus on the right records and enables configuration admins to shape targeted, role-appropriate views that support efficient navigation, reporting, and operational control across the platform.

Filtered results control ​

The Filtered results control is a user interface control shown at the end of the page navigation on Autologyx list pages, including the Records list, and is used to access the list page filter editor. When the filter panel is closed, selecting this control opens it so users can view and adjust the filters currently affecting the records displayed. This matters because it provides a direct, visible entry point to filter management from the list view itself, helping users understand why a list shows a particular set of results and quickly refine what is displayed without leaving the page.

filters ​

Filters, also referred to as merge field filters, are formatting functions used in Autologyx document templating to control how a merge field’s value is rendered in output. They are used in Document Templates by appending a pipe character followed by the filter name to a merge field, allowing configuration admins and template authors to format values from supported field types such as DateTime and other merge field outputs when generating documents. Filters matter because they let you present data in the required output format without changing the underlying field value, helping ensure document content is readable, consistent, and appropriate for its intended use.

filters in the merge field ​

In Autologyx, filters in the merge field are formatting instructions added directly to a merge field expression to control how merged content is rendered in generated documents. They are used when configuring document templates, including image merge fields, where they enable administrators to set output properties such as image width and height as the document is produced. This matters because filters let configuration admins fine-tune document output within the merge field itself, helping ensure generated documents display embedded content in the required size and format without changing the underlying source data.

Finding your way around ​

Finding your way around is a navigation-focused documentation area in the Autologyx Catalyst Knowledgebase for end users. It is used from the Knowledgebase index alongside sections such as Welcome & Introduction to Catalyst, Workspace, and Using Help and Support, and provides guidance on moving through the platform, following links, and locating the main areas and resources available to users. This matters because it helps users orient themselves quickly in Catalyst, understand how the documentation and platform structure fit together, and complete everyday work more efficiently by knowing where to go for the next step, related features, and supporting information.

fly in toast confirmation message ​

In Autologyx, a fly in toast confirmation message is a transient on-screen notification that slides into view after a user completes an action and confirms that the requested change has been applied. It is used in the platform’s administrative and end-user interfaces following actions such as updating User group membership from the Actions menu, including adding members, promoting owners, demoting members, or removing users. This message matters because it provides immediate feedback that an operation has succeeded, helping users verify that their changes were processed without needing to navigate away or manually recheck the page state.

fly out ​

In Autologyx, a fly out (or flyout) is the side panel used to open an associated child record from its parent record without leaving the current context. End-users encounter it when working with relational records, typically by double-clicking a child record or selecting Open from the Actions menu. The child record is displayed in the create/edit view configured for that object class, allowing the user to review or update it while keeping the parent record available in the background. This matters because it supports efficient navigation of parent/child relationships, lets users work with related records in context, and provides a clear way to return to the parent record using the close control in the top-left of the fly out.

fly out modal ​

In the Autologyx platform, a fly out modal, also referred to as a child modal, fly out, or modal page, is an overlay form that opens the create/edit record display for a related child object class from within a parent record, typically when a user selects the Create record button in a relational records component. It is used during parent-child record workflows to let end-users create or update child records, including deeper related records such as grandchildren, without leaving the current parent record page, and it does not have its own URL. This matters because it keeps users in context while maintaining the relationship between parent and child records, supports efficient record creation from child record summaries and related components, and is an important behaviour for configuration admins to understand when designing create/edit record display forms and relational record interactions.

flyout ​

In the Autologyx platform, a flyout is an overlay panel that opens from the current workspace view to display a record in its create or edit view without navigating away from the parent context. It is used in relational record workflows, such as when a user double-clicks a child record row in a child class component and the selected child record opens as a flyout for viewing or updating. Flyouts matter because they let end-users work with child records while keeping the parent record and child record summary visible, and they help configuration admins design efficient record interaction patterns that reduce context switching and support faster related-record management.

For or Group Statements ​

INSUFFICIENT_EVIDENCE

Force unique value ​

Force unique value is an Object class field attribute in Autologyx that enforces uniqueness for a field across all Records in that Object class, preventing any two Records from storing the same value in that field. It is configured in System Configuration when defining supported field types such as Text, Integer, Decimal, Email, and Phone, and is used on Record forms and views wherever that field is captured or edited. This setting matters to configuration admins and Super Admins because it protects data integrity, supports reliable use of identifiers and reference values, and works alongside duplicate-value handling to stop conflicting entries from being created in the same Object class.

Forgot Your Password ​

Forgot Your Password is the login-page link used to start the password reset process for a standard Autologyx user account. It is relevant wherever users sign in with an Autologyx-managed username and password, and is referenced in user administration guidance alongside account management, single sign on, service accounts, and 1 time completion users. This function matters because it provides the supported recovery path when an end-user cannot access their account credentials, helping restore access without manual intervention and informing administrators which account types and authentication methods use password reset versus alternative sign-in flows such as single sign on.

Form builder ​

The Form Builder is the Autologyx design workspace used to create and configure record forms and task response forms, including complete self-contained forms and update-object-record responses. It provides a central canvas for arranging components and fields, with supporting configuration panels and side-stack components to define layout, instructions, record properties, class fields, child object content, and conditional visibility. Configuration admins and Super Admins access it from areas such as Object class display configuration and the Response configuration tab by selecting Create response form. The Form Builder matters because it controls how users capture, view, and complete information in records and tasks, directly shaping data quality, usability, and the overall structure of end-user interactions across the platform.

Show 4 more pages

form canvas ​

In Autologyx, the form canvas is the central workspace in the Create and edit view where configuration admins build record and task forms by placing components onto the form layout. It works alongside the side panels, which list available Properties and other form elements; when a Property has been added to the form canvas, it is shown as greyed out in the side panel to indicate it is already in use on that form. The form canvas matters because it is where the visible structure and content of a form are defined, directly controlling how users interact with records and tasks in the platform.

Form colours ​

Form colours are the theme settings in Autologyx that control the colours used within forms, specifically the create/view Object record form, the standalone form used to create Object records, and Task forms. They are configured on the Configure Theme page, in the Colours tab, where administrators define form-specific colour values such as the Section content background using colour control fields alongside core and additional colour settings. Form colours matter because they determine the visual presentation and readability of form-based user interfaces across the platform, helping configuration and super administrators deliver a consistent, branded, and usable experience for users completing records and tasks.

Form Data ​

Form Data is a request body option in the Autologyx API Call actor used to send simple key/value pairs to an external API as form fields rather than as JSON, XML, or raw binary content. It is configured in the actor’s Data Type setting and is used when an integration endpoint expects standard form-style parameters; in newer document-handling scenarios, the configuration also exposes a Files section under Parameters so file inputs can be included when needed. This matters to configuration admins and developers because selecting Form Data determines how Autologyx serialises outbound request data, which directly affects compatibility with the target service, the correct handling of parameters and files, and the overall success of API-based workflow integrations.

form sections ​

Formbuilder ​

  • Mostly relevant to: Configuration admins, Developers / Integrators
  • Closely related concepts: Elements, Column ratios

Formbuilder is the Autologyx form design tool used to create and structure record and task forms by adding components from its side panel, including layout components such as Sections and Instructions. It is used when configuring how users capture, view, and organise information in the platform, with all components placed within sections and layout controlled through options such as column ratios. Formbuilder also acts as the delivery surface for custom HTML components built as Elements, allowing organisations to extend the platform within their own domain environment. This matters to configuration administrators and developers because Formbuilder is the primary interface for shaping form behaviour, layout, and extensibility in Autologyx.

Formbuilder Components ​

Formbuilder Components are the building blocks available in the Autologyx Form Builder for creating Record and Task Forms. Used by configuration admins and Super Admins when designing data-entry experiences, these components define the elements and structures that make up a form, working alongside related features such as Formbuilder Properties, Conditional Logic in Forms, layout sections and instructions, and task form fields. Understanding Formbuilder Components matters because they provide the foundation for how information is presented, captured, and organised in forms across the platform, making them the starting point for effective form configuration and form design in Autologyx.

Formbuilder Properties ​

Formbuilder Properties are the configurable settings applied to components in the Autologyx Form Builder that define how each form element is presented and behaves. Used when designing record and task forms, these properties control aspects such as layout, field behaviour, and user interaction, working alongside components, elements, sections, and conditional logic to shape the finished form experience. For Configuration Admins and Super Admins, Formbuilder Properties matter because they are the mechanism for tailoring forms to business needs, ensuring forms are structured correctly, function as intended, and provide a clear and effective experience for end users.

forms ​

In Autologyx, forms are the user-facing layouts where configured elements are presented for data capture, display, and interaction within tasks and record experiences on the platform. Forms are used by configuration and super admins when designing how information should appear and behave, and by end-users when completing work, entering values, and viewing related data. They matter because the form is the point where element configuration is realised in practice: field types such as JSON fields can be included on forms, and child object classes created through Autologyx Catalyst relational modelling can be added to record forms, enabling structured, integrated data management and a streamlined user experience.

forms across the Autologyx platform ​

INSUFFICIENT_EVIDENCE

Forms in use ​

Forms in use are standalone form definitions that are already being used by active items in the Autologyx platform. In the context of editing a standalone form from the Forms list or Forms tab under object class configuration, this distinction matters because saved design changes do not affect forms that are already in use; those existing items continue with the version of the form already associated with them. For configuration admins, understanding whether a form is in use is important when updating elements or structure, because it determines the operational impact of changes and helps preserve stability for live work while allowing future items to use the updated form definition.

Forms list ​

The Forms list is the page in the Autologyx Forms tab that displays configured standalone forms and their current status, providing the central place for Configuration Admins and Super Admins to return to after creating or editing a form and to open an existing form for further maintenance. In the context of object class configuration, it serves as the management view for standalone forms, where administrators can identify forms, see statuses such as Disabled, and select a form link to continue configuration. This matters because it is the primary navigation and oversight point for managing standalone forms, helping administrators track form availability and access the correct form definitions during setup and ongoing maintenance.

Forms tab ​

The Forms tab is the section within an object class configuration in Autologyx where configuration administrators and Super Admins create, view, and edit standalone forms used specifically for record creation. It is accessed by opening the relevant object class and selecting Forms, which displays the Forms list and provides actions such as creating a form, previewing it, returning to the list, and editing its name, layout, sections, fields, conditional logic, instructions, and field properties. This tab matters because it is the control point for designing record-creation experiences, including forms that can be used from outside the system, and it determines how users capture the data required to create records correctly and consistently for that object class.

From email address ​

From email address is the mandatory outbound mail configuration field in Autologyx that specifies the mailbox account email address used as the sender on all emails sent from the platform. It is configured in Outbound mail setup alongside the mail service, host, port, authentication, and TLS settings, and it is applied to outgoing platform communications as the visible From address on messages. This setting matters because it determines the sender identity recipients see, must align with the mailbox account used for sending, and is a core part of ensuring outbound email is configured correctly for operational communications from the platform.

From Relation lookup ​

From Relation lookup is a Record field option in the Sequence Runner actor that is used when the Sequence Runner is connected from a Relation Lookup actor. In this configuration, it tells the Sequence Runner to operate on the records returned by the relation lookup rather than on the current record itself. This option is used in sequences for relational records, including scenarios involving child records and Child Object Classes, and works alongside any supplementary conditions defined in the lookup path. It matters because it determines the record context passed into the sequence, ensuring that downstream actions run against the correct related records when configuring multi-record or parent-child process automation in Autologyx.

full account ​

In the Autologyx platform, a full account is a newly created user account type that triggers the standard user activation process. When a user is created with a full account, Autologyx sends an activation email containing an activation link, which takes the user into the account activation journey through the Activate your user account page and, where applicable, the Standard authentication page. This term is primarily relevant when configuring user activation rules, because those rules control the activation experience presented to users created with this account type and ensure they can complete access setup correctly.

Full API Configuration in Sequencer ​

Full API Configuration in Sequencer is the capability within the OpenAI: GPT actor in Autologyx Sequencer that exposes the full set of configurable request options so the actor can be set up to mirror the underlying API functionality. It is used when configuration admins, developers, and integrators need precise control over how a GPT-powered step behaves in a Sequencer workflow, rather than relying only on simplified defaults. This matters because it enables more exact alignment between workflow design and the external AI service configuration, supporting advanced prompt setup, model version selection, and other actor-level settings required to tailor behaviour for specific automation use cases.

function Statements ​

In Autologyx, function Statements are template-level expressions used within Document Templates to control or generate document content beyond standard merge fields, including constructs such as IF Statements and other embedded functions. They are used when editing a document template, typically by downloading the template file and adding or amending these statements alongside merge fields, document text, layout, and formatting. Function Statements matter because they enable configuration administrators and Super Admins to create dynamic, rules-driven documents that adapt content automatically, supporting more precise document generation as part of system configuration.

functions ​

In Autologyx, functions are built-in options available in the Catalyst Word Add-in that help users work with document content more efficiently during document creation. They are used alongside items such as merge fields and class fields within the add-in, where each function is presented with clear guidance to support consistent use. Functions matter because they make document assembly more user friendly, help users apply the correct document behaviour at the point of authoring, and streamline the production of accurate, structured documents within the platform.

Gate Variables ​

Gate Variables are Local Variables used in an Autologyx Sequence to control progression through parallel or branching logic by acting as a simple state flag that is set, checked, and recalculated as processing advances. They are configured by sequence designers and integrators, typically initialized early in a Sequence and then updated by later actors, including Local Variable actors and logic that coordinates Trigger Gates, merge patterns, or completion checks such as an all completed flag. Gate Variables matter because they provide a clear, maintainable way to synchronise branches, avoid invalid actor execution and race conditions, and ensure that downstream actors run only when the required sequence state has been reached.

Generate and download document ​

Generate and download document is a manual document-generation action in Autologyx that creates a document from a selected template for the current record and immediately downloads it to the user. It is used from the template’s Actions menu when working with document templates for a record, alongside other manual generation options such as Generate and save to field. This option matters because it lets end users produce a document on demand without storing it back into the record, while giving configuration administrators a clear output path to support user-driven document production from the Templates tab and related record-based processes.

Generate and save to field ​

Generate and save to field is a manual document generation option in Autologyx that creates a document from a template and stores the result directly in a selected Document type field on the current object class record. It is used when manually generating a document from the Templates tab, where the user is shown the Document type fields available on the object class and chooses the field that will hold the generated file. This matters because it controls where the generated document is persisted in the platform, ensuring the output is saved against the correct record field for later access, downstream processing, and configuration of document-driven workflows.

generated documents ​

In Autologyx, generated documents are files produced automatically by document generation processes that apply Document Templates and merge fields to data held in a record, then save the resulting output back to a designated field on the corresponding record for storage, access, and downstream use. They are used in end-user document production, in configuration of template-driven automation such as image merge fields and document type merge fields, and in integrations where the generated file must be passed through API calls, including as a base64 payload for services such as DocuSign. Generated documents matter because they provide the definitive output of automated document creation in the platform, linking record data, template configuration, and external delivery or signing workflows into a single managed document lifecycle.

Generic oAuth 2.0 (Client Credentials flow) ​

Generic oAuth 2.0 (Client Credentials flow) is an Authentication object provider in Autologyx used to connect the platform to external services that support the OAuth 2.0 client credentials grant. It is configured in the Authentication objects area by administrators or integrators who supply the provider-specific technical details required to obtain and use an access token for system-to-system authentication. This provider is used when Autologyx needs to make API calls to a third-party service without an interactive user sign-in, and it matters because it enables secure, reusable authentication for integrations, API-driven actions, and service accounts across providers that are not covered by a dedicated built-in authentication type.

Generic oAuth 2.0 (ROPC Grant flow) ​

Generic oAuth 2.0 (ROPC Grant flow) is a supported Authentication object provider in the Autologyx platform that enables Autologyx to authenticate to an external service using the OAuth 2.0 Resource Owner Password Credentials grant. It is used when configuring an Authentication object in Administration, alongside other provider types, so that API calls from workflows or integrations can connect to services that require this authentication method. This matters to configuration admins, developers, and super admins because selecting the correct provider type and supplying the required provider-specific technical details is essential for establishing successful connections, enabling dependent integrations, and ensuring platform features that rely on external authenticated access operate correctly.

Generic OAuth 2.0 template ​

The Generic OAuth 2.0 template is an Authentication Object template in the Autologyx platform that is used to configure OAuth 2.0 client-credentials authentication for connections to external services, including providers that do not have a dedicated built-in template. It is used by configuration admins and developers or integrators when setting up integrations in Autologyx Catalyst, where they define values such as the Token URL, Client ID, Client Secret, and any Additional Authorization Headers or Additional Parameters, and can validate the setup with the built in testing feature. This template matters because it provides a standard, reusable way to authenticate securely with virtually any compatible provider, reducing custom integration effort and allowing Autologyx components to obtain access tokens consistently for downstream service calls.

Generic ROPC Authentication Object ​

A Generic ROPC Authentication Object is an Autologyx Authentication Object used to configure Resource Owner Password Credentials (ROPC) authentication for integrations that obtain an access token by sending a username and password directly to a token endpoint. It is used in platform configuration where administrators or integrators need to connect Autologyx to external services using this authentication pattern, with required settings such as Token URL, Username, and Password, and optional settings including Refresh Token URL, Client ID, Client Secret, and Scope. This object matters because it provides a standard, configurable way to manage token-based access for supported providers, and when used with the Expiry Date feature on Authentication Objects, it also helps control authentication lifecycle and maintain reliable access management across integrations.

Get request API call ​

A Get request API call in Autologyx is an API operation that retrieves data or files from an external system so they can be used within a workflow. In platform configuration, it is used as a source for content that other components can consume, such as the Document Picker actor, which can work with documents captured through a Get request API call in the same way it works with content from DocAuto processing or a Record field. This matters to configuration admins and integrators because a correctly configured Get request API call enables the platform to fetch external documents, templates, or metadata for downstream actions, and it determines how that retrieved content is made available to related elements such as API Call documents, Document Fields, and the Files section.

Git repository ​

A Git repository in the Autologyx platform is the source-controlled storage location that holds configuration files used to define and customise platform components, including files such as config.json and ccs files for Elements. It is used by developers and configuration administrators when updating how an Element looks or behaves, with changes made in the repository rather than directly in the platform interface. This matters because the repository is the authoritative location for maintaining, versioning, and deploying configuration changes that support consistent and controlled updates across the Catalyst system.

Git repository token ​

A Git repository token is the access token entered in the Catalyst system’s Git repository token field to authenticate Autologyx to a source code repository when working with Element projects. It is used alongside the Git repository URL and Git repository username in Administration for Elements, particularly during import and setup of an Element, and it must be copied into Catalyst as soon as it is created because it is only shown once by the source control provider. This token matters because it enables the platform to securely connect to the repository and retrieve the Element project content needed for configuration and deployment.

Git repository URL ​

Git repository URL is the HTTPS clone address of the source control repository that stores an Element project’s required files, including its configuration files such as config.json, for use in the Autologyx platform. It is entered when creating or importing an Element in Administration so the Catalyst system can connect to the correct repository and retrieve the Element’s package from Git. This setting matters because it defines the exact repository Autologyx uses as the source of the Element, and it must be provided together with the appropriate Git repository username and token where access-controlled repositories are used.

Git repository username ​

Git repository username is the credential value entered in the Catalyst system when configuring access to the Git repository that stores an Element project. In Autologyx, this field is used together with the Git repository token and Git repository URL in Element configuration so the platform can authenticate to the source repository. For token-based access, the Git repository username is set to the access token’s Token name, as provided in the repository service. This setting matters because Autologyx uses it to connect to the repository that contains Element code and related assets, enabling the platform to retrieve and manage the content required for Element deployment and maintenance.

Give access button ​

The Give access button is a control on the Record access tab of an object record that opens the Add people function so a user can grant record access to other users. It is used when managing who can work on a record, including adding Owners or Assignees in line with the record’s access configuration and any applicable Record Permission Sets. This button matters because it is the entry point for updating the Owner/Assignees list on a record, which directly affects who can see the record in their workspace and take action on it; when access is granted, the platform confirms the change with a success toast message.

Glossary ​

grand child ​

In the Autologyx platform, a grand child record is a relational record that sits one level below a child record in an object-class hierarchy, making it the second-level record beneath the root parent. Grand child records are used in relational models where a parent record contains child records and those child records contain their own related records, such as an Employee Management (HR) parent with a child and one grand child beneath it. Users encounter grand child records when creating, viewing, or filtering related records from a parent context, and administrators define them through object class relationships and child components. Understanding grand child records is important because it determines how related data is structured, how users navigate between records using summaries and breadcrumbs, and how records are found and managed across parent, child, and deeper relational levels.

granted permissions ​

Granted permissions are the access rights assigned to an end user or role in Autologyx that control what actions can be performed on records and what record data can be viewed. In areas that present related or child records—such as configurations built with the Relational modeller, child record components, and the Child Record Summary side tab panel—these permissions are enforced alongside the defined record relationships to determine whether users can add related records, open record details, or access protected data. This matters because the user experience and the visibility of related information in the platform depend on granted permissions, making them a key part of both secure solution design for configuration admins and day-to-day access for end users.

green success toast ​

In the Autologyx platform, a green success toast is the transient on-screen confirmation message that appears after a user completes an action successfully, such as creating a document template. It is used in the user interface during interactive tasks, including within the Document Templates area, to immediately confirm that the requested operation has been completed without requiring the user to navigate away or manually verify the result first. This matters to both end-users and configuration administrators because it provides clear, immediate feedback that a change has been accepted by the platform, helping them continue their workflow confidently and distinguish successful actions from tasks that still require attention.

green success toast message ​

In the Autologyx platform, a green success toast message is the on-screen confirmation notification shown after a user completes an action successfully, such as adding a user to a permission set or saving a task group template. It is used throughout the interface at the point where changes are submitted, providing immediate visual feedback that the requested update has been processed and accepted. This matters to end-users, configuration admins, and Super Admins because it confirms that a configuration or administrative action has been completed without requiring them to navigate away from the current page, helping them proceed confidently with related tasks such as managing permission sets, default user group permissions, or assignees.

green toast message ​

group access ​

Group access is the Autologyx permission area that controls which user groups a person can work with in the platform, and it is configured through custom permission sets as part of User Group Permissions. It is used by Configuration Admins and Super Admins when defining access models for roles, teams, or administrative users, alongside related controls such as group permission sets, group visibility, and group selection. Group access matters because it determines the scope of groups available to a user within the platform, helping administrators enforce the intended operating boundaries for different users and align group-based access with organisational and process requirements.

group based actions ​

Group based actions are actions in Autologyx that are attributed or analysed in relation to a user’s group membership rather than only the individual user account. This concept is used in platform reporting and data analysis, particularly through the Analytics Database and related history data such as User Groups, audit trails, and object record history, to identify activity patterns performed by members of specific groups. Group based actions matter because they help super admins, configuration admins, and compliance or security teams understand how access models and group assignments influence platform activity, making it easier to review operational behaviour, support governance, and investigate actions associated with particular teams or roles.

group based assignment ​

Group based assignment in Autologyx is the capability to assign groups, as well as individual users, within Group Permission Sets so that access and permissions can be managed collectively rather than user by user. It is used when configuring User Group Permissions, where administrators define which users or groups are included in a permission set and therefore inherit the associated group access, visibility, and ownership rules. This matters because it lets Configuration Admins and Super Admins scale administration more efficiently, apply permission changes consistently across teams, and simplify the ongoing management of members, nested group structures, and default or custom permission set design.

Group Field ​

A Group Field is a merge field type in Autologyx that returns a list of groups associated with the referenced field and is used in merge field expressions when configuring document templates and other generated outputs. In the Field Types and Formatting context, it is referenced with the field alias in the merge expression and outputs group data as a list of groups, making it distinct from a User Field, which returns user objects, and from scalar field types such as Set, Enum, JSON, or DateTime. This matters to Configuration Admins and Super Admins because selecting the correct field type determines what data is exposed to templates and formatting logic, ensuring group-based information is inserted and rendered correctly in platform-generated documents and content.

group IDs ​

Group IDs are the unique identifiers for User Groups in the Autologyx platform, used primarily in API requests that manage access control, especially when assigning or unassigning User Groups in Record Permission Sets. In practice, integrators and administrators include a list of user group IDs in the request payload to specify exactly which groups should be added to or removed from a permission set. Group IDs matter because they provide the precise, system-recognised reference needed to automate and control group-based permissions reliably, ensuring that access is granted or revoked for the correct User Groups within platform security configurations.

group owners ​

Group owners are users assigned ownership of a user group in Autologyx and, within that group, they automatically have comprehensive access to all group actions. This role is used in the platform’s user group permissions model, alongside members, Everyone, and configured permission sets, to control who can manage and act within a group. For Configuration admins and Super Admins, group ownership matters because it provides built-in full access at the group level without relying on custom or default permission sets, making it a key mechanism for delegating administration and ensuring the right users can manage group activity and access.

group permission sets ​

Group permission sets are the membership definitions used in Autologyx user group permissions to control which users and groups are granted permissions for a specific group. Used by Configuration admins and Super Admins when configuring group access, visibility, ownership, selection, and group-based assignment behaviour, a group permission set can include both individual users and other groups, allowing administrators to manage access through nested group structures rather than maintaining permissions user by user. This matters because it provides a scalable way to administer group-related permissions, align access with organisational structures, and simplify ongoing maintenance of security and operational configuration across the platform.

group selection ​

INSUFFICIENT_EVIDENCE

group tile ​

In Autologyx, a group tile, also described as a standard tile, is the visual entry used in the User Groups tab to represent a User Group that has been added to a Class Permission Set. It is used by configuration and platform administrators when managing group assignments within the group-based permission system, providing a clear, actionable view of which User Groups are associated with a permission configuration. This matters because the group tile is the interface element through which administrators confirm and work with assigned groups in Class Permission Sets, helping ensure that access and permissions are organised and applied to the correct user populations.

group visibility ​

Group visibility in the Autologyx platform is the configuration that controls which users can see a user group and its members, and is managed through User Group Permissions. It is used by Configuration Admins and Super Admins when defining group access through default or custom permission sets, alongside related settings such as group owners, Members, and Everyone. Group visibility matters because it determines how groups are exposed across the platform, supports precise access control for different audiences, and enables administrators to tailor collaboration and administration within each group to meet organisational requirements.

group-based permission system ​

In Autologyx, the group-based permission system is the approach for managing access by assigning permissions to User Groups instead of configuring individual users one at a time. It is used in Class Permission Sets, where configuration administrators and Super Admins can apply view and other class-level permissions to groups in a single action, then have those permissions apply consistently to all users in the group. This matters because it simplifies permission administration, reduces repetitive manual setup, and provides a scalable way to manage access as teams and organisational structures grow.

Group/Ungroup ​

Group/Ungroup is a design-time feature in the Autologyx workflow editor that lets configuration admins select multiple workflow objects on the canvas and combine them into a named group, or remove that grouping when it is no longer needed. It is used while editing Sequences in system configuration, where users can drag across several objects to select them, choose Group to create and name the group in the modal, and choose Ungroup to dissolve it. This matters because grouping helps organise complex workflow designs, makes related objects easier to manage together in the editor, and improves clarity when building or maintaining process navigation and menu behaviour.

Groups as Task Assignees ​

Groups as Task Assignees is an Autologyx task assignment capability that allows tasks in a workflow to be assigned to an entire User Group instead of only to individual users. It is used when designing, configuring, and operating group-based workflows so that work can be routed faster and managed at team level, particularly where responsibility sits with a shared function rather than a named person. This matters because it simplifies task management, reduces the need to maintain individual assignee lists, and helps administrators and users distribute work consistently across the appropriate group within the platform.

Groups in Class Permission Sets ​

Groups in User Type Class Fields ​

INSUFFICIENT_EVIDENCE

Groups in User Type Fields ​

INSUFFICIENT_EVIDENCE

Guard Clauses ​

Guard Clauses are conditional checks used in Autologyx merge fields, Jinja2 expressions, and document templates to ensure a value, indexed item, related record, child record, or local variable exists before it is referenced. Commonly implemented as an IF statement wrapped around a merge field, guard clauses are especially important when accessing indexed data because records are not always present at document generation time. Also known as existing checking or null checking, they are used in document template configuration and variable logic to prevent errors, avoid blank or invalid output, and make template behaviour reliable when working with document fields and dynamic record structures.

Headers ​

Headers, also called Header Parameters, are the name–value pairs configured in an Autologyx API Call actor to send additional information with an HTTP request, such as content type and authentication-related metadata. They are set as part of API call configuration, where administrators and integrators add, edit, or remove individual headers and can populate values dynamically using Merge fields and Jinja expressions. Headers matter because they control how external services interpret the request and are often required for successful integration, including identifying the request format, supplying access credentials, and passing other service-specific parameters.

Help and Support ​

  • Mostly relevant to: End-users
  • Closely related concepts: FAQs

Help and Support is the area of the Autologyx platform documentation and user guidance that provides users with assistance on how to use the platform, including access to FAQs and other support resources. It is used by end-users when they need practical guidance, answers to common questions, or direction on where to get help while working in Autologyx. Help and Support matters because it enables users to resolve issues more quickly, understand platform features and processes, and continue their work with less disruption.

hidden properties ​

Hidden properties are user object properties in Autologyx merge fields that are not included in the default returned user data and must be requested explicitly when you need them. They are used in the Users and Groups merge field context, including document templates, Sequencer actors such as API Call, Send Message, and Local Variable, related records merge fields, and other supported merge field contexts. Hidden properties matter because they let configuration admins and developers control exactly which user data is exposed and consumed in templates, integrations, and workflow logic, supporting more precise data access and cleaner field handling when working with user and group objects.

hierarchical record creation endpoint ​

A hierarchical record creation endpoint is an Autologyx API endpoint that lets developers create an entire parent-child record structure in a single request by submitting a hierarchical payload that specifies each record’s object class, class fields, and any nested child records. It is used in integration and automation scenarios where external systems need to create related records together rather than issuing multiple API calls and manually managing relationships between them. This endpoint matters because it simplifies implementation, preserves the intended hierarchy from the moment records are created, reduces request overhead, and supports cleaner orchestration of downstream processing and status tracking, including use alongside transaction status links and asynchronous processing status patterns.

Hierarchical Records ​

hierarchical records creation endpoints ​

Hierarchical records creation endpoints are Autologyx API endpoints that let developers create a parent record together with its related child records and relationship links in a single request. Used in API-driven integrations, these endpoints simplify the creation of structured, related data within the platform by removing the need to sequence multiple record-creation calls and manually connect the results afterward. This matters when configuring or building integrations that need to load complex business objects efficiently, because it reduces implementation complexity, lowers request volume, and helps ensure that related records are created together as one coordinated operation.

history database ​

history database backup solution ​

  • Mostly relevant to: Super Admins, Information Security / Compliance / Analytics
  • Closely related concepts: Catalyst

In Autologyx Catalyst, the history database backup solution is the platform capability that creates protected backups of historical database content to provide an additional layer of data security and resilience. It is relevant to the Catalyst environment and is most important to Super Admins and information security, compliance, and analytics stakeholders who are responsible for platform protection, retention, and recovery planning. This matters because historical data underpins auditability, reporting, and long-term operational analysis, and a backup solution helps ensure that this information remains recoverable and safeguarded as part of the overall platform security posture.

History Events Database ​

The History Events Database, also referred to as the History Database, is the Autologyx data store for historical event tracking across the platform. It is used within the Analytics Database capability to provide time-based insight into audit trails, permission changes, field-level updates, object record history, user activity, and user group actions. By combining current operational data from the Resource Database with historical event data from the History Events Database, Autologyx delivers a unified foundation for analytics, compliance reporting, and security review. This matters to super admins, developers, integrators, and compliance-focused teams because it enables them to audit change over time, validate access control configuration, trace who performed specific actions, and analyse how records, fields, permission sets, users, and groups have changed across processes.

Horizontal action menu ​

In Autologyx, the Horizontal action menu is the top-level menu bar displayed across the top of the sequence design interface, providing the primary action buttons used while configuring and editing a sequence. It is used by configuration administrators alongside controls such as Edit mode, Save mode, the Navigator, the Outline modal, and Group/Ungroup functions to access core design and management actions from a consistent location. This menu matters because it centralises the key commands needed to build, organise, review, and save sequence changes, making it the main access point for efficient navigation and control during sequence configuration.

host ​

In Autologyx, the host is the server address or endpoint for the external system that an integration connects to, and in the documented iManage Authentication object it is one of the required connection credentials entered alongside the username, password, and client ID. Configuration admins and developers use the host when creating and testing Authentication Objects so the platform knows which iManage environment to contact for authentication and subsequent service calls. Entering the correct host is essential because it determines the target system for the connection and directly affects whether the Authentication Object can connect successfully and be used by dependent integrations or processes.

Host field ​

The Host field is a configuration field in a DocuSign Authentication Object in Autologyx that defines the DocuSign account endpoint the platform uses when connecting to DocuSign. It is used during system configuration by administrators and integrators when setting up DocuSign access, and must be set to the correct environment-specific value: account-d.docusign.com for developer or test accounts, or account.docusign.com for live accounts. This field matters because it ensures Autologyx authenticates against the correct DocuSign environment, which is essential when configuring integrations and when moving a solution from test to live.

Host selection ​

Host selection is the setting in an Authentication Object that defines the base DocuSign account endpoint Autologyx uses when connecting to that external service. It is used in API configuration and integration setup to point the platform to the correct environment, such as a test host like account-d.docusign.com in a development system or the live host account.docusign.com in a production system. This matters because Host selection ensures that API calls, credentials, and account-specific configuration are aligned with the intended external environment, and it is especially important during system migrations where matching Authentication Objects are mapped between dev and live systems while preserving the correct host for each environment.

How To Configure The Landing Page ​

How To Configure The Landing Page is the system-configuration guidance in Autologyx that explains how administrators set up the platform’s landing page, the first screen users see when entering the environment. It is used within the Landing Page area of system configuration and is primarily relevant to Configuration Admins and Super Admins responsible for shaping the initial user experience. This configuration matters because the landing page controls how users are introduced to Catalyst and other key platform content, helping organisations present the right information, navigation, and entry points from the moment a user logs in.

HTML component ​

An HTML component is a reusable content block available when configuring the Landing page in Autologyx. In the Layout panel, administrators can drag and drop an HTML component into a page section or column as many times as needed, then use the HTML editor to add and format custom content as part of the page layout. It matters because it gives Configuration Admins and Super Admins precise control over the structure and presentation of Landing page content, supports tailored section design, and works with previewing, reverting changes, section header settings, and enabling the page as part of system configuration.

HTML editor ​

The HTML editor is the rich-text and source-editing tool used in Autologyx system configuration to create and maintain Landing page content. It is used by configuration administrators and Super Admins when adding or editing page sections, allowing them to enter and format text, insert tables, horizontal lines, images, media, and iframes from hosted sources such as Power BI, and switch to HTML or Source view to paste or write markup directly. The editor sits within the Landing page configuration experience alongside controls such as section settings, layout options, preview, revert, and page enablement, and it matters because it provides precise control over how information and embedded content are presented to users while supporting both visual editing and direct HTML authoring.

ID ​

In Autologyx, ID is the system-generated integer property of an Object Record that uniquely identifies that record and is available for use in templates through the merge field {{ record.id }}. It is used in the Record Properties set of merge fields alongside values such as Created and Modified, allowing configuration admins and end-users to insert the record’s unique identifier into generated content, notifications, or other template-driven outputs. This matters because the ID provides a consistent, platform-defined reference to the exact record being processed, and it must be accessed with the record property syntax {{ record.id }} rather than the record shorthand syntax.

ID based access ​

ID based access is the legacy data access mode used by Users and Groups merge fields in Autologyx to return references as lists of user IDs and user group IDs rather than full object data. It is used in system configuration where existing templates, rules, integrations, or scripts depend on identifier values, and it preserves compatibility with established configurations that were built around ID-only outputs. This matters to configuration admins, Super Admins, and developers because it determines the structure of data exposed by merge fields, affects how downstream logic and integrations consume user and group information, and is a key consideration when maintaining older implementations or deciding whether to move to object based access for richer functionality.

Identifier ​

In Autologyx, the Identifier is the single field designated on an Object class to represent each record in the user interface, providing the primary business-facing label used alongside or instead of the system-generated ALX ID. Configuration admins set this at Object class level, and only one field can be marked as the Identifier; if none is selected, Autologyx automatically uses the ALX ID. The Identifier is used throughout the platform wherever records need to be recognised quickly, including records lists, card views, summary and create/edit displays, breadcrumbs, task panels, and parent-child record selection and summary views. It matters because it determines how records are presented to end-users, makes related records easier to find and distinguish, and ensures that navigation, search, and relational record management use a meaningful value such as a case number, application number, or name rather than only an internal record number.

Show 4 more pages

If / Else ​

If / Else is the Autologyx conditional logic structure used to evaluate field values and output different content depending on whether a condition is met. It is used when configuring conditional logic in merge fields, including in Document Templates, the Templates tab, the Word Add In, and email body content, and it can be combined with basic and nested conditions and operators such as in, not in, and, and or. This matters because it allows configuration admins to control exactly what text or content is shown in generated documents and communications, ensuring outputs adapt correctly to workflow data and user inputs.

IF Statements ​

IF Statements are conditional expressions used in Autologyx document templates to control whether specific merge content is included when a document is generated. They are configured in template content alongside merge fields and other template functions, typically with the Word Add-in or when editing a template on the Document templates tab, and are used in scenarios such as guard clauses around merge fields to prevent output when related indexed records or values are not present. IF Statements matter because they help configuration admins build resilient, accurate templates and help end-users generate documents without errors caused by invalid merges, reducing document generation issues during manual generation, download, or save-to-field actions.

Image merge fields ​

Image merge fields are a dedicated merge field type in the Autologyx platform used in .docx document templates to insert images dynamically into generated documents during document assembly, including items such as logos, photographs, charts, QR codes, and infographics. They are configured and used within the merge field framework in system configuration and are available in templates and sequences, where the field is placed in the template text box with optional filters just like other merge fields. This matters because it allows configuration admins to design richer, personalised document outputs and enables end-users to generate documents that include record-specific visual content instead of relying on static images, improving both document accuracy and presentation.

Show 1 more pages

iManage ​

INSUFFICIENT_EVIDENCE

iManage API Call actor ​

The iManage API Call actor is an Autologyx Catalyst actor used in sequences to connect directly to iManage and perform file transfer operations, including downloading files from an iManage account and uploading files to designated iManage locations without relying on external tools. It is used by configuration administrators and developers when building or maintaining integrations inside sequence-based automations, and it is typically understood alongside related features such as sequences, the API Call test log, and client credentials flow. This actor matters because it extends the platform’s native integration capability with iManage, allowing document movement to be handled as part of an automated workflow within Autologyx rather than through separate integration components.

iManage API Call template ​

An iManage API Call template is a dedicated API Call template in the Autologyx Sequencer that is tailored specifically for the iManage integration. It is used by configuration admins and developers when building or configuring workflows that connect the platform to iManage, providing a standard way to define calls that interact with iManage services as part of an integration design. This matters because it streamlines the setup of iManage-connected processes, supports consistent integration behaviour, and enables Autologyx experiences such as accessing iManage documents directly from Catalyst record views without leaving the platform.

iManage Authentication Objects ​

An iManage Authentication Object is an Autologyx configuration object that stores the credentials and connection details required to connect Catalyst to an iManage account or library, including the username, password, client ID, and host. It is created by administrators as the first step in setting up the iManage integration, can be tested during creation and editing to validate the connection, and is then selected for use in platform features such as workflow sequences and the API Call actor when the iManage template is chosen. This object matters because it centralises and standardises the secure connection to iManage, enabling workflows and integrations to access iManage consistently without re-entering connection settings in each implementation.

iManage Cloud component ​

The iManage Cloud component is the drag-and-drop form element used in Autologyx Catalyst to surface the iManage integration within a Catalyst record. It is available to configuration admins in the Create/edit record display form builder under Integrations when the iManage integration is active and enabled, and it can then be placed on record views to show the connected iManage screen for that record. The component also supports linking a specific iManage folder or matter to the Catalyst record, either directly from the component by associating a folder or programmatically through the integration API, so that users open the record directly into the assigned iManage location. This matters because it controls how iManage content is embedded in Catalyst record views and streamlines access to the correct workspace for operational users.

iManage Cloud integration ​

iManage Cloud integration is an Autologyx Catalyst integration that connects workflows and records to iManage Cloud so users can search, select, and use iManage documents directly within the platform without leaving Catalyst or building custom code. It is used in workflow and record experiences in the Catalyst UI, including places where documents are surfaced or chosen as part of process execution, and it is relevant when configuring document-driven experiences alongside related platform features such as Create/Edit forms, display forms, document metadata handling, and authentication through Authentication Objects. This integration matters because it brings external document access into the flow of work, reducing context switching for end-users while giving configuration admins and integrators a standard way to expose iManage content inside Autologyx processes.

iManage folder assignment ​

In Autologyx, iManage folder assignment is the configuration that determines which iManage folder is shown first when a user opens an integrated record, so the most relevant document location is presented immediately from within the platform. It is used as part of the iManage integration in Catalyst record views, where administrators define the folder selection behaviour that controls the initial iManage context for a record. This matters because it streamlines access to documents, reduces manual navigation, and ensures users land in the correct iManage workspace when working with a Catalyst record.

iManage integration ​

The iManage integration is an Autologyx platform integration that connects Catalyst records to iManage folders or matters so users can work with document and matter content from within Autologyx. It is used in two main places: in the Integrations section of the Create/Edit Record display form builder, where form designers add the iManage component to a record view, and in API-based automation, where configuration teams can assign the iManage folder or matter to a record programmatically using the relevant endpoint or the iManage option in the API Call Actor. The integration must be active and enabled in the environment before these options are available. This matters because it lets administrators embed iManage access directly into business workflows, supports automated matter setup and bulk operations, and gives end-users a record experience that opens directly to the linked iManage location.

iManage integration ID ​

An iManage integration ID is the unique identifier of a configured iManage integration in the Autologyx platform. It is used in configuration where Autologyx needs to target a specific iManage connection, such as in iManage-related setup and templates, and is entered wherever the platform requests the ID of your iManage integration. This identifier matters because it links record views, document access, and API-driven iManage interactions to the correct integration instance, ensuring that Autologyx uses the intended iManage connection when surfacing documents or executing integration-based actions.

iManage location ​

An iManage location is the currently selected place in iManage that Autologyx uses as the document-management context for a record when the iManage integration is in use. It is used when associating an Autologyx Catalyst record with iManage, where the platform automatically binds the selected iManage location to that record. This matters because it links work in Autologyx to the correct location in iManage without additional API calls or configuration steps, ensuring users, administrators, and integrators can connect records to the right document repository context as part of the integration experience.

iManage oAuth 2.0 (Password Grant flow) ​

iManage oAuth 2.0 (Password Grant flow) is a supported Authentication object provider in Autologyx used to store and manage the credentials and connection settings required for integrations with iManage using the OAuth 2.0 Password Grant flow. It is configured in the Authentication objects area of platform administration alongside other provider types, and is used by configuration admins, super admins, and integrators when setting up API-driven connections that need authenticated access to iManage from within Autologyx workflows or services. This provider matters because it gives the platform a defined, reusable authentication method for iManage-related API calls, helping ensure integrations are configured consistently and can be referenced as part of broader solution setup.

iManage template ​

An iManage template is the API Call actor template used to configure calls to the iManage integration in Autologyx. It is selected in the actor’s Template field when an environment has iManage enabled, and it works with an iManage Authentication object to connect a sequence to iManage services. This template is used when configuring document exchange actions, such as retrieving files with GET requests and uploading documents with POST requests, and requires the relevant integration-specific setup details, including the customer identifier. It matters because it provides the platform-specific configuration path for reliable communication with iManage, allowing administrators and integrators to build document management steps into workflows using the correct authentication and request structure.

img height ​

In Autologyx document generation, **img height** is an image merge field filter used in Document Templates to set the rendered height of an embedded image when the document is generated. It is applied in merge field syntax alongside image sources and related filters, for example when inserting logos, photographs, charts, QR codes, or other personalised images into generated documents; it is commonly used together with img width to control final image dimensions in the output. This matters to configuration administrators and developers because it determines how embedded images are sized within the document layout, helping ensure consistent formatting, correct placement, and professional presentation across generated documents.

img width ​

img width is an image merge field filter used in Autologyx document templates to set the rendered width of an embedded image when generating documents. It is applied within a merge field expression, typically alongside the embedded image source and related filters such as img height, for example when inserting logos, photographs, charts, QR codes, or other personalised images into template output. This matters to configuration admins and developers because it gives precise control over image sizing in generated documents, helping maintain consistent layout, branding, and presentation quality across templates.

Import ​

Import is the action used in Administration when adding a new Element to the Autologyx platform from its project files. In the Elements configuration flow, after creating and enabling the Element and setting where it will be available, the Import button brings the Element definition into the platform so it can be tested and used in the selected system areas. This step matters to configuration admins, super admins, and developers or integrators because it is the point at which the Element’s implementation is loaded into Autologyx and becomes available as a configured platform component.

Improved Breadcrumbs ​

INSUFFICIENT_EVIDENCE

Improved Instructions Editor ​

In Application Help ​

  • Mostly relevant to: End-users, Configuration admins
  • Closely related concepts: Catalyst

In Application Help is the embedded help area within the Autologyx Catalyst experience that provides users with guided documentation and examples directly from within the application. It is used as a starting point for navigating key topics such as workspace usage, tasks, and platform setup areas relevant to configuration administrators and super administrators. In Application Help matters because it gives end-users and configurators immediate access to product guidance in context, helping them understand how to use Catalyst features and where to find information needed to complete day-to-day work or configure the platform effectively.

in line editing ​

In line editing (inline editing) in the Autologyx platform is the edit form behavior that applies changes to an object record immediately as a user makes them, without requiring a separate Save action. It is used when editing object records in the workspace, including contexts such as record summaries and related edit views, and allows end-users to update field values directly within the current record interface. This matters because it changes how users interact with records and how configuration admins design record-editing experiences: updates take effect instantly, which streamlines data maintenance, reduces extra steps in the editing process, and requires users to understand that modifications are committed as they are entered.

in place editing ​

In place editing, also called immediate effect editing, is the Autologyx configuration behaviour used on certain sequence property pages where changes are applied as soon as they are entered, rather than being held until a separate Save action is selected. In the Sequence design area, including the Sequence properties page accessed from the Sequencer tab or related Actions menu options, this means there is no Save button because each permitted update takes effect immediately. This matters for Configuration Admins and Super Admins because edits made with the appropriate Edit permission become live at once, so changes to sequence configuration should be made carefully and deliberately.

In-use deletion protection ​

In-use deletion protection is an Autologyx safeguard that prevents a configuration item from being deleted while it is actively referenced elsewhere in the platform. In the documented release context, this applies to Authentication Objects, which are used to provide credentials for critical integrations such as email delivery, API connections, and machine learning services; if an Authentication Object is currently in use, Autologyx blocks its deletion. This protection is most relevant to Configuration Admins and Super Admins when managing integration settings and reviewing usage panels, because it preserves the integrity of dependent configurations such as Sequencer integrations and helps prevent broken connections, failed workflow steps, and service disruption caused by removing a live dependency.

incorrect merges ​

In Autologyx document generation, incorrect merges are errors in a template’s merge fields or merge logic that cause the wrong data to be inserted, expected values to be left blank, or document content to render incorrectly when a document is generated. This issue is encountered when using document templates, including manual generation actions such as Generate and download document or Generate and save to field, and is typically investigated from the Templates tab by reviewing merge fields, document type fields, and any related IF Statements in the template. Correcting incorrect merges is important because document output depends on the template accurately mapping Autologyx data into the generated document, and merge errors directly affect document quality, usability, and reliability for both administrators configuring templates and end-users generating documents.

index ​

In Autologyx, an index is the zero-based position used in relational merge fields to select a specific item from a set of related records when generating content with Jinja2 in Document Templates. It is used in merge field syntax such as record.related records[0], where [0] identifies the most recently related record, and other index values select subsequent records in order. Indexes matter because they control exactly which related record is merged into a document or output, making them essential for template authors, configuration admins, and integrators who need predictable access to related data. When using indexed related records, templates should include an appropriate IF guard clause to ensure the referenced item exists before attempting to render it.

index.html ​

In Autologyx, the index.html file is the entry-point file for an Element when that Element is displayed in the platform. It is used as part of an Element project alongside related files such as config.json and any Element parameters, and is relevant when developing, packaging, or configuring custom Elements in Administration. This file matters because it defines the front-end content that Autologyx loads for the Element’s user interface, making it a required part of how an Element is presented and interacted with in the platform.

inherit permissions ​

In Autologyx, inherit permissions (or permission inheritance) is the access-control behavior whereby a user automatically receives the permissions assigned to any User Group they are added to. This is used when configuring and managing Record Permission Sets, including through the API for assigning or unassigning User Groups by group ID, so administrators and integrators can apply permission changes to whole teams instead of updating individual users one by one. Permission inheritance matters because it centralises permission management, keeps access aligned with group membership, and makes permission administration faster, more consistent, and easier to maintain at scale.

inline merge ​

Inline merge is the default .docx merge behavior in Autologyx dynamic document assembly, where the merged content is inserted directly within the same paragraph as the merge field in a document template. It is used when configuring or authoring .docx templates that include embedded merge fields, such as record.field[index].embedded, and is selected when the content should flow as part of the surrounding sentence or paragraph rather than replacing the whole paragraph. This matters because it controls the final layout and formatting of generated documents: choosing inline merge ensures embedded content is positioned exactly where the field is placed, which is essential for producing correctly structured text in assembled documents.

Input type ​

Input type is a field configuration setting in Autologyx that controls how supported field types are presented and completed in forms and tasks. It is used when configuring task form fields, standalone forms, task templates, and task response mappings that update object records, and is available only for certain field types such as Text, Single select, Multi select, and Date/Time picker fields. Depending on the field, the input type determines the specific entry format or control shown to users, such as Single line or Multi line text entry, or different date and time entry modes. This matters to Configuration Admins and Super Admins because the selected input type directly affects the form experience, how users enter data, and whether the field behaves in the way required for the business process.

installation will fail ​

Installation will fail describes a hard validation outcome in the Autologyx Elements installation process: the platform rejects the Element and does not complete installation when mandatory requirements are not met. In practice, this is used when creating or configuring an Element in Administration > Elements, especially when installing from a Git repository, and it applies to missing required project files such as config.json and the Element entry-point file, an incorrect project folder structure, or invalid repository access details such as an expired token. This matters to developers, integrators, and configuration administrators because these checks define the minimum packaging and connectivity standards an Element must meet before it can be added to the platform, making them a key reference when preparing, troubleshooting, and maintaining Element deployments.

Installed ​

Installed is an Element status in the Autologyx platform that shows an Element package has completed installation and its files are in a finalised state. This status is used on the Elements list page and related Elements administration views to indicate that the package is no longer being imported or installed, distinguishing it from Processing and Failed. Installed matters to Configuration admins and Super Admins because it confirms the package is present and ready for the next administrative step, while remaining separate from whether the Element is Enabled, so an Element can be installed without being active for use.

instance of Catalyst ​

An instance of Catalyst is a single deployed environment of the Autologyx Catalyst platform. In platform configuration, this term is used to define environment-level scope for components and administration, including the Relational modeller, which exists in a 1:1 ratio with each Catalyst instance. This matters to Configuration admins and Super Admins because configuration decisions, data model design, and related administration are applied at the instance level, making the Catalyst instance the fundamental boundary for managing and governing a specific Autologyx deployment.

Instruction component ​

In Autologyx, the Instruction component is a form builder element used in the Response configuration tab to place advisory or explanatory text anywhere within a response form. Configuration admins and Super Admins use it when creating task templates such as Complete self contained form and Update object record forms, where it helps guide users completing the task by presenting statements, directions, or contextual information alongside input fields. Unlike components that capture data, the Instruction component is used to improve form clarity and usability, making it important for structuring responses, reducing user error, and ensuring the purpose of each section or field is clear during task completion.

Instruction Properties panel ​

In Autologyx Formbuilder, the Instruction Properties panel is the configuration panel used when editing an Instructions component within the Sections and Instructions layout controls. It opens when an instruction element is selected and provides the editor functions and multiline text area used to define and format the instructional content shown on a record or task form. This panel is used by configuration administrators while designing forms, alongside related settings such as Section Properties and Conditional Visibility, and it matters because it controls the guidance presented to end users, helping ensure forms are clear, consistent, and contextually relevant.

instruction widgets ​

Instruction widgets are form-building elements in the Autologyx platform used to place short, clear notes directly within create and edit forms to guide users as they complete a record. They are used in the Catalyst form builder and can be added from the form design area alongside sections and fields by dragging them into position where guidance is needed. Instruction widgets matter because they help configuration administrators and Super Admins improve form usability, reduce user error, and provide context at the exact point of data entry without changing the underlying data structure or adding extra input fields.

instructions ​

Instructions, also called form instructions, are the guidance content shown on forms across the Autologyx platform to help end users complete a form correctly and efficiently. Used by configuration administrators in the form builder, instructions are created and maintained through the instructions editor, which supports rich text, images, and clickable links so guidance can be clear, structured, and visually easy to follow. Instructions matter because they are a core part of form design: well-written instructions improve usability, reduce user error, and create a more consistent and effective form completion experience.

Instructions component ​

The Instructions component is a configurable display component available in the Create and edit view of an object class in Autologyx, used to present instructional text to users within a form layout. Configuration admins and Super Admins add and manage it from the Components panel when defining a display on the Display tab, where it counts as one of the supported non-section components in the view layout. It is not available in the Card view, and its absence there means the Layout section is not shown for that view. This component matters because it allows administrators to embed guidance directly into user-facing forms, helping structure the experience and clarify what users need to do when completing or editing records.

instructions editor ​

The instructions editor is the enhanced text editing capability used when authoring instructions in Autologyx, including forms across the platform and Autologyx Catalyst. It replaces plain instruction text with improved formatting options, allowing configuration admins and end-users who design experiences to present clearer, better-structured guidance directly within forms and related user interfaces. This matters because well-formatted instructions make tasks easier to understand and complete, improving usability, reducing ambiguity, and helping organisations deliver more effective guided interactions throughout the platform.

Intake form ​

An intake form in the Autologyx platform is a record creation form used to capture the information required at the start of a process and create the initial record that work will progress against. It is designed and maintained in the Form Builder, where configuration admins define the fields, structure, and user experience needed to collect complete and accurate input from end-users. Intake forms are used at the point a new case, request, or matter is submitted, and they matter because their design directly affects data quality, user completion rates, and the efficiency of downstream workflow, routing, and processing.

Integer ​

In Autologyx, Integer is a Number field type used in the Catalyst form builder to capture whole-number values only, without decimal places. It is used when designing intake forms and other record creation forms, and can also be selected when configuring fields in create and edit views where users must enter count-based or discrete numeric data. This matters because choosing Integer enforces the correct data format at the point of entry, helps distinguish whole-number fields from Decimal fields, and supports consistent form design and data quality across the platform.

Integer and Decimal field types ​

Integration categories ​

Integration categories are the groupings used in Autologyx Centralised integrations management to organise the available integrations list into distinct types, specifically standard business integrations and Applied AI providers. They are used in System Configurations → Integrations, where Configuration Admins and Super Admins review what connectors are available, identify whether a capability is a core business tool such as DocuSign or Salesforce or an AI service such as OpenAI or AWS Bedrock, and then request or enable the relevant integration. This matters because the categories make the integrations catalogue easier to navigate, support faster configuration decisions, and help administrators select and activate the right services for their organisation’s operational and AI-enabled workflows.

integration framework ​

In Autologyx, the integration framework is the platform capability used to connect Autologyx and Catalyst to external systems through a consistent set of integration and authentication components. It is used when developers, integrators, and configuration administrators set up connections to third-party services, define Authentication Objects, and configure client credentials or templates such as the Generic OAuth 2.0 template. The integration framework matters because it provides the foundation for creating, managing, and scaling both standard provider connections and custom integrations, simplifying how existing systems are connected to Autologyx and reducing the effort required to deliver secure, reusable integrations across the platform.

Integration hub ​

In Autologyx, the Integration hub is the central administration area for managing third-party integrations used across the platform. It is used by configuration admins, Super Admins, and developers or integrators to access and configure available connectors, such as the iManage Cloud integration, so external services can be enabled for use in workflows without custom code. The Integration hub matters because it provides a single place to control how Autologyx connects to external systems, helping administrators standardise setup, streamline integration management, and make connected capabilities available for workflow design and execution.

Integrations ​

In Autologyx, Integrations is the area of platform configuration used to add and manage connected external system components within a record display form, enabling form designers and configuration administrators to surface functionality from integrated services directly in the user experience. It is used in the Create/edit record display form builder, where active and enabled integrations such as iManage appear as options under the Integrations section so they can be placed on a form and configured for use. This matters because it is the point at which external platform capabilities are brought into Autologyx records, allowing organisations to embed connected-system screens and actions in the right context for end users.

Integrations page ​

The Integrations page is the configuration area in the Autologyx platform where enabled third-party and platform integrations are managed and made available for use elsewhere in the system. Used primarily by Configuration Admins and Super Admins within the configuration panel, it controls whether specific connected services can be selected and used by platform features and components, such as the API Call Actor. This matters because integration-dependent options only become available when the relevant integration is enabled on the Integrations page, making it a central point for preparing the platform to connect with external systems and support automation across workflows.

Intelligent autocomplete search is the search capability built into the Create task actor in Autologyx that helps users find and select relevant items as they type. It is used when configuring task creation within sequence design, where configuration admins work with task actors and task templates through the platform’s design interfaces, including side panels. This feature matters because it speeds up configuration, reduces the effort required to locate the correct option in large lists, and makes task setup more efficient and accurate when designing or updating workflow behaviour.

intelligent autocomplete search feature ​

The intelligent autocomplete search feature is the search capability provided in the Create Task actor when selecting a task template in the Create Task Configuration window. In Autologyx, it helps configuration users quickly find the correct task template by dynamically narrowing results as they type, reducing the effort required to locate items within task setup screens. This feature matters because accurate task template selection is central to configuring how tasks are created and assigned in a process, making configuration faster, more efficient, and less prone to selection errors for admins managing task-related actors.

intelligent pathways ​

In Autologyx, intelligent pathways are workflow routes configured in the Sequencer that allow a process to change direction automatically as Record data changes, tasks are completed, or responses are received from third-party systems through API calls. Used by Configuration Admins and Super Admins when designing sequences in the drag and drop interface, intelligent pathways define how Records move between Sequence Actors and process steps under different conditions. They matter because they enable automated, responsive process design, helping administrators build sequences that adapt in real time to business data and system events rather than following a single fixed path.

Interacting With Associated Child Records Via The Parent ​

Interacting With Associated Child Records Via The Parent is the Autologyx capability of viewing and working with child records from within the related parent record, using the parent as the primary context for managing connected relational data. It is used in the platform’s relational-records experience, where users can open a parent record and access its associated child records without navigating away to manage each child independently. This matters because it streamlines day-to-day record handling, keeps related information together, and supports configurations where processes, data entry, and record maintenance are organised around parent-child relationships.

Internal ​

Internal is an account type in the Autologyx platform for users who are employees of your organisation and who work directly in processes by processing records and completing tasks. It is used in user and permissions administration, including when defining access through the platform’s user permission model, and is distinguished from other account types such as External. This account type matters because it helps administrators assign the correct access and operational responsibilities to staff users, ensuring the right people can perform internal workflow activities within Autologyx.

Internal account type ​

Internal account type is the Autologyx user account type for people who belong to your own organisation and need to work with records and tasks in the platform. It is used when creating and editing user accounts, including for users provisioned through Single Sign-On, which are created as Internal accounts, and Internal users are typically assigned to one or more user groups with object class and record permissions so they can carry out operational work. This account type matters because it determines how a user participates in the platform’s permission model and administration features: an Internal user can be changed to a Config admin account type, can be a member or Owner of a user group, and can view a user group through the owner mechanism, but an Owner with an Internal account type does not get the User group menu option and cannot edit or delete the user group or manage its permission sets in the same way as a Config Admin or Super admin.

Internal Service account ​

An Internal Service account is a special service account type in Autologyx Catalyst that exists once per Catalyst build and is granted full, unrestricted permissions equivalent to a Super Admin. It is used in the platform’s user administration and API-based configuration workflows, where it appears in the user list with the account type shown as Service Internal. This account matters because it provides a built-in high-privilege identity for integrations, automation, and administrative operations, but it must be handled carefully: it is distinct from an External Service account, and when updating its password through the users API, the request must be authenticated as a different user because an Internal Service account cannot change its own password.

Internal staff accounts ​

Internal staff accounts are a user account type in the Autologyx platform used for people inside the organisation who need platform access as staff users, distinct from external users, Config Admin users, and accounts with full platform access. This account type is used in system configuration when defining authentication methods by user account type, including API-based configuration that specifies which sign-in method, such as Single Sign On (SSO) or another permitted authentication option, applies to internal staff accounts. Internal staff accounts matter because they let administrators enforce the correct authentication policy for employees and other internal users separately from other account categories, supporting controlled access, consistent security configuration, and clear separation of user populations across the platform.

Internal User ​

An Internal User is a Catalyst user account type intended for platform access through directly granted permissions rather than role membership. In Autologyx, Internal Users are used where a person needs access to system functionality but must not be assigned standard roles, making this account type important for configuration and access-control design. This term is especially relevant to Configuration Admins and Super Admins when managing user provisioning and sign-in behaviour, including Okta OpenID Connect (OIDC) setups, where enabling Automatically create user creates a Catalyst account for a first-time valid Okta user as an active Internal User. Understanding Internal Users is essential when configuring authentication, create SSO permission, and Catalyst login support, because it determines how users are created, what access model applies to them, and how their permissions differ from external users and role-assigned accounts.

Internal user access ​

Internal user access is a single sign-on configuration area in Autologyx that controls how users with an internal user account type are handled when signing in, including whether accounts are created automatically on first access. It is used by Configuration admins and Super Admins when setting up or maintaining user authentication, particularly in SSO scenarios where users do not already exist in the platform. This matters because it determines how internal users gain entry to Autologyx, streamlines onboarding by enabling automatic account creation, and helps administrators align sign-in behaviour with their organisation’s user management approach.

Internal user account type ​

Internal user account type is the Autologyx user classification assigned to users who are created automatically through single sign-on when the Automatically create user option is enabled in the Administration area under Internal user access. It is used by configuration admins and Super Admins when setting up and managing SSO-driven access, and it determines the account type applied to new users entering the platform through this creation path. This matters because it defines how automatically provisioned users are recorded in Autologyx and ensures user creation through SSO follows a consistent account-type assignment during platform configuration.

Internal user type ​

Internal user type is a user account classification in the Autologyx platform used to categorise users for platform administration and access design. Introduced alongside the External user type, it is used by Configuration Admins and Super Admins when defining how users are organised and managed, and it works in conjunction with related controls such as User Group Permissions. This classification matters because it gives administrators more precise control over how different populations of users are distinguished within the platform, supporting clearer configuration, governance, and visibility rules.

Invalid Actors ​

Invalid Actors are configured actors in the Autologyx Sequencer that have missing or invalid configuration and are identified in the configuration interface with a warning icon. In sequence design and system configuration, they indicate that an actor is not valid for execution, and the Sequencer does not process them. This matters to Configuration Admins and Super Admins because invalid actors affect how workflows run: they must be corrected to restore normal processing, and they must not be used as workflow merge points or as a synchronisation mechanism. Autologyx guidance is to treat an Invalid Actor as a configuration issue to resolve and to use supported design approaches, such as paste trigger functionality, instead of relying on invalid actors or timing assumptions to control execution.

Invalid Actors And Best Practice ​

INSUFFICIENT_EVIDENCE

Is Empty ​

Is Empty is a condition used in Autologyx to test whether a field or variable currently has no value. It is used in platform configuration wherever emptiness checks are supported, including record list filtering for document type fields and logic that evaluates values managed through the Local Variable Actor. For example, configuration admins can use Is Empty to find records where required documents have not been added, and developers or integrators can use it in process logic to branch or validate behaviour when a variable has not been populated. This matters because it provides a direct way to identify missing data, enforce process rules, and drive workflow decisions without relying on specific placeholder values or manual checks.

Is Not Empty ​

Is Not Empty is an Autologyx condition and filter operator used to test whether a field or variable contains a value. In the platform, it is used when filtering record lists against document type fields to find records where documents are present, and in configuration logic such as the Local Variable Actor to check that a variable has been populated before subsequent processing. This matters to configuration admins and developers because it supports reliable workflow control, targeted record filtering, and validation of required data, helping ensure actions, routing, and visibility depend on the presence of content rather than a blank value.

ison.config ​

  • Mostly relevant to: Developers / Integrators, Configuration admins
  • Closely related concepts: Elements

ison.config is the configuration file supplied with an Autologyx Element alongside the element’s index.html file. In the Autologyx platform, it is used when packaging and installing Elements to define the customizable parameters for that Element, allowing developers and configuration administrators to control how the imported third-party content is configured within the platform. It matters because it provides the structured configuration interface for an Element, making the installation process usable, repeatable, and adaptable to different deployment requirements.

Jinja expressions ​

Jinja expressions, also referred to as Jinja, are template expressions used in Autologyx configuration to build values dynamically at runtime within API Call actor settings. In fields such as the URL, parameters, headers, and payload, Jinja expressions are supported alongside merge fields so that configuration can render record-specific and sequence-specific data when a call is executed. They are used by configuration admins and developers or integrators when defining outbound API behaviour, especially where request content must change according to the current record or processing context. Jinja expressions matter because they enable fully dynamic request construction, support testing and validation through API test call history, and help diagnose rendering or data issues when reviewing how a Sequence executed for a particular record.

Jinja filters ​

Jinja filters in the Autologyx platform are template functions used in Jinja expressions within Catalyst-driven document generation and sequencing to transform values at runtime, particularly for date and time calculations. Introduced in Autologyx Catalyst 1.9, these filters support operations such as shifting a date by years, months, or days, calculating intervals between dates, and applying business-day logic, using syntax such as {{ value|shift date(years=None, months=None, days=None, business days=False) }}. They are used when configuring templates, workflow content, and related automation that depends on precise date handling, and they matter because they let configuration admins and developers build documents, schedules, and process logic that are more accurate, maintainable, and efficient without external date-processing steps.

Jinja filters for date and time manipulations ​

Jinja filters for date and time manipulations are Jinja templating functions introduced in Autologyx Catalyst 1.9 to format, convert, and otherwise manipulate date and time values within platform templates and other Jinja-enabled configuration elements. They are used where administrators and developers define dynamic content, such as document templates, so that dates and times can be rendered in the required output format or adjusted for business presentation needs at runtime. These filters matter because they expand the platform’s templating capability, reduce the need for external transformation logic, and allow template-driven solutions to produce consistent, correctly formatted time-based content directly within Autologyx configuration.

Jinja logic ​

Jinja logic in the Autologyx platform is the use of Jinja templating expressions within configuration to evaluate data and set values dynamically at runtime. It is used by configuration admins and developers in areas such as sequences, gate variables, local variables, document field checks, and related actor configuration where platform behaviour depends on calculated conditions. For example, Jinja logic can be applied when updating a variable to confirm that all expected documents are present in their respective fields, allowing a gate variable to be set appropriately and controlling how the sequence progresses. This matters because it enables precise, maintainable business rules to be embedded directly in workflow configuration, reducing manual intervention and ensuring that routing, gating, and validation steps respond correctly to the current case data.

Jinja merge fields ​

Jinja merge fields are the standard templating syntax used across the Autologyx platform to insert dynamic data and logic into document templates and other configurable content. They are used wherever template-driven output is configured, especially in Automatic Document Generation scenarios with Word (.docx) templates, the DocAuto actor, and Document Picker flows that pass selected documents to DocAuto for processing. Jinja merge fields can populate templates from record data and related records, and support additional Jinja features such as functions, filters, and conditional statements. They matter because they provide one consistent language for dynamic content across the platform, making template configuration easier to maintain, more flexible for complex document generation, and more effective for admins, end-users, and integrators who need accurate, reusable output.

Jinja2 ​

Jinja2, also called Jinja, is the templating engine used in the Autologyx platform to generate dynamic output by combining record data with expressions and control logic inside merge fields and document templates. It is used wherever administrators and developers configure template-driven content, including document automation, formatted text, JSON payloads, API request bodies, and other outputs that reference values such as record.field and related records, and apply constructs such as if statements, for or group statements, guard clauses, and local variables. Jinja2 matters because it determines how Autologyx renders runtime content, allowing template authors to control both the data inserted and the exact structure of the final output, including whitespace, which is critical for valid formatting, clean document generation, and correctly structured machine-readable content.

JSON ​

JSON is a field type in Autologyx used to store complex data structures within a single Task form field. It is configured in Form Builder when designing Task forms and is also supported in merge fields, where it can be referenced with the **json** field type format, for example {{ record.field json }}. This field type matters to configuration admins and developers or integrators because it enables structured data to be captured and passed through the platform without splitting it into multiple simple fields, which is useful when handling nested values or payload-style data. In Task forms, JSON fields have specific configuration behavior, including that the Required option is not available for this field type.

JSON Data ​

JSON Data is the request body format used in Autologyx API Call actors to send structured data as JSON when calling external services. It is selected in the actor configuration alongside other body types such as Form Data, Multipart Data, XML Data, and Binary Data, and is the most commonly used option for POST and similar requests that require nested fields, arrays, or precisely structured payloads. JSON Data matters to configuration admins and developers because it determines how request content is constructed and delivered to an API, directly affecting compatibility with third-party integrations such as DocuSign and the correct use of merge fields and authentication settings within the payload.

JSON Explorer ​

JSON Explorer is the visual JSON inspection and selection tool used in Autologyx when configuring actors that consume structured JSON data, particularly the Loop actor. When a tested API Call or Local Variable is connected, it loads the returned JSON into a readable panel with a tree view so administrators and integrators can quickly locate the array or element they need and map it into the relevant JSON Path field. This matters because it speeds up configuration, reduces manual path-entry errors, and makes it easier to build reliable looping and data-driven automations from API responses and local variables.

JSON fields ​

JSON fields are an Autologyx object class field type used to store complex data structures in a single field. Configuration admins add JSON fields to classes and place them on record forms, including the Create/Edit record form, where users can enter and maintain structured JSON content. In the user interface, JSON fields are displayed with a Beautify JSON icon that formats the content for easier reading, and the field expands to the full width of its containing column in supported forms to provide more working space. JSON fields matter because they let teams capture structured, multi-level data within the platform without splitting it across many separate fields, which is especially useful for form design, record management, and integration scenarios.

JSON Path field ​

A JSON Path field is a configuration field in the Autologyx Loop actor used to identify the array within a JSON payload that the actor should iterate over. When configuring a loop against JSON output, admins can select an array node in the payload viewer and have the field populated automatically, or enter the JSON Path directly. The field is validated in real time to confirm that it resolves to a valid iterable array, and the actor cannot be saved until any invalid path is corrected. This matters because the JSON Path field controls the data set the loop processes and prevents runtime failures caused by pointing the loop at non-array JSON content.

Json Type ​

JSON type field ​

A JSON type field is a form field type in the Autologyx platform, introduced in Autologyx Catalyst 1.2, that allows structured JSON data to be captured directly within forms. It is used in form configuration and related editing experiences, including the Instructions Editor, where configuration admins and developers define how complex data should be entered and stored. This matters because it enables forms to handle richer, structured payloads than standard simple field types, supporting integrations and configurations that require nested or schema-driven data within platform workflows.

JSON type variable ​

  • Mostly relevant to: Configuration admins, Developers / Integrators
  • Closely related concepts: Variables, sequences

A JSON type variable is a variable type in the Autologyx platform designed to hold structured JSON data, with capacity for up to 250,000 characters in a single variable. It is used in sequence configuration to store and pass complex data structures between actors, enabling data-driven workflows that need more than simple scalar values. This matters to configuration admins and developers because it provides a flexible way to integrate, preserve, and reuse rich payloads across a process, reducing the need to split related data across multiple variables and making sequence data handling more efficient.

JSON variable ​

  • Mostly relevant to: Configuration admins, Developers / Integrators
  • Closely related concepts: API Call actor

A JSON variable is a variable type in the Autologyx platform designed to store large volumes of structured data in JSON format, making it suitable for complex information structures that do not fit well into simple text or scalar variables. It is used in platform configuration where workflows, integrations, or data-processing steps need to capture, hold, and work with richer payloads, particularly alongside capabilities such as API Call actors that exchange JSON data. This matters to configuration admins and developers because it enables more flexible data handling, supports manipulation and analysis of nested or high-volume data sets, and improves the efficiency of building automations that rely on structured external or internal data.

kebab menu ​

In Autologyx, the kebab menu is the three-dot actions menu shown beside an item, such as a permission set on configuration pages or an entry on a list page, and it provides the context-specific actions available for that item. It is used throughout the platform wherever users need to manage an individual object or row without opening a separate screen, including tasks such as editing permission sets, managing assignees, and adding or removing owners from Class permissions and related permission sets. The options shown in the kebab menu vary according to the page, the item selected, and the user’s role permissions, so it is a key part of both everyday navigation and administrative configuration workflows.

Label ​

In Autologyx, Label is the user-facing name of a field, shown on task forms and on Object records so users can identify and complete the correct information. Configuration admins set the Label when adding or editing fields in the Add field panel, including task form fields and Object class fields. On task forms, Labels are displayed on the form and do not need to be unique, although duplicate Labels require distinct Aliases; for Object class fields, the Label is displayed on the Object record and must be unique within that Object class. Label matters because it controls how fields are presented to end users, affects how administrators find fields in configuration, and works alongside properties such as Alias and Default value when defining usable, maintainable form and record structures.

Landing page ​

In Autologyx, the Landing page is the configurable home page users see when they sign in, used to present feature shortcuts, reports, guidance, task-focused information, and interactive components in a single starting point for work. It is configured in System configuration > Landing page and can only be edited by users with the Super admin account type, while other users access it as their entry point to the platform, including in scenarios such as single sign-on without an assigned role. The Landing page supports Elements and other drag-and-drop modules, including file upload and links to standalone forms or create/edit views, making it a central place to surface actions, dashboards, and integrations. It matters because it shapes the user’s first experience of Autologyx, controls how key tools and information are presented, and helps administrators direct users efficiently to the records, tasks, and processes they need.

Show 13 more pages

Landing Page And Theme ​

landing page Elements ​

Landing page Elements are reusable custom Elements that have been coded, made available through your Git repository, and placed on the Autologyx landing page to extend the page with tailored functionality or content. In the platform, they are one of the supported locations where Elements can be used, alongside Object class create/edit views, summary views, and standalone forms. Like other Elements, landing page Elements are hosted and secured within an IFRAME container in the context of the page where they are rendered. This matters to Configuration admins and Super Admins because the landing page is often a primary user entry point, so configuring Elements there allows organisations to present custom actions, guidance, integrations, or interactive components directly at the start of the user experience.

Language and localisation ​

Language and localisation is the My Account settings area where an Autologyx user configures how the platform is presented for their own use. In this tab, users set their time zone, choose the system language, and define regional display formats such as date format, decimal format, and thousand separator format, which are then applied throughout date and numeric fields across the system. This matters because it ensures information is displayed in the user’s preferred language and local conventions, improving readability, consistency, and day-to-day accuracy when working in the platform.

Last task created ​

Last task created is a Task template field in the Autologyx platform that displays the date and time when that template was most recently used to generate a Task. It is used in Task template management, including column configuration and the Task configuration area, to help configuration administrators and Super Admins monitor template activity and understand when a template was last exercised in live use. This matters because it provides a quick operational indicator of template usage, supporting template review, maintenance, and decisions about whether a template is current, active, or no longer being used.

Layout ​

In Autologyx, Layout is the section of the Components panel used when configuring an object class display in the create and edit view canvas, where administrators add and arrange structural display elements rather than data fields or component properties. It is available for standard display configuration but not for Card view, where the Layout section is not shown. Layout matters because it controls the visual structure of a page, helping configuration and super administrators organise content clearly, position components effectively, and apply display settings such as column-based arrangement to produce usable, consistent interfaces.

Layout panel ​

The Layout panel is the configuration area in Autologyx form and page builders that contains the available layout and form components for constructing a page or response form. It is used when configuring items such as the Landing page and Complete self contained form task responses, where administrators can drag and drop sections and other components from the panel—typically shown on the right-hand side—onto the design canvas, including reusable elements such as the HTML component. The Layout panel matters because it is the primary control for structuring content, adding components, and organising how users interact with configured pages and forms across the platform.

Layout Sections And Instructions ​

Layout Sections And Instructions are form builder configuration areas in Autologyx used to structure a record or task form and present instructional text to users. Within the Formbuilder Components area, they sit alongside other configurable components such as elements, properties, child object classes, and task form fields, and are used by configuration admins and super admins when designing how a form is organised and understood. Layout sections define the visual and logical grouping of form content, while instructions provide on-screen guidance that explains what users should do when completing the form. This matters because clear sectioning and instructions improve form usability, support consistent data capture, and help administrators build forms that are easier for end users to navigate and complete correctly.

left hand menu ​

The left hand menu is the main navigation panel in the Autologyx platform that displays the pages and system areas a user can access, such as Administration > Roles and other list or static pages. It is used throughout the application by end-users, Configuration admins, and Super Admins to open functional areas, and its contents are controlled by role permissions. In practice, permissions such as Edit, Create, and Delete determine whether a user can see a menu item, open the related page, and access actions available from that area; when the required permissions are removed, the corresponding item is hidden from the left hand menu and the user cannot access that part of the platform. This makes the left hand menu a key part of how Autologyx enforces navigation, visibility, and role-based access across the user interface.

Lifecycle ​

Lifecycle is the task template configuration area in Autologyx where administrators define the time-based behaviour of a task, including whether it is completed only once or is a task that will expire, and whether it has an SLA for completion. It is used when creating or editing task templates, alongside Response configuration and Stages, and supports setting a Due Date for either lifecycle option; when the task is configured to expire, the Lifecycle tab also exposes Expiry rules. Lifecycle matters because it controls how the platform manages task duration and completion expectations, which directly affects how tasks are tracked as outstanding or overdue and how assignees are managed against deadlines.

Lifecycle and expiry ​

INSUFFICIENT_EVIDENCE

Lifecycle tab ​

The Lifecycle tab is the configuration area in Autologyx where administrators define time-based rules for a task template, including the due date settings held under Expiry rules. It is used when setting up or maintaining task templates, and its effects are visible in operational task views such as the Tasks list, where the Due Date shown for a task is taken from the Task Template Due Date configured in the Lifecycle tab. This matters because it controls how task deadlines are generated and displayed across the platform, helping Configuration Admins and Super Admins ensure tasks are created with the correct timing and lifecycle behaviour.

list and view permissions ​

List and view permissions are distinct object class permissions in the Autologyx platform that control how users access records of a given class. Used within Object class configuration, these permissions separate the ability to see records in lists from the ability to open and read an individual record, allowing administrators to design workspaces where users can access records only in the intended context, such as from a parent record form rather than through general list pages. This separation matters because it gives Configuration admins and Super Admins more precise control over record visibility and navigation, supporting tighter workspace design and more granular access management across object classes.

list page filter editor ​

The list page filter editor, also called the Filter Editor, is the control used on Autologyx list pages to define the criteria that determine which rows are shown in the results. It is available on most list pages and is opened from the filter editor icon in the top-left area of the page, below the list name and beside the Create button, where it opens as a filter panel starting with a field selection. The filter editor matters because it lets end-users narrow large result sets to the records, users, or groups they need to work with, and helps configuration admins and Super Admins review and manage platform data more efficiently across pages such as records lists and administration lists.

Show 1 more pages

list pages ​

List pages are standard Autologyx screens used across the platform to display and manage collections of records, tasks, configuration items, and other system objects. They are used in workspace and administration areas such as task lists and user group lists, and provide a consistent set of controls including the list name, result counts, paging, standard ID and Actions columns, column configuration, and, on most list pages, a filter editor. Each list page has its own default column setup, and users can customise visible columns and their order for that page, while filter results are shown directly beneath the list name. List pages matter because they are the primary interface for finding, reviewing, and acting on items efficiently, and understanding how they work is essential for both everyday users navigating their work and administrators configuring the platform for effective use.

Show 1 more pages

List permissions ​

List permissions control visibility of users, groups, and, in object-class security, the visibility of object classes in the platform. In Autologyx, they are used anywhere a user must see or select users or groups—such as User Type Class fields, dropdown autocompletes, filters, task assignee selection, default assignees in Sequences, and ownership-related configuration—and they are also the permission that makes an Object Class appear in System Configuration and in a user’s record list. For users and groups, list permission is tied to User Group Permission Sets: if a user can view a user or group, they can also list it, and listing a group includes its members for selection across the system. List permissions matter because they determine what people can find, choose, and administer in day-to-day work and configuration, and they are also a prerequisite for some higher permissions, including Edit and Delete at the class-permission level.

list records permission ​

List records permission is the class-level permission that allows a user to see and browse existing records for a child class in relational record controls across the Autologyx workspace. It is used in components such as child lookup controls, child record selectors, and other child class components when associating existing child records with a parent record. This permission matters because it determines whether users can access selectable records in these controls and influences the messages shown when no records can be presented, making it a key part of configuring secure, usable record relationships alongside view class, create records, and edit records permissions.

list view ​

List view, also called the traditional list view, is the tabular record-display mode used in the Records list in Autologyx workspaces, where users browse records by Object class, filter them, and select a record to open related details in the side panel. It sits alongside card view as an alternative presentation option that users can switch between from the records interface. For configuration admins, list view matters because Object class display settings control how object records are shown in the list view, as well as in card and summary views, which directly affects which fields users see when creating, editing, and reviewing records. This makes list view an important part of both everyday record handling and the configuration of record presentation across the platform.

listing pages ​

Listing pages, also referred to as list pages, are the Autologyx screens that display records in a tabular list view. For end users, they are used wherever items need to be reviewed and scanned across the platform, and their display can be controlled centrally through My account using the Row density setting. Changing row density updates all listing pages to use the selected layout option, such as Compact or Default, which changes row and header height across these views. This matters because it lets users tailor how much information is visible on screen and create a consistent browsing experience across all list-based pages.

live system ​

In the Autologyx platform, the live system is the production Catalyst environment used for operational, real-world execution after configuration has been developed and tested elsewhere, typically in a dev system. It is used whenever configurations are migrated into production, particularly in System Migrations where objects such as Authentication Objects are matched by name between dev and live environments. This matters to Configuration Admins and Super Admins because the live system holds the production-specific settings needed for integrations and API configuration, and migrated configuration does not overwrite those environment-specific values; instead, correctly named objects in the live system ensure the migrated configuration connects to the right production services.

Local Variable Actor ​

A Local Variable Actor is a Sequencer actor used within an Autologyx Sequence to evaluate logic and store data for reuse later in that same Sequence. Configuration admins and developers add it from the Actors panel onto the Sequence canvas and configure it in the actor configuration panel to execute Jinja expressions, traverse relational parent and child record data, and create values that can be referenced through merge fields by later steps. Unlike record-update or trigger-driven actors, it does not update records or initiate events; its purpose is to prepare and hold intermediate values that support downstream processing. This matters because it lets sequence designers centralise calculations, data shaping, and reusable variables inside the workflow, which simplifies integrations, reduces repeated configuration, and improves control over how data is passed between actors such as API Call actors and other sequence steps.

local variables ​

Local variables are Sequencer actors used in the Autologyx platform to store values during sequence execution so they can be referenced by later actors and conditions within the same workflow. They are configured in Sequences by defining a variable name and value, and are used across API Calls, Send Message actors, Loop actors, Trigger conditions, and other sequence logic through merge field syntax such as variables.Variable. Local variables support static values, object and record merge fields, constants, loop-driven values such as loop item and loop counter, and Jinja2 expressions, including namespace patterns for carrying values across loops or blocks. They matter because they let configuration admins and developers capture outputs from earlier steps, preserve state, build dynamic requests and messages, control branching and gating logic, and test runtime values directly in the Sequencer without running the full flow.

Show 11 more pages

local variables in Sequencer ​

Local variables in Sequencer are values available within a Sequencer loop context that can be inserted into generated content by using dedicated merge fields. In Autologyx, they are used in Sequencer configurations where loop-based steps produce documents, text, or other template-driven outputs, and from Catalyst 1.14 they are exposed through merge fields such as {{ loop item }} for the current local variable value and {{ loop counter }} for the current iteration number. This matters to Configuration admins and Developers / Integrators because it allows loop-specific data to be referenced directly inside Document Templates and other merge-field-enabled content, making repeating workflow steps easier to configure, more dynamic, and more accurate without hard-coding values for each iteration.

locked object classes ​

Locked object classes are object classes in the Autologyx Relational modeller that cannot be repositioned on the canvas because the relationship between them is already in use by existing records. In the relational model editor, these object classes are identified by a padlock icon, and when you interact with the related relationship the tooltip explains that it cannot be moved. This matters to Configuration admins and Super Admins because it shows that parts of the model are constrained by live data, helping them understand why certain relationship changes are blocked and preventing edits that would disrupt records built on that structure.

logged in user auth tokens ​

Logged in user auth tokens, also called auth tokens, are authentication credentials automatically exposed by the Autologyx platform to hosted Elements through the platform’s pub/sub event mechanism. In the Elements context, these tokens are one of the limited runtime values made available alongside items such as the current record ID, allowing isolated embedded components to identify and act on behalf of the currently signed-in user without direct access to the surrounding page context. This matters to developers, integrators, and configuration administrators because it defines the supported way for an Element to receive user authentication information needed for secure interactions with connected services or platform-aware functionality while preserving the isolation model of the host application.

login page ​

In Autologyx, the login page is the platform’s sign-in screen and forms part of the configurable Theme within System configuration. It is used wherever users access the platform to authenticate, and administrators can tailor its presentation through theme settings, including specific text overrides for the page alongside branding elements such as logo and colours. This matters because the login page is a key entry point to the platform, and configuring its content and appearance helps organisations present consistent branding and clear sign-in messaging to users.

Logout URL ​

Logout URL, also referred to as the Front channel logout URL, is the Autologyx-provided sign-out endpoint used when configuring single sign-on integrations with identity providers such as Azure AD and Okta. It is entered in the identity provider’s logout or sign-out redirect settings so that, when a user signs out, the provider calls back to Autologyx at the correct URI. In the platform’s SSO configuration guidance, this value is supplied alongside the Redirect URI and is used in provider fields such as Azure’s Front channel logout URL and Okta’s Sign out redirect URIs. This matters because it ensures sign-out flows return users to Autologyx correctly and keeps the single sign-on experience aligned with the platform’s authentication configuration.

Lookup field ​

In the Autologyx Relation Lookup actor, the Lookup field is the configuration setting that determines the direction of the relationship search in the platform’s relational model. It is used in the Relation Lookup configuration window, where an administrator selects either Children or Parents to control whether the actor retrieves records related below or above the current record in the hierarchy. This setting matters because it defines which connected records are returned as matched records and therefore directly affects how relationship-driven automation, data retrieval, and process behaviour are configured.

Lookup Parents ​

Lookup Parents is a Relation Lookup actor setting in Autologyx that changes the lookup scope from selecting a target object class to searching parent records related to the current item. In the Relation Lookup configuration window, selecting Lookup Parents causes the Class field to be left blank because the actor derives the lookup from the existing parent relationship rather than from a configured class selection. This matters to configuration administrators and Super Admins because it determines how matched records are found, how relation-based automation behaves in a sequence, and whether the lookup is driven by object hierarchy instead of an explicitly chosen object class.

Loop actor configuration ​

Loop actor configuration is the setup used to define the data source that a Loop actor iterates over in an Autologyx workflow. In practice, configuration admins use it when adding a Loop actor to select one of the supported sources—such as a JSON array returned by another step—and identify the specific array or collection to process, often using tools and fields such as JSON Explorer, a JSON Path field, Document Picker, or local variables. This configuration matters because it controls what items the Loop actor turns into individual iterations, which directly determines how downstream actors receive and process repeated inputs across documents, API responses, AI actor output, or other structured workflow data.

Loop actors ​

Loop actors are sequence actors in Autologyx that iterate through a list source and process each item one at a time within a workflow. They are configured in the Sequencer to loop over selected documents, JSON arrays returned by a tested API call, or other supported list-based inputs, creating controlled, auditable repetition without custom code. Loop actors matter because they enable bulk and list-driven automation such as processing document sets or API results consistently, while also establishing loop context for downstream configuration through features such as Loop Item sources in Local Variables and the {{ loop item }} and {{ loop counter }} merge fields. This loop context lets administrators and integrators reference the current item and iteration number in subsequent actors, which is essential for building scalable, ordered, and dynamic workflow logic.

Show 2 more pages

Loop filters ​

Loop filters are the filter conditions available in the Loop actor when the loop source is an API Call or a local variable that returns a JSON array. They are used during configuration to narrow the selected array before iteration, so only items that match the defined criteria are processed—for example, restricting the loop to records with a specific status. In practice, configuration admins and developers use loop filters alongside the JSON Path field and JSON Explorer to target the correct array and then apply rule groups such as all following rules or any following rules to control which elements are included. This matters because loop filters make process execution more precise, reduce unnecessary iterations, and ensure downstream actions run only for the relevant items in the source data.

Loop Item ​

Loop Item is the merge-field context object that represents the current entry being processed in a Loop actor iteration in Autologyx. It is used in workflow branches triggered by When Loop Item Processed, where each item from the loop source becomes its own actionable context for downstream actors, merge fields, and automation logic. In practice, Loop Item appears in the merge field picker as “Loop Item,” can expose the full structure of the source data, and supports access to item properties such as document metadata through expressions like {{loop item.name}} or the full item through {{loop item}}. It is also available as a source in the Local Variable Actor, but only when that actor follows a Loop actor on the Loop Item Processed trigger. This matters to configuration admins because Loop Item is the mechanism that lets a flow process array entries one by one, pass item-specific data into actors, generate per-item outputs, and build repeatable logic for documents, messages, tasks, approvals, and other item-level actions.

Loop Item merge field ​

In Autologyx, the Loop Item merge field is the dynamic merge field made available inside a Loop actor to expose the current item being processed on each iteration. It appears in the merge field picker as "Loop Item" and automatically reflects the structure of the source data being looped over, such as items returned in a JSON array from an API Call. This lets configuration admins and end-users reference fields from the current looped record without manually recreating its schema, typically when mapping values into actions, documents, messages, or local variables within the loop. The Loop Item merge field matters because it is the primary way to access per-item data during iteration, enabling reusable configurations that process each record in a collection accurately and consistently.

Loop Item Processed ​

Loop Item Processed is a trigger used in Autologyx when an Actor is configured to run once for each item produced by a preceding Loop Actor. It is used in downstream Actor configuration to execute logic at the point each individual loop item has been handled, rather than waiting for the whole looping activity to finish as with Actor Completed. This trigger is especially important for configuration admins and developers when building per-item processing, because it exposes loop-item context to downstream Actors and enables features such as the Local Variable Actor’s Loop Item option, allowing values to be captured or transformed for each item independently within a workflow.

mail service ​

In Autologyx, a mail service is the outbound email provider type selected in Outbound mail setup to define how the platform sends email and which authentication method and provider-specific options apply. It is used by configuration and super administrators when answering the mail service selection question in the communication configuration area, for example choosing Microsoft Office 365 Exchange (Graph) with OAuth 2.0 for Microsoft-based delivery. The selected mail service determines the integration path for outbound email while retaining the standard connection fields such as host and port, and it matters because it controls compatibility with the chosen provider, supports secure modern authentication, and ensures outbound notifications and other platform-generated emails are configured correctly.

mail service credentials ​

Mail service credentials are the authentication details entered in Autologyx Administration to connect the platform to the mail service used for sending system emails. They are configured by Super Admins or other users with the relevant administration permissions in the outbound mail setup area of the Administration section, typically alongside other platform-level configuration tiles. These credentials matter because they enable Autologyx to authenticate with the selected mail service and deliver emails generated by the system, making them a required part of setting up and maintaining email functionality across the platform.

main content window ​

In Autologyx, the main content window, also called the main content area, is the central workspace region where the active page, form, or record interaction is displayed. It is used when users open create or edit record display forms and when navigating between related records, such as creating a child record from a parent record, where the new record form replaces the previous modal or view in the main content area. This area matters because it is where users complete primary tasks, review record details, and continue navigation using surrounding interface elements such as breadcrumbs, making it the focal point for day-to-day work in the platform.

The main navigation menu is the primary top-level navigation control in the Autologyx platform, used to access major areas such as Administration and System configuration. It appears throughout the application as the starting point for moving to specific configuration pages, for example opening Standard authentication under Administration or Object classes under System configuration when creating document templates. For Configuration admins and Super Admins, the main navigation menu matters because it provides the entry point to core setup and management tasks, helping users locate the correct functional area before selecting the detailed pages and tools needed to configure platform behaviour.

main sequence ​

In Autologyx, the main sequence, also called the starting sequence, is the primary workflow that runs for a record in an object class and controls the core progression of that case or process. It is used in sequence design and configuration as the parent flow from which additional steps, escalations, or sub processes can be triggered, including Sequence Runner actions that operate on Self records in the same object class. The main sequence matters because it provides the central path for shared business checks and decision points, and it defines how related sub processes return to the primary workflow through rejoin points such as outcome fields updated by tasks, ensuring the record continues at the correct next stage.

Manage ​

In the Autologyx platform, Manage is the action used to open an existing configuration area, list, or settings page where a user with the appropriate permissions can maintain existing items by editing or deleting them. It is used across Administration and System configuration, including administration tiles such as Users and Roles and settings pages such as Single sign-on and Sequence properties or design. Manage matters because it distinguishes ongoing administration of existing configuration from actions such as Create or Configure, helping Configuration admins and Super Admins navigate directly to the correct maintenance view for operational and system setup tasks.

Manage assignees ​

Manage assignees is the action in Autologyx used to open the assignee management interface for a permission set, where administrators add or remove the users or user groups assigned to that permission set. It is accessed from the kebab menu or Actions menu in areas such as User group Permissions and Object class Permission set configuration, opening either a Manage assignees tab or a right-hand panel depending on the page. This function matters because assignees determine who receives the access defined by a permission set, making Manage assignees a key control for applying custom, additional, and class permissions to the correct people and groups. It is primarily used by Configuration admins and Super Admins, including eligible User group Owners who are allowed to manage permission sets and their assignees.

Manage Assignees panel ​

The Manage Assignees panel is the configuration interface within a Class Permission Set where administrators review and maintain the users and user groups assigned to that permission set. It is accessed from the Class Permission Set configuration area and works with the platform’s group-based permission system to show current assignees and support changes to who receives the set’s view permissions. This panel matters because it is the control point for keeping permission assignments accurate at scale, allowing Configuration Admins and Super Admins to manage access consistently for individual users and group-based assignments from a single place.

Manage assignees side panel ​

The Manage assignees side panel is the configuration interface in Autologyx used to add or remove assignees from a class permission set on an Object class. It is opened from the Permissions tab when configuring class permissions, either by selecting Add assignees or by choosing Manage assignees from the kebab menu on an existing class permission set. This side panel matters because it is where configuration and Super Admin users control which users, groups, or other assignable entities are attached to a permission set, directly determining who receives the access defined for that Object class and ensuring permissions are applied to the correct assignees.

Manage assignees tab ​

The Manage assignees tab is an administration interface in the Autologyx platform used when editing user group permissions to control who is assigned through two sub-tabs: Users and User groups. It is used by Configuration admins and Super Admins as part of permission management, alongside permission sets and custom permission sets, to add, review, or update the users and groups associated with a configuration. This tab matters because assignee membership determines which people or groups receive access through the relevant permission structure, making it a key point for maintaining accurate security and access administration.

Manage default task assignees panel ​

The Manage default task assignees panel is the side stack panel used in Sequence Properties to view and maintain the default task assignees for a sequence in Autologyx. Opened from the Manage default task assignees button on the Sequencer tab during sequence design, it displays assignee tiles that can be added or removed, updates the default task assignees counter, and controls which user avatars are shown alongside the button in the main content area. This panel matters because it is the primary configuration point for setting who is assigned by default to tasks generated by the sequence, helping configuration admins and Super Admins ensure work is routed correctly and visibly at design time.

Manage owners ​

Manage owners is the side panel opened from the Actions menu (kebab menu) while editing an Object class permission set, used to add and remove the users who are designated as owners of that Object class. It is primarily used by Configuration admins and Super Admins when maintaining class permissions in the Data Model, and it updates both the owner count shown in the panel and the Owners column in the Object class list as changes are made. This control matters because ownership governs who can administer the class, and removing yourself has immediate access consequences: Super Admins remain in the panel, while standard users can lose edit access to the Permissions tab or be returned to the Landing page, depending on their remaining class permissions.

mandatory fields ​

Mandatory fields are task fields in Autologyx that must be completed before a user can finish the task. They are used within task forms presented in experiences such as Catalyst, where the platform checks that all required information has been entered before allowing completion. For end users, mandatory fields matter because the Complete button remains disabled until every required field is filled in, and the interface indicates this with a tooltip stating that mandatory fields are not complete. For administrators and process designers, marking fields as mandatory is important because it enforces collection of essential data and helps ensure tasks are completed with the information the process requires.

Manual ​

Manual is a Task creation mechanism in Autologyx that identifies task templates users can create on demand for a record from the Tasks tab or side panel, rather than having the platform generate them automatically. It is used when configuring task templates and determines which templates are available in the standard user interface for ad hoc task creation, including task types such as Complete self-contained form and Update object record. For manual tasks, the assignees are selected at the time the task is created, and additional instructions can be provided to guide the recipient. This matters because it controls how work is initiated, which task templates users can choose from when working on records, and how administrators design flexible, user-driven processes for end-users, including 1-time completion users.

manual document automation ​

Manual document automation is an in-context document creation capability in the Autologyx platform that lets users generate documents manually from within a specific record by surfacing available document automation templates in the record sidebar. Introduced in Autologyx Catalyst, it is used where end-users need to create documents directly in the flow of work and where configuration admins need templates to be available in the correct record context alongside related document handling features, including Sequencer and Create task actor-driven processes. This matters because it brings document generation into the record experience, reducing navigation, keeping work tied to the correct case or matter data, and enabling controlled use of approved templates at the point where documents are needed.

manual generation ​

Manual generation is a document-template capability in Autologyx that allows users to create a document on demand from a configured template directly from a record. When a configuration admin enables manual generation on a document template, that template is exposed in the record’s Templates tab within the side panel for the relevant object class, where end-users can generate the document and either download it or save it into the configured field. This matters because it gives administrators precise control over which templates are available for user-initiated document creation, while enabling end-users to produce the required document at the point of work and repeat the generation process as many times as needed.

Manual Generation Of A Document From A Template ​

Manual Generation Of A Document From A Template is an Autologyx document-template capability that lets a user generate a document on demand for a specific record, rather than having it created automatically by the Sequencer. It is enabled when configuring a document template, using the radio button that allows manual generation, and is then used from the relevant record’s Templates tab in the side panel. This matters because it gives end-users and configuration admins controlled, record-level access to produce documents only when needed, while ensuring the output is driven by the configured template and its merge fields. It is closely tied to document template setup and management, including creating and editing templates, the document templates list and tab, and related document-generation tools such as the Catalyst Word Add-in.

Manual Tasks ​

Manual Tasks are user-created tasks in the Autologyx platform that are added directly from the Workspace for a specific Object record, rather than being generated automatically by the Sequencer as part of a workflow. They are created from task templates whose task creation mechanism is set to Manual, and users can select assignees when creating them, including re-assigning them to available users for that record. Manual Tasks are used in the Task Panel and related task views, where users view, complete, and manage work items, and they matter because they provide a controlled way to initiate ad hoc work on records while still applying the task type, permissions, assignee rules, and template configuration defined by administrators.

:::

mapped during a System Migration ​

In Autologyx, mapped during a System Migration means that when configuration is promoted from a dev system to a live system, referenced objects such as Authentication Objects are linked to their corresponding existing records in the target system rather than having their target-side settings replaced. This behaviour is used during System Migrations, particularly where integrations such as DocuSign depend on environment-specific authentication configuration. It matters to Configuration Admins and Super Admins because it preserves live authentication details while still maintaining the relationship between migrated configuration and the correct target-system objects, helping ensure deployments do not overwrite environment-specific connection settings.

Markdown ​

Markdown in Autologyx is a text field display option that lets content be authored and presented using Markdown formatting instead of only standard single-line or multiline text. It is used when configuring text fields and is supported in create/edit record forms and task forms, where users can work with the Markdown as source code for editing or view it as rendered text for easier reading; elsewhere in the platform, such as record list columns, Markdown fields display the source code by default. This matters because it gives configuration admins more control over how structured rich text is captured and shown, while helping end-users create, read, and maintain formatted content more effectively within forms and records.

Markdown fields ​

Markdown fields are Autologyx text fields configured to store Markdown-formatted content, allowing users to work with either the underlying Markdown source or rendered rich text depending on where the field is shown in the platform. They are used in create/edit record forms and task forms, where Markdown content can be viewed in an editing-friendly source format or as rendered text for easier reading, and they can also appear in record list columns and other interface areas, where the content displays as source code by default. Markdown fields matter because they let teams capture structured, readable content within records and tasks while preserving direct access to the markup needed for editing, and the platform’s automatic height adjustment for Multiline and Markdown textboxes improves usability when working with longer content.

Matched Records ​

Matched Records is a field available in sequence trigger conditions that represents the number of records returned by a Relation Lookup actor. It is used when configuring workflows that depend on relational data, including patterns where a Relation Lookup actor feeds a Sequence Runner actor, so that later workflow steps run only when the required number of related records has been found. This matters because it gives configuration admins precise control over workflow progression in the relational model: for example, preventing document generation or child-sequence execution when no related records exist, or allowing processing only when the count is greater than zero or equals a specific value.

max tokens ​

Max tokens is a standard AI model control in Autologyx Sequencer that sets the maximum number of tokens an AI request can generate in its response. It is used when configuring AI-enabled steps and actors, alongside options such as model selection, temperature, and authentication, including integrations such as OpenAI GPT and AWS Bedrock. This setting matters because it directly governs response length, helping configuration admins and developers control output size, manage how much content a model returns for a task, and align AI behaviour with the needs of the workflow.

Maximum Length ​

Maximum Length is a model configuration setting used on an AWS Bedrock actor in Autologyx to define the upper limit for the response generated by the model. It is configured alongside other generation controls such as Stop Sequences, temperature, Top K, and Top P, and is used when administrators or integrators set up actors that call Bedrock models. This setting matters because it prevents overly long outputs, helping keep responses aligned with the intended task, easier to process in workflows, and better controlled for downstream use in the platform.

maximum number of Authentication objects ​

The maximum number of Authentication objects is the system-wide limit on how many authentication configurations can be created in an Autologyx environment; in Autologyx, this limit is 100. It is relevant when administrators create and manage Authentication Objects in system configuration, including integrations such as DocuSign that require a dedicated authentication object. This limit matters because it defines the available capacity for storing connection and credential configurations across the platform, so Configuration admins and Super Admins must plan, organise, and govern Authentication Objects carefully to ensure sufficient space for current integrations and future setup requirements.

Media tab ​

The Media tab is the default tab on the Configure Theme page in Autologyx, opened when an administrator selects Theme in system configuration. It is used as part of theme setup and management, alongside other theme configuration areas such as the Colours tab, to define the visual assets that contribute to the platform’s branded appearance, including items such as the Autologyx Catalyst logo. For Configuration admins and Super Admins, the Media tab matters because it is the entry point for controlling the media elements of a theme and forms part of the overall configuration used to deliver a consistent, organisation-specific user experience across the platform.

Members ​

Members is one of the three default permission sets created automatically for every Autologyx User Group, alongside Owners and Everyone, and it applies to all users who belong to the group except those designated as Owners. In User Group Permissions, configuration admins and super admins use the Members permission set to control what standard group members can do with the group, such as viewing the group, its membership, and its permissions, and optionally granting broader interaction where required. This permission set is also significant across the platform because group visibility allows members to be listed and selected in places where users or groups are used, including task assignment, default task assignees, ownership, record and object class permission sets, user type fields, and other group-based configuration. Understanding Members is essential when configuring access and visibility, because it defines the baseline experience for users inside a group and directly affects how that group and its users can be discovered and used throughout the system.

Show 1 more pages

Members ​

Members is a configurable column on the User Group List in Autologyx that shows the total number of users in a user group, including users assigned as Owners. It is added through the column configuration link on the User Group List and is primarily relevant to Configuration Admins and Super Admins who manage group structure and access. This value matters because it provides an immediate view of group size for administration, helping users review group composition, distinguish it from the separate Owners count, and support tasks such as auditing, maintaining, and managing user groups.

Members filter ​

The Members filter is the default membership view on the User group edit page in Autologyx. It is used on the Membership tab, alongside the Non members and Owners filters, to display the users who currently belong to the selected user group. Configuration admins and Super Admins use this filter when reviewing group composition, checking the current member count and owners shown on the page, and managing membership and ownership changes such as promoting members to owners or removing users from the group. This filter matters because it provides the primary view of who is already included in a user group, which is essential when configuring access, maintaining accurate group membership, and switching to the Non members view to add additional users with actions such as Add as members.

Membership tab ​

The Membership tab is the user group configuration tab in Autologyx where administrators manage who belongs to a group and identify group owners. It is used when creating or editing a user group in Administration, alongside the Permissions tab, and shows the current members of the group; when a new group is created, the creator is automatically added as both a member and an Owner. This tab matters because group membership controls which users are included in the group structure used across the platform, while owner assignment determines who is responsible for managing that group.

merge field dropdown ​

Merge Field Error ​

A Merge Field Error is an error raised when Autologyx cannot correctly parse or render merge field syntax in configurable content, such as templated values used by the API Call Actor when building requests to external systems. In practice, this occurs when a merge field or Jinja-style statement is malformed—for example, when required syntax characters are missing—causing the platform to fail when resolving dynamic data at runtime. This term is most relevant when configuring integrations, debugging API Call Actor behaviour, and reviewing activity logs to identify why a request or automation step did not execute as expected. It matters because merge fields are used to insert process data into configuration, and any syntax error can prevent outbound calls and other automated actions from completing successfully.

merge field syntax ​

Merge field syntax in Autologyx is the template expression format used in Document Templates to insert dynamic record data and, with the new merge field syntax, embed the full content of a file stored on a record directly into a generated .docx document at the exact location of the field. It is used during dynamic document assembly in .docx merge fields, including expressions such as {{ record.field[index].embedded }}, where the path identifies the record field, item index, and embedded file content to include. This matters to configuration admins and end-users because it provides precise control over how document content is assembled, enabling templates to pull in stored files as part of the final document output and making generated documents more accurate, structured, and fit for the business process.

merge fields ​

Merge fields are Autologyx placeholders written in Jinja syntax that resolve at runtime to values from records, related object class fields, record properties, users and groups, company details, local variables, loop context, dates, and other available system data. They are used throughout the platform wherever dynamic content is assembled, including Document Templates, Send Message actors, Local Variable actors, API Call actors, Sequencer steps, Word Add-in document authoring, GPT prompts, and image-enabled document generation. Merge fields matter because they are the core mechanism for personalising documents, messages, payloads, URLs, and workflow logic with live platform data, allowing administrators and integrators to build reusable templates and automations that adapt correctly to each record, relationship, and looped iteration without hard-coded values.

Show 23 more pages

merge in the correct variable ​

In Autologyx, "merge in the correct variable" means inserting a platform variable token into a configuration field so the runtime value is passed automatically when the step executes. This is commonly used by configuration admins and developers when building actor settings such as API endpoint URLs, message payloads, or update actions, where values like a DocuSign envelope ID, envelope status, authentication object, or other local variables must be referenced dynamically instead of entered as fixed text. In the DocuSign monitoring pattern, the correct variable is merged into the envelope URL so the actor calls the specific envelope created earlier in the process. This matters because correct variable merging ensures integrations target the right record, carry forward data between steps, and keep automated workflows accurate, reusable, and maintainable.

message data ​

Message data (messageData) is the structured payload that Autologyx passes from Catalyst to an Element’s application iframe so the Element can receive the context and configuration it needs to run on a form. It is used when configuring and rendering Elements, where values entered in Element configuration are included in the message data and, when the Element is used on an object class form, related identifiers are also supplied through object record meta such as record IDs. This matters to configuration admins and developers because message data is the standard mechanism for supplying runtime information to embedded Element code, enabling the iframe to initialise correctly, read configured parameters, and interact with the current form and record context through the expected event-listener pattern.

message templates ​

Message templates are reusable predefined message bodies used in the Autologyx platform to generate outgoing notifications and communications. In Administration, they work with merge fields populated from configured company details, allowing standard content such as organisation information to be inserted automatically into messages. This matters for Configuration admins and Super Admins because message templates help enforce consistent wording, branding, and data usage across platform-generated communications while reducing manual editing and configuration effort.

Method ​

In Autologyx, Method is the HTTP request type configured on an API Call actor to define how the platform communicates with an external system. It is used in system configuration when building API integrations, alongside settings such as the API Call name, URL, and Authentication, and supports standard HTTP verbs including GET, POST, PUT, PATCH, and DELETE. The selected method controls whether the call retrieves data, creates a resource, replaces or partially updates a resource, or deletes a resource, and therefore directly determines how request data is sent to the target service and what action the external endpoint performs. For configuration admins and developers, setting the correct Method is essential to ensure an API call behaves as intended and interacts safely and correctly with connected systems.

Microsoft authentication object ​

A Microsoft authentication object is an Autologyx Catalyst configuration object used to connect the platform to a Microsoft account through the client credentials flow. It is used in integration and API call contexts, including with the API Call actor, to provide the authentication details required for Catalyst to access Microsoft-backed services as part of automated business processes. This object matters because it centralises and standardises how Microsoft connectivity is configured, making it simpler for configuration administrators, developers, integrators, and super admins to enable secure, repeatable Microsoft integrations across the platform.

Microsoft Client Credentials ​

Microsoft Client Credentials are the Microsoft application identity details used in Autologyx administration to connect the platform securely to Microsoft services without relying on an individual user account. In the Communication area, they are used when setting up integrations such as outbound mail and other Microsoft-backed communication or authentication features, where Autologyx must authenticate against Azure AD or Microsoft 365 as a registered application. These credentials matter because they enable secure service-to-service access, support centrally managed configuration, and ensure that communication and related Microsoft integrations operate reliably under an administrator-controlled identity rather than a personal mailbox or user login.

Microsoft Client Credentials Authentication Object ​

A Microsoft Client Credentials Authentication Object is an Autologyx configuration object that stores the Microsoft OAuth 2.0 client credentials used to authenticate the platform with Microsoft Office 365 Exchange (Graph) for outbound mail. It is used during Outbound mail setup when the selected mail service is Microsoft Office 365 Exchange (Graph) with OAuth 2.0, where administrators must select an existing object to supply the connection details for the Azure-backed Microsoft integration. This object matters because it centralises and standardises the authentication configuration required for sending email through Microsoft services, enabling configuration admins and Super Admins to connect outbound mail reliably and reuse approved credentials across the platform.

Microsoft Client Credentials Settings ​

Microsoft Client Credentials Settings are the connection fields used in Autologyx when configuring outbound email to send through Microsoft using an authentication object that implements the OAuth 2.0 Client Credentials flow. In the Outbound mail setup, after selecting the relevant Microsoft authentication object, administrators complete this section by entering the Host, Port, and Username, with TLS enabled by default. These settings matter because they define the technical endpoint and sender details that Autologyx uses to connect to Microsoft mail services, and they must be completed correctly for outbound email delivery and mail configuration testing to work as expected.

Microsoft integration ​

Microsoft oAuth 2.0 (Client Credentials flow) ​

Microsoft oAuth 2.0 (Client Credentials flow) is an Autologyx authentication provider used to create an Authentication Object that connects the platform to Microsoft services using application credentials rather than a user sign-in. It is selected from the Provider list when configuring Microsoft authentication, including outbound mail setup for Microsoft integrations such as Office 365 Exchange via Graph, and requires the associated client credentials configuration such as the Client ID, Client Secret, and Microsoft Client Credentials Settings. This provider matters because it enables secure service-to-service authentication for platform features that need to access Microsoft resources in the background, and it gives Configuration admins and Super Admins a standard way to manage and reuse Microsoft authentication settings across relevant integrations.

Microsoft OAuth in Outbound Mail Setup ​

INSUFFICIENT_EVIDENCE

Microsoft Office 365 Exchange (Graph) ​

Microsoft Office 365 Exchange (Graph) is the Autologyx outbound mail integration option for sending email through Microsoft 365 Exchange by using Microsoft Graph with OAuth 2.0 authentication. It is used in outbound mail setup, where configuration administrators and Super Admins select and configure the mail provider and its associated Authentication Object, and it works with the platform’s API Call actor to authorize and send messages through Microsoft’s modern authentication model. This option matters because it provides a supported replacement for Basic Authentication as Microsoft retires legacy methods, helping organisations maintain secure, compliant, and reliable outbound email delivery from Autologyx.

Microsoft Office 365 Exchange (Graph) with oAuth 2.0 ​

Microsoft Office 365 Exchange (Graph) with OAuth 2.0 is the outbound mail service option in Autologyx for sending email through Microsoft 365 Exchange using Microsoft Graph and OAuth 2.0 authentication. It is selected in Outbound mail setup under the mail service choice and, when used, requires an existing Microsoft Client Credentials Authentication Object to supply the Microsoft client credentials for the connection. This is the recommended Microsoft mail configuration in the platform and is important for configuration administrators and Super Admins because it enables supported, secure integration with Microsoft 365 for platform-generated outbound email and forms part of the standard setup and testing process for mail delivery.

migrated to live ​

In Autologyx, migrated to live describes the action of promoting a configuration item from a non-live setup into the live environment so it can be used with production service credentials and operational processes. This term is used in system configuration, particularly when preparing Authentication Objects such as a DocuSign Authentication Object, where an item created for initial setup or testing is moved into live use and then updated with the details of the live external account. For Configuration Admins and Super Admins, this matters because migrating to live is the step that makes an integration ready for real business use, ensuring the correct production connection is configured and that the platform uses live authentication settings rather than non-production values.

milestone ​

In Autologyx, a milestone—also referred to as a designated milestone—is a specific point within a workflow or process that can be selected as the event that triggers automation. It is used in Sequence Runner trigger configuration, where administrators define whether a sequence should start on completion of a connected actor or when the process reaches a designated milestone. Milestones matter because they give Configuration Admins and Super Admins precise control over when automated actions occur, allowing trigger parameters to align automation with the intended stage of work and ensuring sequences run at the correct point in the lifecycle of a case or process.

Min and Max Users selection limits ​

Min and Max Users selection limits are configuration settings for User-type Class fields in Autologyx that define the minimum and maximum number of individual users that can be selected in a field. They are used in the form builder and Object Class Display Forms, including create/edit and card views, alongside related field options such as Required, Read only, Allow Selecting Individual Members, and Allow Syncing Group Members. These limits matter because they let configuration admins and Super Admins control how many user selections a field accepts, helping enforce data-entry rules, standardise form behaviour, and ensure fields capture the intended number of user assignments.

Min/Max Groups selection ​

Min/Max Groups selection is a configuration option for User-type Class fields in Autologyx that sets the minimum and maximum number of User Groups a user can select in a record. It is used by configuration administrators in the form builder, including Object Class Display Forms and create/edit views, as an additional control layer alongside settings such as Allow Selecting Individual Members, Allow Syncing Group Members, Required, Read only, and Min and Max Users selection limits. This setting matters because it enforces the intended structure of group-based assignments or access-related selections within a record, helping ensure users select the correct number of groups and that form behaviour aligns with the process design.

Min/Max input ​

Min/Max input is an object class field attribute in Autologyx that defines the minimum and/or maximum allowed input for supported field types. It is configured when setting up Document Fields within object classes, and its behaviour depends on the field type selected, as some field types support Min/Max input while others do not. This setting matters because it controls field-level validation at the point users enter or save data, helping configuration administrators enforce required length, range, or quantity constraints appropriate to the field and maintain consistent, valid record data across the platform.

minimum and maximum selections ​

Minimum and maximum selections are configuration settings on selectable fields, including User type fields, that define the least and greatest number of values a user can choose when creating or editing a record in Autologyx. These limits are used by Configuration Admins and Super Admins within field configuration to control how many entries can be selected, ensuring the field captures the required number of values without allowing too few or too many. This matters because it enforces data entry rules at the point of record creation and update, helping deliver a smoother, error-free user experience and more consistent record data.

Minimum or Maximum user/group selections ​

Minimum or Maximum user/group selections are configuration limits applied to User Type Class fields that control how many users or groups a person can choose when completing a task or form in Autologyx. These settings are used where User Type fields support selecting individual users, groups, or both, and they work alongside related options such as required fields, Search for users, Allow Selecting Individual Members, and Allow Syncing Group Members. For configuration admins, these limits define valid input and enforce the expected number of selections for a process step; for end-users, they provide clear guidance during selection so entries stay within the permitted range. This matters because it helps standardise assignment and participant selection, prevents over- or under-selection, and ensures the field is completed in line with the workflow design.

mixed operations ​

In Autologyx, mixed operations are a usage pattern of the Jinja shift datetime and shift date filters where multiple adjustment parameters are applied in a single expression, such as combining years, months, days, hours, minutes, and seconds for a datetime, or years, months, and days for a date. This is used in document templates and other Jinja-enabled configuration points when building calculated dates and timestamps, including scenarios that also use the business days option. Mixed operations matter because they let configuration admins and developers create complete date and time transformations in one filter call, making template logic simpler, easier to maintain, and more consistent when generating deadlines, due dates, schedules, and other derived values across the platform.

ML and AI Actors ​

ML and AI Actors are a System Configuration area in Autologyx used to define and manage AI-powered actors that can be invoked within configured solutions, including capabilities such as the OpenAI GPT Actor. They sit alongside other automation building blocks such as Sequence Actors, merge fields, and Catalyst APIs and Variables, and are used by configuration administrators and Super Admins when designing how the platform processes information and performs automated actions. This matters because ML and AI Actors extend standard workflow configuration with AI-driven behaviour, allowing solution builders to incorporate intelligent processing into business workflows as part of the overall platform configuration.

In the Autologyx platform, a modal is an on-screen dialog window that opens over the current form or page to present important information or require the user to acknowledge a message before continuing. Modals are used in interactive form components such as Child Object Classes, where they provide immediate feedback about system-enforced rules; for example, when a parent:child ratio of 1:1 has already been met, clicking the Create record or Search action opens a modal stating that the maximum number of related records has been reached. This matters to end-users because it clearly explains why an action is unavailable, and to configuration admins because it is part of how platform constraints and component behaviour are communicated within the user experience.

model configuration ​

Model configuration is the set of adjustable parameters on an AI actor in the Autologyx platform that controls how a selected model behaves for a specific use case. It is used when configuring actors, including the AWS Bedrock actor, where administrators and integrators define settings such as Maximum Length, Stop Sequences, temperature, Top K, and Top P to tune output style, length, and response behaviour. Model configuration matters because it allows teams to align model performance with workflow requirements, improving the consistency, suitability, and operational effectiveness of AI-driven tasks such as document classification, risk assessment, and automation within Autologyx.

model selection ​

Model selection is the Sequencer control used to choose which AI model an Autologyx AI step runs against. It is available alongside the standard AI configuration controls in Sequencer, where users can select the model, set parameters such as temperature and max tokens, and choose the Authentication Object used for requests. This setting matters because it determines which underlying AI engine is invoked for the step, directly affecting how the action is configured and executed, and it is therefore relevant to both configuration admins defining automations and end-users working with AI-enabled process steps.

model type ​

In Autologyx, model type is a configuration setting used on the Azure OpenAI actor to define the processing mode for an AI request. It determines whether the actor uses a Chat model to generate conversational responses, an Instruct model to follow task-specific instructions, or an Embeddings model to convert text into vector representations. This setting is configured before selecting the specific deployed model and directly affects which related fields and parameters are relevant, such as prompt and context fields, temperature, encoding format, endpoint values, and vector dimensions. Model type matters because it controls how input is handled, what output is produced, and whether the actor is suitable for use cases such as dialogue generation, instruction execution, or vector-based search and matching.

model version ​

Model version is the specific AI model selection configured for an OpenAI: GPT integration in Autologyx. It is used when setting up or maintaining the integration, alongside parameters such as context, temperature, and authentication objects, so that sequencer-driven workflows call the intended model through the platform’s API configuration. This matters because the configured model version determines which GPT model your workflow uses at runtime, allowing configuration admins and developers to align AI behaviour with the requirements of a given process, integration design, and operational standard.

Modified ​

Modified is the Object Record property that stores the date and time when a record was last updated in Autologyx. It is used in templates through the record property merge field syntax {{ record.modified at }} or via the {{ record }} shorthand when accessing record properties, alongside values such as ID and Created. This property matters to configuration admins and end-users because it allows generated documents, messages, and other template-driven outputs to show the most recent update timestamp for a record, helping communicate current record state and supporting date-aware content in configured solutions.

Modified at ​

Modified at is the system date and time field that records when a Record was last updated in the Autologyx platform. It is used in configuration areas that evaluate Record data, such as Sequence commencement conditions, where administrators can apply rules that trigger a sequence only when a Record has been updated at or relative to a specific point in time. This field matters because it enables time-based automation and filtering using the most recent change to a Record, helping ensure workflows start for the correct subset of Records and reflect current record activity.

Mortgage Application class ​

In Autologyx, the Mortgage Application class is a specific object class whose records can be selected when creating a manual task for an object record. It is used in the Create task workflow to scope task creation to Mortgage Application records, ensuring the task is attached to the correct business object in the workspace. This matters to end-users and configuration admins because object class selection controls which records are available in task creation, how work is organised around mortgage-related cases, and whether manual tasks are created against the intended record type.

Mortgage Reviewer ​

Mortgage Reviewer is a permission set example used in Autologyx record-permission configuration to define read-only access to specific object records and their associated tasks. In the Explanation of Record Permissions guidance, it is shown alongside the default Record Owner permissions and works in combination with the Class permission Object class > List on the Permissions tab. When a user is granted the Mortgage Reviewer permission set, they can view the object records covered by that set and view all tasks linked to those records, but they cannot edit or delete records or complete or delete tasks. This matters to configuration admins and Super Admins because it demonstrates how to separate ownership from controlled reviewer access, allowing users to inspect records and workflow activity without granting operational or administrative rights.

Most recent complete task ​

In Autologyx, Most recent complete task is a Delete Target option used in the Set Task actor configuration to remove the newest finished task on a record for the selected task template. It is used when configuring task deletion behaviour, alongside related targets such as Most recent task, Most recent outstanding task, All complete tasks, All outstanding tasks, and All tasks. This option matters to configuration admins because it lets them precisely clean up or reverse task history by deleting only the latest completed instance of a specific template, without affecting older completed tasks or tasks that are still outstanding.

Most recent completed task ​

Most recent completed task is a task-selection option used when configuring the Set Task Actor in Autologyx to target the latest created task for the selected task template on the record that triggered the actor, but only when that latest task is in a completed state. It is used in sequence actor configuration alongside options such as All completed tasks, All outstanding tasks, and Most recent outstanding task to control which existing task instance the action applies to, such as deletion or actor updates. This matters because it lets configuration administrators and Super Admins apply changes only to the newest completed task in the current record context, ensuring task actions are scoped precisely and preventing the configuration from affecting older tasks or outstanding work; if the most recent task is outstanding, the condition is ignored.

Most recent outstanding task ​

Most recent outstanding task is a deletion selection in the Set Task actor used when configuring task management for a specific task template on the record that triggers the actor. It targets the newest incomplete task created for the chosen template and removes that task; if the most recently created task is already completed, the condition is ignored and no task is deleted under this option. This setting matters to configuration admins because it provides precise control over task cleanup and reversal logic, allowing automations to remove the latest open task without affecting completed tasks or older outstanding tasks.

Most recent task ​

In Autologyx, Most recent task is a Delete Target option used when configuring a Set Task actor Delete action to remove the last created task for the selected task template, regardless of whether that task is complete or outstanding. It is used in task and sequence automation where multiple records of the same task template can exist, and it determines which single task instance the platform deletes. This option matters to configuration admins because it provides precise control over task cleanup and re-creation behaviour, helping ensure that automations act on the newest task record rather than deleting all matching tasks or a task filtered by completion state.

Ms Word Add In Configuration ​

INSUFFICIENT_EVIDENCE

multi level relationships ​

Multi line ​

In Autologyx Catalyst, Multi line is a form field input setting used in the form builder when designing intake forms and other record creation forms. It provides a larger text entry area for responses that require more detail than a short phrase or single sentence, in contrast to Single line, which is intended for brief entries. Configuration admins use this option when defining form fields so users can enter fuller descriptions, explanations, or other extended text in a way that matches the expected content. Choosing Multi line correctly improves form usability, helps structure data capture appropriately, and ensures record information is collected in the most suitable format for downstream use in the platform.

Multi select ​

Multi select is a configurable field type in Autologyx used on task forms and object class fields to present a predefined list of options as checkboxes, allowing users to choose more than one value. It is used where a record or task needs to capture multiple selections from a controlled set, and it supports up to 100 configured options. Unlike Single select, Multi select does not support a default value; instead, administrators can configure minimum and maximum selection limits to control how many options a user must or can choose. This matters because it provides a structured way to collect multiple valid values, improves consistency in user input, and enables configuration teams to enforce selection rules in forms and data models.

Multi select field type ​

A Multi select field type is an Object class field in the Autologyx Data Model that lets users select more than one value from a defined list of options on a record. Configuration admins use it when adding or editing fields from the Fields list and Edit field panel within an Object class, where they can maintain the available options and configure minimum and maximum selection limits. It matters because it controls how structured multi-value data is captured in records and how changes to the field behave over time: updates to minimum or maximum selections do not change existing records, but if those constraints become invalid after option changes, the field value is cleared.

multi select fields ​

In the Autologyx platform, multi select fields are a form field type used in Catalyst forms that let users choose more than one option from a predefined list, and they are always displayed as tick boxes so selected options are clearly visible. Configuration admins use multi select fields when designing intake and other record creation forms in the Catalyst form builder, particularly where several values must be captured in a single question. This matters because the field’s tick-box presentation affects form layout, user experience, and how options are presented to users when configuring forms and related conditional logic.

Multiline and Markdown textboxes ​

Multiline and Markdown textboxes are the input controls used in the Autologyx Create/Edit record form for entering and editing longer text content, including Markdown-formatted content and values held in text and JSON fields. These textboxes are presented wherever a record includes fields designed for extended written content, and in the current interface they expand to the full width of their containing column to provide more room to read, write, and maintain complex entries. They matter to both end-users and configuration admins because they directly affect the usability of record forms, making detailed content easier to author and review while improving the efficiency and readability of data entry for structured and free-form information.

Multipart Configuration ​

Multipart Configuration is the section of the API Call actor configuration in Autologyx where you define a multipart request by adding and managing multiple request parts within a single outbound API call. It is used when the request body must include a combination of file parts and text parts, with each part configured with the appropriate content settings such as Content Type and Content Disposition. This matters to configuration admins and developers because it enables integrations that require multipart/form-data payloads, including scenarios where documents selected through the Document Picker must be sent together with form fields or metadata, ensuring external services receive the request in the structure they expect.

Multipart Data ​

Multipart Data is a request body option in the Autologyx API Call actor that lets you send files together with standard form fields in a single HTTP POST request. In the configuration panel for an API Call actor, selecting Multipart Data opens a dedicated multipart configuration section, alongside other body types such as Form Data, JSON Data, XML Data, and Binary Data. This option is used by configuration administrators and integrators when connecting Autologyx to external services that require multipart/form-data payloads, such as DocuSign, media upload endpoints, and document management APIs. It matters because it gives precise control over mixed-content request composition, enabling compliant integrations where APIs expect both uploaded files and accompanying metadata in the same call.

Multipart Data Support ​

  • Mostly relevant to: Developers / Integrators, Configuration admins
  • Closely related concepts: API Call actor, actors

Multipart Data Support is a capability of the Autologyx API Call actor that allows a request to be configured and sent as multipart form data, so a single outbound API call can include multiple discrete parts such as structured fields and file content in the format required by many external services. It is used when configuring API Call actor steps in workflows and integrations that need to submit complex payloads rather than a simple JSON or form-encoded body. This matters to developers, integrators, and configuration administrators because it expands the range of third-party endpoints the platform can connect to, supports APIs that require multipart request handling, and reduces the need for custom workarounds when building integrations in Autologyx.

Multipart Data Support in API Call ​

Multiple page configuration ​

INSUFFICIENT_EVIDENCE

multiple Relation Lookup and Sequence Runner actors ​

In Autologyx, multiple Relation Lookup and Sequence Runner actors in the same sequence means a sequence can include more than one Relation Lookup actor and more than one Sequence Runner actor to work with a record’s related data at different points in the flow. This is used when configuring sequences for relational records, where a Relation Lookup actor identifies related records and a Sequence Runner actor starts processing against those related records, including sub processes where required. This matters to configuration admins because it allows a single sequence to handle several sets of record relationships in an ordered, configurable way, enabling more complex automation across relational records without needing to split the logic into separate top-level sequences.

My account ​

My account is the personal account settings area in the Autologyx platform that each signed-in user accesses by clicking their name or avatar in the top-right corner of the screen. It displays core account information drawn from the user’s account record, including their avatar, name, and username, and provides self-service options such as updating the username and password. Changes made in My account are written back to the underlying user account, so they directly affect how the user signs in and how their account is identified across the platform; for accounts that have not yet been activated, changing the username also triggers a new activation email with a new token. My account matters because it is the main place end users manage their own login and personal account details, while administrators need to understand its relationship to the Users list and account types when creating, editing, or supporting user accounts.

Show 1 more pages

Name field ​

The Name field in Autologyx is a configuration field used to enter the identifying label or reference name for an item being set up in the platform. It is used in system configuration screens such as Sequence Actors, where administrators can update a label for a Record Access Actor or specify the ID and name of the sequence to be run in a Sequence Runner Actor. This field matters because it provides the primary human-readable identifier used when configuring, selecting, and maintaining platform components, helping administrators recognise the correct object and manage configuration accurately.

Namespace in Jinja2 ​

In Autologyx, a namespace in Jinja2 is a persistent variable container used in merge-field expressions to retain and update values across loops and block scopes, where ordinary local variables do not persist in the same way. It is used in Document Templates and the Autologyx Sequencer when building document assembly logic, conditional logic, counters, flags, and aggregated data such as lists or dictionaries within template code. This matters to configuration admins and developers because namespaces enable reliable state management inside complex templates, allowing calculations, cross-record checks, and multi-step output logic to work correctly and consistently in generated documents and sequenced processing.

Namespace in Jinja2 for Local Variables ​

Navigation panel background colour is a theme setting in Autologyx that defines the background colour of the main navigation menu displayed on the left-hand side of the platform. It is configured on the Configure Theme page, within the Colours tab as part of the Additional colours options, using the standard colour control fields. This setting matters because it directly affects the appearance and usability of the platform’s primary navigation area, helping configuration administrators and Super Admins align the interface with organisational branding while maintaining a clear and consistent user experience across the application.

Navigator is a Sequence design tool in the Autologyx configuration workspace that opens an Outline modal in the top-right of the workspace to help administrators move around a workflow diagram. It is used when configuring Sequences, especially those that are very long or very wide, because it provides a compact overview of the workflow and makes it easier to locate and navigate to different areas of the design canvas. Navigator matters because it improves control and efficiency when editing complex workflow layouts, helping configuration admins work accurately within large Sequence designs.

Nested conditions ​

Nested conditions are conditional logic structures in Autologyx that place one If / Else condition inside another to evaluate multiple criteria in sequence when generating dynamic content. They are used in areas that support conditional logic, such as Document Templates and email body content, where merge fields and field values determine which text, sections, or outputs are shown. Nested conditions matter because they let configuration admins build more precise rules than a single basic condition, enabling complex template behaviour such as branching content for different combinations of case data while ensuring end-users see the correct, context-specific information.

New at Autologyx ​

New at Autologyx is the release-notes section of the Autologyx Catalyst Knowledgebase that provides a central entry point to product update information, including versioned Release Notes such as 1.16, 1.14, and earlier releases. It is used across the platform documentation as the place to review what has changed between releases, including new capabilities, updates, and other platform changes relevant to people using, configuring, administering, securing, or integrating Autologyx. This matters because it helps all audiences understand what is new in the platform, prepare for changes, align configuration and operational processes with the current release, and quickly navigate to the detailed notes for a specific version.

next item in the Sequence ​

In Autologyx, the next item in the Sequence is the immediate subsequent step that becomes active for a Record as it progresses through a configured sequence. This term is used in sequence configuration, particularly when defining Sequence commencement conditions that control whether progression should activate the following step for particular Records. It matters because configuration admins use these conditions to direct different subsets of Records into the correct route, ensuring that only Records meeting the defined criteria trigger the next sequence item and continue through the intended workflow path.

No value/default ​

In Autologyx, No value/default is a field-setting option used in the Update Record sequence actor when configuring how a record field should be updated. Selecting this option tells the platform to clear the target field instead of writing a static value, setting the field to blank or Null as appropriate for that field type. It is used when configuring updates to object class fields and properties, including scenarios such as resetting values in single select or user fields. This option matters because it gives configuration admins a controlled way to remove existing data during automated record updates, ensuring downstream logic, field state, and process behaviour reflect an intentionally empty value rather than a retained or overwritten entry.

No, go back ​

In the Autologyx platform, No, go back is the option shown in the warning message that appears when a configuration admin attempts to remove a field that controls conditional logic in a record or task form. It is used in the form designer during form configuration, specifically where fields determine whether other sections or fields are conditionally displayed. Selecting No, go back cancels the deletion and retains the controlling field and its associated conditions, which is important because removing that field would also remove the conditional logic that depends on it.

non active users ​

Non active users are user accounts in the Autologyx platform that have been created but are not yet activated, typically as part of delayed account activation. This state is used in user provisioning and account lifecycle configuration, particularly by Configuration Admins, Super Admins, and developers working with the activation API. Non active users are important because the platform blocks certain system-generated communications for these accounts, including emails sent by Send Message actors and task-related messages, until activation is completed. This helps ensure that accounts do not receive operational or workflow communications before they are fully enabled for platform access.

Non members ​

Non members is the user group list view that shows users who are not currently part of the selected group. In the Autologyx Administration area, when editing a User group, Configuration admins and Super Admins can switch the group list filter between Members, Non members, and Owners; the Non members filter is used to find users outside the group and add them as members, including through bulk actions. This matters because it is the primary view for managing group membership efficiently, especially when onboarding multiple users into a group or checking whether a user is already included before using member management actions.

Non members filter ​

Non members filter is the user group list view option used in Autologyx administration to display users who are not currently members of the selected group. In the user group screen, Configuration admins and Super Admins switch the list from Members to Non members to find eligible users to add, and the list includes all system users except those with a 1 time completion account type. This filter is used alongside actions such as Add as members and the Membership tab, and it matters because it helps administrators identify who is available for group assignment and manage group membership efficiently; when this filter is selected, the list shows 10 rows by default.

Notify ​

Notify is an API Call Actor configuration field in Autologyx used to specify an email address that receives a notification when an API call fails. It is configured in the API Call Actor within the system configuration area, alongside other call execution settings, and is relevant when setting up or maintaining integrations. This setting matters because it ensures integration failures are surfaced promptly to the right recipient, helping administrators and developers monitor API activity and respond quickly to issues that could disrupt automated processes.

Now option ​

In Autologyx, the Now option is a configuration available on task form fields that include a time component, allowing the field to be populated immediately with the current date and time or the current time when the user selects it. It is used in form inputs such as date/time and time-only pickers within task forms, where users need to capture the present moment quickly and accurately. This matters because it speeds up data entry, reduces manual typing, and helps ensure consistent timestamping for time-sensitive information such as meeting details, actions, or event records.

Numeric ​

Numeric is a Task Form field type in the Autologyx platform used to capture number-based input, including whole numbers and decimal values. Configuration admins select this input type when building or editing forms in Form Builder, where it is configured alongside related field settings such as the default value, description, and conditional visibility. Using the Numeric field type ensures that form responses are collected in a number format suited to calculations, validations, and process logic, making it important wherever users must enter quantitative values accurately and consistently.

Numeric field ​

A Numeric field is a form field type in Autologyx that captures number values and can be configured with properties such as precision and minimum and maximum limits. It is used in record and task forms, including within task templates, where configuration admins define how numeric input is accepted and validated. Numeric fields are also commonly used in conditional logic and Conditional Visibility to control whether later sections of a form are shown when a user enters a specific value or range. This matters because changing a Numeric field’s validation settings or allowed values can affect both the data users can submit and the behaviour of form logic that depends on that field.

OAuth 2.0 (Authorization Code Grant flow) ​

OAuth 2.0 (Authorization Code Grant flow) is the authentication mechanism used in the Autologyx iManage integration to establish a secure, one-time authorization between the platform and iManage. It is used when configuration admins or developers set up the iManage integration, including related components such as the iManage Cloud component, iManage API Call template, integration ID, and default iManage screen. In this context, the flow enables Autologyx to obtain authorized access to iManage services without relying on embedded user credentials, supporting secure enterprise integration setup. This matters because it is the foundation for connecting Autologyx to iManage correctly, allowing the integration to authenticate successfully and enabling downstream iManage-related functionality to operate within the platform.

object based access ​

Object based access, also described in Autologyx as Enhanced Functionality, is the merge-field access method used to return full user or group objects rather than only their IDs. It is used in Users and Groups merge fields when configuring templates, data mappings, integrations, or other logic that needs access to complete object data and its properties. This matters because object based access enables richer configuration options, including use of user group objects, hidden properties, and related-record merge fields, making it the preferred approach when developers or configuration admins need more than simple identifier values; ID based access remains available for compatibility with existing systems.

Object Changes ​

Object Class and Record ownership ​

Object Class and Record ownership in Autologyx is the assignment of a user or user group as the owner of an Object Class or an individual record, and it is configured anywhere the platform provides user or user-group selection for ownership fields. It is used in administration and configuration experiences alongside related controls such as Permission Sets, task assignment, User Type Class fields, sequence default assignees, and user group management, with the available owners shown through list permissions. This matters because Configuration Admins and Super Admins must ensure that the correct users and groups are visible and selectable when setting ownership, so administrative ownership choices align with the platform’s visibility model and only appropriate users or groups can be assigned.

Object class Card view ​

Object class Card view is the formbuilder configuration area used to design the card-style presentation for an object class in Autologyx. It differs from other formbuilder areas because it is constrained to a single section, supports only 2- or 3-column layouts, and is limited to 15 fields, so the side panel provides Object Class Fields and Properties rather than the full Layout, Child Object Classes, or Elements options available elsewhere. In this view, administrators configure Section Properties and column ratios, but Conditional Visibility is not available because the card contains only one section. This matters to Configuration Admins and Super Admins because the Card view has a simplified structure and specific limits that directly affect how object information can be arranged and displayed.

Object class configuration ​

INSUFFICIENT_EVIDENCE

Object class Create and edit view ​

The Object class Create and edit view is the formbuilder configuration view used to design the form that users complete when creating a new object record or editing an existing one in Autologyx. Used by configuration administrators and Super Admins, it provides a canvas and side panels from which layout components, object class fields, properties, elements, and—when the object class is a parent in the relational model—Child Object Class components can be added and arranged. This view is used when configuring record entry experiences that are opened from places such as the Records list via the Create record action or through a direct link to the form. It matters because it controls how record data is captured and maintained, including whether related child records can be created and managed as part of the parent object’s form design.

Object class create/edit view ​

The Object class create/edit view is the form used in Autologyx to create a new record for an object class or update an existing one. It is a key configuration surface for Configuration Admins and Super Admins because it supports embedded Elements and conditional logic, allowing the form to present dynamic fields, tailored layouts, and guided data capture during record entry and maintenance. Within the platform, it sits alongside other supported form contexts such as summary views and standalone forms, and it matters because it determines how users input and manage object-class data in a controlled, configurable way.

Object class create/edit view display form ​

Object class create/edit view display form is the Autologyx form context used to show configured Elements when users create, edit, or view records for an object class. Configuration administrators and Super Admins use this display target when defining where an Element is available, alongside other contexts such as the landing page, summary view display form, and standalone form. In this context, the Element’s configuration is applied in the same way as in the other supported form locations, which makes it a key setting for controlling how object class information is presented and maintained in the platform user interface.

Object Class Display Forms ​

Object Class Display Forms are the configured form layouts used to present an object class in different parts of the Autologyx platform, specifically the Card view, Create/Edit view, and Summary view. These forms define how fields for a class are arranged and shown to users when they create records, update them, or review record details, making them a core part of how object data is captured and displayed throughout the application. For configuration administrators and Super Admins, Object Class Display Forms matter because they control the usability, consistency, and relevance of the user experience for each object class, and are typically managed through form-building and class configuration activities.

Object class Display tab ​

The Object class Display tab is the configuration area where administrators define how records of an object class are presented to users, including the Create and edit view that opens when a record is accessed from a list. It is used when setting up or maintaining an object class to control the layout and availability of the record editing experience, and it can also be used to disable that view when it is not required. This matters because the Display tab determines how users interact with object records in the workspace, directly shaping usability, data entry, and the consistency of the record interface across the platform.

Object class Display views ​

Object class Display views are the configured views in Autologyx that present the fields of an object class to users when they work with object data. They are used alongside the Fields list, standalone forms, and object records, and are affected by field-level configuration changes made in the Data Model tab, including updates made through the Edit field panel or Add field panel. For configuration admins, Display views matter because changes to object class field labels and related field settings are reflected in these views, directly shaping how object information is shown and understood across the platform.

Object class Document type fields ​

Object class Document type fields are configuration fields on an object that store a document reference and are exposed in the platform as selectable document sources. In Autologyx, they are used in places such as the Document Picker actor, where selecting Source = Document Field makes any Object class Document type fields from the preceding object available in the Field selector as a single-select list. This matters to configuration admins because these fields determine how documents held on an object can be surfaced, passed between actors, and used in sequence design, especially when working with document-driven automation and the Files section or other document-related features.

Object class edit page ​

The Object class edit page is the configuration page in Autologyx used to manage an object class and its definition. It is used by configuration administrators and Super Admins when maintaining object classes, and includes a set of tabs for editing different aspects of the class; on the first tab, users can create, edit, and remove fields using the fields list, field types, field properties, and add field panel. This page matters because it is the central place for defining the structure of an object class, ensuring the correct fields are available and configured appropriately for use across the platform.

Object class Edit permission ​

Object class Edit permission is an Autologyx permission that allows a user to modify the structure of an Object class in the Data Model, including editing fields and removing fields from the Fields list through the Actions menu. It is used in object class configuration tasks and is enabled through a Role on the Data Model tab or through a Permission Set for a specific Object class; it is also available to Super Admins, and to Config admins when combined with the appropriate Role. This permission matters because it controls who can change the data model definition for an Object class, including related elements such as child object classes and field types such as Document, helping administrators safely delegate configuration access while protecting core platform structure.

object class field merges ​

Object class field merges, also referred to as field merges, are the template merge functions used in Autologyx to insert data from platform object classes into document templates so that generated documents are populated automatically with the correct record information. They are used in document template creation and generation workflows, including through the Catalyst Word add-in support that provides users with a Word sidebar for working with merge fields and related template functions. This matters to both end-users and configuration administrators because it enables consistent, repeatable document generation from Autologyx data, reduces manual editing, and ensures templates are configured to pull the right information into system-generated documents.

Object Class Field Types ​

Object Class Field Types are the defined data types available when creating or editing object class fields in Autologyx, and they determine what kind of information a field stores, how it is presented to users, and how it behaves across records, forms, and displays. Used within Object Classes configuration alongside Uses And Attributes, these field types are a core design choice for configuration admins and Super Admins when modelling business objects, building standalone forms, and shaping the user interface. Selecting the correct field type matters because it affects data capture, usability, display options, and how permissions and class structure operate together across the platform.

Object class fields ​

Object class fields are the defined data fields that make up an Object class in Autologyx and determine what information each record in that class can store, display, and update. Configured from the Fields tab of an Object class, each field has a label, a unique alias within the class, and a type, which together control how data is captured, referenced in reporting, merge fields, and API requests and responses. Object class fields are used across the platform in object record create, edit, summary, and standalone forms, in Update object record task templates, in sequence conditions and update actions, and in document generation. They matter because they form the core data model for an application: they standardise record structure, drive user input and automation behaviour, and provide the field references needed for integrations, dynamic documents, and ongoing record maintenance.

Show 8 more pages

Object class Fields tab ​

The Object class Fields tab is the configuration area where administrators define and manage the fields for an object class, including selecting which field acts as the class Identifier. It is used when setting up the class structure and controlling how records are presented in create and edit views, and it also affects record listing behaviour elsewhere in the platform, such as the Records list, where the Identifier field selected on this tab can be included by default. This tab matters because it determines the core data structure and primary label for records in that object class, shaping both user-facing record displays and downstream configuration choices.

Object Class forms ​

Object Class forms are the configuration forms used within an Object Class in Autologyx to define how fields and form elements are presented when working with that object’s record experience. They are used by Config Admins and other users with permission to edit specific Object Classes, including when selecting and arranging Elements on the form canvas and applying Object Class–specific layout options such as full-width textboxes. Object Class forms matter because they control the structure, usability, and presentation of record data for a given object, directly affecting how records are configured and how users interact with object fields across the platform.

Object Class ID ​

Object Class ID is the numeric identifier assigned to each object class in the Autologyx data model and used to reference that class in relational merge field syntax and Jinja2 variable expressions. It appears in configurations that work across parent, child, and related records—such as Document Templates, Document Fields, and local variables—where the number before an index such as [0] identifies which object class the related record belongs to. For example, a model can define Site as object class ID 11, Lease as 14, Landlord as 51, and Tenant as 52, and those IDs are then used to target values from the correct related record path. Object Class ID matters because it ensures merge fields and template logic pull data from the intended object class, especially in configurations with multiple related records or indirect relationships.

Object class list ​

The Object class list is the tabular view in System Configuration that displays the object classes defined in the Autologyx data model and key summary information for each one, such as the number of Owners shown in the Owners column. It is used by Configuration Admins and Super Admins from the Data Model area as the landing page for reviewing object classes and opening further actions, including editing permission sets and managing related configuration through the Actions or kebab menu. This list matters because it provides the primary control point for monitoring object class configuration at a glance and confirming that changes to class permissions, owners, and associated administrative settings are reflected correctly across the platform.

Object class menu item ​

The Object class menu item is the navigation entry in Autologyx that gives access to Object Classes configuration within System configuration. It is shown to users who hold one or more object class permissions, making it a permission-controlled route into the Object Classes area and its related administration screens. This matters to configuration administrators and Super Admins because the presence of the menu item determines whether they can reach and manage object class settings through the platform interface, and its visibility reflects the user’s assigned access to object class administration.

Object Class name ​

Object Class name is the unique required label for an Object Class in Autologyx and is the primary name used to identify that class throughout the platform. Configuration admins and Super Admins set it when creating an Object Class, and it remains a key reference point when editing that class across areas such as the Display, Fields, and Forms tabs, as well as when managing permissions against Object Classes. For end-users, the Object Class name is also surfaced in navigation elements such as breadcrumbs, where it is shown alongside the record Identifier or ID to clearly indicate the type of record being viewed. It matters because it provides the core, consistent name for a configured record type, supports clear navigation and administration, and must be unique to prevent ambiguity in configuration and day-to-day use.

Object class Owners ​

Object class Owners are users designated as the owners of a specific object class in Autologyx, giving them elevated administrative access across all records within that class. This role is used in both system configuration and workspace areas, including managing record permission sets, accessing and updating the Record access tab on object records, viewing tasks for that object class, creating manual tasks, and performing certain sequence actions when combined with the required sequence permissions. Object class ownership matters because it provides class-level control beyond individual record ownership, allowing the user to administer access, support operational work across all records in the class, and recover or maintain control where record-level owners alone do not have sufficient authority.

Show 1 more pages

Object class Permission set ​

An Object class Permission set is an access-control configuration applied to an object class in Autologyx that grants users specific permissions over the records and tasks associated with that object class. It is used by administrators when configuring user access and directly affects what users can see and do in the Workspace and Tasks list, such as viewing all tasks or completing tasks. This matters because users who are not assigned the appropriate Object class Permission set, and are not otherwise covered by roles such as Super Admin, object class owner, record owner, or task assignee, will not see relevant records or tasks and will be unable to carry out task actions required by the process.

object class permissions ​

Object class permissions are the Autologyx access controls that govern what a user can do with a specific object class, combining class permissions and record permissions to control actions such as visibility, listing, viewing, and editing records within that class. They are used in platform administration and security configuration alongside roles, user groups, and permission sets, and they also influence whether users can see Object Classes in System Configuration. For configuration admins and Super Admins, object class permissions matter because they define how users interact with records and tasks in different workspaces, support more precise access design such as separating list and view rights, and ensure users only have access to the object classes and records required for their role.

Object Class Record permission set ​

An Object Class Record permission set is a record-level access control assignment for an object class in Autologyx that grants a user group permissions on individual object records rather than only at the class level. It is used when configuring record access for object data, and unlike Object Class class permissions or User Group Permissions configured directly in standard administration areas, this permission set is assigned to user groups through a Record Access actor in the sequencer or through the API. This matters because it enables configuration admins, super admins, and integrators to control which groups can access specific records within an object class, supporting precise security and process-driven access management.

Object Class relations ​

Object Class relations are configuration links in the Autologyx platform that connect object classes to other platform components and are enforced wherever those links are referenced, including Sequences, Document Templates, and Records. They are used by configuration and super admins when defining how document metadata, document type fields, and related form or record structures interact across Create/Edit forms and display forms. Object Class relations matter because they underpin dependencies in solution design: if a relation is in use, Autologyx blocks its removal and identifies the specific Sequences, Document Templates, or Records that depend on it, helping administrators maintain configuration integrity and avoid breaking existing process or document behaviour.

Object Class Relationships ​

Object Class Relationships are the configuration definitions that connect one object class to another in the Autologyx data model, forming the links used to represent related records across the platform. They are managed in System Configuration, alongside Object Classes and the Relational Modeller, and are used when designing how business data is structured, connected, and navigated within solutions. For configuration administrators and Super Admins, object class relationships matter because they determine how relational records are created and maintained, how users and processes move between associated data, and how a coherent, scalable data model is established for workflow, automation, and record management.

Object class section ​

The Object class section is the area at the top of a Sequence design page that displays the Object class selected when the Sequence was created. In Autologyx, configuration admins encounter this section when editing a Sequence in System Configuration, where it provides immediate context for the workflow being designed by showing which Object class the Sequence belongs to. This matters because a Sequence is created for a specific Object class, and the displayed Object class helps administrators confirm they are configuring the correct workflow in the correct business context; access to edit that design also depends on being an Owner of that Object class.

object class sequence ​

INSUFFICIENT_EVIDENCE

Object class sidebar ​

In the Autologyx Relational modeller, the Object class sidebar is the palette that lists available object classes for use when designing the data model on the canvas. Configuration admins and Super Admins use it to locate and drag object classes into the model, where they can then be arranged and connected to define parent/child relationships and child object classes. Once an object class has been dropped onto the canvas, it is greyed out in the Object class sidebar to show that it has already been added to the current model view. This matters because the sidebar is the starting point for building and managing the relational structure of object classes, helping administrators understand what is available to add and preventing duplicate placement during configuration.

Object class Summary view ​

Object class Summary view is a Formbuilder configuration area in Autologyx used to design the summary display for an object class. In the Overview of formbuilder, it is listed as a system area that supports the Layout, Object Class Fields, Properties, and Elements sections in the side panel, allowing configuration admins to drag and drop components onto the canvas and control how object class information is presented. It sits alongside other object class displays such as Card view and Create and edit view, and it matters because it defines the structured summary presentation of a record, using the object class fields and display properties configured for that object class.

Object class usage ​

Object class usage, shown in the platform as View usage or usage, is the read-only view of how an Object class is being used in Autologyx. It is available from Object class permissions and related configuration screens, and shows key usage information for that class, including how many records exist, which Task templates are available, and which Sequences have been created for the Object class. This matters to Configuration admins and Super Admins because it provides a quick operational view of the class without granting access to change the class configuration itself, helping them understand the impact and scope of the class when reviewing permissions, managing setup, or assessing how the class is used across the platform.

Object class views ​

Object class/List ​

Object class/List is the class-level permission that allows a user to list and see records for a specific object class in Autologyx. It is configured on the Permissions tab as part of class permissions and is a prerequisite for record visibility: users also need the relevant Object record/View permission, but without Object class/List the record data remains hidden and other record-level permissions such as View All, Edit All, or Complete All are not useful in practice. This permission matters when configuring access because it enables users to identify and work with records belonging to an object class, making it a foundational permission for anyone setting up or troubleshooting record access.

Object classes ​

Object classes are the core data-model entities in Autologyx that define a type of record, its fields, forms, displays, permissions, and relationships to other classes. They are configured in System Configuration as part of the data model, used wherever records are created, viewed, updated, filtered, related, or generated, and provide the foundation for record forms, standalone forms, task templates, sequences, relational models, document templates, merge fields, and API-driven record creation. An object class can operate on its own or as part of a parent/child structure in the Relational modeller, with each object record belonging to a specific class. Object classes matter because they determine how business data is structured, who can access and work with it, how related records interact, and how automation and documents use that data across the platform.

Show 87 more pages

Object classes list ​

The Object classes list is the system configuration list page where administrators view and manage all Object Classes defined in an Autologyx environment. Used by Configuration admins and Super Admins, it acts as the main entry point for creating a new Object Class with the Create button, returning to saved classes, and accessing further configuration such as display settings, forms, document templates, and permissions. The list also presents the default column layout for Object Classes and reflects platform limits by disabling the Create button when the maximum number of classes has been reached. This list matters because it is the central place for controlling the structure and administration of record types in the platform.

Object fields ​

Object fields are the fields defined within an Object class in the Autologyx platform to store the data captured for objects of that class. They are configured by administrators when creating an Object class, including from the create or edit view for the Object class, where you are asked whether to add fields for the class. Object fields are a core part of object class design because they determine what information can be recorded and managed for each object, directly affecting how the class is structured and used in the platform. Each Object class supports up to 2,000 Object fields, which makes field planning an important part of configuration and ongoing administration.

object history ​

Object history, shown as history in some contexts, is the audit trail maintained for an Autologyx object and records changes made to that object over time. In the platform, it is used to provide traceability for configuration and access-control updates; for example, when User Groups are assigned to or unassigned from a Record Permission Set through the relevant API endpoints, each add or remove action is logged in the object history. This matters to configuration administrators, Super Admins, compliance teams, and integrators because it provides a clear record of permission changes, supports governance and review activities, and helps diagnose how access to records has been configured or altered.

Object record fields ​

Object record fields are the fields from an Autologyx object record that users can select in the Catalyst Word Add in when working with document templates, allowing template content to be populated with data held on a specific record. In practice, these fields are used during template configuration and document generation to insert object-specific information into documents. Access to object record fields is controlled by permissions, and users must have at least View permission on the relevant object to select them. This matters because it determines which record data can be used in templates and ensures document authors and administrators can safely expose the right information to end users.

object record lists ​

Object record lists, also called record lists, are UI listings in Autologyx that display records for an object so users can browse, filter, and open related parent or child records from areas such as side panels and other record-driven views. They are used wherever the platform presents collections of object records, including configurations tied to object permissions and Authentication Objects, and they depend on the user having access to the underlying object. Object record lists matter because they are a core navigation and working surface for end users and administrators: they support finding and reviewing records efficiently, keep related information visible in context, and must respond correctly to permission changes so inaccessible lists are handled cleanly and the interface remains accurate and secure.

object record meta ​

Object record meta is the metadata payload included in an Element’s messageData when that Element is used on an object class form in Autologyx. It carries the identifiers for the current object record context, such as the class id and record id, so the Element can recognise which object and form instance it is operating against. This is used by custom Elements on object class create, edit, and view forms, where form context needs to be passed from the platform into the Element’s JavaScript. It matters to developers, integrators, and configuration admins because it enables Elements to read and react to the current object record, connect form behaviour to the correct object class and record, and build context-aware integrations and form experiences.

Object Record Owner ​

Object Record Owner, also shown as Record Owner, is the user designated as the owner of a specific object record in Autologyx. In the record editing experience, this ownership is used to control access to the Record access tab, which is available to the Object Record Owner, users with a Super admin account, and Object class Owners. This matters because record ownership determines who can work with record-level access settings, making it an important concept for end-users managing their own records and for administrators configuring and governing access within the platform.

Object Record properties ​

Object Record properties, also shown as Record properties, are the standard system-defined fields available on an Autologyx object record for use in merge fields within templates. In practice, these properties expose core metadata about the current record, including values such as the record ID, Created date and time, and Modified date and time, using merge field syntax such as {{ record.id }}, {{ record.created at }}, and {{ record.modified at }}, with the {{ record }} shorthand representing the current object record context. They are used when configuring templates and other content that needs to insert record-specific values automatically, and they matter because they provide a consistent way for configuration admins, Super Admins, and end-users to reference essential record information, support record identification, and ensure generated content stays aligned with the source record.

Object record/View permission ​

Object record/View permission is the record-level permission in Autologyx that allows a user to open and see object record data, and it is treated as a minimum prerequisite when configuring access to records and record-related actions. It is used in the Permissions tab alongside class permissions, especially Class permission/Object class/List, because users need both the ability to list the object class and the ability to view the individual record for record information to be visible and identifiable in the interface. This permission matters to Configuration Admins and Super Admins because other permissions such as task-related actions depend on it in practical use: without Object record/View permission, users cannot properly see the records those actions relate to, which results in hidden record data and a reduced or ineffective user experience.

Object records ​

Object records are the individual data entries stored within an Object class in Autologyx and represent the records that users create, view, update, search, filter, and delete as part of day-to-day work. They are used throughout the Workspace Records area, in record lists, card and summary views, create and edit forms, side panels such as Record access, and in related task and process features, where task templates, task groups, manual tasks, and sequences act on specific records. Object records are defined by the fields configured on their Object class, can use identifiers and unique values, support ownership and record-level permissions, and are subject to class and record permission sets. They matter because they are the core operational items the platform manages: they hold workflow data, determine what tasks and automations run, control who can access and update information, feed real-time updates and analytics, and provide the structured foundation for consistent, auditable process execution.

Show 20 more pages

Object Records History ​

Object Records History is the Autologyx history data set that stores a record of changes made to object records in the platform, including event timestamps, event types, and the IDs of the affected records. It is used within the Analytics Database and related reporting or compliance contexts to provide a historical view of record activity over time rather than only the current state of an object. This matters to configuration administrators, super admins, and compliance or analytics users because it supports audit trails, enables review of field-level and record-level updates, and helps teams trace when changes occurred, what kind of change was made, and which record was involved.

Objects ​

In the Autologyx platform, Objects are configurable administrative entities used to define specialist platform capabilities, particularly in areas such as Authentication and Communication. They are accessed from the Administration area, where configuration and super administrators manage advanced platform components and extension features. Examples include authentication objects used to support communication integrations and specific connection flows such as ROPC and WebSocket-based authentication. Objects matter because they provide the structured configuration needed to connect Autologyx to external services, control how platform features operate, and enable the secure, reliable behaviour of advanced integrations across the platform.

Okta OpenID Connect (OIDC) ​

Okta OpenID Connect (OIDC), also called Okta OIDC, is the Autologyx single sign-on provider option used to integrate the platform with Okta for user authentication. It is selected in the Single Sign On Provider field within Catalyst SSO configuration, including the Okta SSO edit page, where administrators configure related settings such as the redirect or callback URI, logout URL, automatic user creation, and permissions required to create SSO records. This provider matters because it enables managed sign-in through Okta, supports Catalyst login, and controls how internal users are authenticated and provisioned into the platform.

Okta SSO edit page ​

The Okta SSO edit page is the Autologyx administration page used to configure and maintain an Okta-based single sign-on provider for Catalyst login. It is used by configuration administrators and Super Admins when setting up Okta OpenID Connect (OIDC), and after the SSO record is saved it displays the platform URLs required to complete the Okta application configuration, including the Redirect / Callback URI that Okta uses to return users to Autologyx after successful authentication. This page matters because it is the control point for the SSO settings that connect Autologyx to Okta, and the values shown there must be entered correctly in Okta to enable working sign-in and sign-out behaviour for users.

Okta Sso In Catalyst ​

on screen warning message ​

An on screen warning message is the alert displayed in the Autologyx form designer when a configuration change will remove conditional logic dependencies, specifically when a Configuration admin or Super Admin deletes a field that controls conditions or removes a section containing a field used in conditional logic. It is used while editing record and task forms, where fields and sections control the display of other sections through conditions. This message matters because it tells the user immediately that deleting the selected field or section will also delete the related conditions, helping protect form behaviour and preventing accidental loss of conditional logic during configuration.

one time authentication ​

In Autologyx, one time authentication is the single OAuth 2.0 Authorization Code Grant sign-in used to establish the platform’s connection to an iManage environment. It is used when configuring the iManage integration, including the iManage Cloud component and related API call templates, and can also affect the default iManage screen experience presented to users. This authentication matters because it securely authorises Autologyx to access iManage on behalf of the configured connection without requiring repeated sign-in during normal operation, enabling a reliable, enterprise-ready integration for document and matter interactions.

One Time Completion (1TC) Accounts ​

One Time Completion (1TC) Accounts are special Autologyx user accounts used to complete specific workflow tasks but, unlike standard users, cannot be assigned to any user group. In the platform, they are specifically handled within Users and Groups visibility controls, where their visibility is automatically granted to Super Admins as part of global visibility because group-based visibility rules do not apply to them. This matters when configuring permissions, task assignment behaviour, ownership-related fields, and user selection experiences such as dropdown autocompletes and filters, because 1TC accounts sit outside normal group membership and therefore require administrators to understand their distinct visibility model when designing and supporting workflows.

one time completion users ​

One time completion users (1TC users) are a dedicated Autologyx account type for completing a single assigned task without signing in to the platform. They are used in task assignment and manual task creation, where Super Admins, Standard users, or one time completion users can be selected as the task completer; if a one time completion user is chosen, no additional users can be added to that task. When assigned, the user receives an email with a unique token linking directly to the task form, such as a Standalone form or Update record, and can complete the task through that link. This matters because it enables organisations to collect information or request record updates from external participants quickly and securely without creating full user accounts, while also distinguishing these users from standard platform users by preventing assignment to permission sets.

one to many relationship ​

In Autologyx, a one to many relationship is a relational modelling pattern that allows a single parent object class record to be associated with multiple child records in a child object class. It is used when configuring data structures in the Relational modeller, where administrators define parent and child levels between object classes as part of the platform’s hierarchy and record model. This relationship type matters because it determines how records are organised, how related information is captured across parent and child records, and how users structure business data for creation, viewing, and ongoing management within the platform.

one to one relationship ​

In Autologyx, a one to one relationship is a relational modelling pattern used to link two object classes so that each parent record is associated with a single child record, and each child record belongs to a single parent record. It is configured in the Relational modeller, where administrators define how object classes connect within a parent/child structure as part of the platform’s data model. This matters because it lets configuration and super admins represent tightly paired business entities accurately, control how records are organised across parent/child levels, and ensure users see and manage related information in a structured, predictable way across the platform.

Open ​

Open is an option in the Actions menu that takes an administrator from a list view to the full page for the selected item. In the User Groups area of Autologyx, selecting Open on a user group row displays the User group page, where configuration admins and Super Admins can view and manage that group, including tasks such as adding members, making members owners, and deleting members. This matters because Open is the standard navigation action used to move from a summary list into the detailed management screen where configuration changes are made.

OpenAI Embeddings ​

OpenAI Embeddings is an Autologyx platform capability used in configuration to submit an Input value to an OpenAI embeddings service as part of an automation or configured actor. It is exposed where builders define the inputs for an OpenAI Embeddings step or action, alongside other configurable platform operations such as API calls and OpenAI GPT prompts. In practice, the Input field supports referenced values, including constants that are injected automatically at execution time, allowing administrators and developers to supply reusable text or data without hard-coding it directly in the step. This matters because it enables consistent, maintainable AI-driven configurations and lets integrators control embedding input dynamically through the platform’s standard configuration model.

OpenAI Embeddings integration ​

OpenAI Embeddings integration is the Autologyx Catalyst integration that brings OpenAI embeddings into Sequencer so the platform can convert content into vector representations for semantic search and context-aware automations. It is used in AI-enabled process design and configuration, alongside related capabilities such as the OpenAI GPT integration, by configuration admins, super admins, and developers or integrators who are setting up or extending Applied AI features in Autologyx. This integration matters because it enables workflows to match and retrieve information by meaning rather than exact wording, improving how automations discover relevant context, connect related content, and support more intelligent orchestration across the platform.

OpenAI GPT ​

OpenAI GPT is an Autologyx platform action or integration used to submit AI prompts within a workflow, specifically through its Prompt and Context fields in configuration. It is used by configuration admins and developers when setting up automated steps that generate or process content as part of a configured actor or wider workflow design. In the configuration modal for this action, Prompt and Context support injected Constants, allowing reusable values to be inserted automatically at execution time and helping standardise prompts, reduce duplication, and simplify maintenance. This matters because it enables more consistent, centrally managed AI-driven behaviour across processes while making OpenAI GPT configurations easier to update and integrate with other platform elements such as local variables and API-driven actions.

OpenAI GPT integration ​

OpenAI GPT integration is an Autologyx platform integration that adds OpenAI GPT capabilities to workflows through a Sequencer actor, enabling builders and administrators to use GPT directly within automated process steps. It is used in workflow design and platform configuration, especially within Autologyx Catalyst and other Applied AI scenarios where AI-powered processing is embedded into a sequence. This integration matters because it extends the platform’s automation capabilities with generative AI functions inside orchestrated workflows, making it an important feature for configuration admins, super admins, and integrators who design, enable, and govern AI-enabled process automation.

OpenAI integration enabled ​

OpenAI integration enabled is the tenant-level configuration state that makes the OpenAI: GPT integration available in the Autologyx platform. When this integration is enabled for a client, configuration users such as Super Admins and other authorised administrators can use the OpenAI: GPT actor in Sequencer to add ChatGPT-powered steps to processes, including prompts that use merge fields and related GPT configuration options. This matters because the integration must be enabled before these AI-driven actors and features can be used in process design, making it a prerequisite for deploying OpenAI-powered automation within Autologyx.

OpenAI: Embeddings ​

OpenAI: Embeddings is an Autologyx platform integration that connects OpenAI embedding models to workflows and built-in tools so unstructured content can be converted into vector representations for semantic processing. It is used by configuration administrators and developers when setting up integrations and workflow capabilities that need semantic search, document matching, or analysis across connected content sources such as document repositories, including integrations like iManage. This matters because it extends the platform beyond keyword-based handling of content, enabling faster discovery of relevant information, more effective analysis of complex datasets, and lower manual effort in automation scenarios that depend on understanding the meaning of documents and other text-based data.

OpenAI: GPT actor ​

The OpenAI: GPT actor is an AI actor in the Autologyx platform that integrates OpenAI GPT models, including ChatGPT capabilities, directly into workflows and Sequencer so users can use OpenAI-powered processing as part of automated steps. It is used when configuring actors in system configuration and when selecting or updating AI models available inside Sequencer, alongside related options such as actor configuration, authentication objects, merge fields, and Dynamic Prompt Customisation. This matters because it enables configuration admins and super admins to embed generative AI functionality into business processes using the OpenAI stack, while giving end-users access to AI-driven workflow behaviour within the sequenced tasks they run.

OpenAI: GPT integration ​

OPTIONS response ​

In Autologyx, the OPTIONS response is the API metadata returned for authentication method management endpoints, used to expose the available authentication configuration settings and controls for a given request context. Introduced as an enhanced OPTIONS response in the Authentication & Security updates, it gives developers, configuration admins, and Super Admins greater visibility into how authentication can be configured and managed through the platform’s API, including the structure and supported options associated with Authentication Objects and related authentication configuration. This matters because it supports accurate integration, safer administration, and more efficient configuration of authentication methods by showing what the platform accepts before changes are submitted.

Outbound mail setup ​

Outbound mail setup is the Administration setting in Autologyx where configuration administrators and Super Admins define and manage the mail service used for all outgoing email notifications from the platform. It is accessed from the Administration menu under Communication and includes selecting the outbound mail provider, such as Microsoft Office 365 Exchange (Graph) with OAuth 2.0, and completing the required connection settings. This configuration is a core platform dependency because application-generated emails, notifications, and message delivery from features such as the Send Message Actor rely on it being set correctly. For anyone configuring or validating an Autologyx environment, outbound mail setup is essential to ensure system communications are sent successfully across all applications.

Show 6 more pages

outgoing messages ​

Outgoing messages are the emails or communications generated by the Autologyx platform and sent from workflows, tasks, or templates to external recipients. In administration and communication configuration, outgoing messages are used wherever standard message templates, company details, merge fields, and the Admin email signature are applied to control the content and branding of platform-generated communications. This matters because configuration administrators and Super Admins use these settings to ensure every message sent from Autologyx includes the correct organisational information, consistent formatting, and approved signature content.

outgoing notifications ​

Outgoing notifications are the emails sent by the Autologyx platform to users and external recipients as part of platform activity, communications, and automated processes. In Autologyx, outgoing notifications are controlled through the Outbound mail setup in Administration, where Configuration Admins and Super Admins define and configure the mail service that the platform uses to send all such messages. This matters because the outbound mail configuration determines how notification emails are delivered across the platform, making it a core administrative setting for ensuring system messages and template-driven communications are sent correctly.

outgoing triggers ​

Outgoing triggers are the output connections exposed by an actor in an Autologyx sequence and are used in Sequence Designer to drive the next step in a workflow when that actor completes or reaches a defined outcome. They are configured by connecting one actor’s outgoing triggers to another actor, such as linking the Task assignment actor’s outgoing triggers to the Create task actor in Autologyx Catalyst 1.5. For configuration admins and developers, outgoing triggers matter because they define how work progresses between actors, control the flow of tasks and automation, and ensure that process steps are sequenced correctly to support efficient, accountable execution.

Outline modal ​

The Outline modal, also labelled Outline in the Autologyx workspace, is the Navigator panel used while editing a Sequence to provide a miniature overview of the current design. It opens from Navigator and is displayed at the top-right of the workspace, where configuration admins can click, drag, and reposition the blue outline to jump to and focus on a specific area of the Sequence. This is used in Edit design and other editing contexts where large or complex Sequences extend beyond the visible canvas. The Outline modal matters because it makes navigation faster and more precise, helping administrators move around the design efficiently and work on the correct section without manually scrolling across the workspace.

Outstanding ​

Outstanding is the initial status assigned to a task in the Autologyx platform when the task is created, including tasks generated from task templates and tasks created manually for an object record. It is shown in task displays alongside key task details such as the task name and due date, allowing end-users to identify work that has been created and is awaiting completion or further progress. This status matters because it provides a consistent starting point for task lifecycle tracking, supports prioritisation and day-to-day task management in the workspace, and gives configuration admins a clear default status behaviour to account for when designing task templates and task creation processes.

Overdue ​

Overdue is a task status in the Autologyx platform that is applied when a task passes its Due Date without being completed. It is used anywhere tasks are created and managed, including task templates, manually created tasks for object records, and tasks assigned through mechanisms such as 1 time completion user links. This status matters because it changes how the task behaves for users: once a due date is exceeded, the task is no longer treated as current, and for 1 time completion users the email link to complete the task becomes inactive. For configuration admins, Overdue is also important when defining due dates and task creation rules, because tasks cannot be created with a past date that would make them immediately overdue.

Override assignees ​

Override assignees is a Record Access actor configuration option in Autologyx that replaces the current assignees on a record permission set with a new set of users, removing any existing assignees from that permission set and assigning only the users specified in the configuration. It is used when configuring record access and permission set assignment, where administrators choose the assignee source from the available single-select options such as Users, User groups, or Field. This setting matters because it enforces a definitive access list for the targeted permission set, which is essential when access must be reset rather than added to or reduced selectively, and it cannot be combined with Append assignees for the same permission set.

override option ​

In Autologyx, the override option is a Record Access actor configuration action that completely replaces the current assignees or owners on a record with the new ownership setup you define. It is used when configuring record ownership and access assignments, including assignments made by selecting specific users, user groups, or dynamic values from a record field. Override matters because it gives Configuration Admins and Super Admins precise control over record access by resetting existing ownership to match the configured target state, rather than preserving or adding to current assignees. Within a single permission set, override is mutually exclusive with append, so each configuration must use one action type consistently.

override or append default task assignees ​

Override or append default task assignees is a configuration option in the Task Assignment actor that controls how assignees are applied to a task in the Autologyx platform. It is used by configuration administrators and Super Admins when designing or updating task assignment behaviour in sequences, allowing them either to replace the task’s existing default assignees or to add additional assignees alongside them. This matters because it gives sequence designers precise control over who receives responsibility for work at runtime, supporting task routing that aligns with business rules, user type field values, and the intended behaviour of tasks created and managed within Autologyx Catalyst 1.5.

Override owners ​

Override owners is a Record Access actor configuration option in the Autologyx platform that removes the current owner of a record and replaces that owner with a new one. It is used in the Record Access configuration modal, typically immediately after record creation, when configuring how ownership should be applied to records within a sequence. When Override owners is selected, administrators can define the replacement owner either By user or By field, depending on whether ownership should be assigned to a specific user or derived from record data. This setting matters because record ownership controls who is recognised as the owner of the record and supports the correct routing, accountability, and access model required by the process design.

Override task assignees ​

Override task assignees is a Task Assignment Actor setting in Autologyx that replaces the default task assignees or owners defined in a sequence’s Sequence Properties with the users specified directly in that actor for the task. It is used when configuring task assignment behaviour within a sequence, typically by Configuration Admins or Super Admins who need a task to be routed to a different set of users than the sequence default. This setting matters because it enforces task-specific ownership at the actor level, ensuring the selected task is assigned only to the configured users instead of inheriting the broader default assignment defined for the sequence.

owner of a User group ​

  • Mostly relevant to: Configuration admins, Super Admins
  • Closely related concepts: Roles, Roles list

In Autologyx, the owner of a User group is the user who created that User group or any user subsequently assigned ownership by an existing owner. User group ownership is used in platform administration when managing access structures such as roles, because owners control the maintenance of the group itself. Any owner can make other users owners of the same group and can edit or delete the User group. This matters to Configuration admins and Super Admins because ownership determines who can administer a User group, delegate management responsibilities, and keep role-related group membership structures accurate and maintainable.

Owner of an Object class ​

Owner of the Object class ​

In Autologyx, the Owner of the Object class is a user-level ownership designation on a specific Object class that grants direct control over configuration and operational actions for that class without requiring platform-wide access. Object class ownership is used across object class administration and related features, including editing object classes and standalone forms, removing fields, creating and designing Sequences for that object class, creating update-object-record Task templates, manually creating Object records, completing tasks against that object class, and accessing the Record access tab for records that belong to it. This matters because Object class ownership is one of the core ways Autologyx scopes authority to a particular data model, allowing configuration admins and other permitted users to manage and work with selected Object classes while avoiding unnecessary access to all classes; users who create an Object class automatically become its owner.

Show 4 more pages

Owner/Assignees counter ​

The Owner/Assignees counter is the numeric indicator shown on a record’s Record access tab that displays how many users are currently listed as Owners or Assignees for that object record. It is used alongside the Owner/Assignees list and updates as access is configured, including when people are added through the Add people function, when ownership is assigned, when assignees are removed, and when the user dropdown is filtered. This counter matters because it gives end-users and configuration admins an immediate view of how many people have access to the record, helping them confirm that record access changes made through the Give access button and related access controls have been applied correctly.

Owner/Assignees list ​

The Owner/Assignees list is the section of a record’s Record access tab that shows which users have been granted direct access to that object record and identifies the user designated as the Owner. It is used when viewing or managing record access, including after adding a user through the access controls, where the selected user is shown in this list and, if added as Owner, is marked accordingly. This list matters because it provides the authoritative view of who is responsible for the record and who has been explicitly assigned access, helping end-users confirm current ownership and assignments and enabling configuration admins to manage record-level access accurately.

Owners ​

Owners are the designated users with built-in full control over specific Autologyx entities, most notably User Groups, Object Classes, and individual records. In User Groups, Owners are a predefined permission set with non-editable full permissions to view, edit, and delete the group; the user who creates the group is automatically added as both a member and an Owner, and a group can have up to 10 Owners. In Object Classes, Owners are also created by default with fully enabled class permissions and can manage additional Owners, permission sets, and assignees. For records, the Owner is the single user who has primary ownership of that record, shown on the Record access tab and in display configurations such as the Owners field or avatar display; the user who manually creates a record becomes its Owner by default unless ownership is changed through configuration or API-driven automation. Owners matter because ownership controls visibility, management actions, access administration, and what users can do across core platform areas such as group administration, class configuration, task and record assignment, filters, and record access management.

Show 9 more pages

Owners ​

Owners is an optional column available on the User Group List in Autologyx Administration that shows how many members of each user group have the Owner role. It is added through the list’s column configuration link and is displayed alongside other user group metadata such as Members, Created, and Last edited. This value matters because Owners have additional actions available for the group, including Open, View usage, and Delete, whereas users who are only members have a more limited actions menu. For configuration administrators and Super Admins, the Owners column provides a quick way to understand group ownership and administrative control across user groups.

Owners' Permission set ​

In Autologyx, the Owners' Permission set is the class permission set that controls which users or groups are defined as Owners for an Object class. It is configured in System Configuration when editing an Object class, under Class permissions, where configuration administrators can add or remove Owners from the kebab menu for the Owners' Permission set. This matters because Owners are managed through this dedicated permission set rather than through the other class permission sets used for Assignees, making it a key part of how responsibility, access, and role assignment are structured for objects within the platform.

Owners' Permissions ​

Owners' Permissions are the default permission set applied to the owner of an Object class item in the Autologyx platform. In Class permissions configuration, these permissions define the access automatically granted to the record owner and, by default, are fully enabled for the object class. Owners' Permissions are system-defined and cannot be edited, which makes them a fixed baseline in the platform’s security model. This matters to Configuration admins and Super Admins because owner access is always available at the default level, so any additional class or list permissions must be designed with that built-in access in mind when configuring how different users and roles can work with object records.

Owners, Members, and Everyone ​

Owners, Members, and Everyone are the predefined user group permission sets in Autologyx that control visibility and interaction for each user group. They are used in user and group visibility control and user group management, where administrators define who can view a group and, as a result, list and select its members across the platform. Owners always have full, non-modifiable permissions to view, edit, and delete the group; Members applies to users who belong to the group; and Everyone governs access for all users. These built-in permission sets are closely related to User Group Permission Sets, custom permission sets, object and record Permission Sets, and list permissions, and they matter because they determine how groups are exposed, managed, and used in workflows, assignment, and collaboration throughout the system.

Package Management section ​

The Package Management section is the part of an Element’s configuration in Autologyx where package metadata sourced from the underlying repository is displayed or entered, such as the repository-backed information needed when creating an Element. It is used within Administration for Elements, including during Element creation and editing, and its fields are controlled by the package and repository details rather than routine manual configuration; when editing an existing Element, these fields are greyed out and cannot be changed. This section matters to configuration admins, super admins, and developers or integrators because it links the Element definition in Autologyx to its packaged source, ensuring the platform uses the correct repository information and preserving consistency between deployed Elements and their managed package configuration.

padlock icon ​

In the Autologyx Relational modeller, the padlock icon marks an object class or relationship as locked, meaning it cannot be deleted and, when shown on a relationship control, cannot be moved. Configuration administrators see this icon while editing the relational model, where it appears instead of the bin icon on elements that are not available for structural change. This matters because the padlock identifies parts of the model that are protected from modification, typically where records already exist with relationships between the locked object classes, helping administrators understand which areas of the data model can still be changed safely and which are fixed by current platform data.

Page controls ​

Page controls are the persistent controls applied at the list page level in Autologyx that determine the baseline set of items shown before or after a user works with the list page filter editor. They are used on list pages alongside filtering features such as Apply filter, Remove all, and filter conditions, and remain in effect when ad hoc filter selections are cleared, so the list returns to its full view only within the limits of those page controls. This matters because page controls define the default scope and behaviour of list results, helping end-users understand why certain items are shown or excluded and enabling configuration admins to shape the initial list experience and enforce the intended view of data.

Panels ​

In Autologyx, a Panel is a side-stack interface area used to display supporting tools and controls alongside the main content without navigating away from the current page. Panels are used across the platform’s UI and navigation patterns, including the filter panel on list pages, which opens to the right of the main content area and provides access to filter conditions, Apply filter actions, and options such as Remove all. Panels matter because they let end-users work with page-specific controls while keeping the underlying page visible, and they help configuration admins understand how filtering and other page interactions are presented and managed within the standard Autologyx interface.

paragraph replacement ​

Paragraph replacement, also called inline paragraph merge, is a document assembly behavior in Autologyx .docx templates where the {{p ... }} merge syntax replaces the entire paragraph that contains the merge field with the referenced embedded content. It is used in Document Templates during dynamic document assembly, typically with embedded merge fields such as record.field[index].embedded.inline, when inserted content must take over the full paragraph rather than appear as text within an existing sentence or line. This matters because it controls how formatted content is rendered in the generated document: template authors and configuration admins use paragraph replacement to preserve paragraph-level structure and layout, while end-users benefit from correctly assembled documents that place embedded content in the intended position and format.

parallel branches ​

In Autologyx, parallel branches are workflow paths in a Sequencer that run independently at the same time rather than as a single sequential flow. They are used by configuration and Super Admin users when designing sequences that split processing into multiple branches and later need to converge before the next Actor or Trigger can run. Parallel branches matter because each branch is evaluated separately and Actor execution is queued, so a shared downstream step can be triggered more than once if convergence is not designed correctly, leading to duplicate actions such as repeated API calls or record updates. When parallel branches must converge, Autologyx best practice is to use explicit gating with Local Variables and Triggers, rather than using a central merge Actor pattern that can create race conditions or invalid-actor configurations.

parameter objects ​

In Autologyx, parameter objects are the configuration definitions on an Element that generate the Element properties shown as input fields when the Element is configured on a form. They are used in Element setup and Element Details to determine which settings an administrator or integrator can enter for that Element, and they matter because they control how an Element exposes its configurable options within the platform, shaping both the configuration experience and the behavior available through that Element.

parameter\ limit ​

INSUFFICIENT_EVIDENCE

parameter\ options ​

Parameter options are the configuration values defined for an Element parameter to supply the selectable choices shown in a drop-down field in the Autologyx platform. They are used when creating or configuring Elements, typically within the Element project and its config.json, to control how parameter values are presented to administrators and other users during setup. Parameter options matter because they determine the valid selections available for a parameter, support consistent configuration across Element implementations, and ensure that Element parameters capture input in a controlled and predictable format.

parameter\ type ​

In Autologyx, parameter type is the setting in an Element definition that specifies the kind of value an element parameter accepts, such as an enumerated value, and it is configured in the element’s config.json when creating or maintaining Elements in Administration. It is used alongside the parameter definition to control how the platform stores, validates, and presents parameter values, and some types require additional configuration—for example, when the parameter type is enum, parameter options must also be provided. This matters to configuration admins and developers because the parameter type determines how an Element can be configured and used, ensuring parameters behave correctly and support the intended integration or automation design.

Parameters ​

Parameters are the named inputs you configure on an Autologyx component, such as an API Call actor, to define the data sent and how it is structured at runtime. In Sequencer, Parameters are used when setting request content such as Form Data, and in this context they now include a dedicated Files section for attaching binary or multipart documents. This matters to configuration admins and developers because Parameters control how integrations are assembled, how values are passed into actions, and how document payloads are included correctly when working with binary data and multipart request formats.

Parameters (Payload) ​

Parameters (Payload) is the request body defined on an API Call actor in Autologyx and contains the data sent to the target API when the call runs. It is configured in the API Call actor alongside settings such as Data Type and URL Parameters, and supports merge fields and Jinja expressions so administrators and integrators can build fully dynamic payloads from workflow data. This matters because the payload controls the business content of the outbound request—such as values, objects, and structured data the external service expects—and correct configuration is essential for successful API integrations, accurate data exchange, and reliable process automation.

parent and child records ​

In Autologyx, parent and child records are two related records linked in a hierarchical relationship, where the parent record is the primary or containing record and the child record is the associated dependent record. This relationship is used in sequence automation, particularly with the Relationship Created trigger in Sequencer, which detects when the link between the two records has been established and starts subsequent actions. The concept matters to configuration admins and developers because parent-child relationships are a core way to model connected business data in relational entities and the Relational modeller, enabling process orchestration, task allocation, and event-driven automation across related records.

parent object class ​

In Autologyx, a parent object class is the object class that sits above one or more related child object classes in the relational model, including the root parent object class at the top of a relationship structure. It is defined in the Relational modeller and then configured in the parent class’s create/edit view, where its direct child object classes become available in the CHILD OBJECT CLASSES section. This matters because the parent object class is the point from which users access and manage related child records, and it enables the parent record to use data from those related records in platform features such as forms, document merges, and send message actors. For configuration admins and Super Admins, setting up the correct parent object class is essential to building working 1:N or other parent/child relationships and ensuring related data is exposed in the right place.

Show 1 more pages

parent or child records ​

In Autologyx, parent or child records are records that have a defined relationship to another record and are used in sequences that operate across related data. Configuration admins use these records in relational record automation by configuring the Relation Lookup actor to search associated parent or child records and identify those that meet specified conditions, then using the Sequence Runner actor to perform actions on the matched records, such as assigning a task or updating a field. This matters because it enables sequence logic to extend beyond the current record and apply controlled actions to connected records, supporting coordinated process automation across related items.

parent record form ​

In Autologyx, the parent record form is the form view of a record that contains or references related child records, allowing users to access those related records within the context of the parent record instead of through standalone class lists. It is used in workspaces and permission models alongside Object classes, Elements, and separated list and view permissions, so configuration admins can allow users to view or edit records from specific classes only when they are opened from the parent record form. This matters because it lets teams control how records are exposed in the platform, supporting more guided user journeys, tighter access control, and cleaner workspaces by restricting direct list access while still enabling work on related records where it is needed.

parent records ​

Parent records are records in an object class that sit on the parent side of a configured relationship in the Autologyx relational model, serving as the record from which related child records are created, associated, viewed, and managed. They are used in the workspace when working with relational records, including creating child records from a parent record, associating child records with existing parent records, and interacting with related child data through the parent record’s create and edit views; they are also used in configuration and automation through the Relational modeller, Relation Lookup, Sequence Runner, and API endpoints that list parent records. Parent records matter because they provide the anchor point for structured record relationships, control how related data is presented and accessed across object classes, and enable users, administrators, and integrators to navigate, automate, and manage multi-record processes consistently.

Show 2 more pages

parent sidebar ​

In Autologyx, the parent sidebar is the sidebar area shown on a parent object class’s create/edit view where related child object class components are displayed. It is used in solutions built from the relational model, so configuration administrators encounter it when adding, removing, or restoring child object class components through the Relational modeller and when managing how related records appear in the parent create/edit experience. This matters because changes to the relationship model directly affect what is shown in the parent sidebar: if a child object class component is deleted from the model, it is removed from the parent sidebar, which changes the layout and available related-item interactions for users working with the parent object.

parent/child levels ​

In Autologyx, parent/child levels are the hierarchical layers within a relationship model defined in the Relational modeller, counted from the root parent object class at the top of the structure down through each descendant child object class. This term is used when configuring object class relationships such as one-to-one and one-to-many models, where parent records and child records are organised into a multi-level structure. Parent/child levels matter because they define how deeply related data can be modelled in the platform and directly affect relationship design during configuration; Autologyx supports a maximum of five parent/child levels in any relationship, from the root parent to the deepest descendant.

parent/child relationships ​

Parent/child relationships in Autologyx are configured links between Object classes in the Relational modeller that define how a parent object class can be associated with one or more child object classes, enabling data to be shared and managed across related records. They are set up as part of the relational model after Object classes have been created, and are then exposed in the parent object class create/edit view so users with the appropriate permissions can associate existing child records with a parent record and interact with those associated child records from the parent in the Workspace, including viewing child record summaries and using relevant actions. This matters because parent/child relationships provide the structure that connects related business data, making relational records usable in everyday work and ensuring applications are configured to support connected processes rather than isolated records.

parent:child ratio ​

Parent:child ratio is the relational-model setting that defines how many child records can be associated with a single parent record in Autologyx. It is used in child object class configuration and directly controls the behaviour of form and workspace components that create, search for, select, and display related records, including child object class components and child record selectors. A 1:1 parent:child ratio allows only one child record for each parent, so once that relationship exists the Create and Search actions are disabled and users are informed that the maximum number of related records has been reached; a 1:N parent:child ratio allows multiple child records to be added to the same parent. This setting matters because it determines the user experience for working with relational records and ensures the platform enforces the intended business relationship between parent and child records.

password complexity rules ​

Password complexity rules are the Autologyx configuration settings that define the required strength and format of user passwords as part of user activation and credential management. In the platform, they are used by Configuration Admins and Super Admins alongside related password controls such as password rules, password reuse prevention, rotation intervals, and user activation rules. These rules matter because they determine the standard that passwords must meet when a user account is newly activated or when a user changes their password; changes to password complexity rules do not retrospectively update existing passwords and apply only to new activations and password changes.

password reset processes ​

In the Autologyx platform, password reset processes are the set of password recovery actions that are governed by the same authentication enforcement rules as sign-in, including sending a password reset email, opening the reset form through tokenised links, and setting a new password with a reset token. These processes are used wherever authentication methods are configured by user account type, alongside options such as password login, SSO, or both. This matters because Autologyx applies the configured rules consistently during password recovery as well as login, ensuring that users assigned to SSO-only access cannot create or regain password-based access through reset flows, and helping configuration and security administrators preserve account controls, policy compliance, and the integrity of the platform’s authentication model.

Password Rules ​

Password Rules are the configurable requirements that govern the passwords users create when Autologyx uses standard authentication. In Administration, configuration admins and Super Admins set these rules, including the minimum number of characters required for a user login password, and the same requirements are presented to users on the Activate your user account page during account activation, where each rule is shown and marked as satisfied as the password is entered. Password Rules matter because they enforce your organisation’s password policy within the platform, support security and compliance standards, and ensure the account activation and login experience aligns with internal IT requirements.

Paste Trigger ​

Paste Trigger is a Sequencer configuration action used to insert a previously copied trigger into a target trigger position within a sequence. In the Autologyx platform, it is accessed by right-clicking the destination trigger node and selecting Paste Trigger, typically when building or restructuring complex trigger logic. This feature is important for Configuration Admins and Super Admins because it enables fast reuse of existing trigger structures, especially large or nested conditions, reducing manual rework, improving consistency, and helping avoid design patterns that rely on Invalid Actors as workflow merge points.

PATCH API calls ​

PATCH API calls are HTTP PATCH requests used in the Autologyx platform to update specific fields on an existing resource without replacing the entire object. They are used primarily by developers, integrators, configuration admins, and Super Admins when working with the platform API, including administrative actions such as resetting a Service Account password, converting an existing service account to another account type, and updating task data such as a record’s associated Due Date where permissions allow. PATCH API calls matter because they are the mechanism Autologyx uses for controlled partial updates, so successful use depends on the correct API payload and the appropriate account type and class or record permissions.

Pause ​

Pause is the state and action used on the Sequences list in Autologyx to stop a Sequence from continuing to create or progress new work until it is resumed. Newly created Sequences start in a Paused state, and users who can access the Actions menu and have the required rights, including Super admin users and users with permission to Edit Sequences who are also the object class owner, can switch a running Sequence to Pause or a paused Sequence to Resume. Pausing a Sequence does not stop Tasks that have already been created, so existing Tasks can still be completed; when the Sequence is resumed, completion of those existing Tasks triggers the connected next step and processing continues. This matters because Pause gives end-users and configuration admins controlled operational management of live Sequences without deleting, redesigning, or interrupting work already in progress.

Paused ​

Paused is the state of an Autologyx Sequence when it is not actively progressing to create new work. In the Sequences list, all newly created Sequences start in the Paused state and remain there until an authorised user selects Resume from the Actions menu to set the Sequence to Running. Super Admins, and users who have permission to Edit Sequences and are the Object class Owner, can pause or resume a Sequence from this list. Paused matters because it gives administrators control over when automation starts or stops: while a Sequence is paused, Tasks that were already created can still be completed, but the Sequence does not continue forward until it is resumed, at which point completion of existing Tasks can trigger the next connected action.

paused by default ​

INSUFFICIENT_EVIDENCE

paused sequences ​

Paused sequences are workflow sequences in the Autologyx platform that are not currently progressing and are counted separately from running sequences. In System configuration, the Sequences tile displays two values: the top number shows running sequences, and the bottom number shows paused sequences. This distinction gives Configuration admins and Super Admins a quick view of workflow activity from the landing page, helping them monitor sequence state, identify work that is on hold, and decide when configuration review or operational intervention is needed.

Paused state ​

Pending ​

Pending is a user account status in Autologyx Administration that indicates the activation email has been sent but the user has not yet completed account setup. This status is shown in user management for accounts such as Configuration Admins and other role-based users, and it is used to identify accounts that have been created but are not yet active. When an account is in Pending status, administrators can use the Resend activation email action to prompt the user to complete setup. This matters because it helps Super Admins and configuration administrators distinguish between users who are fully onboarded and users whose access is delayed until they finish activation.

Pending status ​

Pending status is the user account status in Autologyx that shows an activation email has been sent and the user has not yet completed account setup or confirmed activation. It is used on the Edit user page and in user activation flows exposed through the platform API, including delayed account activation, where sending an activation email changes a user from Created to Pending. This status matters to configuration admins, super admins, and developers because it identifies accounts that are awaiting user action, determines when activation emails can be sent or resent, and helps distinguish users who are not yet able to complete sign-in from those whose accounts are already Active.

Performing Work ​

  • Mostly relevant to: End-users
  • Closely related concepts: Analysts, Managing Tasks, Managing Documents, Object records, Personal Preferences

Performing Work is the end-user documentation path in the Autologyx platform for people whose primary role is carrying out day-to-day operational work rather than configuring the system or building applications. It is used in the Getting Started area as the recommended starting point for users who mainly work with records, tasks, and documents, helping them navigate the platform according to their responsibilities instead of by technical feature. This matters because it directs business users to the guidance most relevant to completing work efficiently in Autologyx, including working with object records and related content, managing assigned tasks and documents, and using personal preferences to support their day-to-day experience.

permission changes ​

Permission changes are the logged changes to access granted through Record Permission Sets when User Groups are assigned to or unassigned from an object in the Autologyx platform. They are used in object history and in the API endpoints that manage group IDs within Record Permission Sets, where each add or remove action is recorded as part of the object’s audit trail. This matters to configuration admins, super admins, security and compliance teams, and developers because it provides full traceability of how access control has been updated over time, supports governance and audit requirements, and helps teams verify which assigned User Groups currently control access, including where permissions inherit through the platform’s permission model.

Permission set allowing them to Edit the object class ​

In Autologyx, a permission set allowing a user to Edit the object class is an access control assignment that grants the ability to modify an object class and perform configuration actions that depend on that capability, such as creating a standalone form for that object class. It is used in system configuration and object class administration, alongside account types such as Super Admin and Config Admin roles, to determine who can maintain class-level configuration. This matters because object classes define key platform structures and related components, so granting this permission set ensures the right users can update configuration while maintaining controlled administrative access.

permission set configuration ​

Permission set modal ​

INSUFFICIENT_EVIDENCE

Permission Sets ​

Permission Sets in Autologyx are named access-control configurations that assign specific capabilities to users and user groups for a user group, an object class, or an individual object record. They are used throughout the platform in Object class Permissions tabs for class and record permissions, in User Group permissions, and in record-level access configuration including the Record Access actor and record side panel. Default permission sets exist for key ownership and membership contexts, such as Object class Owners, record Owners, and the Owners, Everyone, and Members sets on user groups, while additional custom permission sets can be created and assigned to control who can view, edit, create, manage tasks, or administer access in a defined scope. Permission Sets matter because they provide the practical mechanism for implementing operational and security rules in Autologyx, determining exactly what people can see and do in applications, records, tasks, and configuration areas without relying solely on broad account types or roles.

Show 22 more pages

Permission Sets (both Object Class and Record) ​

Permission Sets (both Object Class and Record) are the access-control settings used in Autologyx to define which users or user groups can view or interact with permission assignments at the object-class level and on individual records. They are used anywhere the platform allows selection of users or groups for permissions, including Object Class and Record ownership, User Group management, dropdown autocompletes, filters, task assignment, and other configuration points that expose user or group selectors. Their visibility is governed by List permissions through User Group Permission Sets and custom permission sets, which control which users and groups can be listed and selected in these contexts. This matters because administrators rely on these permission sets to apply accurate access rules while ensuring users only see selectable people and groups that they are allowed to view, supporting controlled administration, security, and compliance.

In Autologyx, the Permission sets link is the control shown under a user’s name in the Record access tab that opens the list of Record Permission Sets granted to that assignee for the selected record. It is used when reviewing or managing record-level access, including after using Give access or Add people to assign users to a record, so end-users, configuration admins, and Super Admins can confirm exactly what permissions each person has. This matters because assignee visibility alone does not show the level of access granted; the Permission sets link provides the detail needed to verify, audit, and adjust record access accurately.

permission to create or edit records in the parent object class ​

Permission to create or edit records in the parent object class is the access control requirement that allows a user to add or update the parent record when working with related data in Autologyx. It is used in relational record scenarios, particularly when creating a child record from within a parent record using the child component, the Create or Create record button, and the create/edit record display form shown in a fly-out modal. This permission matters because Autologyx allows child records to be created while the parent record is still being created or edited, so the user must be authorised to create or edit the parent object class as well as create records in the child object class for the action to be available and valid.

permission to create records in the child object class ​

Permission to create records in the child object class is the access control that allows a user to add new child records for a specific child object class within a parent-child relationship in Autologyx. This permission is used when creating a child record from a parent record and works alongside permission to create or edit records in the parent object class; both are required for the action to be available. In practice, it determines whether the user can use the Create record button and open the create/edit record display form for the related child record from the parent record. This matters because it controls who can extend relational data structures, ensures users can only add records to object classes they are authorised to use, and is a key configuration point for admins managing record creation behaviour in the workspace.

permission to list ​

Permission to list is the Autologyx access control that determines which users and User Groups are visible and selectable to a person when assigning work, including in task assignment scenarios such as the Create Task panel and other places where task assignees are chosen. If a user does not have permission to list a given user or group, that user or group will not be available for selection. This matters because it directly controls the set of assignees an end-user can choose from and therefore affects task routing, operational visibility, and how configuration admins structure access to users and groups in task-related workflows.

Permissions ​

Permissions in Autologyx are the access rights that control what a user can view, create, edit, administer, or interact with across the platform, including system configuration and work on records and tasks. Permissions are primarily granted through Roles, and a user’s effective access is updated immediately when roles are added or removed from their account; if a user has multiple roles, they receive every permission enabled in any assigned role. Permissions are used in user administration and role management, and also within Object Class configuration, where they define which sets of users can administer the class or work with its associated records and tasks. They matter because they determine both day-to-day user capability and administrative control, ensuring that access to features and data is aligned with each user’s responsibilities.

Permissions tab ​

The Permissions tab is the area in Autologyx where authorised users view and manage permission sets that control access to a user group or an Object class. In a user group, the Permissions tab is used by Super Admins and user group Owners to set default group permissions and create additional permission sets; in an Object class, the Permissions tab is available in Edit mode and includes Class permissions and Record permissions, where Super Admins and Object class Owners configure who can access, edit, or administer the class, its records, associated tasks, and assignees. This tab matters because it is the central place for defining role-based access across key platform objects, ensuring users and groups have the correct level of visibility and control while protecting administrative settings and operational data.

Show 2 more pages

Personal Authentication Object API ​

The Personal Authentication Object API, also referred to as the Authentication Object API for personal authentication objects, is an Autologyx API feature for developers and integrators that creates user-specific authentication tokens for each integrated service. It is used when building or configuring service integrations that require credentials to be tied to an individual platform user rather than shared at a broader system level, and it sits alongside the platform’s wider Authentication Objects capability. This matters because it enables integrations to authenticate separately for each user, supporting user-level access control, clearer ownership of connected-service credentials, and more precise configuration of external service connectivity within Autologyx.

Personal Information ​

Personal Information is the section of a user record in the Autologyx platform that stores a user’s personal details and is used in both user administration and the My Account area. Configuration admins and Super Admins can update these details from the Edit User page, and end-users can update the same information in My Account; changes made in either place are reflected in the user account. This matters because it keeps core user details consistent across the platform, supports accurate account management, and ensures each user’s profile information remains current wherever it is viewed or maintained.

phone and e mail ​

Phone and e mail is an Autologyx field type used to store contact details such as telephone numbers and email addresses within records. It is used in record-based views, including the Records list, where values in this field type can be sorted in ascending or descending order alongside other supported field types such as integer, date, text, and single select. This matters to end-users because it helps them organise and review contact information efficiently, and to configuration admins because selecting the correct field type ensures contact data is handled consistently in list presentation and sorting behaviour across the platform.

Phone number ​

In Autologyx, the Phone number field type is a task form input used to capture telephone numbers from end-users in a dedicated field that is presented with a phone icon at the end of the input. Configuration admins use this field when designing task forms in the form builder, alongside other input types and settings such as default value and description, to ensure phone contact details are collected in a consistent, recognisable format. This matters because it gives users a clear, purpose-built place to enter contact numbers on tasks and helps form designers structure data capture appropriately within workflow forms.

Phone type field ​

In Autologyx Catalyst, a Phone type field (also called a Phone field) is a form field used in record and task forms to capture phone numbers in a dedicated phone-number format rather than as general text. It is used when configuring forms in the form builder, particularly on intake and other record creation forms, alongside other specialised field types such as Email and Date/Time. This matters because using the correct field type ensures phone numbers are collected in a consistent way across the platform, improving data quality, usability, and the reliability of form design and downstream processes that depend on structured contact information.

placeholder avatars ​

In Autologyx, placeholder avatars are the default avatar images shown in the Owners field when owner details are not populated or cannot be displayed. They are used in record and task form properties, including the create and edit view, to indicate the presence and layout of owner assignments without showing specific user identities. This matters to both configuration admins and end-users because it distinguishes a visual placeholder state from a fully populated Owners field, helping users understand whether owner information is actually available in the form or is only being represented as a default display element.

placeholder text ​

In the Autologyx platform, placeholder text is the inline hint text sometimes shown inside an empty input field to guide user entry; however, in Autologyx Catalyst and the Catalyst form builder, Catalyst fields do not support placeholder text. This matters when configuration admins design intake forms or other record creation forms, because field guidance must be provided through labels, help text, section content, or other form design elements rather than text displayed inside the field itself.

Platform admin ​

Platform admin, also referred to as Administrators, is the role-focused area of Autologyx documentation for users responsible for administering the platform at a global level. It is used as a starting path in Getting Started for people who manage users, permissions, and system-wide setup, distinguishing this audience from users performing operational work, analysts building applications, and delivery teams supporting rollout. This role matters because platform admins configure the foundational access and administrative settings that govern how the Autologyx platform is set up, secured, and made available for effective use across the organisation.

Platform Admin Administrators ​

  • Mostly relevant to: Super Admins, Configuration admins
  • Closely related concepts: Administration

Platform Admin Administrators are the users responsible for administering the Autologyx platform, typically holding a Super Admin account type and working in the Administration area. They configure and maintain core platform settings such as users, roles, permissions, authentication, and outbound communications to ensure the environment remains secure, correctly configured, and aligned with organisational policies and integration requirements. This role matters because these administrators control the foundational settings that govern access, security, and operational behaviour across the platform as business needs and user requirements change.

Post API call ​

In Autologyx, a Post API call is an HTTP POST request made through the Sequencer to create a new platform resource or submit data for processing. It is used in configuration and integration scenarios where an action is not available in the user interface, such as creating service accounts, and is typically executed by Super Admins or developers using an internal or external service account and the appropriate sequencer auth object. This matters because POST operations are the mechanism for provisioning and automating setup tasks in the platform, enabling administrators and integrators to create required objects programmatically and support repeatable system configuration.

Post or Patch API Call actor ​

The Post or Patch API Call actor, also referred to as the API Call actor in this context, is a sequence actor used to send HTTP POST or PATCH requests to external services from within an Autologyx workflow. It is configured in sequence design and is especially important when integrating document-driven processes, because if it is placed after a Document Picker and the Data Type is set to Form Data, Multipart Data, or Binary Data, the actor exposes a Files section under Parameters so selected documents can be included in the outbound request. It is also a document source for later steps, as a subsequent Document Picker can be configured to take documents from the API Call actor. This matters to configuration admins and integrators because it enables workflows to upload, pass through, and reuse documents across connected systems while keeping document handling and API integration inside the same sequence.

pre configured fields ​

Pre configured fields are provider-tailored fields supplied by Autologyx within Authentication Objects to simplify integration with leading external services. In the Authentication Object configuration, these fields present the key connection settings expected for a supported provider—such as Client ID, Client Secret, Token URL, Refresh URL, Additional Parameters, and Additional Authorization Headers—so administrators and integrators can populate a structured set of values instead of building every field from a generic OAuth 2.0 template. This matters because it speeds configuration, promotes consistency across integrations, and works with the built in testing feature to help users validate authentication setup efficiently.

pre defined templates ​

Pre defined templates, also called document templates or templates, are reusable document definitions in Autologyx that the Templates panel uses to generate customized documents for selected records. In use, an end-user selects one or more records and generates a document from a template, with the output created as generated documents for the corresponding record. This matters because templates standardize document creation, reduce manual formatting and data entry, and help both end-users and configuration admins deliver faster, more consistent document management across the platform.

Precision setting ​

Precision setting is a field configuration option in Autologyx that defines how many decimal places a numeric value can use, with a supported range from 0 to 10. It is used when configuring Task Form fields in the Form Builder, alongside related field properties such as input type, default value, and description. This setting matters because it determines the level of numeric detail users can enter and view, helping configuration admins ensure form data is captured in the correct format for the business process.

predicates and conditions ​

Preferences ​

Preferences are the user-level settings in Autologyx that control how the application is displayed for an individual user. They are accessed from My Account and are used to define options for your view of the platform, such as interface presentation choices including row density and related display settings. Preferences matter because they let each user tailor the day-to-day experience of working in Autologyx without changing shared process or system configuration, and all Preferences settings are global, so the selected options apply consistently across the application.

Preferences settings are global ​

In the Autologyx platform, Preferences settings are global, meaning any changes a user makes in the Preferences area of My Account apply across the entire platform rather than only to a specific workspace, page, or task view. This is relevant wherever users manage personal experience options such as language and localisation, row density, row settings, and other account-level display or usability preferences. Understanding that these settings are global is important because a change made once affects how the user interacts with Autologyx throughout all areas of the platform, helping users configure a consistent experience and avoid expecting different preference behaviour in different locations.

premium add on ​

In the Autologyx platform, a premium add-on is an optional paid capability that extends the standard product with additional functionality. It is used at the platform and solution configuration level, where administrators enable and incorporate the add-on into relevant workflows, and it is then experienced by end-users as extra features within the product. In the documented example, the Zuva integration is delivered as a premium add-on for Autologyx Catalyst, adding contract upload and extraction of key terms and provisions. This matters because premium add-ons determine which advanced capabilities are available in a tenant, influence solution design and licensing decisions, and allow organisations to enhance document handling and automation in Sequencer without changing the core platform.

Present child records ​

Present child records is an Autologyx capability, introduced in Autologyx Catalyst 1.2, that lets child object classes created through the Relational modeller be added to record forms so related child records can be displayed and accessed directly within a parent record workflow. It is used in form design and record experience, alongside relation lookup and the child record component, and is complemented by the Child Record Summary side tab panel for quickly viewing key details of a selected child record. This matters because it enables configuration admins to surface structured related data in the right place on a form, and helps end-users work with connected records more efficiently by linking and reviewing business information in context.

Prevent password re use ​

Prevent password re use is a Standard authentication setting in Autologyx Administration that blocks users from setting a password they have previously used. It is configured alongside password policy options such as the rotation interval and applies immediately to all users. This setting is used in password lifecycle events, including user activation and password reset through the “Forgot your password?” flow, where disabling it allows a user to choose the same password again. It matters because it strengthens account security controls, supports compliance-focused password policies, and helps administrators enforce consistent credential management across the platform.

Preview ​

Preview is an editing-mode feature in Autologyx configuration screens that shows administrators how a configured user-facing item will appear and behave before publishing or returning to design changes. It is used in areas such as Landing page configuration and standalone Catalyst form design, where the Preview button lets you validate layout, components, conditional visibility, and default confirmation behaviour from the end-user perspective. Exit preview returns you to edit mode. Preview matters because it helps configuration admins confirm that the experience presented to users is correct, usable, and aligned with the intended configuration before it is made available.

Preview button ​

The Preview button is a form-design control in Autologyx configuration screens that opens a live preview of the form currently being edited, allowing configuration admins to check how the form looks and behaves before saving or continuing their changes. It is used in object class display configuration and standalone form editing, typically at the top right next to Save, and the Exit preview button returns the user to the editing canvas and Components panel. This matters because it lets admins validate layout, content, and interactive behaviour during configuration, helping ensure the final form works as intended for end users.

Preview mode ​

Preview mode is the form builder view in Autologyx that shows a live rendering of a form as it will be presented to the user who completes the task. It is used while configuring forms, including Create response forms and Complete self contained form task templates, to check layout, section headings, field presentation, and the effect of settings such as conditional logic, Conditional Visibility, Section Properties, and Show this section header before saving changes. Preview mode matters because it lets configuration admins validate the user experience during design, confirm that sections and fields display as intended, and return to the builder with Exit preview to continue editing.

PREVIOUS FIELD VALUE ​

INSUFFICIENT_EVIDENCE

Primary colour ​

In Autologyx, the Primary colour is a core theme setting configured on the Configure Theme page, within the Colours tab, that defines the main accent colour used across key interactive interface elements. It is applied to controls and highlights such as radio buttons, Create buttons on lists including Object classes and Task templates, Add buttons such as the Add field action in an Object Class, and the gradient shown on the right-hand side of tiles in the System configuration and Administration menu pages. This setting matters because it establishes a consistent visual identity across the platform and directly affects the appearance of prominent actions and navigational cues seen by users.

Private RSA Key field ​

The Private RSA Key field is a configuration field in an Authentication Object used when setting up DocuSign integration in the Autologyx platform. Configuration administrators and integrators use this field on the Create/Edit Authentication Object screen to paste the private RSA key generated for the DocuSign application, alongside related connection values such as the Client ID and Host. This field matters because it stores the credential required for secure authentication between Autologyx and DocuSign, enabling the platform to establish the connection needed for DocuSign-enabled processes.

process engine ​

process flows ​

In the Autologyx platform, process flows are the configured sequences of steps that define how work progresses through Catalyst, combining user tasks, automated actions, decisions, and integrations into a single operational workflow. They are used wherever a business process is designed and executed, including scenarios where integrated services such as Adobe Sign or DocuSign are invoked directly within the flow to complete actions like sending documents for signature. Process flows matter because they provide the structure that governs how cases move from one stage to the next, ensure that platform features and external services operate in the correct order, and give configuration admins a central way to design, automate, and control end-to-end business operations.

Processing ​

Processing is an Element status in the Autologyx platform that shows an Element package is currently being imported or installed. This status is used in Element management views, including the Elements list page and related administration areas, to indicate that setup is still in progress and the Element is not yet ready for normal use. For Configuration Admins and Super Admins, Processing is important because it provides immediate visibility into deployment activity, helps distinguish in-progress packages from Installed, Enabled, or Failed states, and supports accurate monitoring and management of Element availability.

promote to owner ​

Promote to owner is an action available in the User group Members list Actions menu when editing a User group in Autologyx. It is used to change a user’s group membership status from Member to Owner, alongside related membership-management actions such as Demote to member and Remove from group. This action is relevant to administrators managing group access and responsibility, because Owners have owner-level status within the group and can be managed through the same membership interface that supports filtering by Members and Non members and performing bulk add or remove actions. Using Promote to owner is important when configuring who should administer or control a User group and maintaining the correct ownership structure for that group.

prompt and context fields ​

Prompt and context fields are configuration inputs used in the Autologyx Azure OpenAI actor for Chat and Instruct model types to define how the model should respond. The prompt field supplies the task or instruction to be performed, while the context field provides supporting details, background information, or constraints that guide the generated output. These fields are used when configuring AI-driven steps and work alongside settings such as model type, temperature, endpoint field, and user parameter. They matter because they directly control the relevance, structure, and boundaries of the AI response, making them key settings for administrators and integrators who need predictable, task-specific behaviour from the platform’s AI integration.

Properties ​

Properties in Autologyx are the configuration settings and system metadata presented through a Properties or options panel, and the related Property components available in form design. They are used in two main places: in record and task form configuration, where Properties appear in side panels and can be dragged onto Card, Create and edit, and Summary views to display built-in values such as the ALX ID; and in the sequence workspace, where administrators right-click a Sequence Actor and select Properties to define or update actor settings, including assigning a clear name. Properties matter because they control how forms present system information, how object class displays are configured, and how sequence actors are identified and configured, making them a core part of accurate platform setup and maintainable automation design.

Show 1 more pages

properties or options panel ​

In the Autologyx Catalyst formbuilder, the properties or options panel is the configuration panel that opens when a builder selects a component on the canvas, allowing the settings for that element to be defined and edited. It is used while designing record forms, standalone forms, and task template self contained forms, alongside the formbuilder canvas and other side panels. This panel matters because it is where configuration admins control how each form element behaves and is presented, making it the primary place for tailoring components to meet process, data capture, and user experience requirements.

Provider field ​

The Provider field is a setting on an Authentication object in Autologyx Administration that defines which external service or integration the authentication configuration is for, such as DocuSign. It is used when creating the authentication object, where administrators select the relevant provider so the platform can associate the object with the correct integration and required connection details. After the Authentication object has been created, the Provider field is locked and cannot be changed, ensuring the object remains tied to its original integration. This matters because the selected provider determines how the authentication object is used by the platform and prevents configuration errors that could result from changing an established integration type.

provider specific actors ​

Provider specific actors are Autologyx Applied AI actors that are tied to a particular AI provider, such as OpenAI, Azure, or Bedrock, and are used in process flows to perform tasks such as content classification, extraction, summarisation, and review through that provider’s integration. They are relevant when configuring and using integrations in System Configurations → Integrations, where platform administrators and integrators enable and manage the underlying provider connection needed for these actors to run. This matters because the selected provider-specific actor determines which external AI service a workflow uses, linking process design directly to integration setup, authentication, and the AI capabilities available in the platform.

provider-tailored fields ​

Provider-tailored fields are the provider-specific configuration fields presented in Autologyx Authentication Objects so an admin or integrator can enter the exact connection and credential details required by a chosen external service. They are used when configuring authentication for integrations, where the platform surfaces a unique set of preconfigured fields for each provider instead of relying only on a generic OAuth 2.0 template; these fields can include core values such as Client ID, Client Secret, Token URL, and Refresh URL, together with Additional Parameters and Additional Authorization Headers where needed. This matters because provider-tailored fields streamline setup, reduce manual interpretation of provider requirements, and help users configure and test integrations more efficiently using the built-in testing feature.

providers ​

In Autologyx, a provider is the external service or authentication type selected when creating or editing an Authentication object, such as Microsoft oAuth 2.0 (Client Credentials flow), Adobe oAuth 2.0 (Client Credentials flow), Box oAuth 2.0 (Client Credentials flow), Generic OAuth flows, DocuSign, or Autologyx internal. Providers are used in the Authentication objects list and in the Authentication object configuration screen, where the chosen Provider is shown as a column value and determines which mandatory configuration fields are displayed. This matters to Configuration admins and Super Admins because the provider selection defines how Autologyx connects to a target system, what technical credentials and settings must be entered, and whether integrations such as outbound mail or third-party service access are configured correctly.

pub/sub mechanism ​

In the Autologyx platform, the pub/sub mechanism is the event-listener channel that exposes a limited set of host application values to an Element, allowing an otherwise isolated Element to receive context from the page it is embedded in without direct page-level communication. It is used when configuring or developing Elements, where specific runtime values such as the current record ID and logged-in user auth tokens are automatically made available through this mechanism. This matters because it defines the supported integration boundary between an Element and the main Autologyx application, enabling secure, controlled access to essential context needed for Element behaviour while preserving the Element’s isolation from the hosting page.

Publisher ​

Publisher is the metadata field on an Element in Autologyx that identifies the organisation or source that published that Element, with the value taken directly from the Element’s configuration file. It is used on the Elements list page as part of the information shown for each Element alongside details such as status and installation state, helping Configuration admins and Super Admins distinguish between Elements from different providers and manage their element catalogue accurately. This matters when reviewing, administering, and selecting Elements, because the Publisher field provides a clear source reference for each installed or available Element in the platform.

radio buttons ​

Radio buttons are a display option for single-select fields in Autologyx forms, used in the Catalyst form builder and when creating standalone forms from the Forms tab. They present all available choices visibly on the form and allow the user to select one option only, in contrast to checkboxes, which support multiple selections, or a drop-down list, which saves space by hiding options until opened. This matters to configuration admins because choosing radio buttons affects form usability, layout, and how quickly users can understand and complete record creation or other input forms.

ratio selector ​

In Autologyx, the ratio selector is the control shown on a child object class in the Relational model canvas that defines the relationship cardinality between the child object class and its parent object class, such as 1:1 or 1:N. It is used by configuration administrators and Super Admins when creating or editing the platform’s relational model to specify how records in one object class can relate to records in another. This matters because the selected ratio determines the structure of parent/child relationships in the data model, directly affecting how object classes are configured and how related records are organised across the platform.

Re Assigning Tasks ​

Re create ​

Re create is an action in the Set Task Actor used by configuration admins to create a new instance of a task that has already been created and completed. It is configured within sequence design by selecting the Re create action in the actor, after which no further setup is required for that action. This option is used when a completed task must be issued again as part of the process flow, rather than relying on the platform’s automatic task creation mechanism or task selection options such as completed or outstanding task lists. Re create matters because it gives administrators explicit control over repeating completed work within a workflow, ensuring the process can trigger the same task again when the business process requires it.

Re create option ​

INSUFFICIENT_EVIDENCE

Re-assigning Tasks ​

INSUFFICIENT_EVIDENCE

Read only ​

Read only is a field configuration in the Autologyx platform that displays a form field as unavailable for manual editing, typically greyed out so the user completing the task or record form cannot enter or change its value. It is used in Form Builder when configuring task form fields and also applies to specific field types such as User type Class fields, where values are intended to be populated or updated by platform automation such as Sequencer rather than by end users. This setting matters because it lets configuration admins present important information on a form while protecting system-controlled or pre-set values from manual change, helping enforce process design, preserve data integrity, and ensure users interact only with the fields they are expected to complete.

Read only fields ​

Read only fields are form fields configured in Autologyx to display data to users without allowing them to edit the value directly. They are used in forms and display form design to control field accessibility, typically where information such as status or system-managed values must remain visible while being protected from manual change. For configuration admins, the Read only option provides a straightforward way to preserve data integrity and enforce process rules, while for end-users it ensures important information is available in context without exposing it for update. This matters because it supports accurate records, controlled updates through platform logic such as Sequencer, and a clearer user experience when certain values are intended for viewing rather than editing.

read only mode ​

In Autologyx, read only mode is the state in which a record form is opened for viewing without allowing changes, typically because the user has view record permission but not edit rights for that record. It is used in the workspace when users open records they can inspect but not update, and it directly affects the available controls on the form. In read only mode, editing actions are suppressed, including relational controls for managing child records, so options such as the Create button and child lookup controls are hidden and users cannot add or remove associated child records. This matters to both end-users and configuration admins because it defines the boundary between viewing and maintaining data, and it explains why certain form elements and relationship-management actions are unavailable in specific permission contexts.

Read only option ​

The Read only option is a field setting in Autologyx display form design that makes a form field non-editable for end users while still displaying its value. It is used when configuring display forms, including standalone forms, by enabling the Read only option during field setup. This setting is important because it protects data integrity for fields that users must see but must not change manually, such as preset or controlled values, while still allowing automated updates through Sequencer when configured conditions are met.

read only perspective ​

In Autologyx, a read only perspective is the access model provided by Autologyx Cross Platform views that exposes data for inspection and analysis without allowing any changes to schemas or records. It is used when viewing Event History and Resource table data, including integrations such as ClickHouse and other database-view access patterns scoped to the selected domain. This matters because it gives developers, configuration administrators, and compliance or analytics users a safe way to query and report on platform data while preserving the integrity of operational data structures and preventing unintended modification.

Real time events related to Object Records, also called Object Record events or real time Object Record events, are the live event stream delivered by the Autologyx WebSockets endpoint as soon as an authenticated connection is established. In the platform, these events are used by developers and integrators to receive immediate updates about Object Records within the environment defined by the authentication token, enabling connected applications, integrations, and Catalyst Elements to react without polling. This matters when configuring or consuming Autologyx integrations because it provides a direct mechanism for synchronising external systems and user experiences with changes to Object Records, while operating within the platform’s WebSocket connection and broadcast limits.

Real Time Workflow Improvements ​

INSUFFICIENT_EVIDENCE

Recipient ID ​

Recipient ID is the identifier assigned to each signer when a DocuSign envelope is created, and in Autologyx it is used in DocuSign integration logic to target a specific recipient and retrieve that recipient’s signing status. It is used when configuring or consuming API call outputs, including local variables that reference signer status values for a particular recipientId, and it depends on recipients being listed in the correct order and mapped to the intended IDs in the envelope creation call. This matters because Recipient ID is what lets configuration admins and integrators reliably connect envelope response data to the correct signee, monitor individual recipient progress, and drive workflow behaviour from the right recipient status.

Recipient status ​

Recipient status is the DocuSign recipient-level signing state captured in Autologyx for each individual recipient on a DocuSign Envelope. It is used in Catalyst workflows that retrieve recipient information, store the returned status in local variables or Record Fields, and then update records through an Update Record actor so the current recipient signing status can be tracked over time. Recipient status matters because it can be displayed in record lists and used in task templates, document templates, send message actors, and trigger conditions such as actions that depend on whether a specific actor has completed, allowing configuration admins and end-users to drive process steps from the progress of each recipient rather than only the overall envelope state.

Record access ​

Record access is the tab in an object record’s edit view side panel that displays the owners of that specific record and is used to review who has record-level ownership. In Autologyx, it is available when a record is opened from the Records list and can be accessed by the Object Record Owner, users with a Super admin account, and Object class Owners. This matters because it gives users and administrators a clear view of record ownership within the platform, supporting day-to-day record management and helping configuration and administrative roles verify who is responsible for a record.

Record Access actor ​

The Record Access actor is a Sequencer actor used to control record access and record ownership on Autologyx records by assigning, overriding, appending, or removing record permission set assignments for individual users or user groups. It is configured in sequences, typically where access needs to be set or corrected automatically as records are created or updated, and it is closely tied to Record Permission Sets, User Groups, and ownership configuration. For Configuration Admins and Super Admins, this actor matters because it provides a central, automated way to enforce who can access a record and who owns it, reducing manual permission management and ensuring record-level access is applied consistently across business processes.

Show 1 more pages

Record Access Actor Users and Groups Visibility Control ​

Record access configuration modal ​

INSUFFICIENT_EVIDENCE

Record access panels ​

Record access panels are the record-level tabs in Autologyx that display access information for an object record alongside other record tabs such as Tasks, Templates, and Activity Log. They are used in record views by end-users reviewing a record and by configuration admins validating how record details are presented, including the identifier shown at the top of the panel when an object class field is marked Use as identifier. Record access panels matter because they are part of the standard record navigation experience, surface key identifying information for the current record, and are affected by platform configuration and permissions, including object class field settings and permission-controlled access behaviour.

Record access tab ​

The Record access tab is the side-panel tab on an individual object record in Autologyx that shows and manages who can access that record. It identifies the record Owner and the users who have access through assigned Record Permission sets, and it is also used to add or remove assignees and apply additional permission sets at record level. The tab is available on object records to the owner of the object class, the owner of the record, and users with a Super admin account type, although it is not available in some contexts such as where record-permission behaviour is restricted for particular object classes. This tab matters because it is the primary record-level control point for granting, reviewing, and maintaining access to a specific record, ensuring the right users can work on it and that record permissions are managed correctly within the workspace.

Record Actions menu ​

The Record Actions menu, also shown as the Actions menu, is the contextual menu for a record in Autologyx that provides commands a user can run against that specific record, such as Open. It is used in record-based interfaces including list and card views, where users access record-level options without opening the full record first. In display configuration and day-to-day use, this menu matters because it is one of the standard entry points into the Create and edit view and related record interactions, so understanding where it appears and what actions it exposes is important when designing user displays and when guiding users through record navigation and processing.

Record and Task Forms ​

Record and Task Forms are the Autologyx forms used to capture, display, and manage information for both Object Records and Tasks. In the platform, they sit between underlying system configuration and the day-to-day user experience, providing the structured interface through which end-users enter data, complete work, and progress activities. They are used in the Catalyst Knowledgebase and related configuration areas such as the Form builder, Formbuilder Components, sections, and Conditional Logic in Forms, where configuration admins design how form content is organised, presented, and controlled. Record and Task Forms matter because they define how users interact with records and tasks in practice, shaping data quality, process consistency, usability, and the effectiveness of the overall workflow.

record based merge fields ​

Record based merge fields are merge fields that resolve values from the current record in an Autologyx case or workflow context, and are used wherever the platform supports standard record data substitution, including Document Templates, Send Message actors, Local Variables, and API Call configurations. In practice, they let configuration admins and developers insert record data directly into generated documents, messages, variable values, and outbound payloads without hard-coding values, ensuring that workflow outputs stay aligned with the live record. They matter because they are the standard mechanism for reusing record data consistently across workflow components and integrations, which simplifies configuration and helps keep automated actions and generated content accurate and maintainable.

Record card view ​

Record card view is the record-level display in Autologyx where a user opens an individual record and sees its key identifying information and details. In the context of object class configuration, this view is one of the places where changes to a field identifier are surfaced, alongside the Fields list and other record-related displays. It matters to configuration admins because field definitions directly affect how records are presented and recognised in day-to-day use, so updates made to object class fields must be understood in terms of their impact on the record card view and the consistency of record display across the platform.

Record create mode ​

Record create mode is the state of the Autologyx record interface used when a user is creating a new Object record, typically after selecting the Create record action and working in the create record form or create/edit view. In this mode, the interface is focused on entering the initial values required to create the record, and the side panel is not available. This matters to end-users because it defines the experience and available interface elements during manual record creation, and it matters to configuration admins because it affects how record creation journeys are designed, what users can access while creating a record, and how create forms should be structured for efficient data entry.

Record created ​

Record created is a Sequence start condition in Autologyx that triggers a Sequence when a new record is created in a selected Object class, either immediately or after a specified time. It is configured in the Design step when editing a Sequence and is one of the most commonly used methods for initiating automated processing. This trigger matters because it determines that a business process starts from the creation of a new object record, allowing administrators to launch the correct workflow at the point data enters the platform and to distinguish this behaviour from related start conditions such as Record created or updated and Record updated.

Record created or updated ​

In Autologyx, Record created or updated is an automatic Sequence start condition used in Sequence Design to trigger a Sequence when a new record is added to the selected Object class or when an existing object record is amended. Configuration admins and Super Admins use this option when configuring automated processing that must run both at the point of creation and whenever record data changes. It matters because it determines when automation is initiated for object records, helping ensure that workflows, actions, and downstream processing are consistently started in response to both new records and subsequent updates.

record creation ​

Record creation is the process in Autologyx of generating a new record in a target Object Class, either manually through platform forms or automatically through components such as the file upload component, which can create a new record for each valid uploaded file. It is used wherever users enter or import new business data and wherever administrators configure the fields, display forms, and field accessibility that control what can be completed, validated, or kept read-only when a record is first created. Record creation matters because it defines how information enters the platform, affects data quality and user experience at the point of entry, and enables scalable automation such as batch creation while reducing manual effort and errors.

Record Creation Datetime ​

Record Creation Datetime is the timestamp field exposed in Autologyx database views that records when a record was created in the platform. It is used in the structured, read-only data snapshot provided by Autologyx Cross Platform views alongside core identifiers such as Record ID and Record Identifier, making it available to reporting, compliance, security, analytics, and integration use cases, including ClickHouse-based querying. This field matters because it provides a consistent creation-time reference for filtering, sorting, auditing, correlating records across systems, and building time-based analysis or downstream integrations from platform data.

record creation form ​

A record creation form in Autologyx Catalyst is the form configuration used to create new records for a specific object class. It is built and maintained in the Form Builder, and in practice includes the Create and edit view configured under the object class Display tab, where permitted logged-in users enter the data required to create a record. Record creation forms are a key configuration point for admins because they define the user experience at intake, determine which fields are presented when a record is created, and support design features such as conditional logic to control how information is captured.

record creator ​

In Autologyx, the record creator is the user who originally created a record, and this role is available in sequence configuration as a recipient option in the Send Message Actor. Configuration admins use the record creator setting when defining email actor behaviour to direct generated messages automatically to the person who created the record, either on its own or alongside other recipient types such as the record owner, specific users, user groups, fixed email addresses, or email addresses stored in record fields. This matters because it provides a reliable way to route notifications and communications to the user who initiated the work item, supporting consistent process communication without requiring recipient details to be entered manually in each case.

record details endpoint ​

In the Autologyx platform, the record details endpoint is an API endpoint used to retrieve metadata for an individual file or record, typically when an integration needs the detailed properties of a specific item returned from record lists or Object records queries. It is used by developers and integrators when building document and records workflows that need per-record metadata, and it matters because it defines the single-record retrieval pattern that newer bulk metadata capabilities improve on by allowing up to 50 files to be fetched in one request instead of calling the record details endpoint separately for each file.

record Displays ​

In Autologyx, record displays are the three configurable views used to present and manage a record through its lifecycle, created in the Catalyst formbuilder. Configuration admins and Super Admins use record displays when defining how an object class is shown in the Card view, Create and edit view, and Summary view, using the canvas, elements, side panels, and properties or options panel to control layout and behaviour. Record displays matter because they define the user experience for viewing, creating, and updating records, ensuring that the right information, controls, and interactions are available in the appropriate context across the platform.

Record Fields ​

Record Fields are the data fields stored on an Autologyx record and used throughout the platform to hold business information, email addresses, document references, and status values such as recipient signing status. They are used in actor configuration and runtime processing, including as merge sources in Send Message and document templates, as targets in Update Record actions, as sources or destinations for documents in Document Picker flows, and as selectable record context in sequences. Record Fields matter because they provide the core mechanism for reading, updating, displaying, and reusing record data across workflows, integrations, templates, record lists, and trigger logic, ensuring that process automation works with the correct record-specific information at each step.

record Filter ​

In Autologyx, a record Filter is the search-and-filter control used when selecting existing records from a list, such as when associating child records with a parent record. It is typically presented in lookup and selector interfaces within create or edit views and flyouts, where users open the filter for the relevant object class, enter search text, and narrow the available records to find the correct item. As selections are made, the displayed list updates to show matching or selected records, and the filter can be cleared using the control’s remove option to restore the full list. This matters because it is the primary mechanism for locating and attaching the correct related records efficiently, and understanding how it behaves is important for both end users performing record association tasks and configuration admins designing usable relational record workflows.

record forms ​

Record forms are the create and edit interfaces used in the Autologyx platform to capture, display, and update object class record data. They are used by end-users when creating or maintaining records and by configuration admins when defining how object class fields are presented, including field defaults, input constraints, user and group selections, JSON fields, and related child object classes exposed through Autologyx Catalyst relational modelling. Record forms matter because they control the practical data-entry experience for records, determine which information users can enter or review, and ensure configured object class structures are surfaced in a consistent, usable way across record creation and maintenance.

record hierarchy ​

  • Mostly relevant to: End-users, Configuration admins
  • Closely related concepts: breadcrumbs

In the Autologyx platform, the record hierarchy is the parent-child structure that shows how a record sits within related records, providing the contextual path from a higher-level item down to the record currently open. It is surfaced in navigation elements such as breadcrumbs, where it helps users quickly identify the exact record they are viewing and understand its place within the wider case or process structure. This matters to end-users because it improves orientation and speeds navigation between related records, and it matters to configuration admins because clear hierarchical relationships support intuitive user journeys and make record structures easier to design and maintain.

Record ID ​

Record ID is the system-generated numeric identifier assigned to a Record when it is created in Autologyx. It is used throughout the platform wherever a specific record must be referenced, including sequence testing and execution, API Call and Local Variable actor configuration, Send Message actor testing, sequence commencement conditions, and in Elements where the record id is passed in object record metadata and exposed to embedded components. Record ID matters because it provides the definitive link between configuration, automation, messaging, API interactions, and the correct business record, ensuring that actors, variables, conditions, and custom elements retrieve, evaluate, and act on the intended data.

Show 2 more pages

Record Identifier ​

Record Identifier is the user-facing identifier for an object record in the Autologyx platform, used alongside the internal Record ID to distinguish and reference a record in a readable way. It is shown in record-level interfaces such as the Record access tab and is also exposed in database views and cross-platform reporting outputs that include key record metadata such as Record ID, Record Identifier, and creation details. Record Identifier matters because it helps end-users, administrators, and compliance or analytics teams recognise and work with the correct record across workspace views, integrations, and reporting, while also reflecting access controls: if a user is not the record Owner or does not have the required record permissions, the Record Identifier is blanked out to prevent disclosure of restricted record information.

record identifier field ​

In Autologyx, the record identifier field is the field that stores the primary human-readable identifier for an object record and is used when records need to be identified in the platform or exposed through templates and integrations. It is relevant in system configuration and template design, particularly when working with record properties and Jinja merge fields, because it is treated differently from standard object fields: the record identifier field cannot be referenced using normal dot syntax in Jinja merge fields. This distinction matters for configuration admins and developers because record-related output, document generation, and integration mappings must use the correct record property or supported shorthand rather than assuming the identifier field behaves like any other field on the object.

record layout ​

In Autologyx, a record layout is the configurable structure of a Catalyst record view that controls how information and components are arranged and presented to users. Configuration admins use the record layout in the create/edit record display form builder to place fields, sections, and integrated components, such as the iManage Cloud component, onto a Catalyst record. Record layouts matter because they define the user experience for viewing and maintaining records, ensuring that the right content, actions, and integrations are available in the correct place for operational use.

record list columns ​

In Autologyx, record list columns are the fields shown as columns in record list views, providing a tabular summary of record data for users reviewing, filtering, and navigating records. They are used anywhere records are presented in lists rather than in full create/edit record forms or task forms, and their display behavior affects how field content is surfaced in those views. This is especially important for Markdown fields: when a Markdown field is included as a record list column, Autologyx displays the underlying source code rather than rendered text. For end-users, this determines what they see when scanning records in lists; for configuration admins, it matters when choosing which fields to expose as columns and how readable that information will be in list-based interfaces.

record lists ​

In Autologyx, record lists are the list views used to display and work with collections of records within a process or object, giving end-users and configuration admins a structured way to review, filter, and manage record-level information. They are used wherever records need to be surfaced in the platform for day-to-day workflow activity, and can be configured to support filtering against related data such as document type fields. This is important because record lists help users quickly identify records that meet specific criteria, including records with missing or populated document information, improving visibility, prioritisation, and control over work in progress.

record owners ​

In Autologyx, a record owner is the user designated as having full control over a specific record. By default, the user who creates a record becomes its owner, including when records are created through hierarchical creation endpoints, and this ownership grants full record permissions such as managing access, assigning or revoking record permission sets for other users, assigning additional owners where supported, and deleting the record. Record ownership is used across the platform in the Record access tab, records and tasks lists, and in sequence configuration through actors such as Record Access, Task Assignment, Send Message, and Sequence Runner, where the record owner can be selected for access changes, task routing, and notifications. Record ownership matters because it determines who can administer a record, who can see related work in key workspace views, and how automation and security rules operate for that record.

Show 4 more pages

Record Owners' Permissions ​

Record Owners’ Permissions are the default, fully enabled permissions automatically applied to the owner of an object record in Autologyx. Used within object class record-permission configuration, they define the access that the record owner has to their record and are shown alongside other permission sets when configuring or reviewing record permissions for an object class. These permissions matter because they establish the platform’s baseline owner access model for object records and, unlike other configurable permission sets, cannot be edited, so administrators must account for them when designing class permissions and ownership-based access behaviour.

record ownership ​

Record ownership is the Autologyx setting that defines which users or groups are assigned as owners of a record and therefore hold owner-level access to that record. It is configured in the Sequencer through the Record Access actor, where administrators can manage ownership centrally alongside Record Permission Set assignment. Record ownership can be removed, applied only when a record has no owner, overridden with new assignments, or appended to retain existing owners while adding more; assignments can be made directly by user, by groups, or dynamically from user-type field values. This matters because ownership controls who has direct responsibility and access to a record, and it is commonly configured immediately after record creation or updated during workflow execution to keep access aligned with operational rules.

record ownership configuration ​

Record ownership configuration is the Record Access actor setting in Autologyx that defines how ownership is assigned to records and which users are set as owners during process execution. Used by configuration admins and Super Admins when configuring record access, it supports multiple assignment methods, including user-based and field-based assignments, and works alongside permission set configuration to control who can access and manage record data. This configuration matters because record ownership drives the assignees applied to a record, enabling organisations to align access with business rules, user roles, and 1TC user mappings while choosing whether new ownership settings append to or override existing owners.

record permission assignments ​

Record permission assignments are the Record Access actor settings used to grant defined Permission Sets to specific users or assignees for a record in the Autologyx platform. They are configured by administrators within record access and permission set configuration, including options such as assigning by users, assigning by field, and controlling how assignments are applied with append or override behaviour. This matters because record permission assignments determine who can access and work with a record beyond ownership alone, enabling secure, consistent, and scalable control of record-level access in automated processes.

Record Permission Sets ​

Record Permission Sets are object-class-level access definitions in Autologyx that are applied to individual records to grant access to specific users or user groups without changing record ownership. They are configured on the Object class, surfaced in the Record access tab and Give access workflow in the workspace, and can also be assigned or removed programmatically through the Record Access actor and API, including support for user groups. Record Permission Sets matter because they provide a controlled, scalable way to manage who can work with a record, distinguish ownership from shared access, and support automation and administration of record-level permissions across business processes.

Show 2 more pages

Record permissions ​

Record permissions are object-class permission sets in Autologyx that control which users or user groups can access and act on specific object records, separate from broader class permissions that govern access at the object-class level. They are used in the Permissions tab of an Object Class, where record permission sets are defined and maintained, and they can be assigned directly to users or groups through record access configuration in the Sequencer; by default, the record Owner has a record permission set with all permissions enabled. Record permissions matter because they determine who can view, edit, delete, and otherwise work with individual records they do not own, allowing administrators to restrict access to defined sets of records while ensuring owners, assignees, and other authorised users have the correct level of record-level access.

Record permissions set ​

A Record permissions set in Autologyx is a configuration on an Object class that defines what a user can do with individual Object records in that class, including actions on tasks associated with those records. It is configured on the Object class in Edit mode under the Permissions tab, within the Record permissions sub-tab, and is used to grant or remove record-level access for specific users. The user who creates a record becomes its Owner by default and can assign a Record permissions set to other users, revoke another user’s access, or give up ownership; Object class owners and Super Admins can create and edit these permission sets and manage ownership more broadly. Record permissions matter because they control operational access to records and related tasks, and they work alongside class-level permissions, so users also need the relevant Class permission such as Object class/List to use record access effectively.

Record properties ​

Record properties are the built-in data attributes of an Autologyx record that describe the record itself, distinct from class fields, which store business-specific data defined on an object class. In the platform, Record properties are used anywhere record data is selected, displayed, filtered, or merged, including Form Builder configurations for create and edit views, child object class presentations, records list column and filter configuration, and document templates and sequencer logic through merge field syntax. They matter because they provide a consistent set of system-level values that administrators, end users, and integrators can rely on when shaping record views, building templates, configuring relationships, and controlling how records are searched and presented across the workspace.

Show 1 more pages

record update task types ​

record update tasks ​

Record updated ​

In Autologyx, Record updated is a Sequence design trigger used to start a Sequence, or a specific workflow within a Sequence, when an existing record is updated. It is configured in the Sequence Design area alongside other activation methods such as Record created and Record created or updated, and is used by configuration administrators when defining how automation responds to changes in business data. This trigger matters because it allows process execution to begin at the point a record changes, ensuring that follow-on tasks, workflow steps, and automated actions run in response to updates rather than only at initial record creation.

Record Updated triggers ​

INSUFFICIENT_EVIDENCE

Record views ​

Record views are the configured display definitions for records in the Autologyx workspace, set at the Object class level to control how records are presented to users in areas such as the Records list. They work alongside class fields and column configuration to determine which record information is shown in different layouts, including related views such as Card view and the create or edit view. Record views matter because they shape how users find, open, and work with records, ensuring that the most relevant information is visible in the right context and that the record experience is aligned with the object’s configuration.

record's page ​

In the Autologyx Catalyst platform, the record page is the user interface page for an individual record where its details, configured fields, and selectable values are presented to end users. It is used during record creation and ongoing record handling as the place where users view and complete the information defined by field configurations. For configuration admins, the record page is important because field setup directly controls what appears there; for example, User type fields can be configured to let users select from registered users on the record page. Understanding the record page matters because it is the main point where configuration choices become part of the user experience and determine how record data is captured and maintained.

record.field ​

In Autologyx, **record.field** is the merge-field syntax used to insert the value of a field from the current record’s object class into platform outputs and automation components. It is used in contexts that support merge fields, including Document Templates, Send Message actors, Local Variables, and API calls, and follows the format {{record.field field name}}, for example {{record.field start date}}. This term matters because it is the standard way to reference record data dynamically within configured templates and sequences, ensuring that documents, messages, variables, and integrations are populated with the correct field values from the record being processed.

record.field[index].embedded ​

record.field[index].embedded is a Document Template merge field syntax used in Autologyx dynamic document assembly to insert the full contents of a file stored in a Record field directly into a generated .docx document. It is used inside .docx merge fields, for example {{ record.field[index].embedded }}, where the field identifies a document-type field on the record and the index selects a specific file from that field. This matters because it allows configuration admins and end-users to assemble complete documents from reusable source files such as clauses, annexes, or statements without copying content manually, ensuring template-driven document generation is faster, more consistent, and easier to control.

In Autologyx, **record.related records** is the merge-field namespace used to access records related to the current record within Jinja2 expressions in Document Templates and other merge-field contexts. It is referenced with the relationship’s internal index, such as **record.related records** 2 or **record.related records** 11[0].field site name, and can be iterated over in for loops or accessed directly by position to read fields from parent or child object-class records. This matters to configuration administrators and developers because it is the mechanism for traversing relationships between object classes when building dynamic templates, conditional logic, and grouped output; using the correct related-record index and applying guard if statements where indexed items are expected ensures templates handle related data safely and render the intended values.

Records ​

In Autologyx, a Record is an individual instance of an Object class that stores the data, documents, relationships, and activity for a specific business item, such as a case, client, application, or related child record. Records are used throughout the platform: end users work with them in Workspace and Records lists, manual tasks are created from a Record, sequences can start or branch when Records are created or updated, document templates and merge fields pull data from Record fields and related Records, and API and integration features use Record IDs and Record data as context. Records matter because they are the core unit around which process execution, task management, permissions, document generation, integrations, and parent-child data modelling are organised.

Show 27 more pages

records and tasks ​

In the Autologyx platform, records and tasks are the two primary contexts in which users view, enter, and act on workflow data: records hold the case or process information being managed, while tasks present the work items users complete as part of that process. The same configured fields, including User Type Class fields, can be surfaced in both areas, giving end users a consistent experience when creating or editing record data and when completing task-driven activities such as record update tasks. This matters because configuration admins can design task templates and record structures that behave consistently across the platform, ensuring that assignments, permissions, responsibility tracking, and group member syncing work in the same way wherever the field is used.

Records list ​

The Records list is the Workspace view that displays the records a user is permitted to access for a selected object class, providing the main place to find, review, sort, open, and create records in Autologyx. It is used by end users as the primary operational list for managing work, including switching between list and card views, opening records, viewing configured fields such as record properties and class fields, and returning to records after create or edit actions; it is also used by configuration admins when defining how object class information is presented through display settings and column configuration. The Records list matters because it is a core navigation and productivity surface in the platform: its display configuration determines what users can see at a glance, features such as sorting help users organise and locate records efficiently, and the Create record button and related create/edit views connect it directly to record creation and ongoing record maintenance.

Show 8 more pages

records list column header ​

A records list column header is the label and corresponding field shown as a column in an Autologyx records list, used to display record data in list views so users can quickly see and work with key values without opening each record. In practice, configuration admins define or populate fields in templates, actors, or update steps—such as storing an envelope status value in a field—and that field can then be exposed as a column header in the records list. This matters because it turns process data into visible, sortable list information for end-users, improving monitoring and operational handling, and it also supports downstream uses such as reporting where the same field value is surfaced consistently across the platform.

Records table ​

In Autologyx, the Records table is the tabular list of object records shown in the workspace and used to view and select a specific record for action. A selected record is indicated by its highlighted row, and that selection is used when starting record-specific actions such as creating a manual task from the task panel or Create task screen. The Records table matters because it is the primary context-setting control for record-level work: choosing the correct row ensures that the action you launch is attached to the intended object record.

records' relations ​

Records’ relations are the defined parent-child links between records in the Autologyx relational model, used to navigate from one record to related records within configured object classes. In practice, they are used in sequence design through the Relation Lookup actor, which traverses these relations one level up to a parent record or one level down to a child record. This matters to Configuration Admins and Super Admins because records’ relations determine how data can be connected and retrieved across related records, enabling sequences to work with relational records correctly and supporting process designs that depend on structured links between business objects.

recurse through child records ​

In Autologyx, recurse through child records is the action of navigating from a parent record down through its associated child records, and then further into grandchild and deeper related records within the same relational structure. It is used in workspace record views when interacting with associated child records via the parent, typically through components and controls that expose parent/child relationships, such as child record listings, summaries, flyouts, breadcrumbs, and create or edit views. This matters because it lets end-users work through a complete hierarchy of related records from a single starting point, while helping configuration admins design object classes and relational models that support efficient navigation, data entry, and management of linked records across multiple levels.

red API call actor ​

A red API call actor, also shown as an API call actor, is a Sequencer actor configured on a sequence to send API requests in the context of a selected service account. In Autologyx it is used when building or testing sequence-driven integrations, where an administrator or developer adds the actor to a sequence, supplies the required authentication and request details, and can test the configuration against a record by using a record ID. This actor matters because it provides the platform mechanism for executing outbound API actions from within a workflow, linking sequence behaviour to internal or external services through the service account model and supporting integration patterns such as POST and PATCH API calls.

red warning exclamation mark ​

In Autologyx, the red warning exclamation mark is a visual indicator shown on an unconfigured or unsaved Create Task actor in a sequence, helping configuration admins identify actors that still require setup before the workflow is complete. In the Create Task Configuration window and related sequence design views, it appears alongside the actor label, which remains displayed as “Create Task” until the actor has been properly configured and saved. This matters because it provides an immediate cue during workflow configuration that a task-creation step is incomplete, helping prevent configuration errors and ensuring the actor is fully defined before the sequence is used.

Redirect ​

Redirect is a standalone form setting in Autologyx that sends the user to a specified URL after the form is submitted. Configuration admins and Super Admins use this option when creating or editing standalone forms in the Object class configuration, typically from the Forms tab, to replace the platform’s default submission confirmation with a custom destination such as a landing page or external website. This setting matters because it controls the post-submission user journey, allowing form experiences to align with business processes, confirmation flows, and onward navigation requirements.

Redirect / Callback URI ​

Redirect / Callback URI is the Autologyx-provided sign-in return URL used when configuring OpenID Connect single sign-on, including Okta SSO for Catalyst. It is shown on the Okta SSO edit page after the SSO configuration is saved, and it must be copied into the identity provider’s Sign in redirect URIs setting so that, after successful authentication, the user is sent back to the correct Autologyx endpoint to complete login. This value is a core part of SSO setup for configuration admins, super admins, and integrators because the identity provider must be configured with the exact URI supplied by Autologyx for sign-in to work correctly and securely.

Redirect URI ​

Redirect URI is the Autologyx-generated callback URL used in single sign-on configuration to return users from the identity provider to the Autologyx platform after authentication. It is used when setting up or editing a Single sign-on setting in the Administration area, where the value is created automatically when the connection between the provider and Autologyx is established and is shown as a read-only field alongside the Logout URL. This matters because configuration admins, super admins, and integrators must copy the exact Redirect URI into the corresponding application registration or enterprise app settings in the identity provider, such as Azure, so that sign-in requests can complete successfully and users are routed back into Autologyx correctly.

Redirect URL ​

Redirect URL is a Standalone form setting in the Autologyx platform that sends users to a specified destination URL after they submit or complete a standalone form. It is configured by enabling the feature in Standalone form settings and entering the target address, and it is used wherever standalone forms are presented outside the main workflow experience. This matters because it lets configuration admins control the post-submission journey, creating a smoother handoff to the next page, system, or information source for end-users and improving the overall form experience.

Redirect Url On Standalone Forms ​

INSUFFICIENT_EVIDENCE

refresh tokens ​

Refresh tokens are credentials stored in an Authentication Object that Autologyx uses to obtain new access tokens before the current access token expires, maintaining continuous authenticated access to an external service such as DocuSign. In the platform, they are configured under Administration / Authentication objects as part of integrations that require ongoing API connectivity, and Autologyx then uses them to keep the connection authenticated while attaching valid access tokens to API requests. This matters to configuration admins and integrators because refresh tokens are central to reliable, uninterrupted operation of connected services, reducing authentication failures caused by expired access tokens.

Refresh URL ​

In Autologyx, the Refresh URL is the endpoint configured on an Authentication Object that the platform calls when it needs to obtain a refresh token as part of an OAuth 2.0 integration. It is used by configuration admins and developers when setting up authentication, particularly with the Generic OAuth 2.0 template alongside related settings such as the Token URL, Client ID, Client Secret, Additional Parameters, and Additional Authorization Headers, including any provider-tailored or pre-configured fields. This setting matters because it directs Autologyx to the correct identity provider endpoint for token refresh operations, which is essential for maintaining authenticated connectivity to external services and for validating the authentication setup through the built-in testing feature.

registered users ​

Registered users are the user accounts created in the Autologyx system that can be selected through a User type field when configuring record pages. This term is used in field configuration, where Configuration Admins and Super Admins define fields that allow users in the platform to choose from users registered in the system, including setting options such as minimum and maximum selections. Registered users matter because they provide the controlled pool of selectable people for user-based fields, ensuring records can reference valid Autologyx users consistently within configured workflows and page layouts.

rejoin the main sequence ​

In Autologyx, rejoin the main sequence is the configuration pattern used to return a record from a sub process or branched path back into the primary sequence so processing continues at the correct next stage. It is used when a Sequence Runner actor has started work against a related object class and an Update object record task writes an outcome back to a field on the original record; that field is then evaluated by trigger conditions or supplementary conditions in the main sequence to determine where execution resumes. This matters to Configuration Admins and Super Admins because it is how separate sequence activity is connected back to the core workflow, ensuring outcomes recorded on relational records drive the correct continuation path and preventing records from stopping, looping, or progressing to the wrong step.

Related conditional logic in the Autologyx platform is the set of conditional logic rules connected to a section you are removing, including rules that use fields in that section or rules that control the display of another section. It is encountered when a configuration admin deletes a section from a record or task form, at which point Autologyx shows an on-screen warning and gives the option to either keep the section or delete the section and all related conditional logic. This matters because removing a section also removes the dependent logic tied to it, which directly affects how fields and sections are conditionally displayed to end-users and helps preserve form integrity during configuration changes.

Related object classes are object classes that have a defined relationship to the primary object class used by a sequence, record, template, or integration, allowing Autologyx to access and use fields from those connected records alongside fields on the main record. In the platform, they are used wherever relational data is supported, including Document Templates and the Catalyst Word Add-in for merge fields, API call configuration such as DocuSign envelope creation, and sequence components such as the Record Access Actor, where matching permissions must also be configured on the related classes. This matters because it lets administrators, integrators, and end-users work with connected business data in one process, populate documents and external requests with the correct linked information, and maintain consistent output across records that depend on relationships between object classes.

In Autologyx, Related records are records linked through configured parent-child object class relationships and presented on a record page through the Related records child component, labelled as “Related records: <child object class name>”. End users use this component to view lists of linked records with selected columns, navigate them with pagination, and create or search for additional linked records where the relationship rules allow it, while configuration admins define which child object classes are shown and which information appears in the list. Related records also matter in document generation, templates, APIs, and scripted logic because they are exposed through relational merge field and Jinja-style syntax such as record.related\ records\ <Object Class ID>, enabling access to fields on child, parent, and deeper linked records within the platform’s relational model.

Related records merge fields are merge fields evaluated within a related-record context, allowing data from linked records to be inserted or referenced when configuring the Autologyx platform. In the Users and Groups area, they are a supported context for user type merge fields, which means configuration admins can access user and user group object properties from records related to the current item rather than only from the primary record itself. This is used in scenarios where templates, workflow actions, or other merge-field-enabled configurations need to pull participant, assignee, or group information from associated records. They matter because they enable cross-record data access in a controlled, structured way, making document generation and automation configurations more accurate and reusable across linked business objects.

Relation Lookup ​

Relation Lookup is a Sequence designer actor in Autologyx Catalyst that retrieves related records defined in the relational model, allowing a sequence to find and work with parent and child records across object classes. It is used when configuring sequences for relational records, typically alongside the Sequence Runner actor, which can then execute a sequence against the records returned by the lookup. Relation Lookup matters because it enables configuration admins and Super Admins to build cascading and cross-record automations, such as managing related records consistently and applying actions across parent, child, and other linked records, provided the underlying relationships have been defined in the Relational modeller.

Show 1 more pages

Relation Lookup actor ​

The Relation Lookup actor is a Sequence Actor used in Autologyx to search the relational model for records related to the current sequence record and return the parent or child records that meet configured conditions. It is configured in the sequence canvas and is available only where a relational model has been defined, allowing administrators to traverse one level up or down between related object classes. After it runs, the matching related records are stored for further processing in the sequence, most commonly by a Sequence Runner actor using the From Relation lookup option to execute actions or sub-sequences against those matched records. This matters because it enables configuration admins and Super Admins to automate work across related records, such as finding specific parent or child records and then updating them, assigning tasks, or triggering additional processing in the correct object class.

Show 1 more pages

Relation Lookup configuration window ​

INSUFFICIENT_EVIDENCE

relational data model ​

INSUFFICIENT_EVIDENCE

relational entities ​

In Autologyx, relational entities are classes configured in the Relational Modeller to participate in defined record relationships, such as parent and child records. They are used wherever the platform needs to create, manage, or respond to links between related records, including automation features such as the Sequencer Relationship Created trigger, which operates only within classes included as relational entities. This matters to configuration and super administrators because a class must be set up as a relational entity for relationship-driven data structures and automations to work correctly, making it a core requirement when designing relational models and sequence behaviour in the platform.

relational merge fields ​

Relational merge fields are merge field expressions used in Autologyx document templates to pull data from records that are related to the current record rather than from the current record itself. They are configured using merge field syntax that navigates the platform’s object model and relationship paths—for example, moving from a Lease record to its parent Site, to a child Tenant, or to another related object such as Landlord where an explicit relationship path and object class context are required; in this syntax, an index such as [0] identifies the most recently related record. Relational merge fields matter because they allow configuration admins and developers to generate documents with values drawn from the correct linked records across object classes, ensuring templates can assemble complete, contextually accurate business information from complex relational data structures.

relational model ​

In Autologyx, the relational model is the configured structure of parent and child relationships between object classes that defines how related records connect across the platform. It is created and maintained in the Relational Modeller under System configuration, and it is used by features such as Child Object Classes on forms, relational record creation in the workspace, merge fields and Jinja access to related data, and sequence components including the Relation Lookup and Sequence Runner actors. A defined relational model enables users and administrators to navigate between parent and child records, expose child record components on parent object classes, reference data from related records, and automate processes that depend on those relationships. For configuration admins, super admins, and integrators, it matters because it is the foundation that makes relational records usable in forms, documents, and automation.

Show 10 more pages

Relational model canvas ​

The Relational model canvas is the main design area in the Autologyx Relational Modeller where configuration administrators build and view the structure of a relational model. It is used on the Creating the Relational model page as the workspace where object classes are dropped to begin modelling, with the first object class automatically placed at the top centre of the canvas and relationship controls becoming available once modelling starts. The canvas matters because it is the visual surface for defining and understanding how parent and child object classes connect, including parent/child relationships and cardinality such as 1:1 and 1:N, making it a core tool for configuring the object hierarchy that underpins platform data relationships and process design.

Relational modeller ​

Relational modeller is the System Configuration feature in Autologyx used to create and maintain the relational model for an instance by defining parent/child relationships between Object classes. It is accessed from System configuration > Relational modeller and is used by Super Admins and authorised configuration users after Object classes have been created. When a relationship is configured and saved, the child Object class becomes available to the parent Object class so child records can be presented and associated in the parent’s create/edit view, supporting organised relational data structures and related workspace interactions. It matters because it is the foundation for configuring relational records, enabling features such as presenting child records, associating existing child records with parent records, and sequence capabilities that depend on configured class relationships.

Show 13 more pages

relational records ​

Relational records are records connected through the Autologyx relational model, where a parent object class is linked to one or more child object classes using defined relationship types such as 1:1 and 1:N. They are used in system configuration when administrators build the relational model, configure object class relationships, and enable create or edit views and display settings that give users an interface to create, associate, and work with related records. In the workspace, relational records let end-users create child records from a parent record, associate existing child records with a parent, and interact with those linked records in context. They also matter in sequence design, where additional sequence features are available for object classes that participate in relationships, including sequence handling for relational records. Understanding relational records is important because they determine how related business data is structured, displayed, linked, and processed across configuration, user interaction, and automation in the platform.

Relational Structure ​

Relational Structure in Autologyx is the navigable set of data relationships available from a specific Record, defining which linked records, fields, and values can be accessed directly in configuration and runtime contexts such as Sequences, merge fields, and data-driven logic. It is used wherever platform features need to read or traverse Record-related data, and it matters because it sets the boundary for what can be referenced without additional integration steps. In practice, this distinction is especially important when configuring API Call actors: if required information or functionality is not accessible from the current Record’s relational structure, an API call can be used to interact with external systems or other parts of Autologyx that sit outside that direct data path.

relational support ​

Relational support is a capability in the Autologyx Catalyst Word Add-in that lets template authors insert fields from not only the currently selected object class but also any related object class defined in the relational model. It is used when designing document templates in the Word Add-in and associated Templates panel workflows, where documents need to combine data from connected business objects rather than a single source record. This matters to end-users and configuration admins because it enables richer, more accurate document generation across linked process data, reducing template limitations and allowing documents to reflect the full context of a case, matter, or business process.

relational tree ​

In Autologyx, the relational tree is the relationship-based structure used in the Catalyst Word Add in to navigate from a primary object to related object classes and expose their data for document generation. It is used when working with Document Templates that need to pull content from linked records rather than from a single object in isolation, enabling template authors and configuration admins to include fields and repeating content from related objects through relational support. This matters because it allows documents to reflect the full connected data model in Autologyx, improving template flexibility, reducing manual data handling, and supporting more efficient creation of complex documents.

relations ​

In Autologyx, relations (also shown as field relations) are the conditional logic links applied to a form field or section that control how it is displayed in response forms. They are used when configuring forms in Create response form and are surfaced in Preview mode by a blue icon; hovering over the icon shows that the field or section has relations. Relations matter because they identify where conditional visibility has been configured through Field Properties or Section Properties, helping configuration admins design dynamic forms and helping end-users understand why particular fields or sections appear or are hidden during form completion.

relationship ​

In Autologyx, a relationship is a configured link between object classes in the Relational modeller that defines how records in one object class connect to records in another within the platform’s relational model. Relationships are displayed on the modeller canvas and are managed by configuration and Super Admin users when designing or editing multi-level structures of parent, child, and descendent object classes. They matter because they control how data is organised and navigated across related records, shape the create and edit experience for connected object classes, and determine whether parts of the model can be moved or removed; where a relationship is in use by existing records, the connected object classes can become locked, indicated by a padlock icon in the modeller.

Relationship Created trigger ​

The Relationship Created trigger is a Sequencer trigger in the Autologyx platform that starts or advances sequence logic when a relationship is established between parent and child records. It is used in sequences configured for classes that are defined in Relational Modeller as relational entities, including Autologyx Catalyst implementations where workflow behaviour depends on linked records. This trigger matters because it enables configuration admins, developers, integrators, and super admins to automate actions at the point records become related, such as assigning follow-up tasks, sending notifications, and launching dependent workflow steps, making relationship-driven processes more structured, responsive, and efficient.

Release Notes ​

Release Notes are the version-by-version updates published in the New at Autologyx area of the documentation that describe what has changed in each platform release, including current releases and announced previews. They are used by end-users, configuration admins, Super Admins, developers, integrators, and governance stakeholders to review new features, enhancements, and platform changes across releases such as 1.14, 1.13, and earlier versions. Release Notes matter because they provide the official record of product change, helping teams understand what is new, plan adoption and configuration updates, prepare integrations and operational processes, and keep platform usage aligned with the capabilities introduced in each Autologyx release.

Release notes 1.10 ​

Release notes 1.10 are the Autologyx product documentation for platform version 1.10, published within the New at Autologyx release notes area alongside other version-specific updates. They are used by end-users, configuration administrators, Super Admins, developers, integrators, and compliance or analytics stakeholders to review the changes introduced in that release, understand what has been added, changed, or updated between versions, and plan platform adoption, configuration updates, testing, integration impact assessment, and operational readiness. This matters because the 1.10 release notes provide the version-specific reference point needed to track platform evolution and align usage, administration, and governance activities with the capabilities and changes delivered in Autologyx 1.10.

Release notes 1.11 ​

Release notes 1.11 is the version-specific release documentation for Autologyx platform release 1.11, published within the New at Autologyx release notes area alongside other versioned updates. It is used by end-users, configuration administrators, Super Admins, developers and integrators, and security, compliance, and analytics stakeholders to review the changes introduced in that release, understand what functionality, fixes, or platform updates were delivered, and identify any actions needed when using, configuring, integrating, or governing the platform. This matters because the 1.11 release notes provide the authoritative reference point for what changed in that version and support controlled adoption, impact assessment, and operational planning across the platform.

Release notes 1.12 ​

Release Notes 1.12 is the Autologyx documentation entry for the changes introduced in Autologyx Catalyst version 1.12. It is published in the New at Autologyx release notes section and used by end-users, configuration administrators, Super Admins, and developers or integrators to review what is new in that specific platform release. This page matters because it provides the version-specific reference point for understanding new functionality and updates in Catalyst 1.12, helping teams plan adoption, assess configuration or integration impact, and track platform changes across related releases such as 1.11, 1.13, and 1.14.

Release notes 1.13 ​

Release notes 1.13 is the Autologyx documentation entry for the changes delivered in platform version 1.13, published within the New at Autologyx release notes area alongside other versioned updates such as 1.12 and 1.14. It is used by end-users, configuration admins, Super Admins, and developers or integrators to review what was introduced, changed, or updated in that specific release before using new functionality, adjusting configuration, validating integrations, or planning rollout and support activities. This matters because the 1.13 release notes provide the version-specific record teams use to understand platform changes, align administration and development work with the correct release, and track how the Autologyx platform has evolved between versions.

Release notes 1.14 ​

Release notes 1.14 is the Autologyx documentation entry for version 1.14 of the platform, published within the New at Autologyx release-notes area alongside other versioned release note pages. It is used by end users, configuration administrators, Super Admins, security and compliance stakeholders, and developers or integrators to review the changes introduced in that specific platform release, including new capabilities, updates, fixes, and any impacts on configuration, operation, integration, or governance. This matters because it provides the version-specific change record needed to understand what has changed between releases, plan adoption and testing, assess operational or compliance implications, and keep platform use and configuration aligned with the features and behaviour delivered in Autologyx 1.14.

Release notes 1.2 ​

Release notes 1.2 is the Autologyx documentation entry for the changes introduced in platform version 1.2. It is used within the New at Autologyx release-notes area alongside other versioned release notes, where end-users, configuration administrators, Super Admins, developers, integrators, and compliance or analytics stakeholders can review what was added, changed, or updated in that specific release. This matters because it provides the version-specific reference point needed to understand platform capabilities and behaviour in 1.2, support upgrade planning, assess configuration or integration impact, and align operational, support, and governance activities with the features and updates delivered in that release.

Release notes 1.3 ​

Release notes 1.3 is the Autologyx documentation entry for the features, fixes, and platform changes delivered in version 1.3. It is used within the New at Autologyx release notes area alongside other version-specific release summaries, where end-users, configuration administrators, Super Admins, developers, integrators, and compliance or analytics stakeholders can review what changed in that release. This matters because it provides the version-specific reference needed to understand newly introduced capabilities, changed behaviour, resolved issues, and any actions required when using, configuring, integrating, or governing the platform after an upgrade to Autologyx 1.3.

Release notes 1.5 ​

Release notes 1.5 are the Autologyx product update notes for platform version 1.5, published within the New at Autologyx release notes area alongside other versioned release summaries. They are used by end-users, configuration administrators, Super Admins, developers and integrators, and security, compliance, and analytics stakeholders to review the changes introduced in that specific release, including updates that affect platform behaviour, configuration, integrations, and operational use. This matters because Release notes 1.5 provide the version-specific record needed to understand what changed in Autologyx, plan adoption activities, assess impact on existing implementations, and keep platform use and administration aligned with the capabilities delivered in version 1.5.

Release notes 1.6 ​

INSUFFICIENT_EVIDENCE

Release notes 1.8 ​

Release notes 1.8 is the Autologyx documentation entry for the changes introduced in platform version 1.8. It is accessed from the New at Autologyx release notes area alongside other version-specific release notes and is relevant to end-users, configuration admins, super admins, and developers or integrators who need to understand what was added, changed, or updated in that release. This entry matters because it provides the version-specific reference point for planning upgrades, validating feature availability, reviewing configuration or integration impacts, and aligning platform use and administration with the functionality delivered in Autologyx 1.8.

Release notes 1.9 ​

Release notes 1.9 is the version-specific documentation entry within the New at Autologyx release notes area that records the changes introduced in Autologyx platform release 1.9. It is used alongside other versioned release notes pages, such as 1.8 and 1.10, to help end-users, configuration administrators, Super Admins, developers, integrators, and governance or compliance stakeholders identify what was added, changed, or fixed in that release. This matters because it provides the official reference point for understanding platform updates, assessing the operational and configuration impact of upgrading to version 1.9, and planning testing, enablement, integration updates, and change management activities.

Remove ​

Remove is the confirmation action in Autologyx form configuration that permanently deletes a selected column when reducing the number of columns in a record or task form layout. It is used in the on-screen removal prompt that appears after a configuration admin chooses which column to delete, and selecting Remove deletes both the column and any conditional logic linked to fields in that column. This matters because it directly changes the form structure and can also remove dependent logic, so users configuring forms must understand that Cancel retains the column, while Remove commits the deletion and its related logic changes.

remove access ​

Remove access is a Record Access actor action in the Autologyx platform that withdraws record access previously granted to users or groups. It is used when configuring record access rules and lets administrators clear all assignees at once, remove selected users or groups, or drive removals from field values. This matters because it gives configuration and super administrators precise control over who can work on or view a record at each stage of a process, helping keep assignee lists accurate and ensuring access is aligned with current workflow and permission requirements.

Remove all ​

Remove all is an action label used in different Autologyx configuration and user interface contexts to clear or revoke items in bulk. In the list page filter editor, Remove all appears at the bottom of the filter panel and clears all current filter conditions so the list can be reset before applying new criteria. In the Record Access Actor configuration, Remove all is an option within assignee removal settings that removes record access for all users other than the record owner, where an owner is set. This matters because it provides a fast way to reset filtering in day-to-day use and, in access configuration, to revoke broad record access in a single step, making it an important control for both usability and permission management.

Remove assignees ​

Remove assignees is a Record Access actor configuration option in the Autologyx platform that removes users, roles, or other configured assignees from a record permission set. It is used when configuring record access behavior in workflows and sequence actors, alongside the related options to append or override assignees, and includes the same assignment configuration choices plus a Remove all option. This setting matters because it gives Configuration Admins and Super Admins precise control over who retains access to a record as a process progresses, helping enforce the correct permissions model, revoke no-longer-needed access, and keep record visibility aligned with the current stage of work.

remove from group ​

Remove from group is an Actions menu option in Autologyx User group management that removes a selected user from the current User group. It is used on the Editing a User group page within the Members list, where Configuration admins and Super Admins can manage group membership for both Members and Owners; when the list is filtered to Members or Non members, removal can also be applied as a bulk action. This option matters because User groups control who belongs to a group and what role they hold within it, so removing a user is a core administrative task for keeping membership accurate, updating ownership and participation, and maintaining the correct group structure for platform administration.

Remove owners ​

Remove owners is a Record Access actor configuration option in Autologyx that clears the current owner from a record. It is used when configuring record ownership behaviour in sequence actors, alongside related options such as overriding owners, and is relevant to configuration administrators and Super Admins who control access rules. Removing the owner immediately removes the ownership-based permissions held by that user for the record, making it an important setting when you need to revoke owner access, reset ownership before reassignment, or enforce a specific record access model within a workflow.

rendered text ​

Rendered text is the formatted display of Markdown content in the Autologyx platform, shown as readable output rather than raw Markdown source code. It is used in create and edit record forms and task forms, where users can switch from source code view to a rendered view to read content more clearly while working with records and tasks. This matters because it improves readability and usability for end-users, while helping configuration admins understand how Markdown fields will be experienced in form-based interactions; elsewhere in the platform, such as record list columns, Markdown fields display as source code by default, so the rendered text view is specifically important in form contexts where content needs to be consumed as finished text.

reporting ​

Reporting in the Autologyx platform is the use of record data and workflow values to define report logic and outputs, including applying trigger conditions that act on captured fields such as envelope status. It is used alongside configured elements such as task templates, document templates, send message actors, and records list column headers, where values collected during a process can be surfaced and then referenced in reporting conditions. Reporting matters because it turns operational data generated by workflows into trackable, filterable information that configuration administrators and compliance, security, or analytics users can use to monitor process outcomes, status changes, and business activity across the platform.

request an integration ​

In Autologyx, request an integration is the action available from the central Integrations management screen that lets authorised administrators ask for a connection that is not yet active in their environment. It is used within System Configurations → Integrations alongside the management of active integrations, integration categories, and enablement controls, giving Configuration Admins and Super Admins a single place to identify missing external system connections and submit a request for them. This matters because integrations determine how Autologyx connects with the wider toolset used to deliver work, so the ability to request a new integration helps administrators close capability gaps and extend the platform’s connected operating model from the same area where existing integrations are managed.

request parts ​

Request parts are the individual components that make up a multipart request in the Autologyx API Call actor. In multipart configuration, each request part is defined separately as either a text part or a file part, with settings such as Content Type and Content Disposition controlling how that part is sent to the target service. Request parts are used when an integration must submit multiple values or files within a single HTTP request, including content selected through features such as the Document Picker for file-based parts. They matter because they determine the exact structure of multipart data sent from Autologyx, which is essential for configuring external API integrations correctly and ensuring receiving systems can process submitted fields and documents as intended.

Required ​

Required is a field setting in Autologyx that makes a form value mandatory before a user can complete the relevant action. It is used when configuring task forms in Form Builder, on supported record or object edit forms, and on specific field types such as User type Class fields, where it enforces that end users enter or select a value before they can submit, save, or proceed. In task forms, a Required field must be completed for the task to be finished, and if a Checkbox is marked Required it must be ticked; this option is not available for JSON field types. Required matters because it enforces mandatory data capture, prevents incomplete submissions, and helps configuration admins control which information must always be provided during record editing and task completion.

required field ​

In the Autologyx platform, a required field is a form field configuration that must be completed before a user can create or edit a record or complete a task. This setting is used in configured forms and task templates, including User Type Class fields where selection rules can require users or groups to be chosen and minimum selection thresholds must be met. Required fields matter because they enforce mandatory data capture and selection rules at the point of user entry, helping configuration admins control data quality and process completeness while ensuring end-users provide the information or assignments needed for records and tasks to progress.

Required option ​

Required option is a field property in Autologyx forms that makes a field mandatory, so users cannot complete or submit the form without providing a value. Configuration admins use this option when editing record, task, and standalone forms in field properties, and it is especially important when configuring fields that control conditional logic or Conditional Visibility, because those trigger fields must contain a value for form behaviour to work consistently. Enabling or disabling the Required option affects how users interact with the form, supports data completeness, and helps ensure that form routing, visibility rules, and downstream processing operate as intended.

required outcomes ​

Required outcomes are the specific business results an Autologyx application is designed to deliver, such as obtaining a signed document, producing a report, or completing another defined operational output. They are used at the application design stage to shape how configuration admins model data, structure task forms and stand alone forms, and build sequences and Catalyst components so the platform captures, processes, and presents the information needed to achieve those results. Required outcomes matter because they provide the target for the application design: they determine what data must exist in the Catalyst data model, what users need to do in the workflow, and what the completed application must ultimately produce.

Required selector ​

In Autologyx, the Required selector is a form-field setting used when configuring a response form, including the Update object record task type, to make a field mandatory for the user completing the task. Configuration admins enable it in the form builder for supported fields in the Fields section, alongside options such as Input type and Conditional Visibility. When turned on, the selected field must be completed before the form or task can be submitted, which helps enforce capture of essential data, supports consistent object record updates, and ensures task responses meet the process requirements defined in the template.

Required value ​

Required value, shown as Required, is a task template field setting used when configuring a response form in Autologyx to control whether a user must complete a particular field before the task can be submitted or progressed. Configuration admins use this setting when editing fields such as text, single select, numeric, or file upload fields within a task template, alongside other field properties such as input type, description, and validation limits. This setting matters because it determines which information is mandatory in the user experience, helping enforce consistent data capture, support process rules, and prevent incomplete task responses.

Resend activation email ​

Resend activation email is an administrative action available on a user account in Autologyx when the account Status is Pending. Used from Administration when managing users, it sends the activation message again so the user can complete account activation and gain access to the platform. This action matters to Configuration Admins and Super Admins because it provides a direct way to resolve onboarding delays caused by a missed, expired, or otherwise uncompleted activation email, helping ensure user access is completed in line with configured user activation rules.

Reset password model ​

INSUFFICIENT_EVIDENCE

Reset to default ​

Reset to default is a control available in column configuration mode on Autologyx list pages that restores the page’s column layout to the original default setting. It appears above the column headers alongside Save changes and Cancel when a user is editing visible columns and their order. Use Reset to default to undo customisations such as added, removed, or repositioned columns and return the list view to the standard layout defined for that page. This matters because it gives end users a quick way to recover a familiar, consistent view without manually reversing each column change.

Resource Database ​

The Resource Database is the PostgreSQL operational database in the Autologyx platform that stores real-time transactional data used by Catalyst, including object records, task statuses, and other live workflow data. It is used as the primary source for operational reporting and analysis, and it also supports platform configuration activities such as creating constants directly in the database. The Resource Database is closely connected to the Analytics Database and History Events Database, where its current-state data is combined with historical event data to deliver unified analytics. This matters to configuration administrators, super admins, compliance and analytics teams, and developers because it is the core system of record for active platform operations, making it essential for monitoring workflow execution, validating data completeness, supporting configuration, and enabling accurate operational and analytical outcomes.

Resource tables ​

Resource tables are replica database tables exposed through Autologyx database views to provide direct access to platform resource data for reporting, analytics, and external integration use cases. They are used alongside Event History tables, including in ClickHouse and Autologyx Cross Platform view configurations, where users select the relevant domain and then query the Resource tables to analyse current and historical business records such as contracts and other managed objects. This matters because Resource tables give technical and compliance-focused users a structured, queryable representation of Autologyx data outside the transactional application interface, enabling trend analysis, risk monitoring, and downstream data processing with consistent access to core platform records.

Response configuration ​

Response configuration is the section of a task template in Autologyx where administrators define the requirements for how a task must be completed and what the task response must contain. It is used when creating or editing task templates, alongside Lifecycle and Stages, to control the response behaviour of the task, including how users submit completion details in relation to the task type and related template settings such as forms, object record updates, assignees, due dates, expiry rules, and completion options. This matters because response configuration determines the structure and completion requirements of work performed from the template, ensuring tasks capture the right information and behave consistently within the process.

Response configuration tab ​

The Response configuration tab is the section of the Create task template page where administrators define a task’s response behaviour and structure in Autologyx. It is used when configuring task templates such as Complete self contained form and Update object record to specify what the task contains, how it is presented to the user completing it, and how it is created through the task creation mechanism. This tab also provides access to response form setup, including creating a response form, and for Update object record templates it determines the object class that controls where the template is available in the Sequence designer. It matters because it is the central place for shaping how a task operates, what end users see and complete, and how the task can be used within automation and sequence design.

Response form ​

A Response form is the form definition configured within a Task template’s Response configuration for task types such as Complete self-contained form, where administrators build the fields a user must complete when responding to a task. In Autologyx, it is created and managed from the Response Form section on the Response configuration tab, using the Form builder to add, remove, and configure fields such as file upload and date/time picker controls, and to apply behaviour such as conditional visibility. It matters because it determines the structure, content, and rules of task responses presented to end users, and changes to its fields must be managed carefully when those fields or values are referenced elsewhere in platform configuration, including sequence triggers.

Resume ​

  • Mostly relevant to: Configuration admins, Super Admins
  • Closely related concepts: Actions menu, Running

Resume is the action used in Autologyx to change a paused Sequence back to a running state. It is available from the Actions menu on the Sequences list and is shown when a Sequence is currently paused. Configuration admins, Super Admins, and other permitted users use Resume to restart operational flow after a Sequence has been stopped, including in relational record scenarios where multiple connected sequences must be resumed individually. This matters because newly created Sequences start in a paused state, and a paused Sequence will not continue processing until Resume is selected; once resumed, existing task completions can trigger the next connected action in the sequence.

Retry ​

In Autologyx, Retry is an API Call Actor configuration setting that defines how many times the platform will automatically attempt a failed API call again before treating it as unsuccessful. It is configured within the API Call Actor in the configuration panel and is used when designing or maintaining integrations that depend on external services. This setting matters because it controls the platform’s resilience to transient API failures, helping configuration admins and developers balance reliability, processing behaviour, and integration handling when external endpoints do not respond successfully on the first attempt.

Revert ​

Revert is an action in the Autologyx configuration interface that discards all unsaved changes and restores the current item to its last saved version. It is used in editable configuration areas such as the Landing page settings and the form designer for standalone forms, alongside controls such as Preview and Cancel, typically at the top right of the page or editor. For configuration admins and Super Admins, Revert matters because it provides a quick way to undo in-progress edits to page layouts, sections, fields, and other configuration changes without affecting the saved live configuration, helping maintain accuracy and preventing unintended updates from being committed.

Revert button ​

The Revert button is an action in Autologyx forms and display configuration views that resets the current screen to its last saved state by discarding unsaved changes. It is used by end users when creating or editing Object records, including child-record creation forms, and by configuration admins when editing a view on the Display tab for an Object class. In record forms, Revert clears any entered but unsaved data; in saved display views, it restores the previously saved configuration after amendments have been made. The button is only enabled when there is something to reset, such as unsaved form input or edits made after a view has been saved, and it typically appears alongside actions such as Save and Cancel. This matters because it gives users a controlled way to undo in-progress changes without saving them, helping preserve clean record data and stable configuration settings.

rich text instructions ​

Rich text instructions are formatted guidance content that System Administrators can add within the Form builder in Autologyx to present clearer, more engaging instructions to end users. Unlike plain text instructions, rich text instructions support enhanced formatting and embedded content such as images and clickable links through the instructions editor, allowing configuration teams to tailor how guidance is displayed in forms. This matters because well-structured, visually clear instructions improve usability, help users complete forms correctly, and enable administrators to deliver process-specific guidance directly at the point of action.

right hand side panel ​

The right hand side panel, also called the side panel, is the panel displayed alongside the main content window in the Autologyx workspace to show contextual information for the record currently selected in a parent or child records component. It is used when working with relational records to display items such as the Child record summary, and its contents depend on the current selection and view configuration. During child record creation, no tabs are available in the right hand side panel; once the child record is created and selected, the child record summary is shown there if that panel view has been enabled from the View menu. This panel matters because it gives end users immediate access to related record details without leaving the current page or opening a separate fly out modal.

role assignment ​

In Autologyx, role assignment is the platform capability that associates a user account with one or more roles so the user can participate in work and access role-driven functions within configured processes. It is used when setting up and administering user access and account types, particularly by Configuration Admins and Super Admins who control how users interact with workflow functionality. Role assignment matters because it determines whether a user can be selected for role-based participation in the platform, and it is also a defining distinction between account types: for example, Internal Users can access system functionality through permissions but are not eligible for role assignment.

role permissions ​

Role permissions are the access rights assigned to a user role in Autologyx that determine which areas of the platform a user can see and which actions they can perform, such as viewing pages, using list page actions, or creating, editing, and deleting items. They are used throughout the platform, including administration areas, application configuration, and everyday UI elements such as the Actions menu and list pages, and they work alongside roles, user groups, and account type to control access. Role permissions matter because they are enforced immediately when changed, directly affecting navigation, visible menu options, and whether a user receives an access denied message, making them a core part of platform security, governance, and operational control for Super Admins and Configuration admins.

Show 1 more pages

Role to assign to created user ​

Role to assign to created user is a configuration field in the Single sign-on settings within the Administration area of Autologyx that specifies which platform role is applied to a user account created through the SSO setup. It is used on the Single sign-on edit screen and becomes visible when the relevant creation and enablement options are turned on. This field matters because it controls the initial access level and permissions granted to newly created users, helping configuration administrators and Super Admins ensure that users provisioned through SSO are assigned the correct role for their intended access in the platform.

Role which allows them to create sequences ​

In Autologyx, a role which allows sequence creation is a user role assigned to configuration-focused users, typically alongside a Config Admin account type, that grants the ability to create sequences as part of platform setup and design. This capability is used in the system configuration area when defining object classes and their class permissions, where authorised users build the sequence structures that support workflow and process configuration. It matters because sequence creation is a controlled administrative function: assigning it through role permissions ensures that only the appropriate configuration or Super Admin users can create and maintain these platform elements, supporting secure and governed configuration management.

Role which allows them to Edit object classes ​

The Role which allows them to Edit object classes is a role-based permission in Autologyx that grants a user the ability to modify object classes in system configuration. It is used when controlling access to object class administration tasks, including actions such as creating a standalone form, where a Config admin account type must also have this role to perform the task. This permission matters because object classes define configurable business structures in the platform, so assigning the role ensures that only appropriately authorised configuration users can change object class design and related setup.

Role with permission to create sequences ​

A Role with permission to create sequences is an Autologyx role configuration that grants a user access to create workflows in the Sequencer. It is used when setting up automatic document generation and related sequence-based processing, alongside components such as the sequence workspace, Document Templates, and the DocAuto actor. This permission is specifically relevant to configuration users and provides an alternative to holding a Super Admin account type, allowing organisations to delegate sequence design and setup without assigning full platform-wide administrative access.

Role with permission to edit object classes ​

A Role with permission to edit object classes is an Autologyx role assignment that grants a user access to object class configuration screens and the ability to modify configuration elements tied to an object class. In practice, this permission is used in System configuration when working with Object classes, including opening the Document templates list, accessing the other tabs within an object class, and editing a document template. It matters because it is one of the explicit access paths that controls who can administer object-class-level configuration, alongside Super Admin access or membership of a Permission Set that allows editing of a specific object class.

Roles ​

Roles are named permission profiles in Autologyx that control a user’s access to Administration and System configuration features beyond the Workspace. They are assigned on user accounts in the Roles section and are used by configuration-focused users to determine which parts of the platform they can see and manage, such as object classes, relational models, task templates, task group templates, sequences, authentication settings, user groups, and other administration areas. Roles are managed from the Administration > Roles list, where permitted users can create, edit, and delete them, and the platform applies role changes to a user immediately when the account is saved. Roles matter because they let organisations give Config admin and other non-super-admin users the exact configuration and administration access they need while limiting access to restricted system areas and supporting controlled platform governance.

Show 15 more pages

Roles and Permissions ​

Roles and Permissions in the Autologyx platform are the administration controls used to define what users can access and what actions they can perform across the system. They are used within the Administration area alongside Users and User Groups, and form part of the platform’s identity and access configuration together with authentication settings. For configuration administrators, Super Admins, and security or compliance teams, Roles and Permissions are important because they determine how platform capabilities are granted, restricted, and governed, helping ensure that users receive the appropriate level of access for their responsibilities while supporting secure and controlled operation of the platform.

Roles list ​

The Roles list is the Administration page in Autologyx that displays all configured roles and their key details, including values such as the role name and identifying information, as well as audit columns showing who created the role and when. It is accessed from the main left-hand menu by navigating to Administration and selecting Roles, and it serves as the central workspace for configuration admins and Super Admins to review, create, edit, or delete roles, including opening a role by double-clicking a row or using the Actions menu. The Roles list matters because roles control how user access is structured for standard users, it helps administrators distinguish between similar roles using unique values, and it provides the operational entry point for maintaining role configuration across the platform within the system role limit.

Roles section ​

The Roles section is an area on the Edit user page that is available only for users with the Config admin account type. In Autologyx, it is used by Configuration admins and Super Admins when viewing or updating a user account, and its presence identifies that the account is configured as a Config admin user. This matters because account type determines which administration options are available during user management, helping administrators understand which users have configuration-level access and where role-related settings can be managed.

Roles to assign to created user ​

Roles to assign to created user is a Single Sign-On (SSO) configuration field in Autologyx that defines which platform roles are automatically applied when a user account is created through SSO. It is used in the Single sign on settings by configuration administrators and Super Admins as part of setting up an SSO provider and controlling automatic user creation. This setting matters because the assigned roles determine the new user’s permissions and access within Autologyx from the moment the account is created, ensuring users receive the correct level of access without manual role assignment.

root parent ​

In Autologyx, the root parent (also called the root parent object class) is the top-most object class in a relationship tree within the Relational Modeller. It is used when defining the platform’s relational model and when working with Child Object Classes in forms, because all direct children and deeper descendant object classes are structured beneath this top object class in 1:1 and 1:N relationships. The root parent matters because it establishes the starting point and hierarchy for related records, determines how child object class components are organised in record and task forms, and sets the scope of a relationship path from the top object class down to the deepest descendant; Autologyx supports up to five root parent object classes in a model.

root parent class ​

In Autologyx, a root parent class is a top-level object class in the Relational model that has no parent above it and serves as the starting point for a hierarchy of related object classes. It is used in System Configuration when creating and editing the relational model in the Relational Modeller, where administrators add the first object class as a root parent and can also move other object classes to the top level so they become root parents. Root parent classes matter because they define the top-level structure of relational records and determine which parent object classes must then be configured with available child object classes to provide the interface users need to create relational records. A relational model can contain a maximum of five root parent classes.

root parent object class ​

In Autologyx, a root parent object class is the top-level object class in a relational model, with no parent above it and one or more child object classes beneath it. It is used in the Relational modeller and in relational model configuration to define the starting point of a parent/child hierarchy, such as Employee Management as the root parent for Employees. Root parent object classes matter because they determine the top structure of related records, control how object classes are organised when moved to the top level, and are subject to platform limits: a model can contain up to five root parent object classes, each object class can have up to five child object classes, and relationships can extend to a maximum of five levels from the root parent to the deepest descendant.

ROPC flow ​

ROPC flow, also called the Resource Owner Password Credentials flow or Generic ROPC flow, is an authentication method in the Autologyx platform where a username and password are supplied directly to obtain an access token. In Autologyx, it is used within Authentication Objects, specifically through the Generic ROPC Authentication Object, to configure integrations with external services that support this token grant pattern. This matters to configuration admins, developers, integrators, and Super Admins because it provides a straightforward way to authenticate connected systems and enable platform integrations that depend on direct credential-based token acquisition.

ROPC Flow Authentication ​

INSUFFICIENT_EVIDENCE

ROPC flow Authentication Objects ​

INSUFFICIENT_EVIDENCE

Rotation interval ​

Rotation interval is the user activation rule in Autologyx that defines how frequently users must change their password. It is configured by Configuration Admins and Super Admins alongside other password and access controls such as Prevent password re use, password complexity rules, and related user activation rules. This setting is used in the platform’s user activation rules configuration area, and any change takes immediate effect for all users. Rotation interval matters because it helps organisations enforce password lifecycle requirements consistently across the platform, supporting security policy, compliance obligations, and controlled user access management.

Row density ​

Row density is a My Account preference in Autologyx that controls the visual spacing and height of rows across all listing pages in the system. It is configured in the Row settings tab, where users choose a global density option such as Compact or Default using radio buttons and can review the change in a row density preview before saving. Once saved, the selected setting is applied to all lists, giving users a consistent way to tailor list readability and information density throughout the platform without changing each page individually.

row density preview ​

Row density preview is the visual sample shown in the My account area when a user selects a row density option such as Default, Comfortable, or Compact. It is used during personal display configuration to show how the chosen density will affect the spacing and layout of rows on listing pages before the setting is saved. This matters because it helps end users choose the most suitable viewing preference for readability and information density, making it easier to tailor the Autologyx interface to their working style.

Row settings ​

Row settings is the My Account preference area in Autologyx where an end user configures row density for all lists across the system. It is used from the Row settings tab in My Account and applies a global display preference rather than changing an individual list. This matters because row density controls how compact or spacious list rows appear, helping users optimise readability and the amount of information visible on screen throughout the platform.

Running ​

Running is the active state of a Sequence in Autologyx, indicating that the Sequence is live and available to execute against its configured object class and process records as designed. It is used in the Sequences list and related configuration areas where administrators monitor and control Sequence state, and it is set by selecting Resume from the Actions menu when a Sequence has been paused or newly created. This status matters because it determines whether the Sequence is operational in the platform, affects whether Pause or Resume is available as the next control action, and confirms to configuration administrators, super admins, and relevant users that the Sequence is currently enabled for use in production processing.

running sequences ​

Running sequences are sequences that are currently active in the Autologyx platform, and their count is shown in the top number on the Sequences tile in System configuration. This value gives Configuration admins and Super Admins an immediate view of how many sequence-driven processes are live across the system, alongside the separate count of paused sequences. Monitoring running sequences matters because it helps administrators understand current operational activity, verify that configured sequences are executing as expected, and manage system configuration with clear visibility of active automation.

same object class ​

In Autologyx, same object class describes a sequence configuration where a Sequence Runner runs another sequence against records of the current record’s object class rather than switching to a related parent or child object class. It is used when configuring Sequence Runner behaviour, including standalone execution and subprocess-style steps within a sequence, to target records that belong to the same business object type as the sequence already in context. This matters because it determines how records are selected and processed, allowing administrators to chain or reuse sequences within one object model while keeping execution aligned to the current record class and avoiding unnecessary relation-based lookups.

Save changes ​

Save changes is the action available in column configuration mode on Autologyx list pages that commits the current column layout updates you have made. It appears above the column headers alongside Reset to default and Cancel after column configuration is enabled, and it is used to keep changes such as adjustments to the visible column arrangement. This matters because it is the control that applies and preserves your updated list page column configuration, ensuring the page reflects the layout you have chosen rather than discarding it.

Save mode ​

INSUFFICIENT_EVIDENCE

Save progress ​

Save progress is the button available on certain Autologyx task forms in Catalyst, including forms completed by 1 time completion users, that lets a user store a partially completed task without submitting it. It is used when a form cannot be finished in one session, enabling the user to leave and return later to continue editing before final completion. This matters because it supports longer or interrupted form-filling journeys, helps users avoid losing entered information, and provides a clear distinction from the Complete button, which is used to submit the task once all required information, including any mandatory fields, has been entered.

saved document ​

In Autologyx, a saved document is a document that has already been stored against a record or task and is available to open from the user interface. It is used in places where documents are presented to end users, including Card view while editing records and on Task completion pages, and selecting it opens the Viewer panel directly so the document can be reviewed in context. This matters because saved documents represent the persisted, accessible document content associated with work in the platform, giving users a consistent way to find and view documents that have already been captured as part of a process.

Saved modal ​

In Autologyx, the Saved modal is the confirmation dialog shown in the Navigator after a Sequence has been saved successfully while being configured. It is used during sequence design and navigation setup, alongside save and edit actions, to confirm that the latest configuration changes have been committed. This matters to configuration administrators because it provides immediate feedback that updates to a Sequence have been recorded, helping them manage configuration work confidently and distinguish between changes still being edited and changes that are now saved.

Scope ​

In Autologyx, Scope is a configuration value used in a Microsoft Authentication Object when setting up OAuth 2.0 client credentials for a Microsoft integration. It defines the target resource the platform is requesting access to, using the resource’s application ID URI with the .default suffix, such as the Microsoft Graph scope format. This value is entered alongside settings such as Client ID, Client Secret, and Tenant, and is used when testing and validating the authentication object. Scope matters because it directs Autologyx to request the correct access token for the intended Microsoft service, ensuring integrations authenticate against the right API and can perform the operations required by the configured provider.

search engine ​

In Autologyx, the search engine is the in-app record lookup used by end users to find and add records from related object classes when working with related-record features such as Present child records. It is used within the user interface wherever users need to search across configured related data, particularly when creating or linking child records from permitted object classes. This matters because it provides a fast, controlled way to locate the correct related records while respecting permissions and the object-class relationships defined in the platform configuration.

search filter ​

A search filter in Autologyx is a control used to quickly locate specific records in a list by matching entered criteria, and in user group configuration it is used on the Membership tab to find users by username when adding members or owners. Configuration admins and Super Admins use the search filter alongside member and non-member views to narrow large user lists and select the correct people efficiently. This matters because it speeds up group administration, reduces manual searching, and helps ensure the right users are added to the correct group roles.

Search for task templates ​

Search for task templates is the task-template selection field used when configuring a Set Task Actor in Autologyx. In System Configuration, administrators use this drop-down to find and select the task template that the actor will apply when the sequence runs and creates or sets up a task. This control is important because the chosen template defines the task structure and behaviour used by the automatic task creation mechanism, making it a key step in ensuring the correct task is generated within the configured object class sequence.

Search for users ​

Search for users is the search bar shown when selecting people in User Type fields that display User Groups and their members in the Autologyx platform. It is used by end-users and configuration admins to quickly find specific individuals within the available group member list instead of manually browsing through every user, especially in large teams. This matters because it makes person selection faster and more accurate when User Type fields are configured to show groups and allow users to choose individual members.

Secondary colour ​

Secondary colour is a theme setting on the Configure Theme page, typically managed by configuration administrators and Super Admins, that defines the colour used for key secondary interface elements across the Autologyx platform. It is configured through the theme colour controls and is applied to the menu area and dividing lines, filter and column configuration button graphics, list page control icons, section names, and the text shown on actions such as Cancel and X No, go back. This setting matters because it controls the visual treatment of supporting navigation and action elements, helping ensure the user interface remains clear, consistent, and aligned with the organisation’s theme design.

Section content background ​

Section content background is a theme colour setting on the Configure Theme page, within the Colours tab’s Form colours controls, that defines the background colour used for the content area of create and view Object record forms, the standalone form for creating Object records, and Task forms in Autologyx. Configuration admins and Super Admins use this setting when creating or updating a theme to control the visual presentation of form content areas and to keep form styling consistent with the wider platform colour scheme. This setting matters because it directly affects the appearance, readability, and overall usability of key data-entry and record-view screens across the platform.

section header ​

A section header in Autologyx is the configurable heading for a form section in the Form builder. Configuration admins use it when designing record forms and task response forms, including Complete self-contained form and Update object record task types, by clicking the section header to define the section label, choose whether the header is shown on the rendered form, set the section’s column layout and ratios, and apply Conditional Visibility. It matters because it provides the primary control point for structuring forms into clear sections while allowing that structure to remain visible or hidden to end users, which supports both form usability and precise layout configuration.

Section header background ​

Section header background is a theme colour setting in the Autologyx platform that controls the background colour applied to section headers on forms. It is configured by Configuration admins and Super Admins on the Configure Theme page, within the Colours tab as part of the form colour controls and Additional colours options. This setting matters because it affects the visual structure and consistency of forms, helping organisations align form presentation with their chosen theme and making section headings clearer and easier for users to distinguish while completing or reviewing form content.

Section Properties ​

Section Properties is the configuration panel shown in the Form Builder side panel when a configuration admin selects a section header in a record or task form. It is used when designing layouts such as sections and instructions, and in task response configuration for self-contained forms, to control how that section is presented, including options related to the section header and, where supported, Conditional Visibility at the bottom of the panel. Section Properties matters because it is the main place to define the behaviour and presentation of each form section, helping admins structure forms clearly, show or hide section headers appropriately, and configure sections so the right content is displayed to users at the right time.

sections ​

In Autologyx, a section is a layout component in the form builder that groups fields and other form content into a labelled area on the canvas, with configurable columns and column ratios to control how information is presented. Sections are used when designing record forms, task forms, standalone forms, object class displays, and the Landing page, and they are a key structural element for organising content into clear, manageable parts for end users. Sections also work with conditional logic, allowing whole sections to be shown or hidden in response to values entered in controlling fields, which is important when building dynamic forms and when maintaining existing configurations. Because sections can contain fields that drive conditional behaviour, removing a section can also remove related logic, so understanding sections is essential for configuring form layout safely and preserving expected form behaviour.

Show 3 more pages

Sections and Instructions components ​

Sections and Instructions components are layout components in the Autologyx Formbuilder, available from the Layout panel, that are used by configuration admins to structure forms and present guidance to users. A Section component defines a form area with its own header and properties, helping organise fields and control how content is grouped and displayed, while an Instruction component is a reusable content block that can be dragged into a section wherever explanatory or directional text is needed and then edited directly in the form editor or preview. These components are used when creating and editing record, task, and standalone forms, and they matter because they improve form clarity, support consistent page structure, and help designers control how information is presented to end users across create and edit and summary experiences.

secure vault ​

INSUFFICIENT_EVIDENCE

Select field ​

Select field is an action used during manual document generation in Autologyx to choose the target document type field that a generated document will be associated with or saved to. It is used in the template manual generation flow, where a user scrolls to the required field, selects it, and then clicks Select field to confirm that choice before completing generation. This matters because it links the generated document to the correct field in the document type configuration, ensuring the output is stored in the intended location and is available in the right context for users and downstream process steps.

Select options ​

Select options are the predefined values available in a selectable field in Autologyx, configured in the Edit field panel when defining or updating object class fields such as multi select fields. They control what users can choose on records and can include standard options as well as selectable users and user groups, which are displayed in the configured selection list. Select options matter because they shape data entry and reporting consistency, and changes to them affect how existing and future records behave: new options can be added without impacting existing records, but renaming an option is treated as deleting the original value and creating a new one unless only letter case changes, so existing records are not updated to the renamed value. Similarly, if a user or user group is removed from the selection options, previously selected values remain visible on existing records, but they are no longer available for future selection.

selected domain ​

selected parent or child object class ​

In Autologyx, the selected parent or child object class is the object class returned by a Relation Lookup and chosen as the execution context for a Sequence Runner, allowing a sequence to run against a related parent or child record instead of only the current record or the same object class. This is used when configuring automation that must traverse relationships between records, such as triggering actions, updates, or downstream processing on related objects. It matters because it extends sequence execution beyond the originating record, enabling configuration admins to design cross-object automations that follow the platform’s data model and operate on the correct related business entity.

selected records ​

In Autologyx, selected records are the records a user has actively chosen in the interface to perform an action on, particularly in the Templates panel where pre-defined templates are used to generate documents for those records. This term is used when working with record lists and document-generation features, where the platform applies the chosen template to each corresponding record and produces the relevant generated documents. Selected records matter because they define the exact scope of the action being run, helping end users control which records are included and ensuring documents are created for the intended items only.

Selection Options ​

Selection Options is the configuration area used when creating or editing certain object class fields in Autologyx to define what values users can choose from. It is available only for the Single select, Multi select, and User field types in the Add field workflow for object classes, and for User fields it is the place where the field’s selectable user-related settings are configured. This matters because it controls the choices presented in those fields at runtime, ensuring the field behaves correctly for data capture, user selection, and any related membership or synchronisation settings configured for the object class.

selection or an input in this field ​

Self ​

In Autologyx, Self is the Record option in the Sequence Runner actor that targets the current record’s own object class—the same object class as the sequence where the actor is configured. It is used when a Sequence Runner is intended to activate another sequence for the record already in context, rather than for records returned by a Relation Lookup actor. In practice, Self is the only available Record option when no Relation Lookup actor is present, and when selected it limits the available target sequences to those configured for the same object class and started by the "When sequence activated" trigger. This matters to configuration admins and Super Admins because it determines whether a sequence runs against the current record or against related records, which directly affects how cross-object and same-object process automation is designed and executed in the platform.

Self contained form ​

A self contained form is a task type in Autologyx that is built from fields that are not linked to any object class. It is used when configuring task templates, typically on the task configuration tab, to create manual tasks that can be attached to records in any object class without depending on object-specific fields or updating the underlying record. This matters to configuration admins and Super Admins because it provides a flexible task creation mechanism for collecting information or guiding user actions across the platform, especially where the same task design must be reused across multiple record types.

Self contained form type ​

In Autologyx, a Self contained form type is a task type used in Task templates that is not tied to a specific Object class, which means it can be included in Task Group Templates across all Object classes without restriction. It is used when configuring or editing Task Group Templates in the Task configuration area, where administrators can add, retain, or remove these Task templates independently of the Object classes assigned to the template. This matters because it gives Configuration Admins and Super Admins greater flexibility when designing reusable task group structures: Self contained form type Task templates remain valid as Object classes change, and additional tasks of this type can be added at any time without class-specific constraints.

Self contained tasks ​

Self contained tasks are task interfaces in the Autologyx Catalyst UI that present their own embedded form content, allowing users to complete task-specific data entry and updates directly within the task experience rather than through a separate record or standalone page. They are used in end-user task workflows and are relevant when configuring user-facing forms and text fields, including features such as Markdown support introduced alongside Create/Edit forms and Standalone forms. Self contained tasks matter because they shape how work is completed in the platform, affecting usability, consistency of the task experience, and how administrators design and format task-driven interactions for end users.

Self records ​

Self records (shown as Self in configuration) are records in the same object class as the record currently being processed by a sequence. In Autologyx, this term is used when configuring actors that need to target or query records relative to the current sequence context, such as the Sequence Runner actor and related relational record operations. Selecting Self tells the platform to work within the current object class rather than a related or different class—for example, if a sequence is running against Mortgage Applications, Self records are other Mortgage Application records. This matters because it determines the scope of lookups, updates, and downstream sequence execution, helping configuration admins and Super Admins ensure that actions are applied to the correct set of records in the main sequence design.

Send activation email ​

Send activation email is an administrative action on the Edit user page that sends the platform’s activation email to a user account when account access is ready to be enabled. In Autologyx, this button is used by Configuration Admins and Super Admins as part of user account management, alongside reviewing or changing the account’s Status such as Created, Pending, or Active. It matters because it gives administrators direct control over when a user is invited to activate their account, helping coordinate onboarding and ensuring activation happens at the correct point in the user setup process.

send email actor ​

INSUFFICIENT_EVIDENCE

Send in header ​

Send in header is an API key authentication method in the Autologyx platform that transmits the key in the HTTP request header when calling external or integrated services. It is used when configuring Authentication Objects for API Keys, where administrators and integrators choose how credentials are included in requests. This setting matters because it determines how Autologyx presents authentication data to the target system and must match the receiving API’s expected authentication pattern for successful, secure connectivity.

Send in query string ​

Send in query string is an API key authentication method in the Autologyx platform that passes the key as a parameter in the request URL instead of in an HTTP header. It is used when configuring API Key authentication in Authentication Objects, where administrators and integrators choose how Autologyx supplies credentials to an external service. This setting matters because it determines the exact request format sent by the platform and must match the authentication requirements of the target API for integrations to connect and operate successfully.

Send Message Actors ​

Send Message Actors are sequence actors used in the Autologyx platform to automatically send emails as part of a workflow. Configuration admins and Super Admins use them in Sequences to deliver bespoke messages at the required point in a process to recipients such as the record creator, record owner, individual users, user groups, external email addresses, or addresses stored on records. Send Message Actors support merge fields, object class data, related record data, and local variables so message content can be dynamically populated at runtime, and they can include attachments made available by preceding Document Picker or DocAuto actors. They matter because they enable reliable, automated workflow communications, including team notifications, status-driven messaging, and document delivery, while integrating with user groups, task-driven processes, and other sequence components.

Show 12 more pages

Send messages ​

Send messages is a Sequencer actor used in sequence design to configure and send a bespoke email to one or more recipients as part of an automated workflow. It is added and managed in Edit design alongside other sequence actors such as API calls and local variables, and it supports merge fields and constants in the Recipients, Subject, and Message fields, including user and group data from Users and Groups where merge fields are supported. This matters to configuration admins and Super Admins because Send messages is the platform mechanism for embedding outbound email communication directly into process automation, enabling workflow-driven notifications, updates, and contextual messaging without leaving the sequence configuration.

Sequence Activated ​

  • Mostly relevant to: Configuration admins, Super Admins
  • Closely related concepts: Edit design, Automatic

Sequence Activated is a sequence start method in the Autologyx platform that allows one sequence to start another sequence programmatically. It is used when designing sequences, where a sequence can be configured with the starting trigger "When sequence activated", and in related automation patterns such as Sequence Runner setups, where the selectable target sequences are those configured with this trigger and relevant to the current, parent, or child object class context. This matters to Configuration Admins and Super Admins because it enables controlled chaining of processes across related records, supports modular sequence design, and ensures that only sequences explicitly configured for activation by another sequence are available for orchestration.

Sequence Actors ​

Sequence Actors are the configurable drag-and-drop building blocks used in the Autologyx Sequencer to perform automated actions within a sequence. Used by configuration administrators and super admins when designing or editing workflows in System Configuration, they sit alongside task and task group templates in the sequence workspace and are configured to carry out specific operations such as sending messages, updating record fields, looking up related records, generating documents with DocAuto, or calling external services through API-related actors. Sequence Actors matter because they define how a process handles data, communications, document generation, and system integrations at each step, enabling sequences to route work, react to record changes and task outcomes, and ensure the right actions happen at the right point in the workflow.

Show 3 more pages

Sequence canvas ​

The Sequence canvas is the visual design area in Autologyx where configuration administrators build and edit a sequence by dragging actors from the Actors panel onto the workspace, arranging them, and connecting or configuring them within the context of the selected object class shown at the top. It is used throughout sequence configuration for workflow design, including adding actors such as API Call, OpenAI: GPT, Relation Lookup, and Sequence Runner, and it also surfaces configuration issues directly on the canvas with warning icons for misconfigured actors. The Sequence canvas matters because it is the primary workspace for assembling, reviewing, and troubleshooting sequence logic, making it central to creating reliable automations and managing complex workflow behaviour in the platform.

Sequence commencement conditions ​

Sequence commencement conditions are the configurable trigger rules that control when a Sequence starts in Autologyx. Used when creating or editing a Sequence in system configuration, these conditions evaluate Record and event data—such as a Record being updated, a specific field being changed, or a field having a defined value—to ensure the workflow begins only for relevant Records. They are a key tool for Configuration Admins and Super Admins because they prevent unnecessary workflow activation, support targeted automation, and help route different subsets of Records into the correct process path from the moment the Sequence is initiated.

Sequence Connections ​

Sequence design ​

Sequence design is the workflow-building view of a Sequence in Autologyx, used after a Sequence has been created to construct and maintain the workflow for the selected Object class. Configuration admins and Super Admins access it by double-clicking a Sequence in the list or choosing Edit design from the Actions menu, and the screen opens as the dedicated design editor, distinct from Sequence properties. Editing Sequence design requires a Super Admin account or a role with the Sequencer tab Edit permission enabled, and the user must also be an Owner of the relevant Object class. This area matters because it is where the operational structure of the Sequence is defined and updated, making it the central configuration point for how that workflow is built and maintained in the platform.

Sequence designers ​

Sequence designers are users who configure and build automation sequences in the Autologyx Sequence Designer, using actors, task templates, object-class-specific options, constants, and lookup features to define how work is created, assigned, and progressed within a process. In practice, this term is most relevant to configuration administrators and Super Admins working in the Sequencer/Sequence Designer interface, where they add components such as Create task, Task assignment, and Relation Lookup actors, and use task templates that are available according to task type, task creation mechanism, and object class. Sequence designers matter because they control the structure and behaviour of automated workflows, ensuring tasks are generated for the correct records, routed to the correct users or teams, and configured in line with the platform’s object model and response settings.

Show 1 more pages

sequence execution ​

sequence execution engine ​

In Autologyx, the sequence execution engine is the runtime component that executes a configured sequence by progressing through its actors and applying the rules and settings defined in sequence design. It is used whenever a process sequence runs, including in actors such as Create Task, where configuration directly affects whether execution can continue. This matters to configuration administrators and developers because the engine enforces sequence behaviour at runtime: for example, if a Create Task actor has no task template selected, the engine halts at that actor to prevent unintended actions. Understanding the sequence execution engine is essential when designing, configuring, and troubleshooting automated process flows, as it determines how and when configured sequence steps are carried out.

sequence ID ​

In Autologyx, the sequence ID is the identifier shown against work carried out by a sequence, allowing users and administrators to link an event or record update back to the specific sequence instance that performed it. It is used in system-generated outputs such as the Update Record actor, where entries are date- and time-stamped and include the sequence ID, making it possible to trace which sequence executed a change. This matters for configuration, audit, compliance, and operational analysis because the sequence ID provides a consistent reference point for reviewing activity logs, investigating processing history, and distinguishing actions performed by different sequences across the platform.

Sequence list ​

In the Autologyx platform, the Sequence list is the configuration view that displays available Sequences and provides the entry point for sequence administration tasks. It is used by configuration administrators and Super Admins to locate a Sequence and open actions against it, such as editing its design by double-clicking the Sequence row or selecting Edit design from the Actions menu. The Sequence list matters because it is the central place from which users access and manage Sequence configuration, making it a key part of controlling how Sequences are maintained within the platform.

Sequence Name ​

Sequence Name is the required unique identifier entered when creating a sequence in the Autologyx platform. Used by configuration administrators and Super Admins in the sequence creation and properties workflow, it is limited to 100 characters and distinguishes one sequence from another in the Sequences list and related configuration screens. This name matters because it provides the primary label for locating, managing, and maintaining the correct sequence throughout configuration and administration activities.

sequence object class ​

In Autologyx, the sequence object class is the object class that a sequencer operates on and provides the data context for the actors within that sequence. It is used when configuring object class sequences, where actors such as Create Task, Set Task, Relation Lookup, and Sequence Runner use it to determine which records, relationships, and task templates are available during execution. For example, task actors can use Update object task templates created for the sequence object class, while relation-based actors can search for related records such as children of that class. This matters because the sequence object class defines the scope of the sequence, controls which configuration options are valid, and ensures the sequence works against the correct business record type.

sequence objects ​

In Autologyx, sequence objects are the configurable building blocks placed on a Sequence design workspace to define workflow behavior and control execution flow. They are used when designing and editing Sequences, where objects can be added, connected, and in some cases dragged from one Sequence into another workspace, and they include items such as Send Message actors, API calls, and Variables. Sequence objects also support platform features such as merge fields, which are resolved at runtime inside supported objects to insert values like client details or the current date and time. This matters to configuration admins and developers because sequence objects are the units through which workflow logic, integrations, messaging, variable handling, and reusable process design are implemented across the platform.

sequence path ​

In Autologyx, the sequence path is the route through a sequence that leads to a specific actor, representing the steps and outputs encountered before that point in the workflow. It is used in sequence configuration where actors need to work with content produced earlier in the process; for example, in the Document Picker actor, enabling the relevant option causes it to collect all documents found along the sequence path leading to that actor. This matters because the sequence path determines which upstream documents and results are in scope at a given step, directly affecting how documents are gathered, combined, and made available to users and downstream processing.

Sequence properties ​

Sequence properties are the configuration settings on a Sequence that define its core metadata and runtime defaults in Autologyx, separate from the Sequence design itself. Used by Configuration Admins and Super Admins on the Edit properties page, accessed from the Sequence Actions menu, this area is where you set or amend the Sequence name, description, associated object class, and any default task assignees or owners. Sequence properties matter because they control how the Sequence is identified, what records it is intended to run against, and who is assigned work by default when tasks are created; these defaults can then be overridden or appended by actors such as the Task Assignment Actor during execution.

Sequence Runner ​

Sequence Runner is a sequence actor in Autologyx that starts another sequence, either on records in the same object class or as part of a cascading design across related parent, child, or other relational records when used with Relation Lookup. It is used in sequence configuration, particularly in Sequences for Relational Records, to automate follow-on processing, ownership or assignment alignment across related records, and workflows for scenarios such as one time completion users. For configuration admins and Super Admins, Sequence Runner matters because it provides a controlled way to orchestrate multi-record and multi-sequence automation with flexible trigger options, and it has specific sequencing rules in the actor chain, such as not being a valid predecessor for a Task Assignment actor.

Show 2 more pages

Sequence Runner actor ​

The Sequence Runner actor is a sequence actor in the Autologyx platform that starts one sequence from within another, allowing administrators and developers to launch a separate workflow or sub process at any point in a sequence. It is configured on the sequence canvas in System Configuration and is used either on its own to run another sequence against the same object class, or in combination with the Relation Lookup actor to run a sequence against related parent or child records returned by the relational model. This matters because it is the mechanism for chaining workflows, reusing process logic, and applying actions such as task assignment or record updates across the current record set or matched related records, making sequence design more modular, scalable, and easier to maintain.

Show 1 more pages

Sequence Runner Configuration window ​

INSUFFICIENT_EVIDENCE

Sequence selection field ​

In Autologyx, the Sequence selection field is the configuration field in the Sequence Runner actor where an administrator chooses which sequence the actor will start. The field is populated only with sequences that match the actor’s configured object class and that have a starting trigger of "When sequence activated", ensuring that only valid, runnable sequences are available for selection. This field is used in the Sequence Runner Configuration window when setting up automation that launches another sequence, and it matters because it enforces compatibility between the actor, the object class, and the target sequence, helping configuration admins and Super Admins select the correct sequence for the process design.

Sequence specific menu ​

In Autologyx, the Sequence specific menu is the left-hand menu shown when working within a sequence, providing access to the sequence-focused sections and controls used to configure and manage that sequence. It is used in the sequence design and navigation area alongside related capabilities such as Edit design, Navigator, actors, API calls, local variables, object classes, and layout tools, making it the primary entry point for sequence-level configuration. This menu matters to configuration administrators because it organises the components and settings that define how a sequence is built, edited, and maintained, helping users move efficiently between design elements and manage sequence behaviour from a single contextual workspace.

Sequence status ​

Sequence status is the operational setting on a sequence that controls whether the sequence is active and able to run against records in its configured object class. In Autologyx, it is used when creating and managing sequences and is reflected in the Sequences list, where administrators can review and control the current state of each sequence, including related states such as paused. This setting matters because a sequence only starts processing records when its starting conditions are met and its status is set to running, making sequence status a key control for enabling, stopping, and governing automated execution.

Sequence trigger ​

A Sequence trigger is a configuration dependency in Autologyx that uses specific fields and field values, including select-field options, to initiate or control sequence-based behaviour in the platform. It is encountered when administrators edit Object class fields in the Data Model and when they modify Task template response forms through the Add field or Edit field panels, particularly where select options are added, changed, or removed. Sequence triggers matter because they rely on the continued existence of the referenced field definitions and values: if an option used by a Sequence trigger is deleted, the trigger is broken and no longer functions. Configuration admins and Super Admins should therefore check whether a field or field value is used in a Sequence trigger before making schema or template changes.

sequence workflow ​

A sequence workflow is the designed flow of actors and tasks inside an Autologyx Sequence, defining how work is carried out for a selected object class from start conditions through each step of processing. It is used in the Sequence design editor, where configuration administrators and Super Admins build and maintain the workflow by adding and arranging actors such as task creation, Update Record actions, document handling, and user-related steps. Sequence workflows are also where specific assignment behavior is configured, including assigning tasks to 1 time completion users and populating User-type fields through actor properties. This matters because the sequence workflow controls the operational path a sequence follows, determines how records, documents, and tasks are handled at each stage, and directly affects how understandable, maintainable, and effective an automated process is for administrators and future editors.

sequence workspace ​

In Autologyx, the sequence workspace is the canvas used in Sequence configuration where administrators build and arrange workflow logic by dragging actors from the actor menu and placing them in the required execution order. It is used when configuring sequences that include components such as DocAuto, Document Picker, Relation Lookup, Sequence Runner, Set Task, and Task Assignment actors, including document generation and sub-process orchestration. The sequence workspace matters because it is the primary design area where sequence structure is assembled, positioned, and connected, allowing Configuration Admins and Super Admins to create, organise, and maintain automated process behaviour accurately within the platform.

Show 2 more pages

sequence's object class ​

A sequence’s object class is the business object type that a sequence runs against in Autologyx, and it defines the record context available to actors configured within that sequence. In configuration areas such as Record Access Actor and Task Assignment Actor, the sequence’s object class determines which user-type fields are available for selection in options such as By field, because only user fields associated with that object class are shown. It also controls whether features such as record permission set assignment can be configured, since the object class must already have appropriate record permission sets defined. This matters to Configuration Admins and Super Admins because the sequence’s object class governs who can be set as record owners, assignees, or permission recipients, and it directly affects how access, ownership, and task assignment behave across the records processed by the sequence.

Sequencer ​

Sequencer is Autologyx’s workflow design canvas for building and maintaining sequences: automated flows made up of triggers, variables, conditions, and actors that execute business actions across the platform. It is used in System Configuration when configuration admins, super admins, and developers design automations that create or update object records, generate documents from templates, create and assign tasks, manage record access, send notifications, and call external or internal APIs using authentication objects, constants, and merge fields. Sequencer matters because it is the control layer for process automation in Autologyx, allowing organisations to turn object class and task template configuration into repeatable, auditable workflows that reduce manual work, enforce operational rules, and integrate Catalyst with external systems and AI-enabled actions.

Show 43 more pages

Sequencer actors ​

Sequencer actors are the configurable action components used within the Autologyx Sequencer to define and execute workflow steps such as API Call, Send Message, and Local Variable operations, and they also include specialised actors for capabilities such as OpenAI GPT integration and record access control. They are used when building and editing Sequencer-based workflow logic, where administrators and integrators configure each actor’s settings, inputs, authentication, and field mappings, including support for User type merge fields in supported actor contexts. Sequencer actors matter because they are the mechanism through which workflow automation is performed in the platform, directly affecting how records are updated, messages are sent, external systems are called, and AI-powered steps are embedded, while platform controls such as Edit Mode protect the integrity of Sequencer designs during configuration.

Sequencer API Call actors ​

Sequencer API Call actors are Sequencer workflow actors that execute outbound API requests to external systems from within a process flow, using configured integrations and their associated Authentication Objects to connect securely. They are used when building or configuring flows that need to retrieve or exchange data with third-party platforms, such as pulling documents into Autologyx from connected document management or other business systems. API Call actors matter because they provide the mechanism that turns an active integration into an operational step in a live workflow, allowing configuration admins and developers to embed external system interactions directly into process automation while managing those connections centrally through System Configurations → Integrations.

sequencer auth object ​

INSUFFICIENT_EVIDENCE

Sequencer Elements ​

Sequencer file download ​

Sequencer file download is an integration capability in the Autologyx Sequencer that uses the enhanced API Call actor to retrieve documents from external sources and bring them directly into a workflow for further processing. It is used when configuring automated steps that need to download files from connected systems, typically alongside authentication settings, source definitions, and downstream actors such as Document Picker or Update Record. This matters because it enables administrators and integrators to design end-to-end workflows that ingest documents from multiple origins without manual handling, ensuring the right files are available at the right point in the process and allowing external content to be incorporated consistently into Autologyx-driven operations.

Sequencer integrations ​

Sequencer integrations is a usage panel shown on an Authentication Object in Autologyx that lists every sequence currently using that object, identified by name. It is used by configuration administrators and Super Admins when reviewing credentials to see exactly which sequenced automations depend on a specific authentication object. This matters because it provides immediate visibility of downstream dependencies, supports safe credential maintenance and rotation, and helps prevent disruption by informing decisions about updates or deletion where in-use protection applies.

Sequencer tab ​

The Sequencer tab is the system-permissions area in Autologyx roles that controls access to sequence management features. It is used by Configuration admins and Super Admins to grant Create and Edit permissions for working with sequences, and it determines whether users can see the Sequences list and edit sequence properties or sequence design in the System Configuration area. This tab matters because it is the primary access-control point for sequence design and maintenance: without the appropriate permissions enabled under the Sequencer tab, users cannot perform sequence administration tasks even if they can access related objects elsewhere in the platform.

Sequencer triggers ​

Sequencer workflow ​

A Sequencer workflow, or Sequencer, is an Autologyx workflow that can be launched after records are created to perform follow-on processing such as enriching record data, routing items for review, and sending user notifications. In the platform, it is used as a post-creation automation step, including immediately after files are uploaded through the File upload component, where uploaded files are indexed, attached to newly created records, and then passed into further workflow handling. This matters to end-users and configuration admins because it connects record creation to operational processing, ensuring uploaded content is acted on consistently and efficiently within the wider Catalyst automation framework.

sequences ​

In Autologyx, a Sequence is a configurable automated workflow defined in the Sequencer that runs against a record or related records when specified triggers and commencement conditions are met. Sequences are built in System Configuration using sequence actors to perform actions such as creating tasks from task templates, updating records, sending messages, assigning permissions, evaluating local variables, calling APIs, generating documents, and interacting with parent or child records in the relational model. They are managed through the Sequences list and are referenced across object classes, task templates, user groups, authentication objects, and integrations. Sequences matter because they are the core mechanism for orchestrating process automation in the platform, ensuring that data collection, task assignment, notifications, integrations, and record updates happen consistently, at scale, and in the correct order.

Show 39 more pages

Sequences for relational records ​

Sequences for relational records are a System Configuration capability in Autologyx that lets administrators define and run document automation sequences against records that are linked through object class relationships in the Relational Modeller. Used alongside Sequences, Sequence Actors, and document configuration, this feature applies generated outputs, dynamic values, and related automation steps to associated records rather than only to a single standalone record. It matters because it enables configuration admins and Super Admins to design automation that follows the platform’s relational data model, ensuring documents and other sequence-driven actions are produced in the correct business context across connected records.

Sequences list ​

The Sequences list is the Autologyx system configuration page for viewing and managing Sequences in the Sequencer. It is used from the Sequences area to create new sequences and to work with existing ones, including editing properties, editing design where permitted, and changing operational state such as run, pause, or resume through the available actions. The list is visible to Super Admins and to users whose role includes the required Sequencer permissions; users without access do not see the Sequences menu option and receive an access denied message if they try to open the page directly. This matters because the Sequences list is the central control point for administering sequence definitions and their lifecycle, and access to it determines whether a user can maintain automation configuration in the platform.

Sequences section ​

The Sequences section is the area of the Autologyx system configuration navigation where administrators view and open configured Sequences for editing and management. It is used from the left-hand menu when working in sequence design, allowing Configuration Admins and Super Admins to locate existing Sequences, such as process-specific workflow definitions, and move directly into their configuration. This section matters because Sequences are a core part of how work is structured and automated in the platform, so the Sequences section is the central entry point for maintaining those definitions and ensuring the correct process behaviour is configured.

Sequences tile ​

The Sequences tile is a tile on the System configuration landing page in the Autologyx platform that provides a quick view of sequence activity across the system. It displays two values: the top number shows how many sequences are currently running, and the bottom number shows how many sequences are paused. This tile is primarily used by Configuration admins and Super Admins to monitor the operational state of configured sequences from a central administration area, helping them assess system activity at a glance and identify whether sequences are progressing as expected or require attention.

sequencing ​

Service Accounts ​

Service Accounts are dedicated Autologyx user account types for system-to-system integration and automation, available as Internal Service accounts and External Service accounts. They are configured in the Users administration area and are used where API-based access must continue through username and password authentication even when Single Sign-On is enabled and password authentication is disabled for regular users. This makes them essential for developers, integrators, Configuration Admins, and Super Admins who need reliable authentication for Catalyst-driven services and API operations such as POST and PATCH calls. In each Catalyst build, Autologyx supports one Internal Service account and up to five External Service accounts, so selecting the correct account type and managing limits is an important part of platform configuration.

Service Levels And Escalation ​

Set ​

Set expiry date ​

Set expiry date is an authentication object configuration option in Autologyx that lets administrators define a fixed expiry date for the credential or access details stored in the object and record what that expiry applies to. It is used when creating or editing Authentication Objects in Administration, where the administrator selects the option, enters the expiry date, and specifies the relevant scope of the expiry. This matters because Authentication Objects are used by providers, API calls, and API Actors, so setting an expiry date helps teams manage credential lifecycle, maintain control over integrations, and support security, compliance, and operational oversight by making time-bound authentication details visible and governable within the platform.

Set Field ​

INSUFFICIENT_EVIDENCE

Set owners ​

Set owners is a Record Access actor configuration option in Autologyx that assigns an owner to a record only when the record does not already have one. It is used when configuring record ownership within a sequence, where administrators can choose how the owner is set either By user or By field. This matters because record ownership drives who is responsible for a record and who can work with it, while preserving any ownership already in place; if ownership must be replaced regardless of the current value, the related Override owners option is used instead.

Set Task actor ​

Set Task actor is a Sequencer actor used to manage tasks generated from task templates that use the Automatic task creation mechanism. In Autologyx, configuration administrators place it in a sequence when they need to act on an existing automatically created task rather than create a new one: it can re-create a task that was previously created and completed, and it can delete tasks, including outstanding, completed, or the most recent matching task, depending on configuration. It is used in workflow design alongside related actors such as Task Assignment actor, which should be placed before Create Task actor or Set Task actor when task ownership or assignees must be set. This actor matters because it gives administrators precise control over the lifecycle of recurring or template-driven tasks, supports subsequent tasks from the same template, and helps keep workflows and task lists aligned with the intended process state.

Show 2 more pages

set task actor configuration ​

Set task configuration modal ​

INSUFFICIENT_EVIDENCE

Set task owner ​

Set task owner is the task ownership setting used within the Task Assignment Actor in Autologyx to define who becomes the owner of a task created or updated by that actor. In sequence configuration, it is the option used in the Configure task ownership section, where administrators specify the assignment method and source of the owner, such as through configured users or field-based values. This matters because task ownership controls who is responsible for the work item in the platform, shaping how tasks are routed, actioned, and managed within a workflow.

sets of Users ​

shorthand {{ record }} ​

In Autologyx templates, the shorthand {{ record }} is a merge-field shortcut for the current Object Record’s identifier property, automatically resolving to the same value as the record property configured as the record identifier field rather than requiring an explicit property path. It is used in the Record Properties merge-field context alongside explicit fields such as {{ record.id }}, {{ record.created at }}, and {{ record.modified at }}, and is most relevant when configuration admins and developers are designing template content that needs to reference the current record succinctly. This shorthand matters because it provides a consistent, simplified way to display the primary record reference in generated content while preserving alignment with the platform’s configured record identifier.

Show Log ​

Show Log is an option in the API Call Actor configuration area that opens the API Test Call History for the selected API test call. It is used by configuration administrators and developers or integrators when working with API Call actors to review the recorded history of test calls made during setup and troubleshooting. This matters because it provides direct access to the results and history of API test activity in the context of an API configuration, helping users validate integrations, inspect previous test executions, and debug API behaviour more efficiently.

Show this section header ​

Show this section header is a section-level display setting in Autologyx that controls whether a section title is shown in the user interface. It is used when configuring form layouts and other page sections, including Create response form, Complete self contained form, and Landing page configuration, typically from the section properties or layout panel. Turning this option off keeps the section and its fields available while removing the visible header, which is useful when you want to organise content structurally without showing a distinct section break to end users. This setting matters because it affects form presentation, readability, and page design, and it is often used alongside section properties and conditional visibility to control how grouped content is presented.

show/hide ​

In Autologyx, show/hide describes the conditional logic behavior that displays or conceals form content—such as a section—according to the value entered in a controlling field. It is used when configuring record and task forms, including layouts that contain sections, fields, and columns, where one field determines whether subsequent content is visible to end-users. This matters because show/hide logic directly affects the form experience and the integrity of the configuration: if a field that controls this logic is removed from a column or layout, any dependent section or content that relies on that condition is impacted, so administrators must understand these relationships when editing forms.

side panel tabs ​

Side panel tabs are the configurable tabs shown in the side panel when a user is working in the Create and edit view for a record in Autologyx. They are made available in edit view when one or more side panel options have been enabled under View, and provide quick access to supporting record information and actions such as Summary, record access details, and activity logs alongside the main record form. This matters because side panel tabs let end users review important contextual information without leaving the record they are editing, helping them validate changes, understand record history and permissions, and work more efficiently within the workspace.

side panel/Tasks tab ​

In Autologyx, the side panel/Tasks tab is the task-focused area of a record where users view and carry out task-related activity for that specific record. It is used from the record side panel to display available tasks and to perform task actions directly in context, rather than navigating away from the record. Access to what appears on the Tasks tab depends on record access and the task permissions defined through class permissions, so users without the relevant task permissions will not see task results there. This matters because the Tasks tab provides an in-record workspace for operational actions and is directly affected by configuration choices that control who can see, assign, edit, complete, or delete tasks.

side panels ​

Side panels are the context-sensitive panels shown on the right-hand side of the Autologyx interface that display and provide access to information and actions related to the item currently selected, and they are also used in configuration areas such as Formbuilder to present components and properties for the canvas. In the workspace, side panels are used from records lists, card view, and record edit views to show tabs such as Summary, Tasks, Templates, Activity Log, and Record access, allowing users to review key record details, create manual tasks, generate documents, and manage access without opening separate pages. In configuration, the side panel is part of the Formbuilder layout and contains sections such as Layout, Fields, Object Class Fields, Properties, Child Object Classes, and Elements, which administrators drag onto and configure for forms and views. Side panels matter because they centralise record details, available actions, and configuration controls in a consistent location, making navigation faster for end users and enabling admins to design how information and interactions are presented across the platform.

Show 13 more pages

Side stack ​

In the Autologyx platform, the side stack is the panel area that opens to the right of the main content area to display supporting pages, editors, and management panels without navigating away from the current screen. It is used in places such as the List page filter editor and sequence configuration, where actions like opening the Manage default task assignees panel load additional configuration options in this right-hand panel. The side stack matters because it lets end-users and configuration admins review, edit, and manage related settings in context, preserving visibility of the underlying page and making multi-step tasks faster and easier to complete.

In Autologyx, the sidebar is the side panel used in workspace record views to display contextual information alongside the main page without navigating away from the current task. It is used when features such as Child record summary are enabled from the View menu, allowing a selected child record’s summary to open in the sidebar while the user continues working in the parent record context. This matters because it lets end users review related record details in place, supports faster association and validation of child records, and reduces the need to switch between full create/edit views or other navigation elements.

In Autologyx Workspace, sidebar tabs are the set of panels shown in the record sidebar that let users view different information and actions while staying on the current record page. They are used when working with records, including parent and child relationships, and can include context-specific tabs such as Child record summary when a user selects an associated child record from a parent record. Sidebar tabs matter because they control how related information is presented in context: when a child record is selected, the child summary can be shown in its own tab, while the other sidebar tabs remain focused on the parent record, helping users navigate related records without losing the parent record context. Each sidebar tab can also be opened in an external window from the icon in the top-right corner of the tab.

Signed Document ​

A Signed Document in the Autologyx platform is the completed document file returned from an electronic signature process, such as a DocuSign envelope, after signing has finished and the final version is available to be retrieved and stored in Catalyst. It is used in e-signature integrations and related API calls that check signing status, download the completed file, and save it into the relevant Autologyx process or record for ongoing case management and auditability. This matters to configuration admins and developers because retrieving and storing the signed document is the step that turns an external signing event into a usable platform asset, enabling the completed agreement or form to be retained, surfaced to users, and used in downstream workflow actions.

Signing Status ​

Signing Status is the per-recipient state of a DocuSign envelope in Autologyx, used to show whether each individual recipient has viewed, signed, declined, or is still pending completion for a document sent through a workflow. It is used in DocuSign-integrated processes and can be monitored through the platform’s signing and envelope tracking features, including API-driven interactions that return recipient-level updates. This matters because configuration admins use it to design and support signing steps that react to recipient progress, while end-users rely on it to track who has completed their action and to identify outstanding signatures needed before a signed document or related workflow step can be completed.

single and multi select field types ​

In Autologyx, single and multi select field types are form fields that present users with predefined option values, allowing either one choice or multiple choices to be captured in record and task forms. They are commonly used by configuration administrators when designing standalone fields and sections, particularly in conditional logic and Conditional Visibility rules configured through the Edit condition modal, because their fixed option sets provide consistent values for evaluating conditions. This matters because these field types are often used to control the display of subsequent sections, and changing their properties can affect any conditions that depend on those configured options.

Single line ​

In the Autologyx Catalyst form builder, Single line is a text field style used on record and task forms when the expected input is a single word or a short sentence. Configuration admins use it when designing intake and other record-creation forms to capture brief values clearly and consistently, rather than longer free-text responses that belong in a Multi line field. Choosing Single line matters because it helps structure form input appropriately, improves the usability of forms for end users, and supports cleaner data capture in create and edit views and any form logic that depends on concise text entries.

single line text fields ​

INSUFFICIENT_EVIDENCE

Single or Multi line ​

In Autologyx, Single or Multi line is a text field configuration option used when adding elements to a form, such as during standalone form creation. It defines whether a text input captures content in a single-line field for short entries or a multi-line field for longer free-text responses. This option is used alongside other field choices, such as dropdown lists and radio buttons, when configuring form elements and field options. It matters because it determines how users enter text, how much content a form field is designed to accept, and how clearly the form supports the intended type of information being collected.

Single page configuration ​

Single page configuration is an Administration permission scope in the Autologyx platform that grants access to create, edit, or delete configuration areas presented as individual administration pages. It is used within role-based access control for Standard account users and determines which items are available in the Administration section of the left-hand navigation. For configuration administrators and Super Admins, this matters because it controls targeted access to specific setup functions without exposing broader administration capabilities, supporting precise delegation of platform configuration tasks.

Single select ​

Single select is an Autologyx field type used in object classes, task templates, and record or task forms to present a predefined list of options from which the user can choose exactly one value. It is configured by administrators when defining fields and their options, supports up to 100 options, and can be displayed as either radio buttons or a dropdown list; for some uses, such as the Country selector, it is presented as a searchable alphabetical single-select dropdown. Single select fields support a default value, which is pre-populated when the field is shown on record forms and views, and they are distinct from Multi select fields, which allow more than one choice. This field type matters because it standardises controlled input, simplifies form completion, supports record sorting, and helps ensure consistent data capture for values such as status, sector, or term.

Single Select field type ​

In Autologyx, the Single Select field type is a form field used in response configuration to present a predefined list of options from which the user can choose exactly one value. It is used when building forms for task types such as a Complete self-contained form, where the field can be displayed either as radio buttons or as a drop-down list. This field type matters to configuration admins because it standardises user input, supports clear form design, and helps ensure that responses are captured in a consistent format that can be reliably used in task execution and related form behaviour.

Single select fields ​

Single select fields are form and object class fields in Autologyx Catalyst that require the user or configuration to choose one value from a predefined list of options. They are used in the Catalyst form builder on record and task forms, where they can be presented as a drop-down list or as radio buttons, and they are also used in platform automation such as sequence commencement conditions and Update Record actors, where a single selected value can be evaluated or set. Single select fields matter because they standardise input, guide users to valid choices, save space in forms when displayed as drop-downs, and provide reliable values for conditional logic, record updates, and sequence behaviour across the platform.

Single select type field ​

A Single select type field is a configurable field in the Autologyx data model that lets users choose one value from a predefined list of options for an object class. It is used by Configuration admins and Super Admins when adding or editing fields in areas such as the Data Model tab, Fields list, and Edit field panel, where the available options and any default value are maintained. This field type is important because it standardises data entry, ensures only one permitted value can be stored, and supports consistent configuration across objects; if an option that was set as the default is deleted, the field’s Default value setting is automatically cleared.

Single sign on ​

Single sign on (SSO) in Autologyx is the platform authentication feature that lets users access the system through an external identity provider such as Microsoft or Google instead of using a separate Autologyx password. It is configured and maintained in Administration, where Super Admins or users with the relevant Single sign on permissions can edit the SSO setting, enable or disable it, and define the roles assigned to users who are created automatically the first time they sign in through SSO. SSO is used alongside user account administration because users expected to authenticate this way should not be sent an activation email, and users created via SSO are always given an Internal account type. This matters because it centralises access management, streamlines user onboarding, and ensures the correct roles and account settings are applied when users enter the Autologyx platform.

Show 4 more pages

Single Sign On (SSO) ​

Single Sign On (SSO) is an authentication method in the Autologyx platform that allows users to sign in through an external identity provider instead of using a platform password. It is configured in the authentication methods by user account type settings, where Configuration Admins and Super Admins define whether each user group can use passwords, SSO, or both, such as enforcing SSO-only access for external users while retaining password login for internal staff. SSO matters because Autologyx applies these rules at login and across password reset flows, ensuring account access policies are consistently enforced and aligned with organisational security and compliance requirements; if SSO-only access is enabled without the required identity provider configuration, affected users will be locked out.

Single sign on configuration ​

Single sign on configuration (SSO configuration) is the Autologyx administration setup that defines how a specific single sign-on provider is presented and handled at login. It is used in the platform’s sign-in experience, where enabled configurations are listed as available Single sign on options, and it controls what happens when a user authenticates through that provider, including redirecting them to the provider’s login page, matching them to an existing Autologyx account by email address, reactivating a non-active matching account, or denying access when no account exists. It also works with related settings such as Automatically create user, Roles to assign to created user, Single sign on provider, Single sign on settings, and Standard account type to determine whether new users are created automatically and which role and account type they receive. This matters to Configuration admins and Super Admins because it governs secure access, user onboarding behaviour, and role assignment for users entering the platform through SSO.

Single sign on configuration Name ​

Single sign on configuration Name is the mandatory label used to identify a Single sign-on (SSO) configuration in the Autologyx Administration area when creating or editing SSO settings. It is shown on the Edit screen alongside other SSO configuration fields such as Client ID, Client Secret, Redirect URI, Automatically create user, and Landing page, and it can be updated but cannot be left blank or removed. This name matters because it provides a clear, manageable identifier for administrators and Super Admins working with SSO configurations through the Administration tab and Actions menu, helping them distinguish, maintain, and correctly manage each configured authentication connection.

Single Sign On create and edit permissions ​

Single Sign On create and edit permissions are role-based permissions in Autologyx that allow a user to create and modify Single Sign On settings and related SSO configurations. These permissions are used in platform administration and setup scenarios, including features such as the Catalyst Word Add-in configuration, where access requires either a Super Admin account or a Standard account whose Role has these permissions enabled. This permission matters because it controls who can define and maintain the platform’s authentication integration, helping administrators delegate SSO configuration tasks appropriately while protecting critical sign-in and access settings from unauthorised changes.

single sign on listing page ​

The single sign on listing page is the administration page in Autologyx where configuration admins and Super Admins return after creating or editing a single sign-on configuration and can view the set of configured SSO entries. Used from the Administration area when managing login integrations, this page acts as the central list for reviewing each configuration and its status, including whether it is enabled. It matters because enabled configurations are surfaced on the Catalyst system login page as selectable single sign-on options, making this page the key control point for managing which external identity provider connections are available to users.

Single sign on option ​

The Single sign on option is the login-page control in Autologyx that lets an end user choose a configured single sign-on provider, such as Azure, instead of signing in with a local username and password. It is used during authentication whenever single sign-on has been enabled for the platform, and it connects the user to the relevant single sign-on configuration that determines how their account is handled after sign-in, including automatic user creation, assigned roles, account type, and access outcomes. This matters because it is the entry point for federated access to Autologyx and directly affects how users are authenticated and what access they receive when they enter the platform.

Single sign on provider ​

A Single sign on provider is the external identity service that authenticates users for access to the Autologyx platform, such as Okta, Microsoft, or Google. It is selected when creating a Single sign on setting in Administration and defines where users are redirected to sign in, after which Autologyx matches the authenticated email address to an existing account or, if enabled, automatically creates a new standard user account. The configured provider is a core part of the SSO setup and cannot be changed on an existing setting, so choosing the correct provider during configuration is important for administrators, while for end-users it determines the sign-in experience and whether they are taken directly into the platform or prompted to log in with their organisation’s identity service.

Single sign on settings ​

Single sign on settings are the Administration records used to configure and manage SSO access for an Autologyx system. Found under Administration > Single sign on settings, they define the SSO provider connection, whether the configuration is enabled, whether users can be created automatically, the roles assigned to auto-created users, and related options such as logout behaviour and support for Catalyst and the Word add-in. These settings are used by configuration administrators and super admins when enabling identity-provider login, editing existing SSO configurations, and controlling how users are authenticated and provisioned. They matter because they determine which external login methods are available, how users enter the platform, whether new users are created during first login, and what access those users receive once they enter Autologyx.

Show 4 more pages

SLA ​

In Autologyx, an SLA is a task template setting that defines the required completion timeframe for a task. It is configured in the Lifecycle section when creating or editing a task template, alongside options such as whether the task is completed once or expires, and it sits alongside Due Date configuration. SLA matters because it establishes the expected service target for completing work, which in turn drives how tasks are monitored and managed through states such as outstanding and overdue, helping configuration admins design task behaviour and operational controls that match business service commitments.

SME ​

sorting ​

Sorting is an Autologyx records-list feature that lets end users organise displayed records by selected field values in ascending or descending order. It is used when viewing lists of records to reorder data by supported field types, including integer, date, text, single select, and phone and e mail fields, so users can quickly surface the information they need. Sorting matters because it makes large or disorganised record sets easier to scan, improves clarity in day-to-day work, and helps users complete tasks more efficiently.

Sorting records ​

Sorting records is the Autologyx Catalyst feature that lets users reorder items in a records list or list view by selected field values, including different field types such as user type fields and object class fields. It is used when viewing collections of records in the platform to organise information into a clearer, more useful sequence, making it easier to scan, compare, and work through disorganised data. For end-users, this improves day-to-day efficiency and visibility when handling record sets; for configuration admins, it is an important usability capability to understand when designing and supporting list-based experiences in Catalyst.

source ​

In Autologyx, a source (also described as a document source or file source) is the configured origin from which files are retrieved into a workflow, particularly when setting up the API Call actor for Sequencer file download. It is used in configuration to identify where documents should be downloaded from and is defined alongside the required authentication method so the platform can connect to the external system and collect the needed files. This matters to configuration admins and developers because the source determines the external location the workflow interacts with, directly affecting how inbound documents are integrated, how download steps are configured, and how securely and reliably file retrieval operates within the process.

source code ​

In Autologyx, source code is the raw Markdown text shown in a field instead of its rendered formatting, allowing users to edit content directly and preserve its structure, syntax, and layout. It is used when working with Markdown fields in create/edit record forms and task forms, where users can switch to a source code view for authoring and maintenance, and it is also the default display for Markdown content shown elsewhere in the platform, such as in record list columns. This matters because it determines whether users interact with Markdown as editable text or as formatted output, which affects how content is entered, reviewed, and managed across forms and lists.

Source field ​

Source field is a configuration field used in document-related sequence actors to define where the actor should take its document input from within an Autologyx workflow. It is used primarily when configuring the Document Picker actor, and in related document generation and retrieval scenarios such as DocAuto and API Call outputs, where the available Source options depend on the preceding object in the sequence. Common options include Document Field, DocAuto Actor, API Call document, and, in DocAuto configuration, Document Template. This field matters because it controls the origin of the document passed into the next step, ensuring that generated, retrieved, or stored documents are sourced from the correct actor or object field and that the sequence behaves as intended.

specific field ​

A specific field, also referred to as a record field, is a defined field on an Autologyx record where data or files are stored and later accessed by actors and users throughout a workflow. In practice, configuration admins use a specific field when setting up actions such as the Update Record actor to write downloaded or generated content back to the record, for example storing a document produced by the Sequencer file download capability. This matters because choosing the correct field determines where information is persisted on the record, how it is surfaced for later processing, and how other actors and integrations can retrieve, route, or present that content within the platform.

SSO ​

SSO (Single sign-on) in the Autologyx platform is an authentication configuration that signs users in through an external identity provider instead of using an Autologyx password flow. It is used at platform login and directly affects how end-users access the system, how Configuration Admins and Super Admins design authentication, and how password-related actions behave; when SSO is enabled, users are returned to the login page rather than being allowed to set a password through the forgot-password process. SSO is also important when configuring account types, because service accounts retain username/password authentication even when SSO is enabled and password authentication is disabled for regular users, allowing API integrations and related system connections to continue operating.

SSO configurations ​

INSUFFICIENT_EVIDENCE

Stages ​

Stages is a task template configuration area in Autologyx that defines the completion steps a task must pass through as part of its lifecycle. It is used in the Stages tab when creating or editing a task template, alongside Response configuration and Lifecycle settings. In the current platform behaviour, tasks have a single completion stage, meaning the task is finished when that stage is completed; the section exists to represent and control how task completion is structured. This matters to configuration admins and Super Admins because stages determine the completion model applied to tasks generated from the template and therefore affect how work is progressed, managed, and concluded within the platform.

stand alone forms ​

In Autologyx, a stand alone form is a form configured on an Object class and used independently of a task to create new records directly. It is defined in the Object class configuration, alongside display settings, document templates, and permissions, and is used by end-users when submitting information through the platform without starting from a task form. Stand alone forms matter because they provide a controlled entry point for record creation, determine which fields are presented in the create/edit experience, and support application designs where user-supplied information is captured directly into an Object class before further workflow, document generation, or task activity takes place.

Standalone fields ​

Standalone fields are task form fields that are created and configured directly within a specific Task template in Autologyx, rather than being drawn from an object class. They are used in Task Templates across the available standalone field types and support standard field settings such as label, description, default value, validation, and conditional visibility through the Edit condition modal. Because they belong only to the Task template in which they are defined, standalone fields are central when configuration admins design task-specific data capture, control form behaviour with conditional logic, and manage the impact of field property changes on template behaviour.

Standalone form settings ​

Standalone form settings are the configuration options for a standalone form in the Autologyx platform, used by configuration administrators and Super Admins to control how the form behaves when it is accessed outside the main application experience. These settings are used when setting up or maintaining standalone forms and include options such as enabling a redirect and defining the destination or redirect URL that users are sent to after completing the form. This matters because it allows organisations to connect standalone forms to existing workflows, shape the end-user journey after submission, and ensure the form fits cleanly into broader business and process experiences.

standalone forms ​

Standalone forms are object class-specific forms configured on the Forms tab and used to create new records outside the standard object create/edit experience. In Autologyx, they are built with Formbuilder using layout components, object class fields, and elements, and support features such as conditional logic, read-only fields, configurable submit behaviour, and optional redirect URLs after submission. Standalone forms matter because they provide a controlled intake experience for end-users and external participants while allowing configuration admins and super admins to tailor exactly which fields and components are shown for a given record creation journey, separate from the object class landing page, create/edit view, and summary view.

Show 17 more pages

Standard account ​

Standard account type ​

Standard account type is the default Autologyx user account type for regular platform users and administrators whose access is controlled through assigned Roles rather than full platform-wide privileges. It is used across Administration, System configuration, Single sign-on provisioning, and My Account: users created through Single sign-on are created as Standard accounts, Standard accounts can access administration and configuration areas when their Role grants the required permissions, and they can have a My Account page. This account type matters because it defines the core access model for most users, allowing Configuration admins and Super Admins to grant targeted capabilities such as managing authentication settings, working with the relational modeller, creating sequences, or using specific system areas, while keeping access restricted to the permissions and object-class ownership defined for that user.

Show 3 more pages

standard admin ​

Standard authentication ​

Standard authentication is the Administration area in Autologyx where password rules for standard user logins are configured for the system. It is used by Super Admins and other users with the relevant Company Details or Standard Authentication edit permissions, and it appears in the Administration navigation only for roles that have access to it. The settings defined here control the password requirements that end-users must meet when managing their account credentials, including the rules shown in My Account during password changes. This matters because it governs how users authenticate with standard accounts, helps administrators enforce organisation-wide password policy, and determines who can view and update these authentication settings through role-based access.

Standard authentication configuration ​

INSUFFICIENT_EVIDENCE

Standard authentication page ​

The Standard authentication page is the Administration area in the Autologyx platform where configuration administrators and Super Admins manage the platform’s standard user sign-in and account activation settings. It is accessed from the main navigation menu under Administration and is used to configure user activation rules that control how users activate their accounts through the activation email, activation link, and Activate your user account page. This page matters because it centralises the settings that govern the user onboarding and authentication experience, helping administrators apply the required activation behaviour consistently across the platform.

Standard Configuration ​

Standard Configuration is the default API Call Actor template in the Autologyx platform, used to define general-purpose API calls that are not tied to a specialist integration such as iManage. It is selected when configuring API Call Actor actions in system configuration, where administrators and integrators specify the request method, authentication settings, and URL, including platform variables such as record and client values. This matters because it provides the baseline pattern for creating outbound calls to external or internal endpoints, enabling common integrations and record-driven requests through a consistent configuration model in the platform’s configuration panel.

standard controls ​

Standard controls are the common AI configuration options available in Sequencer when setting up or running an AI-enabled step in Autologyx. They include selecting the model, setting request parameters such as temperature and max tokens, and choosing the Authentication Object used to send requests through supported AI engines and providers such as OpenAI and AWS Bedrock. These controls are used wherever Sequencer exposes model-level settings, giving end-users and configuration admins a consistent way to tune response behavior, manage provider access, and apply the same core configuration approach across different models and actors.

standard history events ​

Standard history events, also shown as history events, are the platform’s built-in audit entries that Autologyx writes automatically when key actions occur during processing. In the context of the hierarchical record creation endpoint, these events are recorded when ownership is assigned and when records are successfully created, providing a consistent activity trail directly against the relevant records. They are used by developers and integrators to confirm that endpoint-driven operations completed and by security, compliance, and analytics users to review operational activity and record lifecycle changes. Standard history events matter because they give a reliable, system-generated record of important platform actions without requiring custom event handling or additional logging configuration.

standard message templates ​

Standard message templates are the platform’s built-in message formats used for outgoing system communications, such as notifying a user that they have a task to complete. In Autologyx, these templates use merge fields to automatically insert configured information, including values from Company details, into the message content. They matter because they control the consistency, accuracy, and branding of routine notifications sent by the system, so configuration and super admin users need to ensure the underlying company information and related message settings are correctly maintained.

standard users ​

Standard users are Autologyx users with a standard account type who participate in everyday work in the platform, including being assigned to complete manual tasks. In task creation and assignment flows, such as the Create task screen for an object record, Standard users can be selected as task assignees alongside Super Admin users, and selecting a Standard user changes the available assignee options by disabling one time completion users. The term also appears in platform behaviour and performance contexts, such as task list request handling for standard users. This matters because account type controls what user selection options are available during task setup and helps administrators and end-users understand how tasks are assigned and experienced in the workspace.

starting conditions ​

Starting conditions are the trigger rules that determine when an Autologyx Sequence begins for records in a selected Object class. Configured in the Sequence design and trigger configuration areas when creating or editing a Sequence, they define whether the Sequence starts immediately when a specified condition is true or starts after a delay, and they control whether the Sequence runs when records are created or when record fields are updated. Starting conditions matter because they govern exactly which records enter the Sequence and at what point processing starts, making them a core part of accurate automation setup and Sequence behaviour.

starting trigger ​

In Autologyx, a starting trigger is the trigger configured at the beginning of a sequence that defines how that sequence can be initiated. In the Sequence Runner actor and its Configuration window, the starting trigger directly controls which sequences are available in the Sequence selection field: only sequences for the relevant object class that use the starting trigger "When sequence activated" are shown and can be started by the actor. This matters to configuration admins because the correct starting trigger is required for a sequence to be callable from another sequence through the Sequence Runner actor, and clear labelling of that trigger helps identify which parent sequence is intended to activate it.

State ​

INSUFFICIENT_EVIDENCE

Static Value ​

Static Value is a source option in Autologyx configuration that lets you set a field or variable directly with a fixed value entered in the configuration, rather than taking the value from another source such as a Document Picker, API Call Output, or Loop Item. It is used in actor configuration screens and the configuration panel, including places such as the Local Variable Actor and Update Record Actor, where administrators or developers choose how a variable or record field should be populated. Static Value matters because it provides a simple, explicit way to define constant data, default values, and direct field updates when no dynamic source is required, helping ensure predictable behaviour in workflow and record configuration.

Status ​

In the Autologyx platform, Status is the current state of a platform object and is used to show where that object is in its lifecycle and what actions are available to users and administrators. It is used in multiple contexts, including user accounts and tasks: for user accounts, Status is a key column in the Users list within Administration and indicates the account’s current condition, such as Pending, which also enables actions such as resending the activation email; for tasks, Status reflects progress against the task lifecycle and is directly affected by the Due Date, with a task automatically changing to Overdue when it passes its due date without being completed. Status matters because it helps end-users, Configuration admins, and Super Admins monitor work, manage accounts, identify exceptions, and configure or operate the platform with the correct next steps.

status column ​

In Autologyx, the status column is a field shown in the User List that displays each user account’s current activation state, such as Created, Pending, or Active. It is used by Super Admins and Configuration admins to filter, review, and manage users during account setup, especially when delayed account activation is enabled and an activation email has been issued but the account is not yet fully activated. This matters because it provides an immediate view of where each user is in the activation process, helping administrators identify accounts that still require action and navigate to the User details page with the right context for follow-up or support.

status field ​

In Autologyx, a status field is a field used to hold and display the current state of a record or action, such as a preset record status or the outcome of a document-generation step. It is used in configured document type fields and display forms, where administrators can make it read-only to preserve an initial value on record creation and allow updates only through controlled automation such as Sequencer, and where end-users can see status indicators such as successful document download. This matters because the status field provides a consistent, visible source of operational state, helps prevent manual changes that would undermine process control, and supports reliable user interaction with generated documents and workflow-driven updates.

Status header ​

The Status header is the column heading used in Autologyx list views to show the current state of an item, such as whether a standalone form is enabled. It is used on configuration lists alongside list display controls such as the column configuration function, allowing administrators to confirm item state directly from the grid without opening the record. This matters because it provides an immediate operational view of whether a configuration object is active and available for use, which supports accurate administration, validation of setup changes, and quick actions such as deciding when to copy a form URL for use.

Status section ​

The Status section is an area on the User details page in Autologyx that shows the current state of a user account as part of account setup and activation management. Introduced alongside delayed account activation, it is used by Configuration admins and Super Admins to view whether a user is in a state such as Created, Pending, or Active, complementing the status column in the User List with user-level detail. This matters because it gives administrators a clear place to check where a user is in the activation process, including whether an activation email has been sent and whether the account is fully active, helping them manage onboarding and troubleshoot account access efficiently.

Stop Sequences ​

Stop Sequences are a model configuration setting used with AI actors in the Autologyx platform, including the AWS Bedrock actor, to define the exact text patterns that cause the model to stop generating output. Configuration admins and developers use this setting when configuring an actor’s model behaviour alongside options such as Maximum Length, temperature, Top K, and Top P. This matters because it helps control response boundaries, prevents unwanted trailing content, and ensures generated text ends at the correct point for downstream workflow steps, integrations, and user-facing outputs.

sub process ​

In Autologyx, a sub process is a secondary workflow sequence that is started from within a main sequence to handle a distinct part of the overall process for the same object class. It is used in sequence configuration through the Sequence Runner actor, which can be placed at any point in a sequence to launch another sequence when additional workflow steps are required, such as country-specific compliance or sector-specific screening after common core checks are complete. This matters to Configuration Admins and Super Admins because it allows complex workflows to be broken into reusable, modular sequences, making process design easier to manage, maintain, and adapt without duplicating the full main sequence.

Submit button ​

The Submit button is the default form action control used in Autologyx standalone forms to create a record when a user completes and sends the form. In form configuration, it is enabled by default and can be disabled to remove the platform’s built-in Submit button from the form. This setting is used when configuring standalone forms, particularly where submission is instead handled by a hosting element that provides its own submit action or by an embedded third-party iframe. The Submit button only becomes available to end users after all mandatory fields have been completed, so it directly affects form usability, completion behaviour, and how record creation is triggered in the user experience.

success toast ​

A success toast, also referred to as a green success toast, is the transient on-screen confirmation message shown in the Autologyx platform after a user completes an action successfully. In the user group administration flow, it is displayed after Configuration Admins or Super Admins add users as members, confirming that the selected users have been added from the Membership tab when using controls such as Add as member. This message matters because it provides immediate visual feedback that the change has been applied, helping administrators verify membership updates as they work with member and non-member lists and filters.

success toast message ​

In Autologyx, a success toast message is the green on-screen notification that appears after a user completes an action successfully, such as saving an Object Class or updating record access by adding, removing, or changing Assignees and Owners. It is used in create and edit views, after confirmation actions, and in the Record access area to provide immediate feedback that the requested change has been applied. This message matters because it gives users and configuration admins a clear completion signal, helping them confirm that a save or access change has been processed before they continue working.

Summary ​

In Autologyx, Summary is the read-only information view for an object record that presents key details about the record without allowing edits. It is used in the workspace when viewing or editing object records, and also in side panels such as child object class components, where the summary of a direct child record is displayed for quick reference. The Summary view is configured on the object class Display tab and can be enabled or disabled as needed, making it important for configuration admins who control how record information is presented and for end-users who need immediate context while navigating records and related child items.

summary panel ​

In the Autologyx platform, the summary panel is a configurable user interface area used to present key information and interactive components for a record or workflow context. It is used within the application alongside landing pages, and supports placement of Elements so administrators can surface important data, actions, and content in a single, visible location for end users. The summary panel matters because it shapes how users review and interact with case or document-related information, and platform updates such as automatic refresh after document upload ensure the panel stays current and reliable during day-to-day work.

summary view ​

In Autologyx, the summary view is the object class display form that presents a record’s key information in the right-hand side panel when a user selects or opens a record from the records list or card view, and it is also used for child records through the Child record summary tab within a parent record. It is configured at object class level alongside the card view and create/edit view, and supports form-builder components such as fields, sections, properties, elements, and conditional visibility logic, with layout options specific to summary display. The summary view matters because it gives end users fast access to essential record data without opening each record in full, while giving configuration admins and super admins precise control over which information is surfaced in side panels and related record interactions.

Show 7 more pages

summary view display form ​

In Autologyx, the summary view display form is one of the form contexts in which an Element can be made available and configured. It is listed alongside the landing page, object class create/edit view display form, and standalone form as a supported location for Element use, and the Element configuration is the same across all of these contexts. For configuration administrators, this matters because when setting up an Element and its properties, the summary view display form determines that the Element can be shown within the platform’s summary view experience, enabling consistent presentation of configured fields across different pages and forms without requiring a separate configuration model.

Super admin account ​

A Super admin account is the highest-privilege account type in the Autologyx platform, intended for users who administer and configure the system. It is used throughout Administration, System Configuration, and Workspace areas to provide unrestricted access to platform capabilities, including creating and editing users and roles, editing user accounts, managing user groups and their permissions, accessing all Object classes, and viewing or configuring items such as sequences, task templates, task group templates, object records, and manual tasks. This account type matters because it gives complete cross-system access without requiring ownership of specific Object classes or group membership, making it essential for platform setup, governance, permission management, and ongoing operational administration.

Show 9 more pages

Super admin account type ​

In Autologyx, the Super admin account type is the highest-privilege user account type, intended for a very small number of trusted administrators who need platform-wide access across Administration, System configuration, and workspace functions. Super admins can create, edit, and delete user accounts, are the only users with access to Users and Roles by default, and automatically have all role-based permissions enabled; they also have full or unrestricted access to key configuration areas such as landing page, theme, outbound mail, elements, company details, single sign-on settings, relational modelling, object classes, permission sets, sequences, task templates, task group templates, authentication objects, user groups, records, tasks, and record access management. This account type matters because it controls who can perform the most sensitive setup, security, and governance actions in the platform, so assigning it sparingly is essential for protecting system integrity while ensuring critical administrative and configuration tasks can be completed.

Show 37 more pages

Super Admin type ​

Super Admin type is an Autologyx user account type that provides platform-wide administrative access, including the ability to create and edit Single Sign On settings and related SSO configurations. It is used in system configuration areas where authentication and integration options are managed, such as configuring the MS Word add-in, where access requires either a Super Admin account or a Standard account type with a role that includes Single Sign On create and edit permissions. This account type matters because it determines who can manage core authentication behaviour across the platform and who can configure features that depend on those authentication settings.

Super Admin user ​

A Super Admin user in the Autologyx platform is a user with full, unrestricted permissions across the environment. This role is used in platform administration and security-sensitive configuration tasks, and it defines the highest level of access against which other privileged identities are compared, including service accounts that can be granted equivalent permissions. In practice, the distinction matters because certain actions are reserved specifically to a Super Admin user, such as changing a service account’s password, making this role central to controlling privileged access, protecting administrative operations, and governing who can manage critical platform credentials and configuration.

Super admin User account ​

A Super admin User account is an Autologyx user account with the elevated permissions required to access and configure platform-wide features in system configuration. In the documented context, this account type is specifically required to configure the Landing page, including enabling the page, editing its layout and HTML content, managing sections and section headers, previewing changes, reverting updates, and working with related components such as Catalyst forms. This matters because only users with a Super admin account can make these administrative changes, so the correct account type is essential when setting up or maintaining shared user-facing configuration in the platform.

Super Admins ​

Super Admins are the highest-privilege user account type in Autologyx, with platform-wide access to all system resources, full list visibility across the platform including full user account details, and access to restricted administration and system configuration areas. They are used in Administration and System configuration to manage users, roles, elements, themes, landing pages, outbound mail setup, authentication objects, integrations, user groups, sequences, and document templates. This account type matters because it grants the authority to view, configure, and control core platform settings and shared assets that affect all users and processes, so it is intended for carefully controlled administrative use where complete oversight and unrestricted configuration access are required.

Show 7 more pages

supplementary conditions ​

In Autologyx, supplementary conditions are additional field-based criteria applied to a sequence trigger, actor configuration, or related-record lookup to restrict processing to records that meet specific business rules. They are used in configurations such as Sequence Runner actor setups and Relation Lookup patterns, alongside triggers like When Record Updated or When Sequence Activated, to target only the correct object class records or relational records—for example, requiring a field value such as Affordability check outcome = Escalate, or combining conditions such as Contract Type = PAYE and Contract Status = Current. Supplementary conditions matter because they refine when a sequence runs and which records it acts on, helping administrators prevent unwanted activations, exclude irrelevant or archived records, and ensure automation is executed only for the intended cases.

Support Ticket ​

A Support Ticket is the standard mechanism in the Autologyx platform for end-users, configuration admins, and Super Admins to request help from Autologyx Support when they need assistance with the platform. It is used from the Help and Support area, where users can create a ticket, understand what happens after submission, and review the related service levels and escalation process. Support Tickets matter because they provide the formal route for raising issues, tracking support requests, and ensuring that enquiries are handled in line with Autologyx support procedures and response commitments.

supported providers ​

In Autologyx, supported providers are the external services or systems for which the platform can store and reuse connection credentials through an Authentication object. This term is used when configuring authentication for API integrations, where an administrator or developer selects a provider in the Authentication menu and saves the required authentication details once for use across multiple API calls to that same provider. Supported providers matter because they define which third-party endpoints can be managed through Autologyx’s standard authentication framework, helping teams centralise credential management, simplify API call configuration, and maintain a single managed source of authentication details for each integrated service.

Sync group members ​

Sync group members is an object class field configuration option used on user or group selection fields in Autologyx to automatically expand a selected group into its individual user members. When this setting is enabled and an end user selects a group, the platform displays an additional model that synchronises the group’s membership into the field’s selected users, working alongside related options such as Allow Syncing Group Members, Allow Selecting Individual Members, and Class User Field. This matters because it controls how group-based selections are translated into actionable user records, which affects how assignees, participants, or other user-driven process data are populated and maintained in the platform.

sync icon ​

In Autologyx, the sync icon is the visual indicator shown in User Type Class field group selections to identify a user group that has been added with the sync option enabled. It appears in the group list when configuring or viewing fields that support groups in User type fields, distinguishing synced group-based membership from individually selected users, which are shown under their groups with checkmarks. This matters because it lets configuration admins and end-users immediately see that the field value is linked to the group as a synchronized selection, helping them understand how membership is being managed and how group-based selections differ from manual member selection.

System Administrators ​

System Administrators are the users with the administrative permissions required to configure and manage key platform capabilities in Autologyx. In practice, they are responsible for tasks such as adding rich text instructions in the form builder, controlling field configurations including User Type fields, and making admin-managed add-ins such as the Catalyst Word Add-in available to users. This role is used across configuration areas of the Autologyx Catalyst platform wherever setup, user management, and form behaviour are controlled. System Administrators matter because they define how forms, user selection, and managed integrations are presented and governed across the platform, ensuring users have access to the right tools and a consistent, controlled experience.

system areas ​

System areas are the parts of the Autologyx platform in which an Element is made available for users to access and use. When importing or configuring an Element in Administration > Elements, configuration administrators select the required system areas to control where that Element is exposed within the platform, then enable the Element to make it active. This setting matters because it determines the Element’s availability and scope, helping administrators ensure that each Element is presented only in the relevant areas of the Autologyx system for the intended user experience and configuration design.

System configuration ​

System configuration is the area of the Autologyx platform used to build and maintain a solution, defining how the system is structured and behaves to address a business problem. It is accessed from the main navigation menu and provides configuration pages and tiles for capabilities such as object classes, the relational modeller, task and task group templates, document templates, landing page and theme settings, and sequences. System configuration is distinct from Workspace, where end users complete day-to-day work, and from Administration, where global settings such as users, roles, authentication, and security are managed. Access to System configuration and its individual sections is controlled by account type, roles, and permissions, so it matters to configuration admins and super admins because it is the central place to design the data model, control available configuration features, and shape the user experience delivered in Autologyx.

Show 13 more pages

System configuration and Administration areas ​

System configuration and Administration areas are the parts of the Autologyx platform used to manage platform-level settings and administrative functions, and access to them is controlled by a user’s Role. These areas are relevant when creating or updating user accounts, because the Role set on the Edit user page determines whether a user can enter and use configuration and administration features. This matters to configuration admins and Super Admins because assigning the correct level of access is essential for controlling who can manage system setup, maintain administration options, and perform privileged platform tasks, while standard user access remains appropriately restricted.

System configuration tiles ​

System configuration tiles are the tile-based entry points on the System configuration page that represent the platform’s main configuration areas and provide direct access to the corresponding lists and management screens. Used primarily by Configuration admins and Super Admins, the tiles align with the links in the left-hand navigation and show at-a-glance counts of the instances in each area, with some tiles such as Sequences presenting multiple counts for different states. Tiles can also expose actions such as Create when the user has the required permissions. They matter because they organise administrative setup into clearly defined sections, help users understand what configuration items exist in the system, and provide a fast way to navigate, review workload, and manage platform configuration efficiently.

System Configurations → Integrations ​

System Configurations → Integrations is the dedicated administration area in the Autologyx platform for centrally managing the external services connected to Catalyst. Used by configuration administrators and Super Admins, this screen provides a single place to view available and active integrations, organise them by category, enable integrations for use in the platform, and request additional integrations as needed. It matters because it gives administrators clear control over how Catalyst connects with tools such as document management, eSignature, communication, and AI services, helping ensure those connected processes are configured consistently and operate from one central location.

System email configuration ​

System email configuration is the platform setting that designates which authentication object is used for outbound mail in Autologyx. It is shown on authentication objects, where the interface clearly indicates when an object powers the system’s email sending setup, helping configuration admins and Super Admins identify the active mail configuration at a glance. This matters because system emails depend on this designated object to send notifications and other platform-generated messages, and the visible in-use status supports safer administration by making the dependency clear when reviewing, updating, or protecting objects from deletion.

System emails ​

System emails are platform-generated emails sent by Autologyx to support core service functions and workflow operations, using configured SMTP credentials managed through system email configuration and related authentication objects. They are used wherever the platform needs to send automated communications, such as notifications and expiry messages, and their delivery depends on authentication objects that are actively referenced by the platform. System emails matter to configuration admins and Super Admins because these credentials are part of essential runtime infrastructure: deleting or misconfiguring the SMTP authentication that handles system emails can interrupt automated communications and affect business-critical processes, which is why Autologyx protects in-use credentials from deletion.

System fields ​

System fields are platform-provided fields that are available for display across all Autologyx object class views. In the Display tab when configuring an object class, administrators can include system fields in create and edit views, card views, and other display layouts alongside business-specific fields. These fields typically surface core record information managed by the platform, such as identifiers and timestamps, and they matter because they provide consistent, standard metadata that helps users recognise, track, and work with records throughout the application.

system forms ​

System forms are the built-in forms provided by the Autologyx platform where elements can be made available for use through an element’s Available Use settings. In administration, configuration admins and Super Admins use this setting when editing an element to control whether that element can be selected or used on platform-managed forms. This matters because it governs where configured elements are available across standard form experiences, helping administrators manage consistency, reuse, and control over form design within the platform.

System Migrations ​

System Migrations are the Autologyx process for promoting configuration between environments, such as from a development system to a live system. They are used by administrators and integrators when moving configured components into another system while preserving the target environment’s system-specific settings. In this context, Authentication Objects are mapped during a System Migration, but their existing configuration is not overwritten, so connected services such as DocuSign must be validated and reactivated in the destination environment before or after migration as required. This matters because migrations transfer solution structure and relationships, but environment-specific API details such as account identifiers, base URIs, and authentication configuration must remain correct in each target system for integrations to continue working.

system permission under the Sequencer tab ​

In Autologyx, the system permission under the Sequencer tab for Create—also referred to as the Sequencer Create permission—is a role-based system permission that controls whether a user can create new Sequences. It is used in role configuration and is enforced when a user works in the Sequencer area, including from the Sequences list and the Creating a Sequence workflow. This permission matters because creating a Sequence is not available through object ownership alone: a user must be a Super Admin, or have a role with the Sequencer Create permission enabled and be an Owner of the relevant Object class. Correctly configuring this permission ensures that only authorised users can add new Sequences within the platform.

System permissions ​

System permissions are the role-based settings in Autologyx that control access to core system configuration areas and actions across the platform. Defined when creating or editing a Role, they are organised by main system areas such as Data model and Task configuration, where administrators enable specific capabilities including create, edit, and access to features such as relational modelling, Object classes, and Task Group Templates. These permissions are used by Configuration admins and Super Admins to determine which system menus, configuration pages, and administrative functions a user can access, and they work alongside account type and other permissions to enforce platform governance. System permissions matter because they directly control who can view, create, and maintain key platform structures, ensuring administrative access is granted only where required for safe and effective system configuration.

task actor ​

A task actor is a sequence actor in the Autologyx platform that creates a task for the current record during sequence execution using a selected task template. It is used in workflow configuration by admins and developers when designing sequences in the Sequencer, where the sequence execution engine runs the actor and creates the task only if that task does not already exist for the record. Task actors are important because they provide a controlled, repeatable way to generate work items as part of automation, trigger related events such as Task created and Task completed for downstream conditions or process logic, and enforce configuration integrity by halting execution if no task template has been selected.

task assignees ​

Task assignees are the users or User Groups designated to work on a task in Autologyx. They are configured when creating or updating tasks, including through the Task Assignment actor, manual task creation, and sequence defaults, with options to append to or override default task assignees. A task can be assigned to individual users, groups, or both, and any assigned user can complete the task alongside the Task Owner. Task assignees are also used in the Workspace Tasks list, where being an assignee determines task visibility and completion access unless broader task permissions have been granted. This matters because task assignees control who receives operational responsibility for a task, how work is routed across individuals or teams, and which users can see and act on tasks in the platform.

Show 1 more pages

Task Assignment actor ​

The Task Assignment actor is a Sequencer actor used in Autologyx to set who will own a task and who will be assigned to it before a Create Task actor or Set Task actor runs. Configuration admins and Super Admins use it in sequence design to select a task owner from users or User type fields and to define task assignees, with options to override or append default assignees configured for the sequence. It is commonly placed immediately before Create Task or Set Task because tasks have no assignees by default unless assignment has been configured, making this actor a key control for directing work to the correct users or groups and for ensuring accountability, routing accuracy, and efficient task management within automated workflows.

Show 3 more pages

Task Assignment Configuration window ​

INSUFFICIENT_EVIDENCE

Task Card ​

INSUFFICIENT_EVIDENCE

Task completed event ​

A Task completed event is an Autologyx platform event emitted when a task actor finishes a task, and is used within workflow automation and integration contexts to signal that task execution has reached completion. It is used alongside related events such as Task created in actor-driven processes, including configurations built with the Create task actor and the sequence execution engine, where downstream logic, integrations, monitoring, and audit reporting depend on task lifecycle changes. This event matters because it gives configuration administrators, developers, and compliance or analytics teams a clear completion point that can be consumed to drive subsequent workflow steps, capture operational insight, and maintain traceability across automated processes.

Task completion pages ​

Task completion pages are the pages presented at the end of a task in the Autologyx platform where end-users review and complete the final required information before finishing that task. In this context, they are a key location where platform components such as the Viewer panel are available; for example, the Viewer panel opens on Task completion pages to let users access and view saved documents attached to fields while completing the task. This matters because Task completion pages bring together the final user actions, record updates, and document review needed to complete work accurately and efficiently within a workflow.

Task completion screen ​

The Task completion screen, also called the completion view, is the interface an end-user sees when working on a Manual Task in Autologyx. It presents the task details needed to complete the work, including the Task properties and the Instructions that were entered when the task was created, so the assignee can follow the defined guidance while updating the task outcome. This screen is used after a task has been added to an object record and complements the Create task screen, where administrators or users configure the task’s fields. It matters because it is the point at which task configuration becomes actionable: the information defined during setup is surfaced directly to the person completing the task, helping ensure the task is performed consistently and with the intended context.

Task configuration ​

Task configuration is the roles-and-permissions area in Autologyx that controls a user’s access to task design assets, specifically Task Templates and Task Group Templates. It is used when creating or editing roles in Administration, where Configuration admins and Super Admins can enable Create and Edit permissions for each template type. These settings determine whether users can open the template lists, create new templates, edit existing templates, and see actions such as the Create option in the interface. Task configuration matters because it governs who can define and maintain the reusable task structures that support process setup and operational consistency across the platform.

Task configuration tab ​

The Task configuration tab is the area in Autologyx system permissions where administrators control role-based access to task design features, specifically permissions for creating, viewing, and editing Task Templates and Task Group Templates. It is used when configuring Roles so that Configuration admins and Super Admins can grant or restrict access to the task template and task group template lists and the actions available within them, such as create and edit. This matters because access to task configuration is governed through this tab: without the relevant permissions enabled, users cannot open the related lists or manage the templates that define how tasks and grouped tasks are set up in the platform.

Show 1 more pages

Task counter ​

INSUFFICIENT_EVIDENCE

Task created event ​

In Autologyx, a Task created event is the platform event raised when a task actor creates a task in a workflow. It is used in workflow automation and integration scenarios where events from task actors are monitored or consumed, alongside related events such as Task completed, to track task lifecycle activity. This event matters because it provides a reliable trigger point for downstream processing, reporting, compliance monitoring, and analytics, helping administrators and integrators understand when work items are generated and enabling automated actions that depend on task creation.

Task creation mechanism ​

Task creation mechanism is a Task template setting in Autologyx that determines how tasks generated from that template are created: Automatic for tasks launched by a Sequence, or Manual for tasks created by a user against an object record from the Tasks tab in the side panel. It is configured when creating or editing a task template and is shown in task template lists and filters, where it can be used to distinguish template availability. This setting matters because it directly controls where a template can be selected and used across the platform: Automatic templates are available in the Sequence designer and task group templates, while Manual templates are available in the standard user interface for record-level task creation, including assignment scenarios such as 1-time completion users. It therefore governs how work enters the system and ensures each template is exposed in the correct configuration and runtime context.

Show 9 more pages

Task creation mechanism Automatic ​

Task creation mechanism Automatic is the task configuration setting in Autologyx that identifies a task as eligible for automated instantiation rather than manual addition. It is used in task setup and directly controls whether a task can be included in a Task Group Template: only tasks configured with the Automatic creation mechanism can be added to a template. This matters to Configuration Admins and Super Admins because Task Group Templates depend on this setting to define reusable groups of tasks that the platform can create consistently as part of configured processes.

task delegation ​

INSUFFICIENT_EVIDENCE

task delete options ​

  • Mostly relevant to: Configuration admins
  • Closely related concepts: actors, Sequencer

Task delete options are the configuration settings in the Set Task actor that control which existing tasks are removed when a workflow updates or manages task records in Autologyx. In the platform, these options are used when configuring task behavior in a workflow or Sequencer step, and they let administrators choose whether to clean up outstanding tasks, completed tasks, or only the latest task. This matters because task delete options determine how task history and active work items are maintained, helping configuration admins prevent duplicate or obsolete tasks, keep task lists accurate, and ensure the workflow presents the correct actions to the right actors at the right time.

Task details ​

Task details is the section and view in Autologyx where the core information for a task is shown and maintained. It is used both when creating a manual task—where the Create Task panel is divided into Task details, Assignment of stages, and Instructions—and when viewing an individual task, where assignee information such as selected groups is displayed alongside the task record. This matters because Task details holds the primary task-specific data that users rely on to understand the task and that configuration and operational users use to confirm the correct task setup, ownership, and context within the wider workflow.

Task Expiry ​

INSUFFICIENT_EVIDENCE

Task Form Fields ​

Task Form Fields are the field components used specifically on task forms in the Autologyx Form Builder, where administrators configure the data that users must enter, view, or update while completing a task. They are managed within the Formbuilder Components area alongside related configuration options such as properties, elements, layout sections, and conditional logic, and are used to define the structure, behaviour, and presentation of task-specific inputs. Task Form Fields matter because they control how task information is captured and validated in workflow execution, directly affecting user experience, data quality, and the correctness of task completion within a process.

task forms ​

Task forms are the end-user forms presented when a task is created from a task template in Autologyx, and they are used to capture information, guide completion, and submit task-specific inputs as part of a workflow. They appear when users open an assigned task, including through direct links for 1-time completion users, and can display additional instructions, field descriptions, required fields, labels, and configured components such as text, date/time, checkbox, and Markdown-enabled content. Task forms matter because they are the primary interface through which task work is completed and data is collected, so their design directly affects usability, completion accuracy, and whether the right information is captured at the right stage of an application or sequence.

Show 1 more pages

Task Group State ​

Task Group State is a sequence commencement condition attribute in Autologyx that lets administrators evaluate the current lifecycle status of a Task Group for a Record when configuring how a sequence starts. It is used in System Configuration when adding conditions for Sequence commencement, where the available Task Group State values are Not assigned, Not started, In progress, and Completed. This matters because it allows Configuration Admins and Super Admins to route Records through different sequence paths according to the progress of grouped work, ensuring the correct next item in a sequence is triggered only when the relevant Task Group is at the required stage.

Task group template list ​

The Task group template list is the configuration page in Autologyx where Task Group Templates are managed. It is used by configuration administrators and Super Admins to create and edit task group templates, and to view them in a sortable or filterable list that can include columns such as Object Classes. This list is accessed as part of task configuration and is controlled by the relevant system permissions under the Task configuration tab, together with access to the applicable Object class. It matters because it is the central workspace for maintaining reusable task group definitions, helping administrators organise templates efficiently and manage them at scale as the number of configured task group templates grows.

Task group template name ​

Task group template name is the identifying name of a task group template in Autologyx, used when configuring Sequence commencement conditions to search for and select the specific task group template that should drive how a Sequence starts or what the next item in the Sequence is. It appears in the template selection search bar during sequence configuration, where administrators enter the name to quickly locate the required template. This matters because accurate selection of the task group template ensures the correct sequence logic, commencement behaviour, and progression between sequence items are applied in the configured process.

Task Group Templates ​

Task Group Templates are reusable configuration items in Autologyx that group multiple Task Templates so they can be managed and triggered together, most commonly within a Sequence to create several tasks at once for an Object record. They are configured in System Configuration from the Task Group Templates list, where admins can create, edit, and review templates, and they are also surfaced in related areas such as Sequences, Object Classes, and list pages that show which task groups are associated with a workflow or data model. Task Group Templates matter because they standardise repeatable sets of work, speed up workflow design, and help ensure the right tasks are created consistently for the correct Object class; where Task Templates of the Update object record type are included, the task group is constrained to the relevant Object class.

Show 6 more pages

task groups ​

In the Autologyx platform, a task group is a named collection of related tasks that can be referenced in Sequence configuration to control process flow at a higher level than individual tasks. Task groups are used in trigger parameters and Sequence commencement conditions, where administrators can select a specific task group template and evaluate or set its state as part of routing logic for Records. This is important for Configuration Admins and Super Admins because task groups provide a structured way to drive different routes for subsets of Records, coordinate the next item in the Sequence, and build milestone- or state-based automation without configuring each task independently.

Task ID ​

Task ID is the unique identifier assigned to a Task in Autologyx when that Task is created from a Task template for an Object record. It is used to distinguish the individual Task instance from the template it was created from, and is typically encountered anywhere users, administrators, or integrations need to reference a specific Task rather than the reusable template definition. This matters because Task IDs provide the precise handle for tracking, managing, and linking to the correct Task record within the platform, especially when multiple Tasks are created from the same Task template for different Object records.

A task link is the direct URL included in an Autologyx email notification that opens a specific task for the recipient to complete, most notably in Catalyst workflows for 1 time completion users. It is used in task-related emails to take the user straight to the assigned work without requiring a broader navigation path, making it a key part of the end-user completion experience and an important consideration for administrators configuring task assignment and external user interactions. The task link remains active until the task is completed when no due date is set, and it becomes invalid if the task is overdue, already completed, completed by another user, reassigned, or deleted, so understanding its behaviour is essential when managing notifications, due dates, and access to task completion.

Task Lists ​

Task Lists are the Autologyx platform views that present a user’s available and assigned tasks, showing key task details such as assignees and updating task activity within the Catalyst UI. They are used by end-users to monitor and action work from the Landing Page, Task List, and Task Panel, and they are affected by configuration choices such as assigning tasks to groups, where selected groups are displayed as assignees in both the task list and individual task details. Task Lists also support real-time updates using WebSockets, ensuring users see workflow changes as they happen without needing to refresh manually. This matters because Task Lists are a primary operational workspace for processing work efficiently and for verifying that task routing, assignee visibility, and workflow updates are functioning as configured.

Task Management ​

Task Management is the System Configuration area in Autologyx where administrators create and manage the task data model and the sequences that drive task-centric work, providing the landing page for configuring how tasks are structured, related, and processed within the platform. It is used alongside Sequences, Sequence Actors, Task Templates, Task Group Templates, object classes, object class relationships, and relational modelling to define task behaviour, connect tasks to related records, and support document generation, variables, integrations, APIs, and advanced automation such as ML and AI Actors. This matters because Task Management establishes the configuration foundation for how task records are created, linked, automated, and presented in operational workflows, ensuring that task-driven processes are consistent, scalable, and aligned with the organisation’s broader Autologyx data model.

Task Owner ​

Task Owner is the single user designated to own a task in Autologyx. It is configured in the Task Assignment actor, typically before a Create Task or Set Task actor, where administrators can set ownership to the Record owner, select the owner By users, or derive the owner By field from a User type field; only one Task Owner can be assigned, and By users and By field cannot be used together for the same ownership setting. The Task Owner is used alongside task assignees, and either the Task Owner or any task assignee can complete the task. This matters because task ownership controls who is identified as the primary owner of the work item and is a key part of configuring task routing and responsibility in a workflow.

Task ownership and assignment ​

Task ownership and assignment is the Autologyx capability for selecting the user or user group responsible for a task, and it is used anywhere the platform presents user or group pickers for assigning work, including task assignment interfaces and related configuration such as default task assignees in Sequences. In practice, who can be seen and selected in these fields is controlled by Users and Groups visibility and list permissions, which govern whether users can list group members or groups in assignment controls, dropdown autocompletes, and filters; users can always list themselves. This matters because task ownership drives who is responsible for completing work and directly affects whether end-users, configuration admins, and Super Admins can find and assign the correct people or groups when operating or configuring the platform.

Task Panel ​

The Task Panel is the Workspace area in Autologyx where users open, review, action, complete, and manage work that has been assigned through tasks. It is used alongside the Landing Page, Task List, Records, and related-record views as part of day-to-day operational working, and it provides the detailed task context needed to progress assigned work, including functions such as viewing task content and re-assigning tasks. The Task Panel matters because it is the main place where task-based users carry out manual work within a process, and it is also important for configuration and operational teams because task design, routing, and reassignment directly affect how work is presented and completed there.

:::

Task properties ​

Task properties are the task details shown to a user on the Task completion screen in Autologyx, providing the key information configured when the task was created. In the context of Manual Tasks, this section displays items such as the Instructions entered on the Create task screen, so the person completing the task can see the guidance and context they need without returning to the task setup. Task properties matter because they present the configured task information at the point of action, helping end users understand what is required and complete the task correctly for the selected object record.

Task response page ​

The Task response page is the workspace page that opens when a user selects Complete for an incomplete task from the Tasks list. It is used by the task assignee, or by users with the Tasks Complete any tasks permission, to enter or edit the response required to complete the task within the main content area. This page matters because it is the point where task completion is recorded in the platform, enabling users to provide the required outcome for a task and progress work directly from the task list.

Task responses ​

  • Mostly relevant to: Configuration admins, Developers / Integrators
  • Closely related concepts: Alias, JSON

Task responses are the structured data payload produced when a user completes or updates a Task in Autologyx, capturing the values entered into the Task form. In Task templates, any field that is not linked to an Object class field uses its configured Alias as the key in the Task response, which makes aliases critical for defining the response structure and for integrating task data with downstream processing, APIs, or custom logic. This term is used when configuring Task form fields and designing how task-captured information is identified, stored, and consumed across the platform.

Task status ​

Task status (shown as Status in sequence commencement conditions) is the task-level attribute on a Record that represents the current lifecycle state of a specific task, such as Not created, Outstanding, Overdue, or Completed. In Autologyx, configuration admins use Task status when defining sequence commencement conditions to control whether the next item in a sequence starts, based on the status of a task for that record. It is used alongside other task attributes such as Created, Creation Date, Completed, Completion Date, and Expiry Date when building automation rules. Task status matters because it lets you drive sequence progression from real task outcomes and deadlines, ensuring records advance only when the required task state has been reached.

task statuses ​

Task tab ​

In the Autologyx platform, the Task tab is the section in a Record’s sidebar where users view and assign tasks associated with that specific Record. It is used during manual task creation, including when assigning a new manual task to a 1 time completion user, and forms part of the record-level task management experience. The Task tab matters because it is the entry point for creating and managing work items in the context of an individual Record, ensuring tasks are linked to the correct case or process instance and routed to the intended user.

Task template ID ​

Task template ID is the unique numeric identifier assigned to a Task template when it is created in Autologyx. It is used in the Task templates area, including the default ID column on the Task configuration tab, to distinguish one template from another during administration and configuration. This identifier is specific to the template itself and must not be confused with a Task ID, which is assigned only when an individual Task is created from that template for an object record. For configuration admins and Super Admins, the Task template ID matters because it provides a stable way to identify, review, and manage templates alongside related details such as task creation mechanism, last task created, and the number of tasks created from the template.

task template names ​

Task template names are the labels assigned to task templates in Autologyx and are used throughout platform configuration to identify the specific task definition being referenced. They are especially visible in administrative setup areas such as set task actor configuration, where administrators select or review the task template to which actor rules apply. Task template names matter because they provide the primary human-readable identifier for task templates during configuration and maintenance, and overly long names can affect usability in configuration screens by making referenced templates harder to read and manage.

Task template self contained form ​

A Task template self contained form is a task form configuration type in the Autologyx platform that is built directly in the formbuilder for a task template and uses the Layout and Fields sections of the side panel, without Object Class Fields, Properties, Child Object Classes, or Elements. It is used by configuration admins when designing a self-contained task experience on the canvas, where components are dragged and dropped into form sections to define the structure and the fields presented to users. This matters because it distinguishes task forms that are defined entirely within the task template from configurations that depend on object record structures or additional formbuilder panels, helping admins choose the correct form design approach for the task they are configuring.

Task template update object record ​

Task template update object record is a Formbuilder configuration context in Autologyx used when designing the form for a task template that updates an existing object record. In this context, the Formbuilder side panel provides the Layout, Fields, and Object Class Fields sections, and components from those sections can be dragged onto the canvas to define the task’s user interface; the Properties, Child Object Classes, and Elements sections are not available. This matters to Configuration Admins and Super Admins because it defines the specific form-design capabilities and constraints for update-record tasks, ensuring the task captures and edits the correct object data within the object model.

Task templates ​

Task templates are reusable task definitions in Autologyx that control how a task is created, what form or record fields the assignee sees, and how the task behaves when used in a workflow. They are configured in System Configuration under Task Templates, built with Formbuilder, and used either manually from a record when the Task creation mechanism is set to Manual or automatically in the Sequencer through Create Task and Set Task actors when the mechanism is Automatic. Task templates support different task types, including self contained forms and Update object record tasks tied to a specific Object class, and they are also surfaced in related areas such as task group templates, record task creation, sequences, and task lists. They matter because they are the core building block for collecting data, updating object records, assigning work to the right users, and standardising task-driven processes across an application, with access to create and edit them controlled through roles and permissions.

Show 41 more pages

Task Templates Create ​

Task Templates Create is a role-based permission in Autologyx that controls whether a user can create task templates in system configuration. It is used under the Task configuration tab of a role and is relevant to configuration administrators and Super Admins who define how tasks are generated in the platform. This permission is required for creating task templates for Complete self contained form tasks and, for Update object record task templates, it must be combined with ownership of the relevant Object class. It matters because task templates are the source from which tasks are created, so enabling Task Templates Create determines who can design and maintain the templates that drive task creation and operational workflows.

Task templates list ​

The Task templates list is the system configuration list in Autologyx where task templates are created, viewed, and edited. It is used by Super Admins and by users whose role includes Task Templates create or edit permissions in the Task configuration tab, and it provides the standard list features used elsewhere in the platform together with default columns such as the template ID. This list is important because task templates define how a task is presented to the assigned user, what instructions it contains, what response type is required, and whether the task is one-time or renews on expiry, making the Task templates list the central place for configuring the structure and behaviour of tasks across the platform.

Task Templates menu ​

The Task Templates menu is the part of the Sequence designer where configuration admins select reusable task templates to add automated tasks into a sequence. It is populated only with task templates whose Task creation mechanism is set to Automatic, and the templates shown depend on the task type and object-class configuration: for example, Complete self contained form templates are available for all object classes, while Update object record templates are available only for the object class defined on the template’s Response configuration tab. This menu matters because it controls which preconfigured task behaviours can be inserted into a sequence, ensuring designers can use only the task templates that are valid for the sequence context and target object class.

Task Templates permissions ​

Task Templates permissions are system permissions in the Task configuration tab that control whether a user can create and edit Task templates or edit existing templates only. In Autologyx, Task templates are the blueprint used to create Tasks for Object records, so these permissions are primarily relevant to Configuration admins and Super Admins who configure how Manual Tasks are generated and maintained. This matters because the permission level determines who can define new task creation mechanisms, update template settings, and manage the reusable task definitions that drive consistent task creation across the platform.

Task tile ​

In Autologyx, a Task tile (or tile) is the visual representation of a task on the Tasks tab. It is used in the workspace task panel to display tasks, including manual tasks created for an object record, as individual items that users can identify and open from the task list. Task tiles matter because they are the primary way end users see and access created tasks in the interface, linking task creation actions to the operational view where work is tracked and performed.

Task type ​

Task type is the setting on an Autologyx Task template that defines the fundamental kind of task being created and how its response is configured. In Task template configuration, administrators select the Task type in the Task Definition section and then configure the task accordingly on the Response Configuration tab. Autologyx provides two Task types: Complete self contained form, which uses fields independent of any Object class and can therefore be used for records in any Object class, and Update object record, which is tied to a specific Object class and allows the task to update fields on that record when completed. Task type is important because it controls what the task can do, which fields and object data are available during configuration, how the task is presented to users, how it can be filtered in list pages, and, once set on a template, it cannot be changed.

Show 3 more pages

Tasks ​

Tasks are actionable work items in Autologyx Workspace, created for a record from task templates and used to assign, track, and complete operational steps in a process. They are surfaced in the Workspace Tasks area and Tasks list, where users can view task details, status, due date, completion information, related record, task type, and template, and open tasks they are permitted to access. Tasks matter because they are a core unit of day-to-day work for end users and a key configuration touchpoint for administrators: permissions control who can view or act on tasks, object classes define who can interact with associated records and tasks, and sequences can evaluate task attributes such as created, completed, completion date, expiry date, and status to drive automation and workflow progression.

Show 5 more pages

tasks associated with it ​

In Autologyx, tasks associated with an Object class are the workflow tasks linked to records of that class, and they are configured from the Object class Permissions area alongside permissions for the Object class itself and its records. This setting is used by Configuration Admins and Super Admins when defining permission sets, so they can control not only who can create or edit records, but also who can access and work with the tasks generated or managed in relation to those records. It matters because task permissions are a distinct part of Object class security, helping ensure that the right users can act on workflow activity connected to that class while maintaining appropriate operational control.

Tasks associated with the records ​

Tasks associated with the records are the task items linked to specific Object records in Autologyx and are controlled through the additional permission sets configured on an Object class. In the Edit Object class permission settings, administrators can grant or change permissions that apply not only to the Object class itself and its records, but also to the related tasks, including permissions such as Assign all. This matters because task-level permissions determine what users can do with the work items created against records, so Configuration admins and Super Admins must configure them carefully to ensure users can manage record-related work appropriately without granting excessive access.

Tasks Complete any tasks ​

Tasks Complete any tasks is an Autologyx permission that allows a user to complete tasks even when they are not the assigned task assignee. It is used in the Tasks list, where the Complete option is shown for incomplete tasks such as outstanding or overdue items if the user is either the assignee or has this permission enabled. When selected, Autologyx opens the Task response page in the main content area so the task can be completed. This permission matters because it controls who can act on unassigned or others’ tasks, supporting operational continuity and flexible workload handling while maintaining role-based access through the relevant permission set configuration.

Tasks created ​

Tasks created is a column available in the Task templates list in System Configuration that shows the total number of Tasks generated from a specific Task template. It is used by Configuration admins and Super Admins when reviewing template usage, alongside related fields such as Last task created, to understand how actively a template is being used in the platform. This matters because it helps administrators monitor template adoption, validate that task creation is occurring as expected, and support configuration decisions such as maintaining, updating, or retiring task templates.

Tasks For One Time Completion Users ​

INSUFFICIENT_EVIDENCE

Tasks I'm Only an Assignee Of ​

“Tasks I’m Only an Assignee Of” is a task list filter in the Autologyx platform that shows tasks where you are assigned to the task but are not the sole focus of broader assignment filtering, helping you isolate work items that include you specifically as an assignee. It is used in Task Lists alongside other task filters and continues to operate independently of newer group-based task assignment searches, which let users find tasks assigned to particular User Groups. This filter matters because it gives end users a quick way to narrow busy task views to the items they are directly responsible for, improving personal workload visibility and making it easier to find and act on relevant tasks in environments that use both individual and group task assignment.

Tasks list ​

The Tasks list is the Workspace view that displays the tasks assigned to a user in Autologyx, providing a central place to browse, identify, and open task items and the records they belong to. It is used by end-users in the Tasks area of the Workspace and is affected by platform configuration such as object class permissions, task assignment, and column configuration. From the Tasks list, users can use the Actions menu to view related records or work with tasks, while administrators can control whether users see any tasks at all through permission sets and assignee settings. The Tasks list matters because it is a primary operational view for managing assigned work, and its visibility, content, and usability directly determine how efficiently users can find, understand, and act on tasks in the platform.

Tasks panel ​

The Tasks panel, also shown as Tasks, is the record-level panel in Autologyx used to view and create tasks associated with a specific record. It is used by end-users to work with ad hoc manual tasks and by configuration admins when designing how tasks will be made available from task templates. Manual tasks are created from the Tasks panel for a record as needed, and the users who can complete them are defined when the task is created; completion is then controlled by role, ownership, object class permissions, or task assignment. The panel also displays record context at the top, including the field marked as the Identifier, alongside related record panels such as Templates, Activity log, and Record access. This matters because the Tasks panel is the main place where record-specific work is initiated, assigned, and completed, linking task execution to the correct record and access model in the platform.

Tasks tab ​

The Tasks tab is the section of an Object record’s side panel where users view existing tasks and create manual tasks for that record. In Autologyx, it is used at runtime by end-users to open the task list, select Create task, complete the task creation screen, and then see the new task displayed as a tile on the record. It is also relevant to configuration admins because task templates with the Task creation mechanism set to Manual determine which tasks are available from this tab, either for any record in any Object class or for records in a specified Object class. The Tasks tab matters because it is the main record-level entry point for manually initiating work from configured task templates and managing tasks in the context of a specific object record.

Tasks View all ​

Tasks View all is an Object class Permission set option in the Autologyx platform that grants a user access to the Tasks list page so they can view Tasks beyond those assigned directly to them. It is used when configuring Object class permissions for users who need broader operational visibility, alongside other access routes such as Super Admin, Object class owner, Record Owner, or Task Assignee. This permission matters because it controls whether users can open the central Tasks list and work with Task records across an Object class, making it essential for administrators who need to manage oversight, support teams, or configure role-based access to task activity.

Tasks View any tasks ​

Tasks View any tasks is a platform permission that allows a user to open and view incomplete tasks in the Tasks list even when they are not assigned to those tasks. It is used in the workspace Tasks list, where users can double-click a task to access its details; with this permission enabled, the View action is available for outstanding or overdue tasks outside the user’s own assignments, while completed tasks can also be viewed according to task status. This permission matters when configuring access for administrators and operational users because it extends task visibility beyond task assignees, enabling broader oversight, monitoring, and support across active work.

Tasks/View all permission ​

Tasks/View all permission is a permission-set entitlement in the Autologyx platform that allows a user to see manual tasks beyond those directly assigned to them. It is used in task visibility control for manual tasks created from the Create task screen against an object record, where it extends access to tasks that are otherwise visible only to the users selected in the Complete field, Super Admins, or the owner of the object class containing the record. This permission matters because it determines who can access and work with task information across records, making it an important configuration for administrators who need broader operational oversight while preserving controlled task visibility for end-users.

temperature ​

Temperature is an AI model parameter in Autologyx that controls how random or deterministic generated responses are. It is used when configuring supported AI engines and actors, including AWS Bedrock and Azure OpenAI integrations, and in Sequencer where users can set model parameters such as temperature alongside options like max tokens and authentication. Lower temperature values produce more precise, consistent, and predictable outputs, while higher values produce more varied and diverse outputs. This setting matters because it lets configuration admins, developers, and end-users tune AI behaviour to match the task, balancing consistency for structured automation against creativity for more open-ended content generation.

Template areas ​

Template areas are the document-template storage locations configured on an Object class in Autologyx, used to upload and maintain frequently used documents that belong to that class. Configuration administrators use Template areas when setting up applications so that standard documents are available in the correct object context, alongside the relevant object class fields and merge fields used to populate them. This matters because it centralises reusable templates at the object-class level, helping ensure records use the right standard documents consistently and supporting efficient document generation across the platform.

Template field ​

A Template field is a configuration field in Autologyx actors that lets an administrator select the template source or specific document template an actor will use. It is used in places such as the DocAuto actor, where it lists the document templates available for the current Object class so the selected template can be generated, and in the API Call actor, where it can be set to a source such as iManage alongside the required authentication configuration. This field matters because it controls which template-driven content or integration the actor operates against, directly affecting document generation behaviour, downstream document handling, and the correct setup of automated process steps.

Template File Name ​

Template File Name is the document templates list field that shows the name of the uploaded Microsoft Word template file in .docx format for each document template in Autologyx. It is used in document template administration as a fixed column in the Document templates list and identifies the source file associated with the template configuration. This matters because configuration admins use it to confirm they are working with the correct uploaded template file, while end-users and administrators can use it to distinguish between templates with similar business purposes and support accurate document setup, maintenance, and manual or automated document generation.

Template Merge Fields ​

templates ​

Templates in Autologyx are configurable structures used to define how dynamic content or external interactions are generated and executed across the platform. They are used in areas such as API Call Actor configuration, where the selected template determines the type of API call setup, and in any feature that renders merge fields, such as inserting record properties like {{ record.id }} into requests or other generated content. Templates matter because they provide the reusable framework that connects records, tasks, and integrations, allowing configuration admins and developers to standardise behaviour, inject runtime data, and control how information is assembled and passed through workflows.

Templates panel ​

The Templates panel is an Autologyx record-level sidebar panel that displays document automation templates for the current record and lets users generate customized documents directly from predefined templates. Introduced in Autologyx Catalyst 1.5, it is used alongside other record panels such as Tasks, Activity log, and Record access, with the record identifier shown at the top to confirm the active context. For end-users, the Templates panel provides a fast, consistent way to create documents without manually entering data or formatting content; for configuration admins, its value depends on ensuring the relevant templates and supporting object class data are available so the correct templates can be surfaced for the selected record. It matters because it streamlines document creation and record-based document management, reducing manual effort and improving consistency across generated documents.

Templates tab ​

The Templates tab is the section of a record’s side panel in Autologyx where users access templates that have been configured for manual use on that record’s object class. It is used to generate documents directly from document templates, and it can also expose manually available task templates, with the items shown there determined by template configuration and object class setup. The Templates tab matters because it is the primary record-level entry point for manually producing template-driven outputs outside a sequence, and its behaviour is governed by record permissions and class permissions, which control actions such as generating, downloading, and filing documents on the record.

Templates tab in the side panel ​

The Templates tab in the side panel is the record-level area in Autologyx where users can access document templates that have been configured for manual generation against that specific record. It is used during case or record work to create documents directly from eligible templates without leaving the current context, and it is populated only by document templates that have been set up to allow manual generation. This matters to end-users because it provides a direct, in-context way to generate required documents as part of operational work, and it matters to configuration admins because enabling manual generation on a document template determines whether that template is available from the Templates tab in the side panel.

templating language ​

The templating language is Autologyx’s platform-wide syntax for inserting dynamic content and logic into configurable assets, providing a consistent way to define values, expressions, and reusable text across workflow components. It is used in document automation templates and in the Sequencer, where administrators, end-users, and integrators configure templates and steps that need data-driven output or behavior. This matters because it standardises how dynamic content is authored across the platform, reducing inconsistency between document generation and workflow orchestration and making template-based automation easier to build, maintain, and understand.

Tenant ​

In the Autologyx platform, a Tenant is the directory tenant identifier for the Microsoft Entra ID or Azure Active Directory instance that an Authentication Object targets when requesting permission through Microsoft OAuth 2.0 client credentials. It is used when configuring Microsoft integration settings alongside values such as Client ID, Client Secret, and Scope, and it tells Autologyx which organisation directory to authenticate against. This matters to configuration administrators and integrators because the correct Tenant ensures authentication requests are sent to the intended Microsoft directory, enabling successful token retrieval and secure access to the connected Microsoft resources.

Tenant ID ​

INSUFFICIENT_EVIDENCE

terminal actor ​

In the Autologyx platform, a terminal actor is an actor type that ends execution flow within a sequence because it cannot trigger any later actor. This classification is used in sequence design and actor configuration, including the Sequence Runner actor, which is explicitly defined as terminal. For Configuration Admins and Super Admins, understanding whether an actor is terminal is important when building or maintaining sequence logic, because it determines how process steps can be chained and prevents attempts to place downstream actors after an endpoint in the sequence.

Tertiary colour ​

In Autologyx, the tertiary colour is a theme setting used on the Configure Theme page to define the colour applied to the Save and Complete buttons. It is configured by Super Admins and configuration admins as part of the platform’s colour controls, alongside the primary, secondary, core, and additional colour settings on the Colours tab. This setting matters because it directly affects the visibility and consistency of key action buttons in the user interface, helping ensure that important completion and save actions align with the organisation’s theme and remain clear to users.

Test authentication object ​

Test authentication object is the validation action used when creating or editing an Authentication object in Autologyx Administration to confirm that the configured connection details and required fields are complete and accepted before the object is saved for use. It is available on the Authentication object configuration screen, where the button remains disabled until all mandatory fields have been completed without error, and a successful test returns the message “Authentication success!”. This matters to Configuration admins and Super Admins because it provides an immediate check that an integration-specific authentication setup, such as for DocuSign, is correctly configured and ready to be used by the platform.

Test Call ​

In Autologyx, a Test Call is the manual execution of an API Call Actor from its configuration panel to validate the current request setup before the actor is used in a Sequence. It runs the API request against the selected Record and any files specified for testing, and returns an error if the Record ID is invalid. A Test Call is used during API Call Actor setup and debugging, and it is a required step before the API Call can be used in a sequence. This matters to configuration admins and developers because it lets them confirm request configuration and test inputs safely without triggering downstream Actor Completed actions in the Sequence.

Test Email ​

In Autologyx, Test Email is a function within the Send Message Actor configuration that sends a trial version of an email so administrators can verify the message before it is used in a live workflow. It is used when configuring outbound email in sequence actors, specifically to confirm that merge fields resolve correctly and that any links included in the message work as expected. This matters because it allows configuration admins to validate email actor setup, catch formatting or content issues early, and ensure automated communications behave correctly when the sequence runs.

Test mail settings ​

Test mail settings is the control in Autologyx outbound mail configuration that validates the email connection details you have entered before the platform uses them to send messages. It is used in Administration when configuring the mail service, including Microsoft Client Credentials and Microsoft Office 365 Exchange (Graph) with OAuth 2.0 setups, and checks that the supplied credentials and related mail settings are accepted by the configured provider. This matters to configuration admins and Super Admins because it confirms the outbound mail setup is working at the point of configuration, helping ensure notifications, alerts, and other platform-generated emails can be sent successfully from the specified email addresses.

test message ​

In Autologyx, a test message is the validation email sent from a Send Message Actor configuration to confirm that the actor can generate and dispatch an outbound message successfully. It is used when configuring or updating message templates and outbound email settings, where the platform sends the test message to the user’s inbox as an immediate check of the actor setup. This matters because it helps configuration administrators verify that the message content is correctly formed and that outbound mail is working; if the test message is not received, it indicates a problem such as a template syntax or merge field error, or an issue with the platform’s outbound mail configuration.

test user account ​

A test user account is a user account created in Autologyx Catalyst specifically for testing authentication, access, and configuration behaviour without using a live end-user account. It is used in Catalyst account setup and administration, particularly by Configuration Admins and Super Admins when validating login configuration, user access, and environment changes introduced in or supported by Catalyst 1.13. This matters because test user accounts provide a controlled way to verify that authentication and account-related setup are working correctly before changes affect production users, helping administrators safely configure and confirm platform behaviour.

Test Variable ​

A Test Variable is a configuration action in the Autologyx platform that lets configuration administrators preview the value a variable would return for a specific Autologyx Record before the sequence is run. It is used in the configuration panel when working with variable-based components such as the Local Variable Actor, where you enter a Record ID and select Test Variable to evaluate the variable in the context of that record. This is important because it helps confirm that the variable is configured correctly, returns the expected record-specific data, and behaves as intended before the configuration is used in live process execution.

Test Variable functionality ​

Test Variable functionality is the Autologyx configuration tool used to evaluate variable and merge-field resolution during workflow design and troubleshooting, allowing configuration admins to confirm how expressions will resolve in the current execution context before or during runtime testing. It is used where local variables, merge fields, record-based merge fields, Loop actors, Send Message actors, sequence objects, and the Sequencer depend on context-sensitive values, including loop-driven fields such as {{ loop item }} and {{ loop counter }}. This matters because the test output reflects the active loop iteration context, helping admins verify that variables resolve to the correct document object or sequence value, avoid empty or incorrect results when expressions are used outside the appropriate context, and ensure downstream actors receive the expected data.

test your Authentication Object ​

Test your Authentication Object is the built-in validation option available when creating or editing an Authentication Object in Autologyx, specifically highlighted for iManage Authentication Objects. It is used in the Authentication Object configuration workflow by Configuration admins and Super Admins to verify that the connection details supplied for the authentication setup, such as the host and client credentials, work correctly before the object is saved for use by platform integrations such as API Actors and the API Call actor. This matters because it helps confirm that the authentication configuration is valid at the point of setup, reducing configuration errors and helping ensure connected services can be accessed successfully when the Authentication Object is used in runtime integrations.

Testing the new Authentication object ​

Testing the new Authentication object is the validation step used after configuring an Authentication object for the Autologyx Microsoft integration, where the platform checks that required client credentials flow settings such as Client ID, Client Secret, Scope, Tenant, and provider details are entered correctly. This test is used by configuration administrators and developers during setup before the object is referenced in API calls or sequences, and it matters because it confirms the authentication configuration is ready for use, helping ensure the object can be safely incorporated into automated processes that access Microsoft account data.

Text ​

In the Autologyx platform, a Text field is a basic Catalyst form builder field type used on record and task forms to capture free-form user input such as names, references, or other short written values. It is configured by administrators when designing intake and record-creation forms in Autologyx Catalyst, including in create and edit views, and can also be marked as unique when a form needs one value to identify a record distinctly. Text fields matter because they provide flexible data capture, but they are the least useful field type for determining an automated workflow route, so they should be used appropriately where structured routing, conditional logic, or controlled selections would be better served by more specific field types such as drop down lists, Date/Time, Decimal, Email, or checkboxes.

text editor in instructions ​

The text editor in instructions is the enhanced authoring tool used when creating and formatting instruction content in Autologyx, enabling configuration admins to build clear, engaging manuals that are displayed on forms across the platform. Used within the instructions editor, it provides rich text capabilities such as font size, font type, font color, text alignment, and bullet or numbered lists, making it easier to structure guidance for end-users. This matters because well-formatted instructions improve readability and consistency, helping users understand what they need to do on a form and supporting more effective process execution.

Text field type ​

In Autologyx, the Text field type is an object class field used to store free-form textual values within the Data Model when configuring fields through the Add field panel, Edit field panel, and Fields list. It is used by configuration administrators and Super Admins when defining the structure of records that require text-based input rather than numeric, document, or selectable values. A key configuration setting for this field type is Max length, which controls the allowed character limit for future data entry; however, increasing or clearing this limit does not change values already stored in existing records. This matters because it affects how administrators design data capture, validation, and ongoing field behaviour across object classes.

text fields ​

Text fields are a field type in Autologyx used to capture and display user-entered written content in forms and task templates. They are configured by administrators when editing templates, where the Input type for a Text field can be set to standard single-line, multiline, or Markdown presentation, depending on how the content needs to be entered and shown. Text fields are used in create and edit record forms and other workflow data-entry experiences, and they matter because they determine both the structure of text input and the formatting options available to end-users, enabling anything from simple short answers to richer formatted content within the platform.

Text overrides ​

Text overrides are theme configuration settings in the Autologyx platform that let administrators change the text shown on the right-hand side of the login page. They are used as part of Theme setup and management, alongside branding options such as logos and colour settings on the Configure Theme area. Text overrides matter because they allow Configuration Admins and Super Admins to tailor login-page messaging to match organisational branding, user guidance, or communication requirements, helping ensure the sign-in experience is aligned with the organisation’s presentation and instructions.

Text parts ​

Text parts are the non-file components of a multipart request configured in the API Call actor in Autologyx. They are used within Multipart Configuration as individual request parts that carry text-based values such as metadata or form fields, for example a document identifier sent alongside uploaded files. A text part is defined with multipart request settings including Content Disposition, which controls how the part is represented in the outbound request. Text parts matter because they enable integrations to send the complete payload structure required by external APIs, combining descriptive data with file parts in a single multipart submission.

Textbox ​

Textbox is a Task Form field in Autologyx that captures freeform text entered by the user. It is used in the Form Builder when configuring record or task forms, where configuration admins add the field to collect written responses that do not fit a predefined option set, and it is presented to end-users as a standard input on the form. A Textbox can be configured with validation to enforce a maximum character limit, helping control input length and support consistent data capture. This field matters because it provides a flexible way to gather comments, names, references, explanations, or other typed information while still allowing form designers to manage how much text can be entered.

Textbox field type ​

Textbox field type, also shown as Textbox, is a form field used in Autologyx response configuration to capture free-text input from a user as either a single-line or multi-line entry. It is configured in the Form builder when creating a Complete self contained form or other response form layouts, and is used wherever a task requires users to type information directly into the form, such as entering a name, comments, or other written responses. This field type matters to configuration admins because it determines how user-entered text is collected, presented, and completed within a task, helping ensure the form is structured appropriately for the kind of input the process requires.

The Form Builder ​

The Form Builder is the Autologyx configuration interface used to design and maintain record and task forms by assembling the components that control form structure, field behaviour, and user interaction. It is used by configuration admins when creating or updating forms for Object Records and Tasks, including arranging layout sections and instructions, configuring task form fields and other elements, and applying properties and conditional logic to shape the end-user experience. The Form Builder matters because it is where form usability, consistency, and data capture requirements are defined, ensuring that forms are clear, structured, and effective for the processes they support.

The New Product Name ​

Theme ​

In Autologyx, the Theme is the system-wide branding configuration used to style a Catalyst environment so it matches your organisation’s or client’s brand, including logo, colours, and selected text overrides such as content on the login page. It is configured from System configuration > Theme and can be created or managed only by users with the Super admin account type; users without that access do not see the Theme menu item and are shown the Access Denied page if they try to open it directly. The Theme is disabled by default, and once created and enabled it is applied across the system for all users. This matters because it provides a consistent, branded user experience and aligns the platform’s presentation with existing systems and organisational standards.

Theme menu item ​

The Theme menu item is the navigation option in Autologyx system configuration that gives access to theme management, including the Configure Theme page where platform branding and visual settings such as colours and media are maintained. It is used by Super Admins when setting core, form, and additional colour values, uploading assets such as the Autologyx Catalyst logo, and enabling a theme for use across the platform. This menu item matters because it is the entry point for controlling the visual identity and user interface styling of an Autologyx environment, and it is permission-restricted: users without the Super Admin account type do not see it.

This is a task that should expire ​

In Autologyx, This is a task that should expire is a Task template setting that defines the task as time-limited rather than completed only once. It is used when editing a Task template in system configuration, where administrators can switch the task type from This task is completed just once and set an associated expiry timeframe. This setting matters because it controls the lifecycle of tasks created from that template, ensuring they are treated as expiring work that must be renewed or reissued after the configured period, rather than remaining permanently satisfied after a single completion. Changes to this option apply only to tasks created from the template after the updated template is saved.

This task is completed just once ​

In Autologyx, This task is completed just once is a Task template completion setting that defines the task as a one-time activity with no expiry behaviour. It is used in Task template editing within system configuration, where Configuration Admins and Super Admins can switch a template between a one-time task and a task that should expire, depending on the required lifecycle. This setting matters because it determines how tasks created from the template behave after completion, distinguishes them from tasks governed by an expiry timeframe, and helps administrators configure the correct operational model for the work being managed. Any change to this setting applies only to tasks created from the template after the updated template is saved.

tick boxes ​

In the Autologyx platform, tick boxes are the visual presentation used for multi select fields in Catalyst forms, including intake and other record creation forms. Each available option is shown with its own box so users can select multiple values and clearly see which options have been chosen. Tick boxes are used in the Catalyst form builder wherever a field is configured to allow more than one selection, and they matter because they directly affect how information is entered, reviewed, and understood by end-users, while helping configuration admins choose the right field type and form design for clear data capture and any related conditional logic.

Time Completion User ​

In Autologyx, a Time Completion User is a user account type created for people who need access only to complete a one-time task and who do not have login privileges. This account type is used when configuring participant access for ad hoc or single-use activities, typically where an external or limited-scope user must complete a task without being set up as a full internal or standard platform user. It matters to Configuration Admins and Super Admins because it supports precise role assignment and user management, helping distinguish these short-lived task participants from other user account types while controlling how users are counted and managed against platform user limits.

time manipulations filter ​

In the Autologyx platform, the time manipulations filter is a Jinja filter used in template-driven configuration to modify the time portion of a timestamp, such as adding or subtracting minutes or hours for operational scheduling. It is used where administrators and integrators build dynamic values in workflows, notifications, reminders, and appointment-related outputs that depend on calculated times. This filter is particularly important when adjusting appointment times for timezone differences or scheduling follow-up actions relative to a specific timestamp, because it allows time-based logic to be applied directly within the platform’s templating layer without external processing.

timed trigger ​

In Autologyx, a timed trigger is a sequence trigger configured to operate on a time-based schedule rather than requiring manual initiation, and it is used when designing or editing a Sequence in System Configuration. In the sequence design view, a timed trigger is identified by a clock icon once the trigger configuration has been saved. This matters to Configuration Admins and Super Admins because it distinguishes automated, schedule-driven sequence activation from other trigger types, helping them confirm how a sequence will start and manage process automation accurately within the platform.

TLS field ​

The TLS field is an outbound mail configuration setting in Autologyx that controls whether Transport Layer Security is used when connecting to the mail server. It is used in Administration > Communication > Outbound mail setup, including Microsoft Client Credentials settings, alongside the host, port, and username values, and it is defaulted to ON. This setting matters because it directly affects the platform’s ability to establish a valid connection for sending email: if the TLS value does not match the requirements of the configured mail service, outbound email delivery and test mail checks can fail with a connection error.

Token URL ​

In Autologyx, the Token URL is the endpoint defined in an Authentication Object’s Generic OAuth 2.0 template where Autologyx sends the token request to obtain an access token for a connected service. It is used when configuration admins or integrators set up OAuth 2.0 authentication alongside related fields such as Client ID, Client Secret, Refresh URL, Additional Parameters, and Additional Authorization Headers. This setting matters because it directs Autologyx to the correct authorization server endpoint for token acquisition, enabling authenticated communication with external systems and ensuring the platform can successfully establish and maintain API access for integrations.

Tokenised links are secure, time-bound URLs used in Autologyx password reset flows to identify a specific reset request and allow the user to open the reset password form or set a new password without first signing in. In the platform, they are used as part of password recovery and are governed by the same authentication enforcement rules configured by user account type, including policies that restrict password-based actions for SSO-only users. This matters because tokenised links are not an exception to authentication configuration: administrators must understand that password reset emails, token-based password changes, and access to reset forms through tokenised links are all controlled to prevent users from bypassing the authentication methods defined for their account type.

Tokens ​

Tokens in the Autologyx platform are time-bound values used to authorise specific account and authentication actions. They are used in activation emails for user accounts that have not yet been activated, where changing the username generates a new activation email with a new token, and they are also used by Authentication Objects, where updated credentials are not picked up by the sequencer until the current token expires because tokens refresh every 24 hours. Tokens matter because they control when access changes take effect, influence how quickly updated credentials are applied, and determine whether a user must use a newly issued activation link after account details are changed.

Top K ​

Top K is a model configuration setting used with the AWS Bedrock actor in Autologyx to control response generation by limiting the number of highest-probability next-word candidates the model can choose from at each step. It is configured alongside other generation parameters such as temperature, Top P, Maximum Length, and Stop Sequences when administrators set up or tune AI behaviour in actors. Lower Top K values make outputs more predictable and constrained, while higher values allow more variation in the model’s wording. This matters to Configuration Admins and Super Admins because Top K directly affects the balance between consistency and diversity in generated responses, helping them tune AI-driven actions to suit operational, compliance, and user experience requirements.

Top P ​

Top P, also known as nucleus sampling, is a model configuration setting used on AI actors such as the AWS Bedrock actor in the Autologyx platform to control response diversity during text generation. It works by limiting the model to the most probable next-word choices, so lower Top P values produce more focused, formal, and structured output, while higher values allow a broader range of wording and more varied responses. This setting is configured alongside related generation parameters such as temperature, Top K, Maximum Length, and Stop Sequences, and it matters because it helps configuration admins, Super Admins, and developers tune AI behaviour to suit the task, particularly where consistent, professional drafting is required.

A transaction status link is the URL returned by Autologyx from a hierarchical record creation endpoint that lets developers and integrators check the status of an asynchronously submitted transaction after the initial request has been accepted. It is used in integrations that create hierarchical records when processing continues after the API call returns, and it provides a dedicated way to poll or retrieve the current state of that transaction. This matters because it allows calling systems to track progress, determine when processing has completed, and handle downstream actions or error management reliably without requiring the original request to remain open.

trigger a Sequence by another Sequence ​

INSUFFICIENT_EVIDENCE

trigger conditions ​

Trigger conditions are the rules configured on a Sequencer trigger in Autologyx that control whether and when the next actor or sequence runs after a trigger event such as When Actor completed, When Task Created, When Task Completed, or When Sequence Activated. They are used throughout sequence configuration on triggers between actors, including Sequence Runner, Relation Lookup, task-driven flows, document generation, and polling patterns such as DocuSign status checks, where supplementary conditions and delays can be added to restrict execution to specific records, statuses, timings, or outcomes. Trigger conditions matter because they determine the exact routing and scope of workflow automation, preventing unintended actions, enabling subset processing, and ensuring downstream actors run only when the configured business criteria are met.

Show 3 more pages

trigger configuration ​

Trigger configuration is the set of options used to define exactly when a Sequence starts in Autologyx and, where needed, what additional conditions must be met before commencement. It is used in Sequence setup and Sequence Runner configuration, where administrators select a base trigger such as “When Actor completed” and can refine it with further condition options, including checks against variables or outcomes from a connected actor. This matters because trigger configuration controls the automation entry point for Records, enabling different routes for subsets of Records, ensuring the correct process starts at the correct time, and allowing more precise behaviour through actor Properties and conditional logic.

trigger configuration modal ​

trigger connector ​

A trigger connector, often shown simply as a trigger, is the sequence design element used in Autologyx to connect one object or actor to another so that a downstream step runs when the source event occurs. Configuration admins use trigger connectors while editing a sequence on the design canvas, for example to start a task actor from an object class such as Employment Contracts, to run a Sequence Runner from a Relation Lookup, or to trigger processing when a task is completed. When a trigger connector is added, its Trigger configuration dialog defines the event relationship between the source and target components. Trigger connectors matter because they control how activity flows through a sequence, ensuring that tasks, lookups, and child or related record actions start at the correct point in the process.

Trigger Gate ​

In Autologyx, a Trigger Gate is a configuration pattern used within a Sequence to control when Triggers are allowed to fire, especially where processing splits into parallel branches and race conditions must be prevented. It is typically implemented by initializing a Local Variable at the start of the Sequence and then using that variable as the gate condition as processing progresses, replacing a simple merge point with explicit gating logic. Trigger Gates are used by configuration admins when designing Sequences that need ordered or protected execution across branches, and they matter because they provide a reliable way to coordinate Trigger behaviour, avoid invalid actor scenarios, and keep process flow consistent when purely sequential processing is not practical.

trigger parameters ​

Trigger parameters are the set of selectable data references used when configuring a trigger in Autologyx, particularly within Sequence Runner, to define the context and conditions that control when automation starts or progresses. These parameters include records, fields, tasks, task groups, and variables, and are used by Configuration Admins and Super Admins when building trigger configuration that needs to evaluate information from the current record or related workflow elements. They matter because they determine what data a trigger can read and act on, enabling precise, context-aware automation across task groups and sequence execution.

In Autologyx, triggering Sequences when a related Record is updated is a configuration capability that starts a Sequence automatically in response to changes made to a Record that is linked to another Record in the process. This is used in Sequence trigger configuration where process automation needs to react not only to updates on the current Record, but also to updates on associated Records elsewhere in the data model. It matters because it allows administrators to build cross-record automation, keep connected work in sync, and ensure downstream tasks, decisions, and actions are launched immediately when related business data changes.

Triggers ​

In Autologyx, a Trigger is the configured condition and connection that controls when execution moves from one sequence object or actor to the next within a Sequence. Triggers are used throughout sequence design by linking actors such as Relation Lookup, Local Variable, Sequence Runner, and AI or API actors, then defining the event or condition that must be met, for example When Actor Completed, Loop Item Processed, or variable-based checks. They are central to workflow behaviour because they determine whether downstream steps run, prevent unintended processing such as advancing on empty lookup results, and enable complex branching and reuse of logic across parallel paths. Triggers must be configured with awareness of sequence state and data availability, since conditions that reference variables will not activate until those variables have been created by an earlier step.

UI ​

UI (user interface) is the visual part of the Autologyx platform that users interact with to navigate system areas, access product features, and work with capabilities such as Sequencer and Catalyst. It is used throughout the platform wherever pages, menus, forms, and on-screen controls are presented to end-users and configuration administrators. The UI matters because it is the primary way people use and configure Autologyx, and improvements to the UI directly affect usability, performance, navigation, and the overall experience of completing work in the platform.

UI and Navigation ​

  • Mostly relevant to: End-users
  • Closely related concepts: My account

UI and Navigation in the Autologyx platform describes the shared interface elements and movement patterns that users rely on to work effectively across the system, including list pages, filters, layouts, and common navigation structures. It is used in introductory and guidance content such as Finding your way around to help end-users understand how core screens are organised, how to move between system areas, and how consistent interface behaviours apply throughout the platform. This matters because a clear understanding of UI and Navigation enables users to find features faster, work more efficiently, and build confidence before moving on to platform-specific areas such as My Account and Workspace.

Unassign User Groups ​

INSUFFICIENT_EVIDENCE

Unique ​

Unique is a field setting in the Autologyx platform that enforces distinct values across Records for that field. It is used when creating or editing Object records, including in create and edit views and in-line editing, to prevent a user from saving a value that already exists in another Record for the same field. When a duplicate value is entered into a field marked as Unique, Autologyx displays an on-screen warning and does not update the Record. This matters to end-users and configuration admins because it protects data integrity, avoids duplicate key values in business records, and ensures that fields intended to identify or differentiate records remain one of a kind.

unique field ​

In Autologyx, a unique field is a form field, typically a text field configured in the Catalyst form builder so that each record must contain a value not already used in that field on another record. This setting is used when designing intake forms or other record-creation forms for an object class, and it is enforced during manual record creation from the Create record button and related record entry screens. If a user enters a duplicate value in a field marked as Unique, Autologyx shows a warning, identifies the field that must be unique, and prevents the record from being created. This matters because it helps configuration admins prevent duplicate records at the point of entry and helps end-users maintain clean, reliable records lists and object data.

unique token ​

In Autologyx, a unique token, also referred to as a task token, is the single-use identifier included in the email sent to a one time completion user when a task is assigned to them. The token is used in the link to open the specific task form, such as a Standalone form or an Update record form, so the recipient can access and complete that task without being a regular platform user. This is used in one time completion user workflows and matters because it connects the external recipient directly to the correct form instance, enabling completion actions such as using the Complete button or Save progress while maintaining the intended task-specific access path.

Unique value ​

Unique value is a field validation property used when creating or editing Object class fields in Autologyx. When enabled in the Validation section of a field, it requires every populated value in that field to be distinct across all records in the same Object class, so no two records can contain the same value for that field. This setting is configured by Configuration admins and Super Admins from the Add field panel and is reflected in the Fields list as part of the field’s properties. It matters because it enforces data integrity for fields that must identify records uniquely, helping prevent duplicate entries and supporting reliable record management alongside related concepts such as identifiers and Autologyx ID numbers.

Unique value flag ​

Unsaved changes will be lost ​

"Unsaved changes will be lost" is a warning message shown in Autologyx when a user tries to close or cancel a create or edit record form after entering data without saving it. It is typically encountered in record entry experiences such as child records opened from a parent record in a fly-out modal, for example when selecting the X to close the form or using Cancel. This warning matters because it prevents accidental loss of information, helping users decide whether to continue editing and save their work or discard the changes before leaving the form.

Unsaved changes will be lost modal ​

The Unsaved changes will be lost modal is a confirmation dialog shown in Theme configuration when a user attempts an action that would discard edits that have not been saved. In the Autologyx platform, it is used on the Configure Theme page, including actions such as clicking the Enable button while working in areas like the Colours tab or Media tab. This modal matters because it prevents configuration changes from being accidentally abandoned, helping Super Admins and other authorised configuration users preserve intended branding updates before leaving the current state or applying another action.

Unsaved changes will be lost warning ​

The Unsaved changes will be lost warning is an Autologyx confirmation message shown when a user has modified values on an edit screen and then attempts to leave or cancel without saving. It is encountered in configuration workflows such as editing Single Sign-On settings in the Administration tab and creating or editing task group templates, typically after using Cancel or navigating away before a save is completed. This warning matters because it protects users and administrators from accidentally discarding in-progress changes, helping ensure that only intentionally saved updates are committed and reducing the risk of losing configuration work that has not yet produced the green success toast message.

Unsaved changes will be lost warning modal ​

The Unsaved changes will be lost warning modal is a confirmation dialog in the Autologyx platform that is shown when a user editing Sequence properties attempts to navigate away, close the editing view, or otherwise leave the current context before saving changes. It is used in Sequence design workflows, including in-place editing from the Sequencer tab and related side stack interactions, to prevent accidental loss of configuration updates. This warning matters because it protects administrators from discarding unsaved edits to Sequence settings, helping maintain control over configuration changes and ensuring that intended updates are either saved explicitly or abandoned deliberately.

update actor ​

In Autologyx, an update actor is a workflow actor used to write values into fields on a record as a process runs. In the DocuSign monitoring configuration, it is connected to the envelope status variable so the current envelope status is stored directly on the record. This makes the status available outside the workflow itself, such as in reporting and in records list column headers, and allows configuration admins to persist integration data like DocuSign status in record fields for visibility, tracking, and downstream process use.

Update object record Task type ​

Update object record Task type is a Sequence design task in Autologyx used to modify an existing Object Record during workflow execution. It is used by configuration and Super Admin users when building or editing a Sequence, where it performs a record update rather than creating a new record, and its changes are treated by the platform as an update in the same way as edits made manually in the Object Record. This matters because it determines how record changes are applied within automated processes and how those changes relate to update-driven behaviour and related concepts such as Record updated, Record created or updated, Object classes, and the Object class section.

Update object record type ​

Update object record type is a Task template type in Autologyx used to create tasks that update records for a specific Object class. It is used in task template configuration, task form design, sequence actors such as Create Task and Set Task, task group templates, and list page filtering where Task type can be set to this value. Unlike self-contained form tasks, an Update object record type task can include both standalone fields and Object class fields, because it is tied directly to the configured Object class. This matters to Configuration Admins and Super Admins because template availability depends on the sequence object class, and task group behaviour is controlled by Object class selection: if the original Object class is removed, associated Update object record type task templates are removed, and if multiple Object classes are added, these task templates cannot be selected.

Update Object record type tasks ​

An Update Object record type task is a workflow task in Autologyx that presents a form for editing an existing object record of a specified object class, allowing users to update field values as part of a sequenced process. It is used in task sequences where record data must be captured or amended after the record has been created, including document fields such as images that need to be populated before downstream steps like document generation. For configuration admins, this task matters because it inherits and displays object class field definitions and labels, reflects changes made on the Data Model tab, and relies on the correct placement of fields in the relevant form or display configuration so users can maintain record data accurately within operational workflows.

Update object records ​

Update object records is a Task type in Autologyx used to create tasks that capture user input against a specific Object class and write the response directly back to the related Record when the task is completed. It is configured in a Task template’s Response configuration, where the Object class must be selected, the task structure is defined, and the task creation mechanism is set; automatic templates of this type are then available in the Sequence designer only for that Object class. Unlike Complete self contained form tasks, Update object records tasks are object-class-specific, can use fields from the Object class along with optional additional fields, and are commonly used in sequences, task groups, manual task creation, and process steps where task outcomes must update record data and drive subsequent workflow behaviour. This matters to configuration administrators and Super Admins because it determines how user actions update business records, how templates are filtered and reused, and what permissions and object ownership are required to create and manage the template.

Show 7 more pages

Update object records type ​

Update object records type is a task template type in Autologyx used for tasks that update fields on object records for a specific object class. It is used in configuration when building task group templates and in the workspace when creating a manual task for an object record. This type is tied directly to object class selection: until an object class is chosen, task templates of this type are excluded from selection, and once one is selected, only update-object-records templates for that object class remain available and additional object classes cannot be added. This matters because it ensures the task is aligned to the correct object record structure, controls which task templates users can select, and prevents invalid combinations when configuring or launching tasks.

Update objects records ​

Update objects records is a task type in Autologyx used in Task templates to modify records from a selected Object class as part of a workflow. When configuring this task in the Editing a Task template area, administrators specify the Object class that the task will update, which determines the records and fields available to the task and how the response form interacts with that object data. This matters because the task controls how users update structured business information within a case or process, and correct configuration requires the appropriate permissions, including the ability to edit Task templates, to ensure the task updates the intended object records accurately and consistently.

Update record ​

Update record, also called the Update Record Actor, is a native Autologyx actor used in sequences to change fields on an Object record to defined values, including values taken from sequence variables. It is used by configuration admins and integrators when designing workflow automation, forms, and trigger-driven sequence behaviour, and it can also be the target of one-time completion user interactions where a task directs a user to an Update record form. Update record matters because it is the standard in-platform method for modifying data held in Autologyx, making it the preferred option over an API Call Actor when the change is to an Autologyx record itself; its use also affects downstream automation, as sequence triggers and dormant connections determine whether the update causes subsequent tasks or actions to run.

Update Record actor ​

The Update Record actor is a Sequence Actor used in the Autologyx Sequencer to write changes back to the current record during workflow execution, including updating one or more record fields such as status, text, local-variable-driven values, recipient status, and document type fields. It is configured in sequence design and is commonly placed after actors such as Document Picker or DocAuto to store generated, retrieved, combined, added, replaced, or cleared documents in a specific record field, making it central to automating record updates and document filing. This actor matters because it is the standard mechanism for persisting workflow outputs onto the record itself, but it must be validly configured to perform that role, and updates made through it do not count as record updates for starting a separate Sequence workflow.

Show 6 more pages

Update record tasks ​

Update record tasks are task-based user interactions in the Autologyx Catalyst UI that let users modify an existing record within a workflow. They are used where a process needs controlled updates to record data, and they sit alongside other form-driven experiences such as Create/Edit forms, standalone forms, and self contained tasks. In practice, update record tasks present editable fields for the target record and, from Catalyst 1.14 onward, support Markdown in text fields, giving users richer formatting options when entering or revising content. This matters because it improves how record data is maintained during process execution while giving configuration admins a consistent form experience across the platform’s record and task interfaces.

Updated date/time ​

Updated date/time is a system field in Autologyx that records when a record was most recently edited. It is used as a property on record and task forms and can be included in object class display configuration, including create and edit views, summary views, and side panels; when creating a new record, it is shown as visible only when editing because no update has yet occurred. This field matters because it gives users and configuration admins an immediate view of record recency, helping them identify the latest changes, distinguish it from Created date/time, and present key lifecycle information consistently alongside other system fields such as ALX ID and Identifier.

UPDATED FIELDS ​

UPDATED FIELDS is a sequence commencement condition option in Autologyx that exposes the fields on an Object class that were changed in the triggering update, allowing configuration admins and Super Admins to target sequence start logic to specific field changes rather than any update to the object. It is used when adding conditions for sequence commencement, typically alongside PREVIOUS FIELD VALUE, so a sequence can check both which field or fields were updated and the field’s current value. This matters because it enables precise, event-driven automation, helping ensure sequences start only when the intended data change occurs and reducing unnecessary or incorrectly triggered process execution.

upload history ​

Upload history is the area of the Autologyx file upload experience where users review current and previous upload activity. Within the File upload component, it provides visibility of ongoing processing and detailed summaries of completed past uploads, helping users track what has been submitted, monitor progress, and confirm the outcome of upload-driven actions such as record creation. Upload history matters because it gives end users a clear operational view of their file submissions, making it easier to follow up on failed or incomplete uploads and manage repeat upload work efficiently.

URL ​

In the Autologyx platform, URL is a task form field input type used to capture web addresses such as links to websites, online forms, or other web resources. It is configured in the Form Builder when designing record or task forms, where administrators can add the field alongside other form settings such as description, default value, conditional visibility, and placement within form sections. The URL field includes front-end validation to help ensure users enter data in a valid web address format, making it important for maintaining clean, usable links and supporting form experiences that depend on accurate external references.

URL input ​

URL input is the configuration field in the Autologyx platform where an administrator or integrator enters the full request URL used by an actor, including any required path segments and placeholders such as {Hostname} and {documentId}. It is used when configuring integrations such as the API Call actor, where template-driven values and system variables are combined to form the endpoint the platform calls at runtime. This field matters because it defines exactly which external resource or service Autologyx connects to, so it must be completed correctly for the integration to function, resolve template values properly, and support successful connection testing and execution.

URL Parameters ​

URL Parameters are the key-value values configured on an API Call Actor in Autologyx to send additional information to an external API as part of the request URL, such as filters, sorting options, or control values. They are used in System Configuration when defining or editing API integrations, where administrators and integrators can add or remove parameters in the API Call Actor and can also populate them with constants. URL Parameters matter because they control how an API request is interpreted by the target service, enabling the platform to retrieve or submit the correct data and making integrations more flexible, reusable, and easier to manage without changing the core endpoint definition.

Usage column ​

The Usage column is a field in the Authentication objects list under the Administration area of Autologyx that shows how many API Actors are configured to use each authentication object. It is used by Configuration Admins and Super Admins to understand whether an authentication object is currently in use before making changes, especially when managing records through the Actions menu. This value matters because it directly affects administration options: when the Usage value is zero, the authentication object is not assigned to any API Actors, and if the value is not zero, the delete option is hidden, helping prevent removal of authentication objects that are still in active use.

usage panels ​

In Autologyx, a usage panel is the comprehensive deployment view shown on an authentication object that lists exactly where that object is being used across the platform. It is used by configuration administrators and Super Admins when reviewing or maintaining authentication objects, alongside related controls such as credential expiry timestamps, expiry notifications, automatic expiry notifications, and in-use deletion protection. The usage panel matters because it gives immediate visibility into dependencies before an authentication object is updated, renewed, or deleted, helping administrators avoid broken workflows, prevent disruption from expired credentials, and manage platform authentication changes safely.

Use as identifier ​

Use as identifier is an Object class field setting in Autologyx that designates a single field as the identifier for records of that Object class. Configuration admins and Super Admins use this option when editing Object class fields, in the Add field panel and related field configuration screens, to control which field is displayed as the record’s primary label in the Fields list, Summary view, card view, Tasks, Templates, Activity Log, Record access panels, and search results for child Object classes in parent create or edit views. Only one field in an Object class can be marked as the identifier at a time, and enabling the flag on one field automatically removes it from the previously selected identifier field. If the flag is turned off and no field is selected, the hidden Autologyx ID becomes the identifier. This setting matters because it determines how records are named, recognised, and navigated throughout the platform.

User account ​

A User account is the core identity record for a person in the Autologyx platform, used to create and manage access, profile details, and authentication settings for administrators and end-users. It is configured in user administration, where Super Admins and Configuration admins create accounts and edit user details, and it is also surfaced to individuals through My account, where personal information and preferences are populated from the same underlying record and any updates are synchronised back to it. User accounts are central to platform operation because they determine who can sign in, how they authenticate through standard login, forgot-password flows, or single sign-on, and how user information is maintained consistently across the platform; they are also distinct from specialised account types such as service accounts and 1 time completion users.

user account page ​

  • Mostly relevant to: Configuration admins, Super Admins
  • Closely related concepts: My account, Username

In Autologyx, the user account page is the administrative record for an individual platform user, used by configuration and super administrators to manage core account details such as the Username field. It is linked directly to the My account page used by the end user: when a user updates their value in My account, that value is written back to the Username field on the user account page. This matters because the user account page is the authoritative location for user identity data within platform administration, ensuring that changes made through self-service account settings are reflected in the central user record.

User Account Types ​

User Account Types are the platform-defined categories that determine how a user accesses Autologyx, what capabilities they can use, and how they are governed in configuration. In Autologyx Catalyst, these types include 1 Time Completion users for one-off task completion without login privileges, Internal users, External users, Configuration Admin users, and accounts with full platform access, with the interface showing visual indicators such as the dotted-circle avatar for 1 Time Completion users. User account types are used in user management, licensing and user counts, permission and role boundaries, and in System Configuration where authentication methods can be configured and enforced per account type through the API. This matters because selecting the correct account type controls the user experience, applies the right security and access model, and ensures administrators manage users, authentication, and platform limits correctly.

user activation ​

User activation, also referred to as account activation, is the Autologyx capability that controls when a newly created or updated user account is enabled for first-time access and when the platform sends the activation email that lets that user complete setup. In Autologyx, this is used in user provisioning and administration workflows, including API-driven creation and editing of users in Catalyst, where the delay activation parameter gives Super Admins, Configuration admins, and Developers or Integrators explicit control over the timing of activation. This matters because it allows organisations to align account access with onboarding, deployment, and security requirements, avoid sending activation emails before a user is ready to access the platform, and manage user rollout in a controlled and predictable way.

user activation rules ​

User activation rules are the Standard authentication settings in Autologyx that define how users activate their accounts and access the platform. They are configured by Configuration admins or Super Admins in Administration on the Standard authentication page, and sit within the platform’s communication and user management setup alongside items such as activation emails, activation links, the Activate your user account page, account types, and single sign-on configuration. These rules matter because they control the user activation experience for full accounts, determine how new users complete account setup, and help administrators align onboarding and access processes with the organisation’s authentication model.

user and group management ​

  • Mostly relevant to: Super Admins, Configuration admins
  • Closely related concepts:

INSUFFICIENT_EVIDENCE

user avatars ​

User avatars are the visual user identifiers shown throughout the Autologyx platform in places such as lists, dropdowns, and other user-selection or user-reference controls. In addition to helping end-users quickly recognise who is assigned, involved, or available in a process, these avatars can be clicked to open user details where the viewer has the required access. This behaviour is governed by permissions, including the View Users permission and applicable role permissions, which configuration administrators and Super Admins must enable when they want Config Admins or other users to inspect user information from avatar-based links. User avatars therefore matter both as a core usability feature for everyday navigation and collaboration, and as a controlled access point for user detail visibility within platform configuration.

user count ​

In Autologyx, user count is the platform value that shows how many users of a specific account type are allocated or in use against that type’s distinct user limit. It is used in platform administration and configuration contexts where Super Admins and Configuration Admins manage user account types such as Internal User, External User, and Time Completion User, and need to understand capacity for each category separately. User count matters because it communicates consumption against the configured limit for each user type, helping administrators control access, plan provisioning, and ensure the platform is configured in line with available user entitlements.

User details page ​

The User details page is the administrative page in Autologyx used to view and manage an individual user account. It is used by Super Admins and Configuration admins as part of account administration, typically accessed from the User List, and includes a Status section that shows the user’s account state, such as Created, Pending, or Active, alongside information related to account setup and activation email processing. This page matters because it gives administrators a single place to check where a user is in the activation lifecycle, understand delayed account activation status, and take informed action when configuring or supporting access to the platform.

User Experience Interface Improvements ​

user field ​

A user field is an object class field type in Autologyx that stores one or more user references, and can also be configured to work with user groups, depending on how the field is set up. It is used in object class configuration, in permissions models where access can be granted via a user field, and in merge fields where it returns a list of user objects using the appropriate alias syntax. User fields matter because they drive how records are assigned, displayed, and accessed by named users or group-based selections, and they require specific configuration and handling: administrators must define how end users interact with group selections, deleted users are flagged in field editing, and sequence actions such as Update Record do not update user fields.

User field type ​

In Autologyx, the User field type is an object class field used to store user-based selections, allowing individual Users and User groups to be added to or removed from the field as part of the object’s configured data structure. It is used by Configuration admins and Super Admins when defining or updating fields for an object class through the Data Model tab, including from the Fields list and the Add field or Edit field panels. This field type matters because it enables object data to be linked directly to platform users or groups, supporting configurations where ownership, participation, responsibility, or other user-related values must be captured in a structured and maintainable way.

User group edit page ​

The User group edit page, also referred to as the User group page, is the administration screen in Autologyx used to manage an existing user group after it has been created or when adding members during group creation. It is used by Configuration admins and Super Admins to open a selected group and maintain its membership by adding users, promoting members to owners, or removing members, typically through the Membership tab and related member and non-member filters. This page matters because it is the central location for controlling who belongs to a user group and who can own it, which directly supports effective access, responsibility, and group administration across the platform.

User group ID ​

User group ID is the unique numeric identifier assigned to a User group in the Autologyx platform. It is used in the administration URL for that group, for example /administration/user groups/89, where the final number identifies the specific User group record. Configuration admins and Super Admins use the User group ID to open a group directly when editing the group itself or its permissions, especially in cases where the group is not readily accessible through the user interface. This matters because it provides a precise way to locate and manage the correct User group for membership, ownership, and permission changes.

User group list ​

The User group list is the administrative list view in Autologyx for managing User Groups, used by Configuration Admins and Super Admins from the Administration area, including the Administration tab of System permissions. It displays existing user groups and, in its default column configuration, shows core details such as the group ID, with additional columns available for information such as owners and member counts. From this list, administrators can create a new user group using the Create button, review groups after they are saved, and use list actions to manage membership and ownership, including adding users as members or owners. This list matters because it is the central control point for organising users into groups, maintaining group ownership, and supporting permission and visibility configuration across the platform.

User Group management ​

User Group management in Autologyx is the administration capability for working with user groups where group selection is supported across the platform. It is used in areas such as task ownership and assignment, Object Class and Record ownership, Permission Sets, User Type Class fields, default task assignees in Sequences, and other user or user-group dropdowns, autocompletes, and filters. Visibility of groups and their members is controlled by list permissions, which determine whether users can see and choose specific groups or group members in these contexts, while users can always list themselves. This matters to Configuration Admins and Super Admins because correct user group management and permission configuration governs who can be assigned, selected, granted access, and administered throughout the platform.

User Group management and Permission Sets ​

User Group management and Permission Sets in Autologyx are the administration areas and security controls used to create and manage user groups and to assign the permission sets that govern what those groups can access or do across the platform. This capability is used anywhere administrators configure group-based access or select users and groups, including task ownership and assignment, object class and record ownership, object class and record permission sets, user type class fields, default task assignees in sequences, and user or group dropdowns, autocompletes, and filters. It matters because list permissions determine which users and groups are visible and selectable in these areas, enabling Configuration Admins and Super Admins to control access accurately, maintain clear ownership and assignment models, and ensure that group-based security behaves as intended throughout the platform.

User Group Members ​

  • Mostly relevant to: Configuration admins, Developers / Integrators
  • Closely related concepts: merge fields, Loop actors

User Group Members are the individual platform users contained within a User Group, exposed in Autologyx through enhanced resolution of User-type merge fields. In practice, this is used in workflow and real-time automation features such as merge fields and related loop-based processing, where a field that references a User Group can now return its constituent users for downstream actions or content generation. This matters to configuration admins and developers because it allows group-based assignments, notifications, and dynamic workflow logic to operate on actual users rather than only the group object, making automations easier to configure and more effective when working with team or role-based participation.

user group objects ​

User group objects are the structured group records returned by Autologyx user-and-group merge fields when object-based access is used to retrieve groups rather than individual users. In this context, each item in the returned array represents a group with its core properties, including the group identifier, group name, and member count, and can be accessed directly or by index in templates, sequencer actors such as API Call, Send Message, and Local Variable, related-record merge fields, and other supported merge-field contexts. User group objects matter because they allow developers, integrators, and configuration admins to work with group data as discrete objects for dynamic document content, automation logic, and access-aware configurations, instead of relying on simple text values.

User group Owner ​

A User group Owner is a designated owner of a specific User group in Autologyx and is always also a member of that group; a group can have multiple Owners. In administration of User groups and User group Permissions, this status is important because it controls who can manage the group itself: User group Owners with a Config Admin account can access the group from the main navigation, promote members to Owners, demote Owners to members, remove users, manage group membership, edit the group, create and edit permission sets other than the default Owners set, delete custom permission sets, and delete the User group. User group Owners with an Internal account type do not see the menu option, but with the correct direct URL they have the same group-level capabilities. For configuration and platform administration, User group Owner status matters because it delegates operational control of a specific group and its permissions without requiring Super Admin access across the whole system.

User Group Permission Sets ​

User Group Permission Sets are the predefined access controls applied to each user group in Autologyx—Owners, Members, and Everyone—that determine who can view and interact with that group. They are used in the Users and Groups visibility configuration area and work directly with the List permission, including the users.list permission, to control visibility of users and groups across the platform. This matters because these permission sets define how group membership and group records are exposed to different audiences, helping configuration admins and Super Admins manage access consistently and supporting downstream behaviours such as ownership, assignment, and interaction with related Object Class, Record, and custom permission set configurations.

User Group Permissions ​

User Group Permissions are the permission sets applied to an Autologyx User Group to control who can access the group, view its members, and manage the group across relevant Catalyst areas. They are configured from the Permissions tab within a User Group and include three default permission sets—Owners, Members, and Everyone—with support for additional custom permission sets to provide more granular visibility and access control. Super admins and User Group Owners can configure these settings, with Super admins having unrestricted access and Owners managing permissions for the groups they own. This matters because User Group Permissions determine how groups are exposed and administered in the platform, enabling configuration teams to enforce clear ownership, restrict visibility appropriately, and tailor collaboration and user management to business needs.

Show 3 more pages

User Groups ​

User Groups are a configurable way to organise users into teams or other reusable subsets so they can be managed and referenced as a single unit across the Autologyx platform. They are administered from Administration > User Groups, where groups are created with a unique name and then managed through Membership and Permissions tabs; the creator becomes an owner, and Super Admins or authorised owners can maintain members, owners, and group permissions. User Groups are used throughout configuration and runtime features, including task assignment, messaging, User type fields in Object Classes and task forms, Class Permission Sets, Record Permission Sets via the Record Access actor or API, and other areas that need group-based access or responsibility assignment. They matter because they simplify administration, make permissions and assignments scalable, and ensure that access, task ownership, and team-based actions can be updated centrally by changing group membership instead of reconfiguring individual users in multiple places.

Show 27 more pages

user groups API ​

The User Groups API is an Autologyx platform API used to retrieve and manage user group information, including locating users within groups through search support on GET requests. It is used by developers and integrators building administrative or identity-aware integrations, and by Super Admins configuring access-related solutions that depend on group membership data. This API matters because user groups are a core mechanism for organising users and supporting access configuration across the platform, and efficient search within group data improves administration, integration performance, and the accuracy of group-based processes.

User Groups in Tasks ​

User Groups in Tasks lets tasks in Autologyx be assigned to a User Group instead of only to individual users, enabling group-based task distribution for teams that share responsibility for the same work. This is used anywhere task assignees are viewed or configured, including the Create Task panel, Task details, and Task Lists, where users can also filter tasks by User Groups and use views such as Tasks I’m Only an Assignee Of to understand their relationship to group-assigned work. For configuration admins, this feature reduces manual administration by allowing a single group assignment to represent multiple eligible users; for end-users, it improves visibility of shared workload and makes it easier to find, manage, and act on tasks assigned through team membership, subject to the relevant permission to list those tasks.

User groups sub tab ​

The User groups sub tab is the section within the User group Permissions configuration screen where administrators manage permission assignments for other user groups against the selected user group. Used when editing a user group’s permissions alongside the Users sub tab, it lets Configuration admins and Super Admins define how group-based access is applied across the default permission sets—Owners, Everyone, and Members—and any custom permission sets configured for that user group. This matters because it enables scalable permission management by assigning access through groups rather than individual users, helping administrators control membership-related access consistently and efficiently across the platform.

User groups tab ​

The User groups tab is a selection area in Autologyx configuration screens that lets administrators add and manage User Groups instead of individual users when assigning access, assignees, or class permissions. It is used in contexts such as User Group Permissions, class permission set configuration, and the Add Assignees workflow, where users can switch from the Users tab to the User groups tab and use the add action to include groups. This matters because it enables permissions and assignments to be managed at group level, which simplifies administration, supports consistent access control, and makes it easier to maintain assignee and permission settings across multiple users.

User Groups Usage Panel ​

The User Groups Usage Panel is an administrative interface in Autologyx that shows where a User Group is currently used, specifically highlighting usage in Send Message Actors. It is used by configuration administrators and Super Admins when reviewing or managing User Groups, providing a clear view of dependencies before changes are made. This matters because it helps protect platform configuration integrity by preventing the accidental deletion of groups that are still in use, supporting safer maintenance of access, messaging, and related group-based configuration.

User ID ​

User ID is the DocuSign user identifier that Autologyx requires when configuring a DocuSign Authentication Object in Catalyst. It is one of the key connection values collected from a DocuSign developer account alongside related integration settings such as the API Account ID and Account Base URI, and is entered during system configuration to bind the authentication object to the correct DocuSign user context. This matters because the authentication object uses that identity information to establish and maintain the DocuSign integration correctly, making the User ID an essential configuration value for administrators and integrators setting up or managing DocuSign connectivity in the Autologyx platform.

User ID field ​

The User ID field is a configuration field in a DocuSign Authentication Object in Autologyx where administrators paste the User ID obtained from DocuSign Settings > Integrations > Apps and Keys. It is used when creating or editing authentication objects under Administration so the platform can associate the DocuSign connection with the correct DocuSign user account. This field is configured alongside related connection values such as the Client ID and Host, and it matters because a correctly populated User ID field is required for the DocuSign integration to authenticate and operate against the intended DocuSign user context.

User ID number ​

User ID number (User ID) is the system-assigned identifier created for a user account in Autologyx when the account is added through Administration > Users. It is shown in the users list after creation and provides a distinct reference for that account within user administration. For configuration admins and Super Admins, it matters because it supports accurate identification and management of users when reviewing account details, coordinating activation, and distinguishing between accounts that might share similar names or email addresses.

user limit ​

In Autologyx, the user limit—also described as a distinct user limit—is the maximum number of accounts permitted for a specific user account type, with that allowance presented through the corresponding user count. It is used when configuring and managing platform access across the different user categories introduced in Autologyx, such as internal and external users, and is most relevant to Configuration Admins and Super Admins who oversee account provisioning and tenant setup. This matters because user limits define how many users of each type can be created or maintained, helping administrators control access allocation, stay within licensed capacity for each account type, and manage the platform’s user model accurately.

User List ​

User List is the administrative view in the Autologyx platform where Configuration admins and Super Admins manage user accounts. It is used to view users added to the platform in the normal way, including standard users and service accounts, with account type shown for entries such as Service External and Service Internal. The User List also includes status information that supports filtering and identifying users by activation state, including accounts that have not yet activated because of delayed account activation. This matters because it provides the central place to review account setup, distinguish account types, and monitor activation status when configuring and administering access to the platform.

user objects ​

User objects are the full structured representations of Autologyx users returned by Users and Groups merge fields when object-based access is used. In this context, a user object is delivered as part of an array and exposes user properties such as user ID, first name, last name, email address, company, phone numbers, deletion flag, and account type, with additional hidden properties available through explicit access. User objects are used in document templates, Sequencer actors such as API Call, Send Message, and Local Variable, related records merge fields, and other merge-field-supported contexts where workflows need to read, index, or iterate through assigned users. They matter because they enable configuration admins and integrators to build dynamic templates, routing logic, and integrations that rely on specific user attributes, while also supporting privacy handling for deleted users by restricting returned data to the deletion state.

user parameter ​

In Autologyx, a user parameter is a configurable value used in the Azure OpenAI actor to identify the end user for tracking or personalisation purposes when sending requests to the AI service. It is configured alongside other actor settings such as the endpoint field, model type, temperature, and prompt and context fields, and is used wherever an Azure OpenAI integration needs outputs tailored to a specific user context. This matters because it supports more contextually relevant AI responses while enabling administrators, developers, and compliance or analytics teams to align AI interactions with user-specific tracking and personalisation requirements in a controlled configuration.

User Permissions ​

User Permissions are the platform access rights assigned through Roles in Autologyx that determine which features, actions, and administration capabilities a user can use. They are configured in the Roles and Permissions area by configuration administrators and Super Admins when creating or editing a role, and they are applied to users through the roles they are given. User Permissions matter because they control access across the platform, ensure users can perform the tasks required for their responsibilities, and support secure, structured administration by aligning each role with the correct level of functionality.

user preferences ​

User preferences are the personal display and interaction settings applied to an individual user’s experience in the Autologyx platform. They are used across workspace list and record-view components to control interface behaviour such as row settings, and these settings are also inherited by related components such as child components, where row heights follow the same user preference configuration as other lists. User preferences matter because they let end users tailor how information is presented and navigated without changing shared application design, helping maintain a consistent, efficient experience across records, relational views, and other data-driven screens.

User roles ​

  • Mostly relevant to: Configuration admins, Super Admins
  • Closely related concepts: role permissions

User roles are platform-level assignments used to define what an individual user can do in Autologyx by applying specific role permissions directly to that user. They are used when setting up and administering an application, particularly by Configuration admins and Super Admins who need to control access and responsibilities for particular people. User roles matter because they provide a direct way to grant or restrict capabilities for named users, complementing the permissions that most users inherit through their User group memberships and helping ensure the right people have the right level of access within the platform.

User tile ​

In Autologyx, the User tile is a selectable user card shown when choosing individual users in administration workflows such as User Group Permissions. Administrators click the User tile to add or assign a specific user, and once selected the tile is disabled and marked “Already selected” to prevent duplicate selection. This control matters because it provides a clear, visual way to identify and manage individual assignees when configuring access, membership, or permission-related settings in the platform.

User Type Class fields ​

User Type Class fields are Class Fields configured to capture a user-related selection on records and tasks in Autologyx, and can be set up by administrators to offer specific individual users, User Groups, or both as valid choices. When configuring the field, admins define which users and groups are available and how groups behave through options such as Allow Selecting Individual Members and Allow Syncing Group Members, which control whether end users can choose whole groups, members within those groups, or both. These fields are used anywhere user and group selection is needed, including records, task forms, filtering, ownership, and default task assignees in Sequences, and they work with list permissions and users-and-groups visibility controls so the configured options remain selectable where required. This matters because User Type Class fields standardise how responsibility, access, and assignment are captured in the platform, making workflows easier to configure and more efficient for end users.

user type field values ​

User type field values are configurable user attribute values that can be selected in the Sequencer as assignment targets for Record Permission Sets and record ownership, alongside individual users and groups. In Autologyx, they are used when configuring access and ownership rules from a centralised point so that permissions and ownership can be applied according to defined user classifications rather than managing assignments one user at a time. This matters to Configuration Admins and Super Admins because it supports scalable, consistent access control and ownership configuration across records, especially where responsibility and permissions need to follow user categories maintained in the platform.

User type fields ​

User type fields are object class fields in Autologyx that store selected users and, where enabled, user groups as values on a record, so administrators can capture responsibility, collaboration, ownership, or other person-based relationships directly in platform data. They are used across record views and standalone forms, can be included in update-object task forms, and are available to sequencer features such as Task Assignment actors, record access configuration, and merge-field contexts including document templates and other supported automations. User type fields matter because they provide a reusable, configurable source of user and group selections that drives task assignment, record access, ownership-related workflows, filtering, and document generation, helping configuration admins design consistent user-driven processes and helping end-users select the right people or groups when working with records.

Show 5 more pages

user type merge fields ​

INSUFFICIENT_EVIDENCE

user type Object Class fields ​

User type Object Class fields are Object Class fields configured to store a user-based value, such as an individual user or a User Group, and are used when records, workflows, and document templates need to reference platform users dynamically. In Autologyx, these fields are especially relevant in merge field resolution, where their values can be inserted into generated content or used by automation steps that depend on user information. This matters because configuration admins can model user assignments directly in record data, while end-users benefit from workflows and documents that automatically resolve the correct user-related values, including User Group Members, improving how User Groups are handled across automation and template-driven processes.

Username ​

Username is the sign-in identifier stored on a user’s account in the Autologyx platform and exposed on the My account page and the user account page. When a Username is edited and saved in My account, Autologyx writes the new value back to the underlying user account record. This matters because Username directly controls how a user accesses the platform: if it is changed before the account is activated, Autologyx automatically sends a new activation email with a new token to the new Username; if it is changed for an active standard admin or Super Admin account, that user must use the updated Username the next time they log in. For end-users and administrators, keeping the Username accurate is essential to successful account activation and ongoing access.

username/password authentication capability ​

In Autologyx, username/password authentication capability is the ability for an account to sign in directly with stored credentials instead of using single sign-on (SSO). This capability is specifically relevant to service accounts, which retain username/password access even when SSO is enabled and password authentication has been disabled for regular users. It is used in user and account configuration, particularly when setting up and managing Internal Service accounts and External Service accounts that must support system integrations, automated processes, or non-interactive access. This matters because it defines how service accounts remain operable in environments governed by SSO policies, and it is an important control point for administrators and security teams when designing access models, enforcing authentication standards, and reviewing platform account usage.

Users ​

In Autologyx, Users are the individual platform accounts that identify people who sign in and interact with the system, and they are managed through the Users administration area and Users list page. This list shows key account information such as Username, Roles, Account Type, and Last Logged In, and, where a user’s role permissions allow, administrators can create new users and open existing entries to edit or delete them from the relevant Administration tile or section. Users are closely tied to roles, account type, authentication objects, and single sign on settings because these settings determine how a person authenticates and what administration areas and platform capabilities they can access. Users also matter for governance and reporting because user data is written to the History/Analytics Database, where it is used to analyse user-level activity such as who created or modified records, completed tasks, or owns specific workflows, supporting audit trails, compliance oversight, and operational analysis.

Users And Groups ​

Users And Groups Visibility ​

Users and groups visibility control ​

Users and groups visibility control is an Autologyx platform capability that governs which users and groups are visible and selectable across platform lists and interactions, using list permissions to tighten and streamline access. It is primarily relevant when configuring how people and groups are exposed in administrative and operational areas where users or groups can be viewed, searched, or chosen, particularly by Configuration admins and Super Admins. This matters because it helps ensure that only the appropriate users and groups are available in the right contexts, supporting cleaner administration, reducing inappropriate selection or exposure, and aligning user and group visibility with related permission models such as list permissions, record access, task assignment, and ownership configuration.

Users list ​

The Users list is the administration page in Autologyx where Super Admins and other authorised administrators view and manage user accounts across the platform. Accessed from Administration > Users, it presents each user as a record and highlights key account details, particularly account type and status, so administrators can quickly identify how a person accesses the system and what administrative capabilities they can hold, including configuration access through appropriate account types and roles. From the Users list, administrators can open user records to create, review, and edit accounts, making it the central control point for user administration, account lifecycle management, and oversight of the platform’s user population.

Users Roles And User Groups ​

INSUFFICIENT_EVIDENCE

Users sub tab ​

The Users sub tab, also shown as the Users tab, is a section within User group permission editing in Autologyx administration where permissions are configured for individual users rather than for user groups. It sits alongside the User groups sub tab when defining the permission sets for a User group, including the default sets such as Owners, Everyone, and Members, as well as any custom permission sets. This sub tab matters to Configuration admins and Super Admins because it provides the user-level view for controlling who can access or act within a User group’s permission model, supporting precise assignment and maintenance of group permissions in the platform.

Users tab ​

The Users tab is the section of the assignee and class permissions interface in Autologyx where administrators manage individual user entries separately from user groups. It is used when editing an Object Class, including creating Class permissions and adding or removing Assignees, and it is the default tab in the refreshed two-tab layout alongside the User Groups tab. Configuration admins and Super Admins use the Users tab to add specific named users by selecting the + button and maintaining user-level access assignments. This matters because it provides direct control over which individual users are assigned or granted permissions for a class, distinct from group-based configuration managed elsewhere in the same interface.

Users' search field ​

The Users’ search field is the control on the Record access tab used to find and select platform users when granting access to a record. It is used alongside the Give access button and the Owner/Assignees list to add users as owners or assignees, making it a key part of record-level access management in Autologyx. This field matters to end-users, configuration admins, and Super Admins because it determines which users can be located and added during access updates; users with a 1 time completion account type are excluded from the search and cannot be selected through this field.

Users, Roles and User Groups ​

Users, Roles and User Groups is the Administration area in Autologyx used to create and manage user accounts and organise access across the platform. It is used by Super Admins and configuration or platform administrators as part of system-wide administration, alongside other global controls such as authentication and shared environment settings. In this area, administrators manage the people who can use the platform, the roles that define their permissions, and the user groups that help organise users for access and administration purposes. This matters because it is the central place for controlling who can sign in, what they can do, and how users are structured across the environment.

users.list permission ​

The users.list permission is an API-assigned permission in the Autologyx platform that controls whether a Config Admin can view lists of users and groups. It is used in the Users and Groups visibility model and is granted exclusively through the API by assigning a dedicated role, rather than through standard in-platform configuration. This permission matters because it determines whether configuration administrators can access user and group directory information needed for administration and setup, while allowing organisations to restrict that visibility separately from broader admin capabilities through role design and permission management.

Uses And Attributes ​

Uses And Attributes is an Object Class field type in Autologyx configuration that is used when defining object class fields as part of the object model for a solution. It is configured within the Object Classes area alongside other field types and contributes to how object data is structured and presented in platform forms and user interfaces. This field type matters to Configuration Admins and Super Admins because choosing the correct object class field type determines how information is captured within an object class, how that class behaves in the platform, and how effectively users can work with the configured data model.

Using An Authentication Object In An Api Call ​

Using an authentication object in an API call means referencing a configured Authentication Object within the Autologyx platform so the call can authenticate to an external service using centrally managed credentials and connection settings. This is used when developers or configuration administrators set up API interactions that need secure access to third-party systems, and it typically forms part of the API call configuration rather than embedding authentication details directly in the request. It matters because it standardises how integrations authenticate, simplifies reuse across multiple calls or workflows, and makes credential administration easier when updating, replacing, or governing external system access.

Using Help and Support ​

Using Help and Support is the Catalyst Knowledgebase section in the Autologyx platform documentation that provides guidance on accessing assistance and support resources while working in Autologyx Catalyst. It is used by end-users as part of the knowledgebase navigation alongside areas such as Getting Started, Finding your way around, and system-specific topics, helping users locate instructions, support information, and related documentation quickly. This matters because it gives users a clear route to self-service help and platform support content, reducing friction when learning the product, resolving issues, and completing work efficiently.

Validation ​

Validation in Autologyx is the field-level configuration used in Form Builder to control what values a user can enter into a task form field. It is applied when configuring specific input types and sets enforced limits or rules such as the maximum number of characters in a Textbox, minimum or maximum values for Numeric fields, future-only dates for Date fields, or the number of files allowed for upload fields. Validation is used alongside other field settings such as default value, description, conditional visibility, and form section placement to shape how data is captured on a form. It matters because it ensures users enter information in the correct format and within permitted limits, improving data quality and helping configuration admins design forms that behave consistently and support downstream process requirements.

Validation section ​

In Autologyx, the Validation section is the part of field configuration where administrators define input rules for supported field types, including Text, Integer, Decimal, Multi select, Email, Phone, Document, and User. Used when creating or editing Object class fields in the Add field panel and related field settings, it controls constraints such as requiring a unique value, limiting the minimum or maximum number of selections, or restricting how many documents can be added. This matters because validation enforces data quality and consistency at the point of entry, ensures fields behave as intended within Object classes and Document Templates, and allows configuration admins to apply business rules such as uniqueness across one or more fields in the same Object class.

Validation settings ​

Validation settings are the field-level configuration options in Autologyx that define and enforce permitted values and selection limits for an Object class field. Used by Configuration admins and Super Admins when adding or editing fields from the Fields list, Edit field panel, Add field panel, and Data Model tab, these settings control constraints such as minimum and maximum values or minimum and maximum selections for supported field types, including Integer, Decimal, Multi select, and Document fields. Validation settings matter because they protect data quality and form behaviour by preventing configurations that would make record create or edit forms impossible to complete, and any updated constraints are applied when a record is next edited, while existing stored data remains unchanged until that point.

Value field ​

In Autologyx, the Value field is the configuration input used to define the expression that sets a variable’s contents, most notably in the Local Variable Actor. It is used in the actor’s configuration panel alongside Source to specify either a static value or a dynamic expression, including Jinja, that derives data from sources such as API Call Output, Document Picker, or Loop Item context. The Value field determines exactly what is stored in the variable for later use in the Sequence, whether that is a literal value, a transformed result, or a selected part of a response using expressions such as {{output}}. This matters to configuration admins and developers because it controls how data is captured, transformed, and reused across workflow steps, and it must be configured carefully to match the target field type and avoid invalid values such as unsupported whitespace or incompatible formats.

Variable Source ​

Variable Source, shown as Source in the Local Variable Actor configuration, defines where a variable’s value is taken from in an Autologyx workflow. It is used by configuration admins when setting or updating Local Variables in the configuration panel, where the source can be a static value or a value supplied by workflow context such as another Actor, including API Call Output, Document Picker data, or a Loop Item depending on the preceding Actor and trigger type. This setting matters because it determines how the variable is populated at runtime, controls how data is passed between actors in a sequence, and allows the same variable to be redefined at different points in a workflow to support changing process context.

Variable Type ​

Variable Type (also shown as Type) is the field used when defining a variable in the Autologyx configuration panel to specify the variable’s data type and therefore the format of values that the platform will store, validate, and pass between workflow components. It is used by configuration admins and developers when configuring Local Variable actors and related variable-driven features such as Gate Variables, API Call outputs, and other actor interactions, with supported local variable types including String, Integer, Decimal, Boolean, Date, Date/Time, JSON, and Document. Variable Type matters because it controls compatibility between a variable’s source and its downstream use: Jinja-generated values must match the selected type, document-based sources remain Document, and the type must stay consistent even when the source changes across workflow paths, ensuring reliable execution and correct handling of data throughout the workflow.

Variables ​

Variables are sequence-scoped data values in the Autologyx platform that store and expose information for use across actors, conditions, and message content within a workflow. They are used in sequence configuration to reference data in commencement conditions, to pass values into integrations such as the API Call Actor, and to insert dynamic content alongside record fields and constants through merge fields in actors such as Send Message. Variable types determine how values can be evaluated and used, including support for JSON variables that can hold complex structured data and large payloads. Variables matter because they enable data-driven automation: they carry values between steps, support dynamic decision-making, allow external API requests to be built from runtime data, and ensure sequences can personalise outputs and coordinate processing reliably.

Variables on your Sequence ​

Variables on your Sequence, also called Sequence Variables, are the data items defined on a sequence that store values available within that sequence’s configuration and runtime logic in Autologyx. They are used wherever a sequence needs to reference sequence-level data, including in Sequence commencement conditions, where the VARIABLE option lets you select and evaluate data held in the sequence’s variables; the operators available depend on the variable’s configured type. This matters because Sequence Variables provide a structured way to capture and reuse sequence-specific data, enabling administrators to control when a sequence starts and helping users and configurators build consistent, data-driven sequence behaviour.

Vault ​

Vault is the secure storage mechanism in the Autologyx platform used to hold sensitive authentication material, including API keys configured in Authorization Objects. It is used when administrators and integrators set up external service authentication, such as keys sent in headers or query strings as part of authentication sequences. Vault matters because it protects credentials from unauthorized access while allowing the platform to use them securely during integrations, making it a core control for secure configuration, compliance, and operational governance.

Vault Variables ​

vector dimensions ​

In the Autologyx platform, vector dimensions is a configuration setting used with the Azure OpenAI actor to define the size of the embedding vectors generated for text processing and similarity operations. It is configured alongside options such as model type and encoding format, and directly affects how content is represented for search accuracy and similarity matching. This matters to configuration admins and developers because the selected vector dimensions influence the quality and behaviour of embedding-based features, making it an important setting when tuning Azure OpenAI integrations for retrieval, matching, and search performance.

Versatile Responses ​

Versatile Responses is the Autologyx capability within the OpenAI: GPT integration that returns GPT-generated output directly into the platform so it can be used by workflows, records, and downstream steps. It is used when configuring GPT-enabled automation, including actors and sequenced processes, where generated text needs to be written back into the system rather than only displayed externally. This matters because it allows configuration admins, developers, and end-users to turn AI-generated content into actionable platform data that can populate fields, update records, and drive subsequent workflow behaviour.

View all ​

View all is an object class permission in Autologyx that allows a user to see all display views for every record in that object class within the Workspace. It is configured in System Configuration as part of class permissions and is primarily used by Configuration Admins and Super Admins when defining record access across an object class. This permission is foundational to broader record-level access, because users without View all who are not the record Owner or Assignee do not get action options for those records, and permissions such as Edit all and Delete all cannot be enabled without it, with View all being automatically enabled when either of those permissions is selected. It therefore matters as the core visibility setting that controls whether users can access records across a class and supports the correct operation of related list and action permissions.

View And Complete Tasks ​

View And Complete Tasks is the end-user activity of opening assigned work in the Autologyx Task Panel, reviewing the task card and related object record details, and carrying out the required manual steps to progress the workflow. It is used in the workspace when users access their task list, select a task, and complete the actions, data entry, or decisions required for that stage of a process. This matters because it is the primary way human work is performed within an Autologyx journey, ensuring tasks are handled by the right user, process state is updated correctly, and operational work moves forward in a controlled and auditable manner.

view class permission ​

View class permission is the permission that controls whether a user can see that a class exists and have its class identity exposed in relational record controls for that class in Autologyx. It is used in child class components, child lookup controls, child record selectors, and child record summaries when users associate child records with parent records. If a user does not have view class permission for the child class, the control hides the child class name and shows only a restricted minimal state; if the user has view class permission, the class name can be shown even when the user does not have record-level permissions such as list, create, or edit. This permission matters because it determines the baseline visibility of class metadata in the workspace and directly affects how clearly end-users can understand and interact with related-record controls, while helping configuration admins design secure, permission-aware user experiences.

View menu ​

The View menu is the display configuration menu available at the top right of record and list pages in Autologyx. It is used to control which optional information panels and summaries are shown when you select a record, including items that open in the side panel such as the Record access tab, Owners information, and Child record summary. In list view, the side panel opens when a record is selected if one or more items are enabled in the View menu. This matters because it lets end users tailor the page layout to the information they need while working with object records and relational records, making related record details and access information immediately visible without leaving the current page.

view permissions ​

View permission is the basic access level in Autologyx that allows a user to see specific platform content and selectable data without granting broader change rights. It is used throughout the platform’s permission model, including class permission sets and the group-based permission system, to control which groups a user can see in areas such as the Add Assignees and Manage Assignees panels, and it is also required for users to select Object record fields when working with Document Templates through the Catalyst Word Add in. This matters because View permission determines what information is visible and available for selection in the user interface, helping configuration admins and Super Admins present only role-relevant items while ensuring end-users can access the records and fields they need to complete tasks.

view record permission ​

View record permission is the record-level access right in Autologyx that allows a user to open and read a specific record and its details without granting change actions. It is used throughout the workspace wherever record access is evaluated, including the Records list and record forms, and it directly controls access to features such as the Activity log for the selected record. This permission also affects the behaviour of related-record interfaces: when a user has view record permission for a parent record but not edit capability, the form opens in read-only mode and controls for adding or removing child records, such as the Create button and child lookup controls, are hidden. For end users and configuration admins, this permission matters because it defines the baseline visibility of record content while enforcing read-only access where update actions are not allowed.

View usage ​

View usage is an Actions menu option in the Autologyx platform that shows where a configuration item is referenced elsewhere in the system. It is available on items such as user groups, object classes and object class fields, and document templates, and is primarily used by Configuration admins and Super Admins when opening administrative lists. For document templates, View usage identifies which sequences generate the template through a DocAuto actor; across other configuration areas, it provides the dependency and reference information needed before editing or deleting an item. This matters because it helps administrators understand downstream impact, avoid breaking existing configurations, and manage platform changes safely.

View usage panel ​

The View usage panel is a system configuration panel in Autologyx that shows where a selected field is used within an object class configuration, helping administrators understand field associations before or after making changes in the Data Model tab. It is used by Configuration admins and Super Admins during object class maintenance, particularly when removing fields from the Fields list, and can open automatically after a field removal action or close if the related field is removed while the panel is open. This panel matters because it provides immediate visibility into how a field is connected within the object class, supporting safer configuration changes and helping prevent unintended impact on dependent configuration elements.

View Users permission ​

The View Users permission is a platform permission that extends a Config Admin user’s ability to see user information across Autologyx beyond the user groups they own. It is used in user group and assignee management, including when editing User group Permissions, working with the Manage assignees tab, and viewing user details from avatars, lists, and dropdowns. In practice, without this permission a Config Admin can manage only the users visible within their owned user groups and can lose access to group member details; with it, they can view user details needed to find, identify, and assign available users as part of configuration and administration tasks. This matters because it controls the visibility required for effective permission management, assignee administration, and broader configuration workflows, and is granted to Config Admins via API.

Viewer panel ​

The Viewer panel is the Autologyx document viewing interface used to open and work with saved documents directly in the platform. It opens when a user selects a saved document in Card view, while editing records, and on Task completion pages, providing a consistent place to access document content as part of everyday workflow. For end-users, the Viewer panel matters because it streamlines document handling by making attached or saved files immediately accessible in context; for configuration admins, it is an important user experience element to understand when designing processes, record interactions, and task pages that include document upload or viewing components.

Views ​

In Autologyx, Views are used in two distinct but related ways: as a View permission within Permission Sets that controls whether a user can see lists, records, or object classes in the application, and as database views in the Analytics Database, where ClickHouse virtual tables combine or pre-aggregate data to simplify reporting and BI integration. Configuration admins and Super Admins encounter View permission when configuring roles, because it determines whether users can access specific configuration areas or object-class data even when Create, Edit, or Delete permissions are restricted. Information Security, Compliance, and Analytics teams encounter analytics views when shaping reusable reporting datasets across the platform’s data model. Views matter because they govern both visibility in the operational platform and the structure of consumable datasets for analysis, making them central to access control, data presentation, and downstream reporting design.

warning icon ​

In Autologyx, the warning icon is a visual indicator shown in the Sequencer when an Actor in a sequence has missing or invalid configuration. It is used during sequence design and configuration to highlight steps that require attention before the sequence is relied on in operation. For configuration administrators, the warning icon provides an immediate way to identify and correct invalid Actors in the sequence definition; for end-users, it helps explain why a configured process step is in an incomplete or incorrect state. This matters because it improves visibility of configuration issues within sequences, helping maintain valid process design and reducing the risk of misconfigured workflow steps.

warning modal ​

In the Autologyx platform, a warning modal, also referred to as a confirm modal, is a dialog displayed to end-users when they trigger certain actions in column configuration on list pages that require explicit confirmation before the action is completed. It is used when actions such as saving changes, resetting to default, or cancelling configuration are selected, giving the user a clear choice to proceed with the action or return to column configuration mode. This matters because it helps prevent unintended changes to list page column settings and ensures users can review or reverse their decision before the platform applies an impactful action.

Web Sockets ​

Web Sockets in Autologyx is an Administration area for managing platform-level WebSocket settings that support real-time communication across the environment. It is used by Super Admins, configuration administrators, and developers or integrators within the Administration section, alongside other shared controls such as authentication, communications, and elements. This configuration matters because it governs how the platform handles live, connection-based interactions at an environment level, making it an important part of setting up and maintaining reliable behaviour for features and integrations that depend on immediate updates or persistent communication channels.

WebSockets ​

WebSockets in the Autologyx platform are a back-end, persistent connection mechanism in Autologyx Catalyst that streams real-time events from the server to connected clients, allowing Object Record updates and task state changes to appear immediately without a manual page refresh. They are used in integrations and real-time user experiences that connect to the platform’s WebSocket endpoint, where API users authenticate with a generated token before the server begins sending event updates. This matters to developers, integrators, super admins, and configuration admins because WebSockets support more responsive interfaces, faster operational awareness, and event-driven solutions, while also introducing connection and throughput considerations such as client connection limits and broadcast event volumes.

WebSockets for Elements ​

WebSockets for Elements is an Autologyx platform capability that enables real-time data synchronisation within Element-based user experiences, allowing information in the interface to update immediately as underlying data or workflow state changes. It is used when building or configuring Elements that need live, event-driven updates as part of Autologyx Catalyst solutions and workflows, rather than relying on manual refreshes or periodic polling. This matters to configuration administrators and developers because it supports more responsive, connected solutions, helping Elements stay aligned with current process activity and improving the end-user experience in scenarios where timely updates are important.

Welcome & Introduction to Catalyst ​

Welcome & Introduction to Catalyst is the introductory documentation section in the Autologyx Catalyst Knowledgebase that orients new users to the platform and its core navigation before they begin day-to-day work. It is used from the Knowledgebase landing page alongside other foundational topics such as Getting Started, Finding your way around, Workspace, and Using Help and Support, and serves as the first point of reference for understanding how Catalyst is organised and how to access the guidance most relevant to a user’s role. This section matters because it helps end-users build a clear starting context for using Autologyx Catalyst efficiently, reducing onboarding time and making it easier to locate the correct features, pages, and support resources across the platform.

Welcome And Introduction To Catalyst ​

INSUFFICIENT_EVIDENCE

What kind of mail service are you using? ​

"What kind of mail service are you using?" is a field in Autologyx Outbound mail setup where administrators choose the outbound email provider and authentication method the platform will use to send emails. It is used when configuring platform email delivery, including settings such as the From email address, backend failure alerts email address, Azure environment, and Microsoft client credentials authentication details. This choice determines which connection options and credentials are required for the mail configuration, and it directly affects whether Autologyx can send notifications and other outbound messages correctly. Autologyx provides three options in this field, and the recommended option is Microsoft Office 365 Exchange (Graph) with OAuth 2.0.

When Actor completed ​

When Actor completed is a trigger condition in Autologyx that starts downstream logic after a specific actor has finished running. It is used in sequence trigger configuration to connect one actor to the next, including common patterns such as continuing after a Relation Lookup Actor, monitoring DocuSign status through an auth object, or passing values into an Update Record actor. In loop-based designs, this trigger has a specific meaning: it fires only after the entire loop has finished processing all items and all item-level branches have completed, not after each individual iteration. This matters because it controls sequencing accuracy and prevents actions from running at the wrong time; for example, using only When Actor completed after a Relation Lookup can cause a following actor to run even when no records were returned, so it is often paired with additional conditions or actor properties to ensure the next step runs only when the completed actor produced the required outcome.

When Actor Completed Trigger ​

In Autologyx, a When Actor Completed Trigger is a sequence trigger condition that starts an actor after a specified upstream actor has finished, and it is used in sequence configuration to control execution order between actors and branches. Configuration admins use this trigger when designing workflows in the Sequencer, particularly to connect parallel branches back into a subsequent step by having each branch feed into the next actor through actor-completion dependencies. This matters because it provides a direct way to coordinate progression through a sequence, ensuring downstream actors run only after the required preceding work has completed and helping structure complex workflows that include parallel execution.

When Loop Item Processed ​

When Loop Item Processed is a Loop actor trigger in the Autologyx platform that fires once for every item handled in a loop iteration. It is used in flow design to connect the Loop actor to downstream branches so that actions, decisions, or updates run separately for each item returned to the loop, such as items produced from a JSON array and stored in local variables. If multiple branches begin with When Loop Item Processed, all of those branches execute for every iteration, making this trigger central to per-item orchestration. This matters to configuration admins and end-users because it determines how repeated work is performed across a collection of items and directly controls whether processing happens item by item throughout the flow.

When Record Updated ​

When Record Updated is a sequence trigger in the Autologyx platform that starts a sequence immediately after an object record is changed. It is used when configuring sequences, including Sequence Runner and DocAuto actor patterns, to react to updates on a record and optionally combine the trigger with supplementary conditions that check which field or value was updated. This trigger matters because it enables update-driven automation, allowing configuration and Super Admin users to launch follow-on processing as soon as record data changes, rather than waiting for manual intervention or a different activation event such as When Sequence Activated.

When Sequence Activated ​

When Sequence Activated is a sequence starting trigger in Autologyx that marks a sequence as one that can be invoked explicitly by another platform component instead of starting automatically from an event such as record creation or update. It is used in sequence configuration within the sequence workspace and is required for sequences that need to be launched by the Sequence Runner actor or exposed in navigation and menus for the same object class. This trigger matters because it controls which sequences are available for activation, enables parent or related-process designs such as sub processes and relation-driven child flows, and provides the entry point for adding conditional logic that should run only when the sequence is deliberately activated.

When Task Completed ​

In Autologyx, When Task Completed is a sequence trigger condition used by the sequence execution engine to start or continue processing after a task reaches completion. It is configured on sequence actors such as the Create Task Actor, where it is one of the default trigger conditions and can be used directly or offset by a defined time period after task completion. This trigger is especially important when downstream workflow logic needs to reference data captured in the completed task, because it allows subsequent steps, routing, and conditions in the Sequencer to act on the final task response rather than on task creation alone.

When Task Created ​

When Task Created is a task lifecycle trigger condition in Autologyx that fires at the point a task is created and is used primarily in sequence configuration for Create Task and Set Task actor behaviour. In the Create Task actor, it is one of the default outgoing trigger conditions, alongside When Task Completed, and it controls when subsequent sequence processing starts in relation to the new task. It is also referenced by the Set Task actor, which can trigger onward processing where the original Create Task outgoing trigger is set to When Task Created. This trigger matters to configuration and super admin users because it determines whether downstream automation, assignments, updates, or related task actions happen immediately on task creation rather than waiting for completion or a time-based offset.

whitespace control ​

Whitespace control, also called a whitespace control modifier, is the Jinja2 syntax that uses a hyphen within template delimiters to trim unwanted spaces and line breaks from rendered output in Autologyx merge fields and document automation templates. It is used when configuring Jinja expressions, variables, and control structures such as loops so that generated content does not include unintended blank lines, extra spacing, or formatting artifacts. This matters because many Autologyx outputs depend on exact rendering, including documents, JSON payloads, boolean values, and API request bodies, where stray whitespace can create inconsistent presentation, invalid formatting, or request failures.

Whitespace Control in Jinja ​

Whitespace Control in Jinja is the use of Jinja template syntax to remove or preserve spaces, blank lines, and line breaks when merge fields and conditional logic are rendered in Autologyx document templates. It is used in document assembly, particularly in .docx merge field configurations where template tags can otherwise leave unwanted gaps or formatting artifacts in the generated output. This matters because correct whitespace control keeps assembled documents clean, readable, and professionally formatted, especially when sections are included conditionally, repeated, or combined with formatted field values and namespaces in Jinja2.

Word Add In ​

The Word Add In is the Microsoft Word integration used in the Autologyx platform to create and configure document templates for generated documents and related content such as email bodies. It provides template authors and configuration administrators with guided support for inserting and formatting merge fields, building conditional logic with If / Else statements, and defining repeating structures such as For or Group Statements directly within Word. The Word Add In is used during template design and maintenance, making it easier to produce comprehensive templates that correctly render platform field values and relational data. It matters because it streamlines template configuration, reduces manual syntax entry, and helps both end-users and admins build accurate, maintainable output documents more efficiently.

Workflow area ​

Workflow area, also called the workflow or Workflow design area, is the canvas in the Sequence Edit design view where Configuration admins and Super Admins build and organise a Sequence’s workflow. It is the main workspace that opens as a blank area when a Sequence is edited for the first time, and it is used to place starting objects for the selected Object class, drag and drop actors and other workflow elements, connect them into the required flow, and visually organise related items with features such as Group/Ungroup. The workflow area matters because it is where the structure, trigger points, and layout of a Sequence are defined, directly determining how records enter and move through the automated process in the Autologyx platform.

workflow engine ​

In Autologyx, the workflow engine is the Sequencer, the platform component used to design and run intelligent pathways that coordinate tasks, decisions, Sequence Actors, and API calls within a process. It is used in sequence configuration by Configuration Admins and Super Admins through the drag-and-drop interface, where authorised users create and edit sequences that define how work progresses across people, systems, and automated steps. The workflow engine matters because it controls the structure and execution of process automation in Autologyx, making it the core mechanism for translating operational requirements into repeatable, governed workflows.

Workflow section ​

In Autologyx, the Workflow section is the area within task template Response Configuration where form and instruction elements are added to define the user-facing workflow for a task. It is used on task types such as Complete self contained form and Update object record, where administrators drag and drop components from the form builder into this section to assemble the sequence and structure of the response experience. The Workflow section matters because it is the primary canvas for configuring what users see and complete during task execution, including how content is organised with items such as section headers, instructions, and conditionally visible elements.

workflow sequence ​

In the Autologyx platform, a workflow sequence is the ordered progression of steps within an automated document workflow that determines when actions are executed for a Record. It is used in process design and system configuration, including Catalyst-driven integrations, to place activities such as generating a document from a template, creating a DocuSign envelope, and sending that document at the correct stage of the workflow. This matters to configuration admins because the workflow sequence controls the timing and coordination of platform actions, ensuring documents are produced and dispatched at the right point in the lifecycle of a Record.

workflows ​

In Autologyx, a workflow is the configured sequence of tasks, data handling, and automation that drives a business process through the platform from one step to the next. Workflows are created and maintained in the system configuration areas by linking task templates, object classes, fields, and related design properties so that work is routed correctly and platform features such as integrations and embeddings can be applied within the process. They are used by configuration admins and super admins when building applications and process designs, and they directly shape the experience of end-users by determining what happens, when it happens, and what information is required at each stage. Workflows matter because they are the core mechanism for delivering efficient, reliable automation in Autologyx, and changes to dependent configuration such as task templates can disrupt or break the process if not managed correctly.

Working with relational records ​

Working with relational records in the Autologyx Workspace is the set of end-user actions used to view and manage records that are linked to one another, including parent and child records and other associated information. It is used from workspace task-focused screens, alongside areas such as the Task Panel and Records, where users need to understand how one record connects to another while completing work. This matters because many tasks depend on navigating between related items, creating related records, and reviewing connected data in context, which helps users complete work accurately and maintain the correct relationships between records across the platform.

Workspace ​

Workspace is the main operational area of the Autologyx platform where users carry out day-to-day work on Records and Tasks. After login, users are taken to the Workspace, which presents system areas such as Records and Tasks and includes features used to view, create, update, and progress object records, manage assigned work, create ad hoc manual tasks, and work with related parent and child records through the Task Panel and related views. Workspace access and what a user can see or do there are controlled by configuration such as Object class permissions, Permission Sets, and task assignment, which determine whether users can create records, view records for an object class, or access and complete tasks. This matters because Workspace is where most end users interact with the platform, while administrators and configurators use its behaviour as the practical outcome of setup decisions made in Administration and System Configuration.

Show 6 more pages

Workspace Sections ​

Workspace Sections, often shortened to Sections, are the distinct areas within the Autologyx Workspace that organise the information and actions users need for day-to-day operational work. Used throughout the Workspace alongside elements such as the Task Panel, Tasks, Records, and relational record views, Sections help users navigate between different types of work and related information within a single working area. This matters because Sections provide the structure that lets end users access the right records, tasks, and connected data efficiently, making the Workspace easier to use for completing operational processes.

Workspace/Records ​

Workspace/Records is the main area of the Autologyx Workspace where users view, search, and filter records by object class and open individual records for work. It is used after records have been created, including from standalone forms, and provides the record list context from which users can navigate into parent records, review associated child records, and use workspace navigation elements such as breadcrumbs and the Actions menu. For end-users, it is the starting point for locating and working on the correct record set; for configuration admins, it is important because object class design and related components such as child object class components, child search controls, and child record summaries determine how records are surfaced and interacted with in this area.

X time period After either Task Created or Completed ​

In Autologyx, X time period After either Task Created or Completed is a configurable trigger condition in the Create Task Actor that delays automatic task creation until a defined interval has elapsed after a reference task is either created or completed. It is used in the Create Task Configuration for sequences, where configuration administrators set the timing that the sequence execution engine uses to determine when the next task should be generated, instead of triggering immediately on task creation or completion. This matters because it enables precise control over sequence timing, supports scheduled or wait-period-driven process steps, and ensures downstream tasks are created at the correct point in the workflow lifecycle.

XML Data ​

XML Data is the API Call actor request body format used in Autologyx when an external endpoint expects payloads encoded as XML rather than form fields, JSON, or binary content. Configuration admins and developers select XML Data in the API Call actor when defining an integration that must send structured XML in the body of an HTTP request, typically to match the schema or protocol required by the target system. This matters because the body format directly affects how Autologyx packages and transmits request data, and choosing XML Data ensures the receiving service can parse and process the payload correctly during execution, testing, and debugging of API-based integrations.

Yes ​

Zoom Actual ​

Zoom Actual is a Navigator view control in the Autologyx platform that resets the current page or design canvas to its default layout and scale after the view has been changed. It is used in Navigation and Menus, typically alongside other Navigator actions exposed through the horizontal action menu and during Edit design activities, to restore a standard on-screen arrangement. This matters to end-users and configuration admins because it provides a quick way to return to the baseline view, making navigation easier, reducing disruption after zooming or repositioning content, and helping users continue working from a consistent layout.

Zuva Document Viewer Element ​

INSUFFICIENT_EVIDENCE

​

{documentId} is a configuration placeholder used in the Autologyx platform when setting up the iManage integration in the API Call actor. It is entered in the actor’s URL input alongside other required placeholders such as {Hostname}, where it represents the target iManage document identifier that the request should address. This matters to configuration admins and developers because the correct document ID is required for the API call to resolve to the intended iManage document, ensuring the actor interacts with the correct content and that the integration behaves as configured.

​

{Hostname} is a configuration placeholder used in the Autologyx platform when setting up URL values, including in the API Call actor for iManage integrations. It represents the hostname portion of the target service address and must be replaced by the person configuring the actor with the correct environment-specific value, alongside other placeholders such as {documentId}. This placeholder is used directly in the URL input so that Autologyx can construct the correct endpoint for calls to external systems. It matters because an incorrect or unresolved hostname prevents the actor from reaching the intended service, making accurate configuration essential for successful integration and execution.

{{p ... }} syntax ​

In Autologyx Document Templates, the {{p ... }} syntax is a .docx merge field format used for paragraph-level insertion of file content stored on a record during dynamic document assembly. It is used when a template needs to pull embedded document content, such as annexes or clauses, into the generated output and replace the entire paragraph that contains the merge field, rather than inserting content inline within surrounding text. Configuration admins use this syntax when designing templates that assemble documents from record data and embedded files, and end-users encounter the result in generated documents that preserve the intended document structure. This matters because it gives precise control over how merged content is placed in the final document, ensuring complete paragraphs of source content are inserted cleanly and in the correct location.