Autologyx Docs

Appearance

Api terminology index ​

This file is built from the saved terminology store.

/api/integrations/ ​

**/api/integrations/** is the Autologyx REST endpoint used to create, list, and retrieve integration configurations that connect the platform to external services. It is used by developers, configuration admins, and Super Admins when setting up or managing outbound and system-to-system integrations, including selecting the integration type, defining core metadata such as name, description, and enabled state, and supplying type-specific settings such as the authentication object, object class, folder, object class field, and deduplication behavior. The endpoint supports standard API patterns for creation, listing, sorting, filtering, and retrieving a single configuration, and its request schema is driven in part by OPTIONS **/api/integrations/**, including details.schema by type for integration-specific fields and validation rules. This endpoint matters because it is the central configuration surface for integration records in Autologyx: the values defined here control how integrations are authenticated, structured, validated, and administered across the platform.

/api/integrations/test/ ​

**/api/integrations/test/** is the Autologyx API endpoint used to validate an integration configuration by submitting a test request against the settings defined for an integration. It is used by developers and configuration administrators when setting up or troubleshooting integrations exposed through /api/integrations/, and follows standard ALX API request, header, schema, status, and response conventions. This endpoint matters because it provides a direct way to confirm that connection details, authentication objects, AuthenticationObjectData, and the selected authorization method are configured correctly before the integration is relied on in live platform processes.

/api/object class forms/ ​

**/api/object class forms/** is the Autologyx REST API endpoint used to create, list, retrieve, and update Object Class Forms, which define the form configuration associated with an object class. It is used by developers and configuration administrators when managing standalone forms and create-form definitions for object classes, including configuring components, custom components, enabled status, and metadata, with access controlled by caller permissions and object-class permissions. This endpoint matters because it is the programmatic interface for governing how users create and interact with Object Records through class-specific forms, enabling consistent configuration, controlled rollout, and integration-driven administration of form behaviour across the platform.

1 Time Completion ​

1 Time Completion is an Autologyx user account type listed in the Users configuration area and used when defining the kinds of accounts available in a tenant. In the platform’s account type limits, 1 Time Completion has a maximum of 5000, making it one of the high-volume user categories that administrators can provision and manage. This matters to Configuration Admins and Super Admins because account type selection controls how users are classified within the environment, affects capacity planning against tenant limits, and helps ensure the correct type of account is assigned for the intended operational use.

1 Time Completion account ​

A 1 Time Completion account is an Autologyx account type that is excluded from ownership and assignee roles across the platform. In configuration and API operations for object classes, object records, permission set assignees, and user group permission set assignees, this account type cannot be set as an Object Class Owner, Object Record Owner, or assignee, and requests that use it in those contexts are rejected with validation errors such as “1 Time Completion account cannot be owner” or “1 Time Completion account "{user id}" cannot be assignee.” This matters to configuration admins, super admins, and integrators because user selection and assignment logic must filter out 1 Time Completion accounts when working with assignees/users endpoints, Permission Set IDs, Object Class Assignees, Object Record Assignees, and related ownership configuration to avoid failed API calls and invalid access setup.

Show 2 more pages

account type ​

Account type is the user classification assigned to an Autologyx user account that determines what kind of account it is within the platform and governs how that account can be created, validated, filtered, and constrained across user-management features. It is used in the Users API and administration screens as a required user field, in User Groups where users can be filtered by exact account type, and in ownership features such as Object Class Owners and Object Record Owners where eligibility is checked against account type and some account types cannot be assigned as owners. Account type also matters because Autologyx enforces separate limits for each account type, applies account-type-specific validation and behaviour such as whether roles can be assigned to config admin accounts, and exposes it in user listings and related metadata so administrators and integrators can correctly provision users, control access patterns, and avoid invalid configuration or exceeded account limits.

actions ​

Actions, also shown as valid actions, are the allowed operation names that can be assigned to a resource within an Object Record permission set in Autologyx. They are used when configuring permissions for resources such as object records and tasks, where each resource accepts a defined list of actions—for example, object records support edit, view, and delete, while tasks support create, edit, view, delete, complete, and assign. These action values are submitted as part of the permission-set configuration for an object class, validated by the platform, and converted together with any required permission dependencies. This matters to Configuration admins and Super Admins because actions determine exactly what users can do with records and tasks, and sending an incorrect action or omitting an existing one during an update can result in validation errors or the removal of permissions that are not retained through dependency rules.

Activation link valid period is the Security Rules setting that defines, in days, how long an Autologyx account activation link and its activation token remain valid before expiring. It is used in the platform’s security configuration alongside password complexity, password reuse prevention, password rotation interval, and authentication method controls, and is exposed through the /api/security/ GET and PATCH endpoints as the systemconf.activation link valid period integer value. This setting matters to configuration administrators and Super Admins because it controls the window in which newly issued activation links can be used, helping balance onboarding convenience with security and compliance requirements by limiting how long an unused activation link remains active.

Actor completed ​

Actor completed is a Sequencer trigger condition used when connecting one actor to run after another actor has finished execution. In Autologyx, it is configured on connections between actors and is relevant in flow design where a downstream actor, such as an API Call actor, should start only after the preceding actor completes. This trigger matters because it defines execution context: in testing, Sequencer-specific merge fields that depend on loop iteration context are not populated when an API Call actor is connected using Actor completed, and resolve to an empty string instead. For configurations that need loop item data or other loop-scoped merge fields, the downstream actor must be triggered from the loop processing path rather than by Actor completed.

add roles ​

Add roles is the Users API operation that appends one or more roles to a user’s existing role assignments without replacing them, and is exposed as the PATCH /api/users/{id}/**add roles**/ endpoint for updating an individual user or in batch workflows for applying roles across multiple users. In Autologyx, it is used by integrators and administrators when provisioning access, expanding responsibilities, or aligning users with permission models defined through roles and related controls such as account type, super admin status, and meta.permissions. This operation matters because roles directly govern what a user can see and do in the platform, so using add roles ensures access can be extended safely and incrementally while preserving current assignments and supporting controlled administration at scale.

adding records ​

In Autologyx file upload workflows for Object Records, adding records is the backend processing stage that starts after antivirus scanning and file saving are complete, when the platform creates records from the uploaded files and adds them to the target Object Class. This term is used in the WebSocket file upload event flow in Catalyst, where clients monitor upload processing through progress responses and status updates after completing multipart upload steps and submitting files for backend handling. Adding records matters to developers and integrators because it marks the point at which uploaded content becomes usable Object Records in the data model, enabling downstream Object Records changes, class-based processing, and any automation or integrations that depend on the records existing in the correct Object Class.

additional authorization headers ​

Additional authorization headers are a JSON object field in an Authentication Object that lets you define extra HTTP headers to be sent as part of the authorization request for supported OAuth-based providers, particularly Generic Client Credentials integrations. This field is configured in the credentials section alongside values such as client ID, client secret, token URL, refresh URL, and additional parameters, and it is validated as a non-null JSON object. It matters when an external identity provider or token endpoint requires custom headers beyond the standard authentication payload, allowing configuration admins and integrators to adapt Autologyx authentication to provider-specific requirements without changing platform code.

additional limits ​

In the Autologyx platform, additional limits are a set of limit values exposed as an object in the Limits resource for platform constraints where a corresponding usage count is not provided. They are used in API and administrative limit information alongside other count-based limits to show the configured boundaries that apply to tenant or platform operation. This matters to developers, integrators, and Super Admins because these values define enforced operational caps that must be considered when designing integrations, monitoring platform capacity, and configuring services, even when current consumption for those specific limits is not available.

additional parameters ​

In Autologyx, additional parameters are an optional JSON object field used in the credentials payload of a Generic Client Credentials authentication object to supply extra key-value pairs required by an external token service beyond the standard fields such as client ID, client secret, scope, token URL, and refresh URL. They are configured when creating or updating authentication objects for integrations that use non-standard OAuth token request parameters, and they sit alongside related settings such as additional authorization headers. This matters to configuration admins and integrators because it allows Autologyx to authenticate successfully against providers with custom token endpoint requirements without changing platform logic, while validation rules require the value to be a valid JSON object and not null.

Admin Context ​

Admin Context is a system merge field category in the Autologyx platform that exposes information about the system administrator for use in template-driven content and automation. It is used wherever merge fields are supported, such as document templates and email templates, allowing configuration admins and Super Admins to insert administrator-related values alongside other system contexts such as Client Context, Date and Time Context, Constants Context, and Loop Item Context. This matters because it enables centrally managed, reusable templates and messages to include administrator information consistently without hard-coding values, improving maintainability and standardisation across configured outputs.

AdminContext ​

AdminContext is a default Autologyx context that provides administrative, system-level information for merge fields and related runtime expressions. It is part of the DefaultScope foundation and is available in both Sequencer Actor and Document Generation scopes, which means it can be used when configuring workflow logic as well as when generating documents. AdminContext matters because it gives configuration admins, super admins, and integrators consistent access to core system information across key platform scopes, supporting reusable templates, standardised configuration, and predictable behaviour wherever default contexts are available.

Adobe Client Credentials ​

Adobe Client Credentials is an Authentication Object provider in the Autologyx platform used to store the client credentials configuration for Adobe integrations that authenticate with the client credentials flow. It is configured in Authentication Objects by selecting the provider as Adobe Client Credentials and supplying the required credentials fields: client id, client secret, and scope. This authentication object can then be referenced by integrations or automated processes that need to obtain access tokens for Adobe-connected services. It matters because it standardizes how Adobe authentication details are created, validated, and managed in Autologyx, helping configuration administrators and developers set up secure reusable connectivity without embedding credentials directly in process logic.

AI Actors ​

INSUFFICIENT_EVIDENCE

All AI Actors ​

All AI Actors is the collective term for the AI-powered actors in the Autologyx platform, used to describe functionality or configuration that applies across every AI actor rather than to a single actor type. In practice, this term is used in feature availability and configuration guidance—such as merge field custom filter support—to indicate that the same merge field processing behavior is available throughout all AI actor implementations. This matters to configuration administrators and developers because it identifies platform-wide consistency: when a capability is documented as supported in All AI Actors, it can be used when designing prompts, messages, or inputs for any AI actor without needing actor-specific handling for that feature.

allow on demand generation ​

Allow on demand generation is a boolean setting on an Object Class Document Template that controls whether that template can be generated directly for an individual object record through the object record documents endpoints. It is configured when creating or updating a document template and is also exposed in document template and object record document list and detail responses, where it can be used for filtering and ordering. This setting matters because it determines which templates are available for ad hoc document generation in the document generation process, helping configuration admins and integrators control user access to template-driven document creation, limit generation to approved templates, and design integrations that only present or trigger generated documents for templates explicitly enabled for on-demand use.

ALX API standards ​

ALX API standards is the Autologyx developer guide that defines the platform-wide conventions for working with API endpoints, especially the standard filtering predicates and related query behaviours supported for each resource type. It is used alongside endpoint documentation for resources such as Tasks, object classes, user groups, object record uploads, and integrations, where individual pages list sortable fields and then direct developers to the ALX API standards for the full set of supported predicates. This matters because it provides the shared rules needed to build consistent API requests across the platform, validate integrations against endpoint expectations, and correctly configure queries for endpoints such as /api/integrations/ and related API resources.

Show 1 more pages

ALX API standards Developers guide ​

The ALX API standards Developers guide is the core developer reference that defines the standard API conventions used across the Autologyx platform, particularly for common query behaviour such as filtering predicates and related request patterns. It is used alongside resource documentation for platform endpoints such as Roles, Task Group Templates, and Events, where those pages defer detailed filter syntax and standard predicate definitions to this guide instead of repeating them. This guide matters to developers and integrators because it provides the shared rules needed to build consistent API requests, apply supported filters correctly across object classes, and interpret resource-specific documentation in a uniform way when integrating with Autologyx services.

ALX Catalyst BE ​

ALX Catalyst BE is the backend component that consumes the presigned URL returned by the Event History Files API, such as GET /api/files/upload_url, to upload a file directly into history storage before that file is referenced by a History Event. It is used within the Event History microservice file-handling flow when integrating event workflows that attach files stored in S3. This matters to developers and integrators because the upload performed by ALX Catalyst BE is a required step in the platform’s history event process: files must be placed in history storage through the presigned URL workflow before an event can be recorded with an associated file.

ALX system ​

In the Autologyx platform, the ALX system is the runtime environment that renders dynamic content across generated outputs such as documents, emails, and other templates. It is used wherever template-driven content is produced, including document templates, email templates, and merge-field processing, where live platform data is inserted into rendered content through features such as Merge Fields and Object Record Merge Fields. This matters to end-users because it determines how business data is presented in communications and generated artefacts, to configuration administrators because they define and maintain the templates and fields that the ALX system renders, and to developers and integrators because platform templating behaviour is implemented using Jinja2 and underpins how data is transformed into final output.

anonymized ​

In the Autologyx platform, anonymized describes a user account whose identifying user record has been anonymized, which affects how that user participates in platform configuration and assignment features. This is used in areas such as Object Class Permission Set assignees, where an anonymized user is automatically removed from the assignee list and no longer retained as an active assignment target. This matters to Configuration Admins and Super Admins because user anonymization directly impacts permission-set assignment integrity, access administration, and the accuracy of assignee configurations linked to object classes.

anonymized user assignee removal ​

Anonymized user assignee removal is the Autologyx platform behavior that automatically removes a user from a permission set’s assignees when that user has been anonymized. This applies where user assignees are managed for permission sets, including Object Class permission sets and User Group permission sets, and is reflected in the assignee management APIs such as the assignees/users endpoints. For administrators and integrators, this matters because assignee lists remain aligned with the current user record state without requiring separate cleanup, which helps keep permission set assignments accurate for configuration, access administration, and compliance-sensitive user lifecycle management.

any, password, sso ​

In Autologyx, any, password, and sso are the valid enum values used for the authentication method setting within Security Rules, where administrators define how users are allowed to sign in. These values are exposed through the /api/security/ configuration for user categories such as internal, external, full, and super admin, and determine whether an account can authenticate using either supported method (any), only a local Autologyx password (password), or only single sign-on via an external identity provider (sso). This setting matters because it controls access behavior across user types, supports alignment with organisational security policy and identity architecture, and ensures authentication is configured consistently alongside related controls such as password complexity, password reuse prevention, password rotation interval, and activation link validity.

API Actor ​

An API Actor in the Autologyx platform is a configurable integration component that accepts parameter inputs when making API-based interactions, and those inputs can be populated dynamically using merge fields from Object Records. API Actors are used in workflow and integration configurations wherever external systems need data passed from Autologyx, alongside other merge-field-enabled resources such as document templates and email content. This matters to configuration admins and developers because it allows API requests to be driven by live case or record data, reducing manual input, improving consistency across integrations, and enabling more flexible, data-driven automation.

API Call ​

API Call actor ​

An API Call actor is a Sequencer actor in the Autologyx platform that sends an HTTP request to an external service as part of a workflow. It is configured and used within sequences, where administrators and developers define the request details and can populate API call parameters with merge fields, including loop-driven values and supported custom filters, to pass Object Record data dynamically at runtime. The API Call actor is closely related to API Call testing, merge field rendering, and downstream actor execution, because its behavior and the values it sends depend on sequence configuration, trigger paths such as Loop item processing, and the data context available when the actor runs. It matters because it is the primary mechanism for integrating Autologyx workflows with external systems, automating data exchange, and ensuring that sequence actions use the correct record-specific information.

API Call test ​

API Call test, also referred to as testing an API Call actor or testing mode, is the Sequencer test context used to evaluate an API Call actor’s configuration and merge field rendering before live execution. In Autologyx, it is used by configuration admins and developers when validating API Call actors, especially those placed downstream of a Loop actor, to confirm that fields such as loop item resolve against the current iteration data exactly as the test context supplies it. During this test process, nested properties are rendered, misconfigured loop sources fall back to the first available item where possible, exceptions resolve as empty strings, and when multiple Loop actors are connected the most recently modified Loop actor is the one used for evaluation. This matters because API Call test determines how request data is previewed and validated in design time, helping users configure integrations correctly and avoid incorrect results caused by trigger choice, loop configuration, or merge field context.

API History Event microservice ​

The API History Event microservice is the Autologyx service that manages history-event data and related file handling outside the main Autologyx application, providing endpoints for tenant mapping and file upload flows used when recording events. It is used by administrators and integrators to connect a client instance in the main system to its dedicated history storage, with tenant records linking the client instance database name to the corresponding client-specific ClickHouse history database created during client setup, alongside a matching entry in the default ClickHouse database. It also supports workflows in which a history event must reference a file stored in S3, requiring the file to be uploaded through the service by presigned URL before the event is recorded. This microservice matters because it underpins how history data is separated by tenant, how external systems authenticate and call history endpoints, and how Autologyx preserves a structured, queryable record of events and associated files for operational, compliance, and analytics use cases.

api key ​

An API key in Autologyx is a credential type used in an Authentication Object when an external service authenticates requests with a static key rather than OAuth or username/password credentials. For the **api key** provider, the authentication object stores the key itself as **api Key** together with header key and url key, which define how the platform sends that value to the target system in request headers or URL parameters during integrations. API keys are used by developers, integrators, and configuration administrators when setting up connector authentication and service-to-service access, and they are also validated on protected platform endpoints, where an invalid key returns 401 Unauthorized with Unauthorized **API Key**. Because the API key directly controls whether requests are accepted, configuring the correct key and placement is essential for successful integration calls, tenant-related API operations, and secure access management across the platform.

approval conditions ​

Approval conditions are the task template configuration object that defines the rules governing task approval within Autologyx. They are set on each task type entry in the Task Templates API and are carried into the task’s configuration when a task is created, alongside related settings such as approval required and task creation. In practice, approval conditions are used wherever a task needs controlled sign-off behaviour, allowing developers and configuration administrators to specify how approval is applied as part of the task definition rather than at runtime. This matters because approval conditions make approval handling consistent across tasks created from the template, ensuring the platform enforces the intended approval model for that task type.

approval required ​

In Autologyx, approval required is a task configuration setting that determines whether completion of a task must pass through an approval step before it is treated as fully accepted in the workflow. It is used in task configuration and is exposed in task API payloads within the task’s plugin config, alongside related settings such as approval conditions. This setting matters because it changes how task outcomes are controlled: when enabled, task completion is subject to defined approval rules rather than being final immediately, which affects task state handling, downstream next actions, and the overall governance of task-driven updates to object records or other workflow data.

array index ​

An array index, also referred to in merge field filters as the index parameter or Mandatory array index, is the required numeric position used to select a specific attachment from a document field that stores multiple files in Autologyx. It is used in merge field custom filters for image embedding and DOCX embedding within document templates, where the field alias is combined with an index value from 0 to 99 to identify which attachment to render. This matters because document fields can contain up to 100 attachments, and the array index ensures the correct file is inserted into the generated document; if the index is missing, the embedding filter returns an empty string, so template authors and configuration admins must supply the correct index for reliable output.

Array source ​

Array source is a Loop actor source type in the Autologyx Sequencer that iterates over elements in an array and exposes each element as the current loop item for every loop iteration. It is used when configuring loops that process structured list data, including data supplied directly as an array or passed into downstream actors such as an API Call actor, where merge fields can reference the current item and its nested properties in the execution context of that iteration. This matters because choosing Array source determines how loop item data is populated and accessed, which directly affects merge field resolution, downstream actor behaviour, and whether a loop-driven configuration processes each array element correctly.

assign users for Object Record Permission Set ​

INSUFFICIENT_EVIDENCE

assignees ​

Assignees are the users or user groups explicitly attached to an Object Class or Object Record permission set in Autologyx, defining who receives that permission set for the targeted class or record. They are used in configuration and API operations that add assignees to permission sets, in record history where assignees added and assignees removed events are tracked, and in related permission-set objects identified by Permission Set ID. This matters because assignees are the mechanism for granting targeted access and participation at class and record level, enabling administrators and integrators to control exactly which people or groups can act under a specific permission set, audit those changes over time, and manage assignments in bulk while observing platform rules such as no assignees on everyone or members permission sets and restrictions on unsupported account types.

assignees added ​

Assignees added is an event type recorded in Autologyx history data when one or more assignees are added to an object record. It is used in Object Records History Events and in the Event History API, where it appears alongside the event id, event datetime, and source type to classify a specific change made to a record. This event matters to developers, configuration administrators, and compliance or analytics teams because it provides a clear, queryable audit trail of assignment activity, supporting integrations, reporting, operational monitoring, and governance over how responsibility for work is allocated within the platform.

assignees removed ​

Assignees removed is an event type in Autologyx history data that records when one or more assignees are removed from an object record. It is used in Object Records History Events and the Event History API alongside related lifecycle and change events such as assignees added, owners added, owners removed, and field values changed, and is returned with standard event metadata including event id, event datetime, and source type. This event matters to developers, configuration administrators, and compliance or analytics users because it provides a definitive audit trail of assignment changes, supports integration logic and reporting on work allocation, and helps verify who was removed from responsibility for a record and when that change occurred.

assignees/user groups endpoint ​

The assignees/user groups endpoint (/api/user groups/{group id}/permission sets/{permission set id}/assignees/user groups/) is the Autologyx API endpoint used to manage user-group assignees for a specific permission set attached to a user group. It is used in developer and administrative integrations when configuring which user groups are assigned to a given permission set within the user-groups permission model, alongside related assignee management endpoints such as the users variant. This endpoint matters because it provides the programmatic mechanism for creating and maintaining permission set assignee records, enabling controlled access configuration, scalable group-based permission administration, and consistent automation of security and platform setup.

assignees/users endpoint ​

The assignees/users endpoint is the Autologyx REST API resource used to manage direct user assignments on a permission set for a specific object class, object record, or user group. It is exposed as context-specific routes such as /api/object records/{record id}/permission sets/{permission set id}/assignees/users/ and /api/user groups/{group id}/permission sets/{permission set id}/assignees/users/, where GET returns the current user assignees, POST creates new user assignee records, DELETE removes assignees in batch, and OPTIONS returns the schema for supported operations. This endpoint is used by developers, configuration admins, and super admins when configuring access control at a granular level, because it defines which individual users receive the permissions granted by a selected permission set on the target resource. It matters because it is a core mechanism for implementing explicit access assignments, enforcing permission-set design, and administering secure access consistently across object classes, records, and user groups, with platform limits such as a maximum of 100 assignees per operation or permission set context.

attached roles ID's after create user ​

Attached roles ID’s after create user is the Single Sign On configuration field, exposed as the roles parameter, that defines which Autologyx role IDs are automatically assigned to a user when auto create user is enabled and the platform creates that user during first sign-in through an SSO provider such as Azure or Okta. It is used in the SSO configuration request, update, and response schema, where administrators and integrators set the role mapping for newly provisioned users. This setting matters because it determines the user’s initial access model in Autologyx immediately after account creation, controlling what the user can see and do through the permissions associated with the assigned roles.

authenticated user preferences ​

Authenticated user preferences are user-specific settings stored in Autologyx for the currently signed-in user and accessed through the User Preferences API, including endpoints such as GET /api/users/preferences/{key}/ and POST /api/users/preferences/{key}/. Each preference is identified by a preferences key and is typically used by applications and integrations to save and retrieve personal interface and workflow settings, such as frontend layout configuration, filtering, sorting, and table column selections. This matters because it allows developers and integrators to deliver a consistent, personalised experience for each authenticated user, while ensuring those settings can be programmatically created, updated, and reused across sessions.

authentication method ​

In Autologyx, the authentication method is the security rule that defines which sign-in mechanism is permitted for each account type in the platform. It is configured in the Security Rules settings and exposed through the /api/security/ endpoints as an **authentication method** object, with account-type keys such as internal, external, full, and super admin, and supported values including any, password, and sso. This setting is used when administrators review or update platform security configuration, because it controls whether users in each account category must authenticate with a password, must use single sign-on, or can use either method. It matters because it enforces organisation authentication policy consistently across user populations, supports security and compliance requirements, and ensures the correct access model is applied to standard users, external users, service accounts, and privileged administrators.

authentication objects ​

Authentication objects are reusable configuration records in Autologyx that store the credentials and provider-specific connection details used to authenticate platform integrations with external services and, in some cases, other Autologyx endpoints. They are managed through the Authentication Objects resource and API, referenced from integration configuration such as the authentication object field exposed by /api/integrations/ and validated through related integration endpoints, with provider-specific schemas for services such as Microsoft Client Credentials, DocuSign, Box, Adobe, iManage, and generic OAuth patterns. Authentication objects matter because they centralise credential management, enforce provider-specific validation and platform limits, support expiry and access control through permissions and roles, and allow administrators and integrators to attach the correct authenticated connection to integrations without embedding credentials directly in each integration definition.

AuthenticationObjectData ​

AuthenticationObjectData is the Autologyx platform record type referenced by integration endpoints when an authentication object is supplied as a primary key, and it represents the stored authentication configuration that an integration uses to connect securely to an external service. It is used in API requests such as /api/integrations/ and /api/integrations/test/, where the authentication object field must contain the ID of an existing authentication object record; if the value is missing, invalid, or does not exist, the platform returns a validation error identifying **AuthenticationObjectData**. This matters to developers, configuration admins, and Super Admins because integrations cannot be created, updated, or tested successfully unless they reference the correct authentication object, making this record a core dependency for configuring authorization methods and ensuring integrations comply with Autologyx API standards.

Authorization header ​

  • Mostly relevant to: Developers / Integrators, Configuration admins, Super Admins
  • Closely related concepts: api key, Microsoft SSO OAuth2 On Behalf On, API History Event microservice, ALX Catalyst

The Authorization header is the HTTP request header Autologyx services use to carry authentication credentials when a client calls protected endpoints. In Autologyx documentation it is used in API and integration contexts such as the API History Event microservice tenant endpoints and Microsoft SSO OAuth2 On Behalf Of flows, where the header must contain the correct token or API key expected by the target service. It matters because Autologyx validates this header before processing the request: if it is missing, malformed, or contains the wrong credential, the platform rejects the call with an unauthorized error, preventing access to tenant management and other secured operations. For developers, configuration admins, and super admins, understanding the Authorization header is essential when configuring integrations, troubleshooting 401 responses, and ensuring that each service receives the right authentication mechanism in the required format.

authorization method ​

Authorization method is the integration setting that defines how Autologyx authenticates an outbound mail configuration when connecting to the SMTP service. It is used in the SMTP settings and integration administration APIs, including configuration and test endpoints, where it is set to either username and password or microsoft client credentials. This field determines which credentials the platform expects and validates: standard mailbox credentials for username and password, or a linked authentication object for microsoft client credentials, with the authentication object required and checked for the correct provider type when that method is selected. For configuration admins and Super Admins, this setting matters because it controls how outbound email is authorized, directly affecting whether email sending and related failure notifications can be configured and tested successfully.

auto create user ​

Auto Create User is a Single Sign-On (SSO) configuration setting in Autologyx that controls whether the platform automatically creates a user account when someone successfully authenticates through an external identity provider but does not already exist in Autologyx. It is used by configuration administrators and Super Admins when setting up Azure application SSO or Okta-based SSO, alongside provider details such as the Azure tenant identifier or Okta tenant domain, and the roles assigned on creation. This setting matters because it determines whether first-time SSO users can be onboarded immediately at login or must be created in advance, directly affecting access provisioning, user administration, and the initial role mapping applied to new accounts.

autocomplete ​

  • Mostly relevant to: Developers / Integrators
  • Closely related concepts: API calls

In the Autologyx platform, autocomplete is a Users API endpoint (GET /api/users/**autocomplete**/) that returns a simplified array of user records formatted for selection controls, with each result providing a value field containing the user ID and a text field containing the display string. It is used by developers and integrators when building user lookup, picker, or search experiences that need to populate a list of matching users from query parameters rather than retrieving full user objects. The endpoint also supports standard API filtering and ordering, including sorting by text, which makes it suitable for responsive, consistent user-selection behaviour across custom integrations and UI components. This matters because it provides a lightweight, predictable way to supply user choices in forms and workflows while reducing payload size and aligning custom implementations with Autologyx API conventions.

autocomplete relative url ​

In the Autologyx platform, an autocomplete relative URL is API metadata returned in an OPTIONS response that tells a client which relative endpoint to call to populate an autocomplete field for a related resource. It is used in endpoint schemas and other API metadata for resources that expose relationship fields, including cases involving filtering predicates, nested schema handling, permission-related fields, file fields, and owners types. This matters to developers and integrators because it provides the canonical lookup path for building dynamic selection controls, ensures client applications query the correct resource collection for list and detail workflows, and supports consistent implementation of searchable, permission-aware autocomplete behaviour across the Autologyx API.

autocomplete widgets ​

Autocomplete widgets are Autologyx selection controls that populate searchable option lists by calling dedicated /autocomplete/ API endpoints for platform resources such as object classes, object class fields, task templates, task group templates, and user groups. They are used wherever a configuration or custom component needs a user to find and select an existing platform object without loading the full resource list, and they typically support standard query-parameter filtering and ordering in line with ALX API standards. For developers and configuration admins, autocomplete widgets matter because they define the expected lightweight lookup pattern for building forms, template configuration screens, and integrations: the widget consumes compact results such as display text and underlying values, enforces permitted choices, and relies on the correct resource-specific autocomplete endpoint to deliver responsive, accurate selection behaviour across the platform.

Autologyx ​

In Autologyx, Autologyx is a provider type used in Authentication Objects to store the credentials required for one Autologyx environment or service to authenticate to another using an email-format username and password. It is used when creating and listing authentication objects through the platform API and configuration interfaces, where provider is set to **autologyx** and the credentials payload must contain valid Autologyx login details. This matters to configuration admins and integrators because selecting the Autologyx provider ensures the platform applies the correct validation rules and credential structure for Autologyx-to-Autologyx connections, enabling reusable, centrally managed authentication that can be referenced by configured integrations and automation.

Autologyx API ​

The Autologyx API is the platform’s JSON-based application programming interface, used by developers and integrators to read, create, update, and query Autologyx data through defined endpoints across configuration, workflow execution, integrations, permissions, event handling, and operational services. It is used wherever external systems, custom applications, or internal services need to interact with platform resources through a stable contract, including support for consistent schema definitions, strong typing, filtering predicates, ordering, list and detail views, nested schema structures, permission fields, and non-modifiable properties. This matters because the API standards applied across Autologyx make requests and responses predictable, enforce validation and error handling consistently, and give integrators clear expectations when building reliable, maintainable solutions on the platform.

Autologyx frontend application ​

The Autologyx frontend application is the platform’s user-facing web application where configured forms and record interactions are presented to end users. In Autologyx, it is used as the host for Object Class Forms defined in form configuration, allowing those forms to be rendered as part of the main application experience rather than only as standalone pages. This matters to configuration admins and developers because form design, object class setup, and custom component integration must align with how the frontend application displays and uses forms to create, view, and update Object Records.

Autologyx main system ​

available resources ​

In Autologyx, available resources, also shown as resource keys, are the defined permission targets and their action sets that can be assigned within an Object Class Permission Set for an object class resource. They are used by Configuration Admins and Super Admins when configuring Object Class level access, where each resource key exposes the actions that can be granted for that object class, such as create, edit, view, delete, complete, or assign, depending on the resource. Available resources matter because they determine the exact operations a user or role can perform against an object class, making them the core mechanism for designing, reviewing, and controlling functional access in platform configuration.

available use ​

Available use is the required configuration object on a Custom Component that defines where that component can be surfaced in the Autologyx platform. In the Custom Components API and related configuration workflows, it is provided as a JSON/object with boolean flags for supported contexts such as landing page, object class create form, object class summary form, object class standalone form, and task template form. This setting is used when creating, updating, and retrieving custom components, alongside fields such as component status, index url, parameters, and meta.permissions. It matters because it controls the placement and usability of a custom component across platform screens, ensuring the component is exposed only in the intended UI locations for the relevant object class or task configuration experience.

AWS Event Bridge Lambda ​

AWS Event Bridge Lambda is the integration component used by the Autologyx Event History service to create history event records in a client’s ClickHouse history database through the Event History API endpoint. It is used in the platform’s event ingestion flow for storing event data and event types as part of the historical activity captured for each client environment, alongside the tenant-specific ClickHouse database created during client setup. This matters to developers, integrators, and compliance or analytics teams because it is part of how Autologyx records, routes, and persists operational history, supporting downstream reporting, auditability, and standards-aligned event processing within the platform.

Azure application SSO ​

Azure application SSO is an Autologyx Single Sign-On configuration for Microsoft Azure that connects the platform to an Azure application using a client ID and Azure tenant identifier. It is used in the Single Sign On Configuration area by configuration administrators, Super Admins, and integrators when defining an SSO provider, enabling or disabling the integration, setting user auto-creation and assigned roles, and optionally enabling support for the Word Add-in. This configuration matters because it controls how users authenticate to Autologyx through Azure, standardises sign-in for a specific Azure application and tenant combination, and is subject to platform validation rules, including uniqueness constraints and a restriction that only one Word Add-in-enabled configuration can exist for the same Azure application SSO defined by the same client ID and tenant ID.

Azure tenant identifier ​

An Azure tenant identifier is the Azure-specific value entered in the tenant id field when configuring an Azure application SSO provider in Autologyx. It identifies the Microsoft Entra ID tenant that the SSO configuration connects to and is used alongside the client id and related sign-in settings in the Single Sign On Configuration workflow. This field is relevant to configuration admins, super admins, and integrators creating or updating Azure-based authentication, including setups that use features such as auto create user, logout URL handling, and Word Addin support where applicable. Supplying the correct Azure tenant identifier is essential because it binds the Autologyx SSO configuration to the intended Azure directory and ensures users authenticate against the correct organization.

Box Client Credentials ​

Box Client Credentials is an Authentication Object provider in Autologyx used to store and manage the credentials required for Box client-credentials authentication. It is configured when creating or updating an authentication object with the provider value **box client credentials**, where the credentials payload includes client id, client secret, optional scope, box subject type, and box subject id. This provider is used in integrations that need Autologyx to authenticate to Box on behalf of a specific Box subject defined by the subject type and subject ID. It matters because selecting this provider and supplying the correct Box-specific fields enables Box-connected actions to authenticate successfully, while incorrect or missing values prevent the authentication object from being created or used.

box subject id ​

Box subject id is the required string field in a Box Client Credentials authentication object that identifies the specific Box subject the Autologyx platform authenticates as when requesting access tokens. It is configured in the credentials payload alongside client id, client secret, scope, and box subject type, and is used anywhere Box Client Credentials authentication objects are created or maintained through the Authentication Objects API or related configuration tooling. This field matters because it binds the authentication object to the exact Box user or enterprise defined by the accompanying box subject type, ensuring Autologyx connects to the intended Box context and applies the correct access scope for integrations and automated actions.

box subject type ​

Box subject type is an enum credential field used when configuring a Box Client Credentials authentication object in Autologyx. It is supplied alongside client id, client secret, scope, and box subject id in the credentials payload, and it identifies the type of Box subject that the authentication should act as for the specified subject ID. This field is used in authentication object creation and validation for Box integrations, where it is required and must contain a valid enum value. It matters because Autologyx uses it to correctly construct the Box authentication context for API access, so configuration admins and integrators must set it correctly to ensure Box-connected processes authenticate against the intended Box subject.

buffered events ​

Buffered events are Catalyst WebSocket events that were generated after the current broadcast message reached its limit of 1,000 items, so they are temporarily held in a server-side buffer and sent in the next WebSocket response when the next delivery interval or another response threshold is reached. This behaviour is used in the Catalyst Websockets API, where endpoints broadcast real-time updates in batches every 5 seconds, and it is important for developers and integrators designing event-driven clients because it affects how update volume, batching, and delivery timing should be handled. Buffered events are not preserved across a connection interruption: if the WebSocket connection is disconnected while events remain in the buffer, those events are discarded and are not replayed after reconnecting.

Catalyst ​

Catalyst is the Autologyx platform API surface used by developers, integrators, and advanced configuration administrators to interact with platform services programmatically. It is used through the Catalyst API documentation and related references for core platform operations, payload structures, API conventions, merge fields, event history, and WebSockets, making it the technical entry point for building external integrations and real-time or event-driven solutions. Catalyst matters because it provides the standard way to retrieve and update platform data, connect Autologyx with other systems, and implement integrations that depend on consistent service interfaces across the platform.

Catalyst API endpoint ​

The Catalyst API endpoint is the HTTP endpoint used to obtain the UUID v4 authentication token required to establish a connection to the Catalyst Websockets API. In the Autologyx platform, it is used by developers and integrators before opening a WebSocket connection, specifically through the GET /api/users/ws auth/ route referenced in the real-time updates documentation. This endpoint matters because it provides the credential needed to authenticate WebSocket clients and receive broadcast Catalyst updates, including real-time and buffered events, making it a foundational part of any integration that consumes live platform activity.

Catalyst API Reference ​

The Catalyst API Reference is the Autologyx technical documentation for the Catalyst API and serves as the primary guide for developers, integrators, configuration admins, and other technical users working with platform integrations. It is used in the Catalyst documentation area to explain available endpoints, request and response formats, payload structure, merge field syntax, API conventions, and related integration patterns, including real-time and event-driven implementations through associated APIs such as the Catalyst Websockets API and Event History API. This documentation matters because it provides the core information needed to connect external systems to Autologyx correctly, configure advanced integrations, and build reliable services that interact with Catalyst in a supported and consistent way.

Catalyst Websockets API ​

The Catalyst Websockets API is the Autologyx real-time integration interface that allows developers and integrators to open authenticated WebSocket connections and receive live platform event updates as WebSocket responses. It is used in the Catalyst technical documentation and integration flow alongside the Catalyst API endpoint, including the GET /api/users/ws auth/ authentication step that provides the UUID v4 token required to establish the connection. This API matters when building event-driven integrations, synchronising external systems with Autologyx activity as it happens, and handling high-volume updates through related concepts such as buffered events, which manage broadcasts sent in batches of up to 1,000 items.

cells ​

In the Autologyx platform, cells are the individual data values within a row of a table or grid-based dataset, representing the contents of specific fields that users view and edit in records. Cells are used prominently in integrations and front-end experiences that consume the Catalyst Websockets API, where real-time updates are delivered so changes to rows, cells, and record counts are reflected immediately without a page refresh. This matters to developers and integrators because cell-level updates enable interfaces to stay synchronised with platform data efficiently, support responsive user experiences, and ensure that displayed record details remain current as changes are made elsewhere in the system.

Child added/removed event ​

children limit ​

In Autologyx, children limit is the maximum number of child objects that an object class relationship allows within an Object Model; when this configured limit is exceeded, the platform returns the error message “Limit of children exceeded” for the relevant Object Class. This constraint is used in the relational model and object model APIs that create or manage hierarchical records, alongside related settings such as multiplicity, modifiable multiplicity, and relation depth limit. It matters to configuration administrators and developers because it governs the valid structure and size of parent-child record hierarchies, ensuring object relationships conform to the designed data model and preventing invalid hierarchy creation or update requests.

class fields ​

Class fields are the fields defined on an object class in Autologyx, representing the named data points that can be stored on records of that class and referenced by configuration and API operations. They are used when configuring object-record update tasks, where a task can be limited to a specific set of object class fields and exposed through endpoints such as GET /api/tasks/{id}/class fields/, and they are also used in document templates, where merge tags are validated against the related class fields and invalid field references generate warnings. Class fields matter because they determine which record data users can capture, update, upload files against, and merge into generated documents, so correct field selection and valid field aliases are essential for task behaviour, record creation and updates, and successful document template configuration.

class id ​

Class id, also shown as Object Class id, is the unique identifier of an object class in Autologyx and is used as a URL path parameter in object-class API endpoints to target the specific class being configured or queried. It is used in operations such as listing, creating, and retrieving Object Class Owners, where the class id determines which object class the ownership settings apply to and is combined with related identifiers such as owner id for individual owner records. This identifier matters to developers, integrators, and configuration administrators because it is the key that scopes requests to the correct object class, controls which ownership relationships are managed, and must be valid for the platform to return or update data successfully.

class relations ​

ClickHouse database ​

In the Autologyx platform, the ClickHouse database is the client-specific history data store created automatically when a new client is provisioned in the main system. It is used in the event history capability to hold that tenant’s event data, while a corresponding tenant record is also created in the default ClickHouse database so the platform can register and route the client correctly. This database underpins how Autologyx captures, organises, and queries historical events and event types, making it important for Super Admins, security and analytics teams, and developers or integrators who need to understand where event history is stored, how tenant separation is implemented, and how related services such as event ingestion components interact with client history data.

clickhouse default database ​

In Autologyx, the ClickHouse default database is the central ClickHouse database used by the API History Event service to store platform-level metadata about history tenants, separate from each client’s own history database. It is used in event-history configuration and operations, including health checks that verify the application can connect to ClickHouse, and in tenant lifecycle processes where creating a client in the main Autologyx system creates both a client-specific ClickHouse database for history data and a corresponding tenant record in the default database’s tenant table. This database matters because it underpins tenant registration and service connectivity for event history, making it an important configuration and validation point for administrators and integrators managing history data services.

Client Context ​

Client Context is the merge field context in Autologyx that exposes information about the current client so it can be inserted dynamically into platform content and automation outputs. It is used wherever merge fields are supported, such as document templates and email templates, alongside other system contexts including Admin Context, Date and Time Context, Constants Context, and Loop Item Context. For administrators configuring templates, Client Context provides a standard way to reference client-specific data without hard-coding values, and for end-users it ensures generated communications and documents are populated with the correct client details for the active transaction or process.

client history database ​

In Autologyx, the client history database is the client-specific ClickHouse database created during client setup in the main system to store that client environment’s historical activity for the Event History API microservice. It is used by the event-history services when recording and retrieving events, and it is linked through a tenant record created in the default ClickHouse database, which maps the tenant or client instance to the correct history database. This matters because it defines how historical data is partitioned per tenant, supports correct routing of event-history operations, and is a key concept for super admins, compliance and analytics teams, and developers or integrators who configure, manage, or query tenant-level history data.

client id ​

In the Autologyx platform, client id is the unique string identifier for a tenant in the Event History microservice, used to create, reference, and delete that tenant’s event-history connection and associated database. It is supplied during tenant initialization, returned in the tenant configuration response alongside the client secret and database name, and required in request headers for tenant deletion and related administrative API operations. For developers, configuration admins, and Super Admins, the client id matters because it links API requests to the correct tenant record, enables the platform to locate the tenant-specific event-history database, and is validated as a required field with a maximum length of 64 characters.

client instance ​

In the Autologyx platform, a client instance is the specific customer environment identified on an API request by a header and used by platform services to resolve the correct tenant-specific context for processing. It is used in integration and service interactions such as the API History Event microservice file upload flow, where the client instance determines the client instance database name that is applied as part of the file key prefix, alongside a generated UUID v4 file name. This matters because the client instance controls how requests are routed and how data and files are namespaced and stored, so developers, configuration administrators, and Super Admins must ensure the correct client instance header is supplied to keep operations associated with the intended customer environment.

client instance database name ​

The client instance database name is the unique database identifier for a client instance in the Autologyx platform, and in the event history file storage model it is used as the file key prefix when generating and resolving stored file paths. This value is relevant when working with file handling and history integrations, including endpoints such as GET /api/files/upload_url, because it determines how files are partitioned and associated with the correct client instance. For developers, configuration admins, and Super Admins, understanding the client instance database name is important for configuring integrations, tracing file locations, and ensuring that history-related file operations are routed to the correct tenant-specific storage context.

client secret ​

In the Autologyx platform, a client secret is the confidential string stored with a tenant record in the Event History microservice and paired with the client id to identify and secure a tenant connection. It is used when creating or managing tenants through tenant administration endpoints such as POST /api/initialize tenant, where it forms part of the tenant configuration alongside values such as the database name and is handled separately from request-level credentials such as the Authorization header API key. This matters to Super Admins, configuration admins, and integrators because the client secret is a core tenant credential: it must be created, stored, and protected correctly to support secure tenant setup, maintain access boundaries between tenants, and ensure the platform can associate the tenant with its event history and related databases.

Client tenant entry exists ​

ClientContext ​

ClientContext is the default merge-field context that exposes client or organization information within the Autologyx platform. It is part of the DefaultScope baseline contexts and is available in both Sequencer Actor and Document Generation scopes, where it can be referenced alongside other standard contexts when configuring templates, automation, and generated documents. This matters to configuration admins and developers because ClientContext provides a consistent, built-in source of organization-level data across supported scopes, helping ensure reusable configurations and document outputs can access core client information without requiring custom context definitions.

Company details ​

Company details is the administration resource in Autologyx that stores the organisation’s designated system administrator or generic contact information, including fields such as name, email address, phone number, job title, and email signature. It is used in the Administration API as a single-instance resource at /api/administration/**company details**/, which means there is only one Company details record for the environment, and it can be retrieved with GET, updated with PATCH, and inspected with OPTIONS. Access to view or edit this resource is controlled through role-based Company details permissions and exposed through permission metadata, making it important for configuration admins, super admins, and integrators who need to maintain accurate administrative contact data and ensure the correct users can manage it.

Company details permissions ​

Company details permissions are the platform permissions that control whether a user or integration can view and update the single Company details record in Autologyx. This record stores the nominated system administrator or generic contact information used across the platform as merge fields and in standard message templates, so its permissions are relevant when configuring administrative access and when integrating with the administration API. They are used with the Company details resource and its single-instance endpoint, including GET, OPTIONS, and PATCH /api/administration/company details/, where permission information is exposed through meta.permissions to show the actions available to the current user. These permissions matter because they govern access to organisation-level contact data that can affect system-generated communications and template output across the platform.

compatible endpoint supporting uploaded files ​

complete by ​

In Autologyx, complete by is a required task template setting that defines how the platform calculates or records the deadline for completing a task. It is used when configuring task templates through the API and works with the related fields complete by date, complete by time unit, and complete by time value to specify either a fixed completion date or a duration-based deadline, depending on the selected complete by mode. This setting matters because it establishes the expected completion window for every task created from the template, which in turn affects how administrators and integrators design task timing alongside related controls such as reminders, expiry, and renewals.

complete multipart upload ​

In the Autologyx platform, complete multipart upload is a file-upload event used in the Catalyst WebSocket file upload workflow to tell the backend that all parts of a multipart object upload have been sent and the upload should be finalised. It is used after a client has obtained multipart presigned URLs, uploaded each part to the target object store, and is ready for Autologyx to complete processing for the Object Record file. This event matters to developers and integrators because it marks the transition from part-by-part transfer to a completed file asset, enabling the platform to assemble the uploaded parts against the relevant S3 upload ID and S3 key, continue backend processing, and issue subsequent progress updates through the same WebSocket channel.

completed upload files ​

Completed upload files are the files endpoint output for an Object Record Upload that has finished processing in Autologyx, returned by the GET /api/object records/uploads/{upload_id}/files/ API. In this context, the term refers to the list of files associated with a specific upload only after processing is complete, rather than while the upload is still in progress. This endpoint is used by developers and integrators working with the Object Records Uploads API to retrieve the final file set and related upload details for completed bulk document or record ingestion workflows. It matters because it provides the definitive post-processing view of an upload, enabling integrations to confirm completion, inspect the uploaded package, and drive downstream automation or reconciliation steps using a stable, completed result set.

Complex filtering ​

Complex filtering is an Autologyx API query capability that lets developers express more advanced filter conditions in a JSON-like structure within the request query string, beyond the standard field-and-predicate format used on endpoints such as Tasks. It is used when retrieving platform records and actions need to be narrowed with combinations of conditions that cannot be expressed cleanly through simple single-parameter filters alone. In practice, it sits alongside the platform’s standard filtering model for fields such as status, dates, assignees, object class, and object record, giving integrators a structured way to build precise queries against workflow data. This matters because it enables more targeted data retrieval, supports sophisticated integrations, and helps ensure API consumers can return exactly the records needed for downstream processing, user experiences, and automation logic.

component status ​

Component status is the lifecycle state of a custom component in the Autologyx Custom Components area, used to show whether an individual component is being processed as part of repository import and installation. It is surfaced alongside custom component repository operations and component creation workflows, where repository status and component status are linked: when the repository is processing, the component status is processing, and when components are created from an imported repository, installation continues in the background with the component marked accordingly. This matters to Configuration admins, Super Admins, and Developers or Integrators because it indicates whether a custom component is ready for use, still being installed, or dependent on repository import progress, which directly affects configuration, deployment timing, and troubleshooting of custom component availability.

config admin account ​

A config admin account is an Autologyx user account type used for platform configuration and role-based administrative access. In the Users API and user management workflows, this account type is identified through the account type field, and it is the only account type that can have roles assigned or unassigned; if roles are provided for any non-config admin account, the platform rejects the request with a validation error. This matters because role assignment is how configuration permissions are granted and controlled, so when creating, updating, or integrating user provisioning in Autologyx, you must use the config admin account type for any user who needs configuration responsibilities or access governed by roles.

ConstantContext ​

ConstantContext is the built-in Autologyx context that exposes system and configuration constants for use in merge fields and other context-driven template expressions. It is part of the DefaultScope foundational context set and is available in both Sequencer Actor and Document Generation scopes, which means the same constant values can be referenced consistently across workflow execution and document output. For configuration admins and developers, ConstantContext matters because it provides a central, reusable source of fixed platform or configuration values, helping standardise templates, reduce duplication, and ensure core constants are accessible wherever supported context data is used.

Constants ​

Constants are a standard merge field type in the Autologyx platform, used within merge field processing to insert fixed, predefined string values into generated content. They are used anywhere merge fields are supported, including document templates and features such as custom filters and merge field rendering, where they are treated alongside basic, relational, and system fields. Constants matter because they let configuration admins and developers reuse consistent static values across templates and automated outputs, reducing duplication, simplifying maintenance, and ensuring standardised text is rendered correctly wherever those values are referenced.

Constants Context ​

In the Autologyx platform, Constants Context is the merge field category used for user-defined constant values that are made available across the system and referenced with a dedicated constants prefix. It is used anywhere system merge fields are supported, including document templates, email templates, and other configurable content that inserts dynamic values at runtime. Constants Context matters because it allows configuration admins and Super Admins to define reusable fixed values once and then apply them consistently across templates and processes, reducing duplication, simplifying maintenance, and helping ensure standardised output for end-users.

Context Availability by Scope ​

Context Availability by Scope is the Autologyx reference that defines which merge-field context types are available in each execution scope, specifically Sequencer Actor and Document Generation. It is used when configuring templates, document generation, and automation logic to determine which contexts can be called in a given part of the platform. The scope matrix shows that foundational contexts such as AdminContext, ClientContext, DateAndTimeContext, ConstantContext, TaskContext, ObjectRecordContext, UserContext, UserFieldContext, UserFieldMetaContext, UsersGroupContext, and DocumentContext are available in both scopes, while VariableContext and VariableDocumentContext are restricted to Sequencer Actor, and EmbeddedDocumentContext is restricted to Document Generation. This matters because context availability directly controls which data, functions, and merge fields can be used in a configuration, helping administrators and developers design templates and processes that work correctly within the supported scope.

Context scopes ​

Context scopes are the system-defined availability boundaries that determine which merge field contexts can be used in a given Autologyx execution area, such as Sequencer Actor and Document Generation. In practice, context scopes are used when configuring merge fields, document generation, and other context-driven features to control access to platform data sources including AdminContext, ClientContext, DateAndTimeContext, ConstantContext, TaskContext, ObjectRecordContext, User-related contexts, DocumentContext, and EmbeddedDocumentContext. The DefaultScope provides the baseline contexts available across the platform, while specialized scopes add or restrict context types for specific runtime scenarios; for example, VariableContext and VariableDocumentContext are available in Sequencer Actor but not in Document Generation, whereas EmbeddedDocumentContext is available only in Document Generation. Context scopes matter because they define exactly which data and functions are valid in each configuration surface, helping administrators and developers design templates, merge fields, and automations that use supported context types in the correct part of the platform.

Context types ​

Context types are the named categories of merge-field context exposed by Autologyx to supply data and functions within a given scope, such as Sequencer Actor and Document Generation. They define which sources of information are available when configuring templates, expressions, and generated documents, and include core types such as AdminContext, ClientContext, DateAndTimeContext, and ConstantContext, alongside specialised types such as DocumentContext and EmbeddedDocumentContext. In practice, context types are used in merge-field scope availability documentation and configuration decisions to show exactly which context objects can be referenced in each execution area. This matters because the set of available context types controls what data a configuration can access, ensures templates are designed for the correct scope, and helps administrators and integrators avoid using fields or functions that are unavailable in the part of the platform where the configuration runs.

count ​

Count is the integer value that shows the current number of objects in a given resource category on the Autologyx platform. It is used in limits-related API responses alongside limit information for platform resources such as object classes, task group templates, task templates, sequences, user groups, roles, and similar authentication or configuration objects. For developers, integrators, and administrators, count matters because it provides the live usage figure needed to monitor resource consumption, compare current usage against configured limits, and manage platform configuration before additional objects can no longer be created.

count and limits ​

In the Autologyx platform, count and limits describes the usage and capacity information returned for configurable resources, showing both how many items currently exist and the maximum or related constraints that apply to that resource type. It is used in platform and API limit reporting for resources such as object classes, task group templates, task templates, sequences, user groups, and roles, where each resource is represented as an object containing its count and limit data. This matters to developers, configuration admins, and super admins because it provides a direct way to monitor tenant consumption, understand configuration ceilings, and plan changes to items such as authentication objects, custom components, document templates, fields, owners, assignees, and permission sets before platform limits block further configuration or deployment.

create edit view delete complete assign ​

Create edit view delete complete assign is the full set of valid task actions that can be granted in an object class permission set in Autologyx. It is used when configuring permissions for the tasks resource at Object Class level, alongside other resource action sets such as list edit view delete for object classes and edit view delete for object records. These actions control whether users can create tasks, open and view them, change them, remove them, mark them complete, and assign them, making this permission set central to how task work is performed and governed within a configured object class. For configuration admins and Super Admins, setting these actions correctly is important because task permissions directly determine what operational users can do in task-driven processes, and the platform converts submitted permissions using defined dependency rules.

create form type ​

In Autologyx, the create form type is the form configuration type used for forms that support creating object records, defined on Object Class Forms and stored and served by the backend for use in the Autologyx frontend. It is configured in object class form definitions, including through the /api/object class forms/ interface, where the type field is an enum and currently only accepts the value create. This type matters to developers, integrators, and configuration administrators because it identifies a form as a creation form within an object class, ensuring the correct form configuration is associated with record creation scenarios and enabling the frontend to use the intended layout and components when users create new records.

created at ​

In Autologyx, created at is a system-generated datetime field that records when a specific object record permission set user assignee entry was created. It is returned in the assignees/users endpoint response alongside fields such as id, user, and created by, and is used by developers, configuration administrators, and compliance or analytics teams to identify the exact timestamp at which a user was assigned within that permission set context. This field matters because it provides a reliable audit point for tracking assignment activity, supporting integration logic, operational reporting, and governance over who was granted access to an object record and when.

created by ​

Created by is a user field on Autologyx object-record relationship resources that identifies the user account that created the record entry. It is returned in API responses for endpoints such as Object Record Owners and Object Record Permission Set user assignees, appears alongside fields such as created at, and can be used as a filter in object record owner queries. This field matters when integrating with or administering the platform because it provides a clear audit trail for who added an owner or assignee relationship, supports reporting and compliance review, and helps distinguish the creator of the relationship record from the related user, owner, or assignee referenced elsewhere in the payload.

credentials ​

In Autologyx, credentials are the provider-specific values stored within an Authentication Object that the platform uses to authenticate with Autologyx itself or with external services such as iManage, DocuSign, Microsoft, Box, Adobe, Salesforce, API key integrations, and generic OAuth endpoints. The credentials field is a required object in Authentication Object configuration and contains the exact keys needed for the selected provider, such as username and password, client ID and client secret, tenant, host, private RSA key, token and refresh URLs, scope, Box subject values, API key details, and any additional authorization headers or parameters supported by that provider. Credentials matter because they determine whether integrations can connect successfully, obtain tokens, and execute platform-driven actions, so administrators and integrators must supply the correct provider-specific structure and maintain related settings such as expiry at and expiry applies to where applicable.

current assignees user groups ​

Current assignees user groups is a Tasks API filter field in Autologyx that targets the user groups currently assigned to a task. It is used when querying task records through the /api/tasks/ endpoint, where it supports the isnull, containsall, and containssome predicates, for example to return tasks assigned to any or all of a specified set of groups. This field is important for developers, integrators, and configuration administrators who need to build task lists, routing logic, integrations, or reporting around group-based work allocation, because it enables precise filtering of tasks by their active group assignees using standard Autologyx API filtering conventions and complex filtering patterns.

current assignees users ​

Current assignees users is a task filtering field in the Autologyx API that represents the individual users currently assigned to a task. It is used on the Tasks endpoint when retrieving task records, and supports the predicates isnull, containsall, and containssome, enabling developers and configuration administrators to query for tasks with no direct user assignees or to match tasks assigned to one or more specific users. This field is particularly important when building integrations, work allocation views, dashboards, or complex filters, because it allows task lists to be targeted to the people who currently hold responsibility for action on the task, distinct from related assignment fields such as current assignees user groups and current owner.

custom component id ​

In Autologyx, a custom component id is the integer identifier used to uniquely reference a custom component in platform API endpoints, particularly when retrieving, deleting, or checking usage for items held in the Custom Components Repository. It is supplied as a URL parameter in custom component API calls and is distinct from the backend-generated id value returned in responses for the component record itself. This identifier matters to developers, integrators, configuration admins, and Super Admins because it is the key used to target the correct custom component for administration tasks, validate whether the component exists, and determine whether it is currently in use by forms or landing pages before changes or deletion are attempted.

Custom Component in use ​

Custom Component in use is the Autologyx status returned when a custom component cannot be deleted because it is still referenced elsewhere in the platform. In the Custom Components API, this is surfaced as a 400 Forbidden response with the message that the custom component is in use by specific items, and the related usage endpoint shows where it is currently applied, including object class summary forms, create forms, standalone forms, and landing pages. This matters to configuration administrators, super admins, and developers because a custom component must be removed from all active configurations before it can be deleted, making usage checks an essential part of safely managing component lifecycle, avoiding broken form or page configurations, and understanding the impact of configuration changes.

custom components ​

Custom components are reusable UI elements registered in the Autologyx platform and referenced by ID in configuration to extend standard screens and forms with tailored functionality. They are used in UI configuration for landing pages and object classes, and in object class form definitions exposed through endpoints such as /api/object class forms/, where the custom components field stores the set or array of enabled component IDs to render. Management of these components is controlled through the dedicated custom component permission resource, and their use is subject to platform validation and limits, including enabled-state checks and maximum counts. Custom components matter because they provide a governed way for configuration administrators and developers to introduce bespoke interface behaviour into object-class-driven experiences while keeping deployment, permissions, and API usage aligned with Autologyx standards.

Custom Components Repository ​

Custom filters ​

Custom filters are Autologyx merge-field functions used to transform and format values during document generation and related runtime processing. They are applied in places where merge fields are supported, including Document Templates and sequence actors such as Send Message, Variable, and API Call, with additional use in Doc Auto for embedded images and DOCX content. Custom filters support advanced operations such as date and time manipulation, JSON-to-object conversion, newline-to-HTML conversion, and document-field attachment handling for images with size controls and DOCX embedding, often working with related concepts such as merge field rendering, document field aliases, and array indexes. They matter because they let configuration admins and integrators control how raw platform data is converted into output-ready content, ensuring generated documents and messages contain correctly formatted text, dates, and embedded files without changing the underlying source data.

Custom User Group Permission Set ​

A Custom User Group Permission Set, also called a Custom Permission Set, is a user-group-scoped permission set in the Autologyx platform that is created with the Custom Permission Set type to define additional access and action rules for members of a specific user group. It is used in the user groups configuration area and related API resources, where administrators and integrators create, manage, and assign these sets independently of reserved or system-defined permission sets such as EVERYONE, MEMBERS, and other restricted sets. A single user group can contain multiple Custom User Group Permission Sets, allowing configuration teams to model distinct roles, responsibilities, and permission dependencies within the same group. This matters because it provides a structured way to extend group security design without changing built-in permission sets, enabling precise access control, clearer ownership boundaries, and more maintainable user group configuration.

database name ​

Database name is the unique identifier of the tenant-specific database created and managed by the Event History microservice in Autologyx. It is used in the tenant lifecycle APIs, including POST /api/initialize tenant, where the database is created and returned in the response, and DELETE /api/delete tenant, where the tenant connection and its related database are removed. This value is distinct from the client identifier and client secret, is validated as a string with a maximum length of 64 characters, and is part of the configuration that links a tenant to its event history storage. For Super Admins, configuration admins, and integrators, the database name matters because it defines where that tenant’s history data is stored, supports correct tenant provisioning and deletion, and ensures the Event History service is connected to the correct database within the wider Autologyx platform.

Date and Time Context ​

Date and Time Context is the Autologyx system merge field category that exposes current temporal values for use in template-driven content and automation. It is used anywhere merge fields are supported, including document templates and email templates, alongside other system contexts such as Admin Context, Client Context, Constants Context, and Loop Item Context. By inserting Date and Time Context fields, users and configuration admins can populate generated content with the current date or time consistently at runtime, which is essential for producing accurate, time-aware communications and documents without manual updates.

Date and Time Manipulation ​

Date and Time Manipulation is a functional category of Autologyx custom filters used in merge fields to calculate and transform dates and times when rendering content in the platform. It is used primarily in document templates and other merge-field-enabled outputs, where administrators and end-users need to shift a reference date or date-time by years, months, days, hours, minutes, or seconds, with support for options such as excluding weekends and accepting ISO strings or date/date-time merge field values as input. This matters because it enables precise, repeatable generation of dynamic dates directly in template content, helping users produce correctly calculated deadlines, schedule-related values, and other time-sensitive information in a consistent ISO-formatted output.

DateAndTimeContext ​

DateAndTimeContext is a default merge-field context in the Autologyx platform that provides date- and time-related functions and variables for use in template evaluation and data resolution. It is part of the foundational context set supplied by the DefaultScope and is available in both Sequencer Actor and Document Generation scopes, making it accessible when configuring workflow logic and when generating documents. DateAndTimeContext matters because it gives administrators and integrators a consistent, built-in source for working with temporal values across supported scopes, helping ensure templates and configuration behave predictably wherever date and time data is required.

dedupe ​

Dedupe is a Boolean integration configuration field used in the Autologyx Integrations API for supported integration types, including the iManage-specific configuration shown in /api/integrations/. It is supplied in create and update requests, returned in integration configuration responses, and validated as a required non-null field in the integration’s schema. This setting matters to configuration admins and developers because it controls whether duplicate items are handled through deduplication logic within the integration configuration, making it an important part of defining consistent outbound integration behaviour and ensuring the integration is configured correctly through API-driven setup and maintenance.

Default Contexts ​

default Task assignees ​

Default Task assignees are the standard users or user groups designated in a Sequence to receive stage 1 of Tasks created by the Sequencer in the Autologyx platform. This setting is used when configuring Sequences and task group templates, and it determines the initial assignment of newly generated work so Tasks are routed to the correct people or teams from the moment they are created. Default Task assignees matter because they control operational workload distribution and are also governed by platform limits, including separate limits for assigned users and user groups, which configuration administrators and Super Admins must account for when designing scalable task assignment models.

DefaultScope ​

DefaultScope is the baseline context scope in the Autologyx platform that supplies the foundational set of merge-field contexts available across the system. It is used in context availability and merge-field configuration to define the core data sources that users and features can rely on regardless of specialised execution scope, including AdminContext, ClientContext, DateAndTimeContext, and ConstantContext. DefaultScope is documented alongside other scopes such as DocumentGenerationScope and Sequencer Actor scope, and serves as the foundation that broader or more specialised scopes build on. This matters to configuration admins, developers, integrators, and super admins because it determines which essential system, organisation, date/time, and constant values are always available when designing templates, configuring context-driven behaviour, or validating where specific merge fields can be used.

delay activation ​

Delay activation is a boolean user-setting in the Autologyx Users API that controls whether a newly created user account is activated immediately or kept inactive until activation is completed later. It is supplied in the request body when creating or updating users through POST or PATCH /api/users/, and its use is restricted by account type, with validation rejecting unsupported combinations. This matters to configuration admins, developers, integrators, and super admins because it affects the user onboarding flow, the account’s initial status and activation timing, and whether invitation or follow-up activation steps are required for that user.

DELETE /api/delete tenant ​

DELETE /api/delete tenant is the Event History microservice endpoint used to remove a tenant from the Autologyx platform by deleting the tenant connection record and its associated Event History database. It is used by developers, integrators, and administrative users when decommissioning a tenant or cleaning up an Event History configuration that was previously created through tenant initialization. The endpoint sits alongside tenant management operations such as POST /api/initialize tenant and relies on authenticated API access, including the required Authorization header and API key, with request values such as client ID, client secret, and database name subject to the service validation rules. This operation matters because it permanently removes the tenant’s Event History storage and connection details, ensuring that obsolete or retired tenant configurations are fully removed from the Event History environment.

delete permission ​

Delete permission is the file access permission in Autologyx that controls whether a user can delete files from public storage. It is used when configuring file permissions for public storage operations and is enforced on the DELETE public storage API endpoint for removing a specific file. This permission matters because it governs a destructive action on shared stored content, helping administrators restrict file removal to the appropriate role; in the documented configuration, it is disabled by default and enabled only for Super Admins.

detail view ​

In the Autologyx platform, a detail view is the API representation returned when a GET request targets a single resource, providing that item in full detail with an extended set of attributes beyond the corresponding list view. It is used across resource specific endpoints and in API metadata exposed through OPTIONS, where detail related schema information describes the fields available for create and detail operations, including nested schema structures, permission fields, and non modifiable properties. Detail view matters to developers and integrators because it defines the complete payload shape for retrieving, inspecting, and working with individual records, while preserving consistency with list view formats for shared fields and supporting correct implementation of validation, filtering, ordering, and client side handling of resource data.

details.schema by type ​

In the Autologyx platform, "details.schema by type" is the type-specific schema metadata exposed by the OPTIONS /api/integrations/ endpoint, used to determine which fields, enums, and validation rules apply to an integration configuration for a selected integration type. It is referenced when configuring integration properties such as authentication object, object class, and object class field, where the allowed structure and values depend on the integration being created or updated. This schema is important to developers and configuration administrators because it provides the authoritative contract for building dynamic configuration interfaces, validating requests, and supplying the correct payload for each supported integration type in line with Autologyx API standards.

display configuration ​

Display configuration, also called Object class UI configuration or UI configuration, is the JSON definition on an object class that controls how that object class is presented in the Autologyx user interface. It is used when creating, updating, and retrieving object classes through the Object Classes configuration, alongside related settings such as object class fields and custom components, and it can reference UI elements such as custom components and autocomplete widgets used for specific form types. This configuration matters because it determines how users interact with records of that object class in the platform, enabling configuration admins, Super Admins, and developers or integrators to tailor the record experience to the object class’s purpose while ensuring the JSON structure is valid, including the requirement that keys are not duplicated.

Doc Auto Actor ​

Doc Auto Actor is a sequence actor in the Autologyx platform used in document-generation workflows to embed images into DOCX-based outputs using merge fields and custom filters. It is configured within sequences alongside other actors and is specifically referenced where image embedding is required, complementing document templates, merge field processing, and related automation components such as API Call actors. This actor matters to configuration admins and developers because it enables generated documents to include dynamic visual content from workflow data, and its correct setup—including the required image merge field parameter—is essential for reliable document output.

Document field alias ​

A document field alias is the identifier used in Autologyx merge-field expressions to reference a document field when embedding files from that field into generated output, such as images or DOCX content in document templates. It is used in template configuration and custom filter syntax alongside a mandatory array index to select a specific attachment from a document field that can hold multiple files. This matters to configuration admins and developers because the alias is the key that connects a template expression to the correct source field, enabling reliable file embedding, correct attachment selection, and predictable document generation behaviour.

document field name ​

In the Autologyx Object Record Uploads workflow, the document field name is the string value that identifies which document-type field on the target object class is used for the files in a specific upload. It is returned in upload responses alongside values such as upload id, object class name, and zip filename, and is used when working with the Object Record Uploads API and related completed upload file information. This field matters because it links the uploaded documents to the correct field definition on the object class, ensuring that uploaded files are associated with the intended document type during integration and troubleshooting.

Document fields ​

Document fields are Object Record fields in Autologyx that store one or more files, such as PDFs, DOCX documents, and images, and expose them as an array of document objects with properties including document ID, file name, size, download URL, file type, and Base64 content. They are used in the Object Record Documents API endpoint to list the documents attached to a record, and in merge fields within document templates to access document metadata or file content for tasks such as generating links, embedding images, or processing generated documents. Document fields matter to developers and configuration admins because they define how files are attached to records, retrieved through integrations, and referenced in document generation, making them a core part of configuring document-centric workflows and template behaviour in the platform.

document generated ​

In Autologyx, document generated is an event type recorded in Event History and Object Record History to indicate that a document has been produced for a specific record. It appears in history API responses alongside event metadata such as event datetime, source type, and event data, and is used by developers, integrators, and configuration administrators when retrieving, filtering, or auditing record activity. This event matters because it provides a traceable history point showing when document output was created within a workflow, supporting operational monitoring, downstream integrations, and compliance or analytics use cases that rely on a complete record lifecycle.

Document Generation ​

Document Generation is the Autologyx platform scope used when creating documents from templates, and it defines which merge-field contexts are available during that process. In this scope, document templates can access the default contexts used across the platform, record-related contexts for the item being processed, and the additional EmbeddedDocumentContext used to insert embedded images into generated output. Document Generation is used wherever document templates and merge fields are configured, and it matters because it determines exactly which data sources, variables, and context objects can be referenced when building document content, ensuring administrators and integrators design templates that resolve correctly at runtime.

document generation process ​

In Autologyx, the document generation process is the platform action that creates a generated document for a specific Object Record from a selected Document template, optionally writing the result to a Document-type field on that record. It is used in Object Record Documents through the document-generation API and related record document endpoints, where users and integrations can start, monitor, list, and cancel generation for templates available to the record and permitted to the caller. The process enforces key configuration and access rules: the Object Record and Document template must belong to the same ObjectClass, the target field must be a Document field if supplied, the caller must have the required record and template permissions, and duplicate requests for the same record-template pair are blocked while processing is already in progress. This matters because it is the mechanism that turns template and merge-field configuration into actual record-specific documents, supports on-demand document creation, and determines how generated outputs are attached to records and managed operationally.

Document Object Structure ​

Document Object Structure is the standard data shape Autologyx uses when a document field is returned in merge fields and related template or integration outputs. In this context, a document field does not return a single value; it returns an array of document objects, with each object representing one file and exposing properties such as the document ID, file name, file size, download URL, file type or format, and Base64-encoded content. This structure is used wherever document field values are accessed for document generation, merge field configuration, and external integrations, allowing administrators and developers to reference specific file metadata, generate download links, and work directly with the underlying file content. It matters because understanding the document object structure is essential for correctly configuring templates, selecting the right document properties in merge expressions, and building integrations that reliably handle stored files.

Document Picker ​

Document Picker is a Loop source type in Autologyx Sequencer that supplies a Loop actor with document records, so the loop item merge field resolves to the current document representation for each iteration rather than to a value from an array. It is used when a Loop actor is configured to iterate over documents and is available in any downstream actor executed on the Loop item processed path, where nested properties of the current document can be referenced in configuration such as API calls and other actor inputs. This matters to configuration admins and developers because it determines the data shape exposed during loop execution, enables document fields to be mapped reliably through merge fields, and requires the correct trigger and downstream connection pattern for testing and runtime behaviour to resolve as expected.

document representation ​

In Autologyx, a document representation is the structured loop item produced when a Loop actor uses a Document Picker as its source, making the selected document available as data within the execution context of each loop iteration. It is used in downstream actors connected to the Loop actor, such as API Call actors, where merge fields can access the document representation and its nested properties in the same way other loop sources expose their current item. This matters to configuration admins and developers because it determines what data shape is available in sequencer expressions, merge fields, and integrations when iterating over picked documents, enabling workflows to read document-specific values reliably and pass them to subsequent processing steps.

Document Template usage ​

Document Template usage is the Autologyx API view that reports whether a specific document template within an object class is currently referenced elsewhere in the platform, particularly by Sequences. It is used through the object class document templates endpoint at GET /api/object classes/{object_class_id}/document templates/{document_template_id}/usage/ and is relevant when developers, configuration administrators, and Super Admins are validating, updating, or preparing to remove a template. This matters because templates can be embedded in operational process design through object classes and sequence configuration, so checking usage helps prevent disruption, explains in-use warnings such as "Document Template is in use by Sequences.", and supports safe governance of template changes alongside related features such as merge fields, merge tags, Jinja template syntax, verification, and download actions.

Document Template warning ​

Document Template warning is the warning field returned for an Object Class Document Template when Autologyx detects issues in the template, especially invalid class fields found during template parsing or verification. It is used in the document template API responses for create, retrieve, list, and update operations, and can also be surfaced as a list of issues when validating templates against object class fields. For configuration admins and developers, this warning is important because it highlights problems in DOCX templates such as incorrect or outdated merge fields or Jinja-based references to class data, helping them correct templates before document generation is used in live processes.

Document templates ​

Document templates are reusable templates in Autologyx, typically DOCX files, that define how document content is generated from Object Record data using merge fields and supported Jinja-based filters. They are used in the Templates panel during configuration and at runtime when users generate documents for a specific Object Record through the Object Record Documents features and related APIs, where each template is tied to an Object Class and only available when permissions and class compatibility requirements are met. Document templates matter because they standardize document output, enable on-demand generation, control which relational data can be rendered, and directly influence platform configuration such as Object Model changes, since relationships referenced by a template cannot be removed while that template depends on them.

document templates/download ​

In Autologyx, document templates/download is the API operation used to retrieve an existing Object Class Document Template file from the platform, exposed as the GET /api/object classes/{...}/document templates/{...}/download/ endpoint. It is used by developers, integrators, and configuration administrators when they need the original template content for review, version control, external editing, migration, or reuse alongside related document-template actions such as create and verify. This operation matters because document templates define how platform data, including class fields, merge fields, merge tags, and Jinja template syntax, are assembled into generated documents, so the ability to download the stored template is essential for maintaining template quality, supporting controlled updates, and integrating template management into deployment and administration workflows.

document templates/verify ​

Document templates/verify is the Object Classes API operation used to validate a document template definition before it is used in the Autologyx platform. Exposed as the POST /api/object classes/{...}/document templates/verify/ endpoint within Object Class document template configuration, it is used by developers and configuration administrators when creating or updating templates that rely on Jinja syntax, merge fields, merge tags, class fields, and object class data structures. This verification step matters because it checks that a template is correctly formed in the context of its object class, helping users identify template issues early and supporting reliable document generation, download, and use of Object Class Document Files across automated workflows.

Document tokens list ​

A Document tokens list, also referred to as a valid tokens list, is the API value format used when working with document-type fields on an Object Record in Autologyx. It is a list of document tokens that identify the files currently associated with that field, and it is validated by the Object Records API whenever document values are submitted, updated, or files are removed. This format is used in Object Record payloads and in document field operations, where the platform requires the value to be a non-null list and rejects any token that does not match a valid uploaded document. It matters to configuration admins and developers because document-type Object Class Field options and integrations depend on this exact structure to manage record attachments correctly, enforce file limits, and avoid validation errors such as invalid list values or invalid document tokens.

document type ​

In the Autologyx platform, a document type is an Object Class field type used to store file attachments on an object record. It is configured as part of an object class definition and is referenced by APIs and upload workflows that require the selected object class field to be of type "document" before files can be associated with a record. In object record history events and related event data, document-type field values include the file information for the uploaded content, including an additional ordered list of file names. This matters to configuration admins and developers because document types determine which fields can accept uploaded files, control validation in upload endpoints, and shape how attached documents are represented in record data, integrations, and audit history.

document type field ​

A document type field is an Object Class field whose type is specifically configured to hold a generated or uploaded document for a record. In Autologyx, it is used wherever the platform needs a target field for document handling, including UI configuration and the object record document generation API, which validates that the selected object class field or object record field is of Document type and belongs to the same Object Class as the record and document template. This matters because document generation, storage, and document-related UI behaviour depend on a valid document type field: without it, generated documents cannot be written back to the record, upload or generation components cannot be correctly configured, and requests fail with validation errors when a non-document field is supplied.

DocumentContext ​

DocumentContext is the Autologyx context component that provides document-specific data and metadata for record-related documents during processing. It is available in both the SequencerActorScope and the DocumentGenerationScope, where it sits alongside the default contexts and other record-related contexts such as ObjectRecordContext and TaskContext. In practice, DocumentContext is used when configuring merge fields, templates, and related processing logic that need access to information about the current document being handled as part of a workflow or generated output. It matters because it enables administrators and integrators to reference document-level values consistently within the correct scope, ensuring document processing and generation can use the metadata required for accurate output and automation behavior.

DocumentGenerationScope ​

DocumentGenerationScope is the context scope used by Autologyx during document generation to supply all data required to create a document from templates and merge fields. It combines three context categories: Default Contexts for platform and administrative information, record-related contexts for the record being processed, and the EmbeddedDocumentContext for document-specific operations such as embedding images in generated output. This scope is used in merge-field and context-availability configuration for document creation, where administrators and integrators need to know which data objects and properties are accessible at generation time. It matters because it defines the full set of contexts available to document templates and generation logic, ensuring documents can be produced with the correct system, record, and embedded content data in a controlled and predictable way.

DocuSign ​

DocuSign is a supported authentication provider in the Autologyx platform, used when creating and managing Authentication Objects for integrations that connect Autologyx to DocuSign services. In this context, the provider value is **docusign**, and the authentication record stores the DocuSign-specific credentials required by the platform: user id, client id, private rsa key, and host. It is used by configuration administrators and developers through the Authentication Objects and Integrations API areas to register, validate, and maintain the credentials that enable the DocuSign integration. This matters because the correct provider selection and credential set are required for the integration to be activated, enabled, and usable by Autologyx processes that depend on DocuSign connectivity.

DOCX embedding ​

DOCX embedding is the Autologyx merge-field capability that inserts a DOCX file attached in a document field directly into generated documents, preserving the source document’s formatting. It is used when configuring document templates and merge fields, typically through custom filters that reference the document field alias, a required attachment index from 0 to 99, and the special property for document embedding. This functionality is relevant to configuration admins who design templates and to end-users who supply the source attachments, because it enables reusable document assembly from uploaded Word content while ensuring that only supported DOCX files are embedded and unsupported file types are ignored.

downstream actor ​

A downstream actor is any Sequencer actor that runs after a Loop actor within the path of a single loop iteration, whether it is connected directly to the Loop actor or reached indirectly through other actors. In this context, downstream actors execute within the loop iteration’s execution context and can use loop-specific values such as the current loop item and its nested properties, with the value changing on each invocation to match the element currently being processed. This matters when configuring workflows that iterate over arrays, API results, variables, or document selections, because only actors executed downstream of the Loop actor—and triggered in the loop-processing path, such as by Loop item processed—receive the per-item context needed for correct data mapping, API calls, and automation behaviour.

edit view delete ​

In Autologyx, edit view delete is the set of valid actions that can be granted in an object class permission set for the object records resource. It is used when configuration or super administrators define Object Class–level permissions to control what users can do with records of a given object class: view allows users to open and read records, edit allows them to update record data, and delete allows them to remove records. This permission grouping matters because it determines the operational access users have to object records within the platform and forms part of the resource/action model that Autologyx uses to enforce access consistently when permissions are configured and sent.

Email templates ​

Email templates are reusable message templates in the Autologyx platform used to generate emails and system notifications with dynamic content. They are used anywhere merge fields are supported, allowing configuration admins and Super Admins to insert system and object record data into email subject lines and bodies so each message is automatically populated at runtime. Email templates matter because they standardise outbound communications, reduce manual drafting, and ensure notifications and process-driven emails are consistent, scalable, and aligned with the data and workflow context defined in the platform.

EmbeddedDocumentContext ​

EmbeddedDocumentContext is a document-generation context type in the Autologyx platform that is used specifically to embed images in generated documents. It is available in the Document Generation scope and is not available in the Sequencer Actor scope, making it a context intended for merge-field resolution during document creation rather than general workflow execution. For configuration admins and developers or integrators, EmbeddedDocumentContext matters because it extends the standard DocumentGenerationScope with image-embedding capability, allowing generated outputs to include embedded visual content alongside the default system and record-related context data used in document templates.

ERR LIMIT EXCEEDED ​

ERR LIMIT EXCEEDED is an Autologyx API error code returned with HTTP 400 Bad Request when a request exceeds a platform-defined maximum for a resource or configuration item. It is used across administrative and integration endpoints such as object class document templates, object class, object record and user group permission sets and assignees, integrations, and user account creation, with the response detail stating the specific limit reached, for example the maximum number of document templates, permission sets, assignees, integrations, or accounts. This error matters because it tells configuration admins, super admins, and developers that the request is structurally valid but cannot be completed until the relevant count is reduced, the configuration is redesigned, or a different assignment approach is used, making it a key control point when planning scalable object security, user provisioning, and API-driven administration in Autologyx.

Show 8 more pages

error reason ​

In Autologyx, error reason is the object returned on an Object Record Upload file entry that captures the specific failure details for that uploaded file. It is used in the Object Records Uploads API response for completed upload files alongside fields such as file name, status, record id, and created at, and is particularly relevant when a file has not uploaded successfully. This field matters to developers, integrators, and configuration admins because it provides the structured information needed to diagnose upload failures, understand the causes behind failed count and failed percent metrics, and take corrective action in upload processes or source data before retrying.

event data ​

Event data is the JSON payload attached to an Autologyx history event that stores the event-specific details for that record in the platform’s event and object record history APIs. It is returned in the results array for each event alongside fields such as event type, source type, source id, event id, and event datetime, and its schema changes according to the event type, for example record created, document generated, status initialized, field values changed, or assignee and owner updates. Event data matters because it contains the actionable content of an event beyond its metadata, enabling developers, integrators, administrators, and audit or analytics users to interpret what changed, build integrations, drive downstream processing, and review record activity with the correct schema for each event type.

Event History API ​

The Event History API, also documented as the Event History API Reference, is the Autologyx technical API for accessing and managing event history data from the platform. It is used in the Event History documentation area and covers service-level interfaces for technical areas such as tenant management, including endpoints to initialise and delete tenant-specific event history storage and related service configuration. This API is intended for developers, integrators, and controlled engineering workflows that need to retrieve, submit, or administer historical activity data, often alongside related concepts such as the Autologyx API, Catalyst API Reference, Catalyst Websockets API, filtering predicates, and ordering. It matters because it provides the platform interface for working with historical event records in the correct tenant environment, supporting integration, audit, compliance, analytics, and platform operations use cases.

event timestamp ​

In the Autologyx platform, the event timestamp (exposed in event payloads as timestamp) is the datetime value recorded when a task event is created. It is used in the task events WebSocket resource, including GET /ws/events/tasks/, alongside fields such as task id and event to describe real-time task activity such as task creation, deletion, status changes, and assignee or owner updates. The event timestamp matters because it defines the chronological sequence of streamed task events: clients cannot control sorting, and when results are delivered in chunks, Autologyx orders them in ascending order by event timestamp. For developers and integrators, this field is therefore essential for processing task event streams in the correct order and building reliable real-time update handling.

event type ​

An event type, also called History Event type, is the enumerated classification assigned to each record in the Autologyx Event History API that identifies what happened to a record and determines how that history entry should be interpreted. It is returned on event records in the **event type** field alongside metadata such as event id, event datetime, source type, and source id, and its supported values include record created, owner initialized, owners added, owners removed, assignees added, assignees removed, field values changed, record deleted, document generated, and status initialized. In Autologyx, event type is used by developers, integrators, and audit or analytics teams to filter, categorize, and process history events, and it matters because it defines the business meaning of the event and the expected structure of the associated event data payload for downstream reporting, compliance review, and system integration.

everyone or members perm set ​

In Autologyx, the everyone or members permission set is a permission set type whose access is defined inherently by broad audience scope rather than by explicit assignee lists, so individual users or user groups cannot be added to it through assignee configuration endpoints. This type is encountered when configuring permission sets for object classes, object records, and user groups, and any attempt to use assignees, users, or user groups assignment operations against it returns the validation error "Assignees can not be set to this permission set type." For configuration admins, super admins, and integrators, this distinction matters because it determines whether access should be controlled by selecting the correct permission set type or by managing assignees on assignable permission sets, helping avoid failed API calls, incorrect security design, and unnecessary assignee management logic.

everyone perm set ​

In Autologyx, the everyone permission set is a system-defined permission set type used to apply an object class permission set universally rather than to specific assignees such as user groups. It is used when configuring Object Classes Permission Sets, where assignee management differs by permission set type. The everyone permission set does not accept assignees, and any attempt to assign user groups or other assignees to it returns an error stating that assignees cannot be set for that permission set type. This matters to configuration and Super Admin users because it determines how access is modeled: use the everyone permission set when permissions must apply to all users automatically, and use assignee-based permission set types when access needs to be targeted to defined groups or members.

EVERYONE Permission Set ​

The EVERYONE Permission Set is a special Permission Set type used within a User Group in Autologyx to define the baseline permissions that apply to all members of that group. It is configured in the User Group Permission Sets area and is distinct from other group permission set types, such as MEMBERS, because it represents the common access model shared by everyone in the group rather than permissions assigned to a subset. Each User Group must contain exactly one EVERYONE Permission Set, making it a required structural element of group-based access configuration. This matters to configuration administrators and Super Admins because it establishes the default permissions framework for the group and ensures consistent, controlled access across all users associated with that User Group.

execution context of a single loop iteration ​

In Autologyx, the execution context of a single loop iteration is the scoped runtime context created for one pass through a Loop actor, where merge fields and values are bound to the current loop item and its iteration-specific data. This context is used by actors triggered during that iteration, including actors directly connected to the Loop actor and actors reached indirectly through downstream steps in the same execution path. It matters because it determines which item-specific values are available to each actor at run time, ensuring that configuration, mapping, and processing logic operate on the correct element from the loop source rather than on the full array or another iteration’s data.

expiry ​

expiry applies to ​

In Autologyx, expiry applies to is an optional text field on an Authentication Object that identifies what the configured expiry date relates to, such as the credential, secret, token, or certificate stored in that authentication record. It is used alongside expiry at in the Authentication Objects API request and response payloads, and the two fields are interdependent: if one is provided, the other is required, and expiry applies to cannot be blank or null. This field matters to configuration admins and integrators because it gives operational context to an authentication expiry, making it clear which part of the credentials will expire and supporting accurate maintenance, renewal planning, and troubleshooting of external service integrations.

expiry at ​

In Autologyx, expiry at is the optional date field on an authentication object that defines when the stored authentication details expire. It is used when creating, updating, listing, and sorting authentication objects through the platform API, and it must be supplied as a valid future date in YYYY-MM-DD format; when expiry at is set, expiry applies to is also required to identify what the expiry covers. This field matters because it allows configuration admins and integrators to manage the lifecycle of credentials and other authentication assets used by integrations, helping ensure that authentication objects remain accurate, valid, and appropriately governed within the platform.

external ​

In Autologyx, external is an authentication method setting within Security Rules that defines how external account types are allowed to sign in to the platform. It is used in the authentication method object returned by and updated through the /api/security/ configuration endpoints, alongside related account-type settings such as internal, full, super admin, service internal, and service external. For configuration and super administrators, this setting matters because it controls the permitted login mechanism for external users as part of the platform’s security policy, helping enforce the required balance between user access, single sign-on adoption, password-based access, and compliance with organisational security standards.

extract files ​

In Autologyx, extract files is the file-processing stage in the Catalyst Object Record upload workflow that runs after uploaded file parts have been completed and confirmed, and is surfaced through the files WebSocket endpoint. During this step, the backend processes the uploaded content and emits periodic progress messages so client applications can track the status of extraction alongside other monitoring updates in the upload lifecycle. This matters to developers and integrators because it marks the transition from raw file transfer to backend handling of the uploaded files, enabling them to present accurate progress feedback, coordinate subsequent workflow actions, and ensure their integrations respond correctly as file ingestion advances.

failed count ​

Failed count is the integer field returned for an Object Record Upload that shows how many files in the upload were not processed successfully. In Autologyx, it is used in the Object Records Uploads API response alongside total files, successful count, successful percent, and failed percent, and it is relevant when retrieving upload status and reviewing completed upload files. This value matters to developers and integrators because it provides a direct measure of upload failures, supports monitoring and validation of bulk object record ingestion, and helps identify when further investigation is needed using related fields such as error reason.

failed percent ​

Failed percent is the integer response field in the Object Record Uploads API that shows the percentage of files in an upload that failed processing. It is returned in upload status and metadata for object record upload jobs, alongside related fields such as total files, successful count, successful percent, and failed count, and is used when retrieving information about a specific upload and its completed files. For developers and integrators, this field matters because it provides a quick, normalized measure of upload failure rate that supports monitoring, validation, troubleshooting, and downstream handling of bulk object record imports without requiring manual calculation from the raw counts.

failure email ​

In Autologyx, failure email is an SMTP integration configuration field that defines the email address or comma-separated list of addresses that receive notifications when outbound mail delivery fails. It is used in the platform’s outbound mail and SMTP settings APIs, including integration retrieval, update, and test endpoints, alongside related fields such as host, port, TLS, from email, and authorization method. This setting matters because it directs delivery failure alerts to the right operational or support recipients, enabling administrators and integrators to monitor mail issues, troubleshoot configuration problems, and maintain reliable automated communications; the field supports up to 10 recipients and has a maximum length of 255 characters.

field id ​

In the Autologyx platform, a field id is the integer identifier assigned to a field within event data returned by the Events API. It is used alongside field type, field name, and field value to describe individual data elements in an event record, and it is also referenced in API validation and error handling, for example when a request contains an invalid field identifier. For developers, integrators, and teams using event history for security, compliance, or analytics, the field id matters because it provides a stable machine-readable key for identifying, processing, and troubleshooting event fields independently of their display label or value.

field name ​

In the Autologyx platform, a field name is the string label associated with a field in event data, used alongside the field id, field type, and field value to describe an event record in the Events resource. It is used when developers, integrators, and reporting or compliance users inspect or process event payloads, because it provides the human-readable identifier for a field while the field id provides the system identifier and the field value contains the actual data. Field names matter because they make event content understandable in integrations, analytics, auditing, and troubleshooting, and they help users map raw event data to the business meaning of each field.

field type ​

In Autologyx, field type is the enumerated classification attached to a field within event data, used alongside field id, field name, and field value to describe the structure of an event returned by the Events resource. It identifies what kind of field the event record contains and provides the schema-level meaning needed to interpret the associated value correctly when consuming event history through integrations, analytics, compliance reporting, or other downstream processing. Field type matters because it enables developers and administrators to parse event payloads consistently, map event fields reliably, and apply the correct handling rules for different kinds of event information across the platform.

field value ​

In the Autologyx platform, a field value is the actual data held in a field and returned as part of a field value object in event-related API responses. It is used alongside the field id, field name, and field type to represent the content captured for a specific field, and it supports any JSON-compatible value so that different field types can be represented in a consistent API structure. This matters to developers, integrators, and compliance or analytics users because the field value is the payload they read, process, validate, store, and report on when consuming event data from the platform.

field values changed ​

Field values changed is an event type in Autologyx history and event streams that records an update to one or more fields on an object record. It is used in Object Records History Events and the Event History API alongside other lifecycle event types such as record created, record deleted, document generated, and status initialized, and is returned with standard event metadata including event id, event datetime, and source type. This event matters to developers, configuration administrators, and compliance or analytics users because it provides a consistent way to identify and process record data changes, support audit and monitoring requirements, and distinguish field-level updates from ownership, assignment, status, document, and record lifecycle events.

file fields ​

File fields are API request fields in the Autologyx platform that accept file-type values when creating or updating resources through the Autologyx API. They are used in resource schemas and API payloads defined in the Catalyst API Reference, including scenarios that involve nested schema structures or other resource properties with specific update rules. File fields matter to developers and integrators because they determine the required format and handling of file content in requests, and correct implementation is essential for requests to align with the configured behavior of the target resource.

file id ​

In the Autologyx platform, a file id (file identifier) is the unique string returned by the GET /api/files/upload_url endpoint alongside a presigned S3 upload URL, and it identifies the specific file being uploaded for event-history storage. This identifier is used by developers and integrators when working with the Files resource and related history services, providing the platform with a stable reference to the uploaded file independently of the temporary upload URL itself. The file id matters because it is the canonical handle for associating uploaded content with history records and downstream processing, enabling files to be tracked, linked, and retrieved consistently across the API History Event microservice and other integrations.

file key prefix ​

In the Autologyx platform, the file key prefix is the storage path prefix applied to file objects and is set to the client instance database name. It is used in the file-handling flow for history and event-related file storage, including APIs such as GET /api/files/upload_url that return presigned S3 URLs, so uploaded files are organised under the correct client instance context. This matters because it provides tenant-specific segregation of stored files, aligns file locations with the owning client instance, and is an important configuration and integration detail when managing file uploads, retrieval, and history storage across environments.

file permissions ​

File permissions, represented as meta.permissions, are the file-level permission settings used in the Autologyx platform to control what actions can be performed on an uploaded file. They are used in the Files resource as part of a file’s metadata and work alongside file operations such as store, list, and delete to define access to a specific file within the platform’s file handling model. This matters to developers, configuration admins, and Super Admins because meta.permissions determines how uploaded files can be accessed and managed through compatible endpoints, object record document fields, and storage configurations, helping ensure that file access aligns with role design, integration requirements, and platform security controls.

file token ​

A file token, often shown simply as token, is the backend-generated unique string returned when a file is uploaded to Autologyx and used to identify that specific file in subsequent API requests. It is used by developers and integrators with compatible endpoints that accept uploaded files, allowing a previously uploaded file to be referenced without resending the binary content. In practice, the token appears in file upload responses and is then supplied as a request field to attach, process, or otherwise use that file in supported operations. This matters because the file token is the platform’s standard mechanism for linking uploaded files to other resources and workflows, and correct use of the token depends on the file existing and the caller having the required file permissions, such as store, list, or delete access where applicable.

File uploads Tech design ​

INSUFFICIENT_EVIDENCE

filter by ​

filtered count ​

Filtered count is the integer value returned in the Autologyx Object Records permissions context that represents how many records are visible to the current user after both permission rules and any applied filters have been enforced. It is used when working with Object Record permission sets and related object class permission configuration to show the effective number of accessible results, rather than the total number of records in the underlying dataset. This matters to developers, configuration admins, and Super Admins because it provides the correct post-permission, post-filter result size for interfaces, integrations, and access-controlled logic, helping ensure that record lists, counts, and user-facing totals align with the records a user is actually allowed to see.

filtering ​

Filtering in the Autologyx platform is a user preference that stores how an authenticated user narrows the data shown in frontend application views, particularly alongside table column and sorting settings as part of layout configuration. It is used within User Preferences under a frontend-managed preferences key and is accessed through the user preferences API endpoints, including GET and POST /api/users/preferences/{key}/, which read and persist these settings for the current user. Filtering matters because it allows users and integrators to preserve consistent, personalised views of records and lists across sessions, helping the interface return in the expected state and supporting a more efficient user experience when working with tabular data.

filtering predicates ​

Filtering predicates, also called predicates, are the operator-based query terms used in the Autologyx API to restrict list results by field value. They are used on collection and list-view endpoints as part of standard API query syntax, alongside ordering, and are defined per field in API metadata such as OPTIONS responses, which identify the field alias, type, supported predicates, and whether sorting is allowed. Available predicates depend on the field’s data type and include operators such as exact match, case-insensitive text matching, null or empty checks, numeric and date comparisons, ranges, membership tests, and set operators. Filtering predicates matter because they provide the standard mechanism for building precise, consistent queries across Autologyx resources, allowing developers and integrators to retrieve only the records relevant to a workflow, integration, or user interface.

folder ​

In Autologyx, a folder is a required string field used in the configuration of an iManage integration through the Integrations API, including create and update operations on /api/integrations/. It is supplied as part of the integration details payload, returned in the integration response schema, and validated as a non-null, non-blank value with a maximum length of 255 characters. This setting matters because it defines the target folder context used by the integration configuration, so developers and configuration administrators must provide it correctly to ensure the integration can be saved and function as intended.

form configuration ​

Form configuration is the JSON definition stored on an Object Class Form that tells the Autologyx frontend application how a form should be rendered and behave for a given object class or standalone create form. It is used when creating, retrieving, and managing forms through the /api/object class forms/ endpoints, alongside related settings such as form type, enabled state, and any referenced custom components. For configuration admins and developers, this matters because the configuration controls the structure and user experience of data entry for Object Records, supports integration of custom components, and works in the wider context of object classes, class relations, and form metadata such as meta.labels and meta.permissions. A valid form configuration is required for form creation and maintenance, making it a core part of configuring how users interact with business objects in the platform.

from email ​

From email is the outbound sender address configured for an Autologyx mail integration or SMTP settings record, and it is used as the email address that Autologyx sends messages from when delivering outbound mail. It is exposed as a string field in the integrations and SMTP settings administration APIs, including configuration and test endpoints such as /api/integrations/, /api/integrations/test/, and the SMTP settings administration endpoints, where administrators and integrators supply or update it alongside host, port, TLS, authorization method, and any authentication object. This field matters because it defines the sender identity presented to recipients, supports correct outbound mail setup, and must conform to platform validation rules, including a maximum length of 254 characters, when configuring or automating email delivery in Autologyx.

frontend application layout settings ​

Frontend application layout settings are the per-user configuration values that store how the Autologyx frontend is arranged and behaves for an authenticated user. In the platform, these settings are managed as user preferences under frontend-controlled preference keys and are used to persist interface choices such as table columns, sorting, filtering, and other layout-related options. They are accessed through the user preferences API, including GET /api/users/preferences/{key}/ and POST /api/users/preferences/{key}/, allowing the application or integrations to read and save a user’s personalised interface state. These settings matter because they preserve a consistent, user-specific working experience across sessions and devices, and they provide developers and integrators with a standard mechanism for storing and retrieving frontend UI configuration.

full ​

INSUFFICIENT_EVIDENCE

generated document ​

In Autologyx, a generated document is the output file produced for an object record through the document generation process, typically from a document template populated with record data such as merge fields and document fields. It is used in the Object Record Documents area and related API endpoints, where each document entry includes generation details such as status, error message, the generated file reference, when it was generated, who generated it, and downloadable file metadata including name, URL, size, and type. This matters because it is the operational result that users and integrators track, download, sort, and manage, and its status determines whether generation has completed successfully, failed, or can still be cancelled while processing.

Generic Client Credentials ​

Generic Client Credentials, shown in the Authentication Objects API as the provider value oauth client credentials, is an authentication object type in Autologyx for connecting to external services that use the OAuth 2.0 client credentials grant. It is used when creating or managing authentication objects and requires configuration of a client id, client secret, token URL, and optionally a scope, refresh URL, additional parameters, and additional authorization headers. This provider is the flexible alternative to product-specific options such as Adobe Client Credentials or Box Client Credentials, allowing configuration admins and integrators to support standards-based OAuth services that are not covered by a dedicated provider. It matters because the authentication object stores the connection details Autologyx uses to obtain access tokens for API calls, so correct setup is essential for successful integrations, secure credential management, and reliable operation of workflows that depend on external systems.

GET /api/administration/company details/ ​

GET /api/administration/company details/ is the Autologyx administration API endpoint used to retrieve the current Company details record for the tenant as a single-instance resource. It is used by developers, configuration administrators, and Super Admins when reading the organisation-level details configured in the platform, and it also exposes the applicable permissions context for viewing or editing Company details through the related administration resource model. This endpoint matters because Company details are a core administrative configuration area, and using the GET operation is the standard way to obtain the current values before presenting them in administrative interfaces, validating access, or preparing updates through the corresponding PATCH endpoint.

GET /api/files/upload_url ​

GET /api/files/upload_url is an API History Event microservice endpoint used by developers and integrators to generate a presigned Amazon S3 upload URL before attaching a file to a History Event. In the Autologyx platform, it is part of the file-handling flow for history storage: a client first calls this endpoint to obtain the upload target, uploads the file to the S3 bucket, and then records the event with the associated file metadata such as the file id or file key prefix. This endpoint matters because it enables secure, controlled file ingestion for event-related documents without routing file content directly through the main event creation request, supporting scalable storage and reliable association of files with History Events.

GET /api/history/events ​

GET /api/history/events is the Autologyx API endpoint used to retrieve a paginated list of History Events from the platform’s event history store, filtered by supplied query parameters such as date range and other event attributes. It is used by developers, integrators, and reporting or compliance teams when they need to access event data programmatically for audit trails, analytics, monitoring, or downstream processing. Within the platform, this endpoint sits alongside other event-history resources and follows Autologyx API authentication and tenant/client validation requirements, with defined error handling for invalid source, field, client, and date-range inputs. It matters because it provides the standard supported mechanism for extracting structured historical event records from Autologyx, enabling reliable integration with external systems and consistent access to operational and compliance-relevant history data.

GET /api/history/events/{event_id}/file ​

GET /api/history/events/{event_id}/file is the Autologyx History Event API endpoint used to retrieve a presigned Amazon S3 download URL for the file associated with a specific history event. It is used by developers and integrators working with the Event History service when an event record includes file content that must be downloaded outside the standard event payload. In practice, the endpoint is called with an event ID after identifying the relevant event data and event type, and it returns a secure, time-limited link rather than the file itself. This matters because it provides a controlled, scalable way to access event-related files while aligning with Autologyx API patterns and the platform’s external file storage approach.

GET /api/users/preferences/{key}/ ​

GET /api/users/preferences/{key}/ is the Autologyx API endpoint used to retrieve the authenticated user’s stored preference values for a specific preferences key. In the platform, user preferences hold frontend application layout settings such as table column configuration, sorting, filtering, and other saved interface choices, and this endpoint is typically used by developers and integrators when building or extending user-facing experiences that need to load those settings. It matters because it allows applications to restore a user’s personalized view consistently across sessions, ensuring the interface reflects the user’s previously saved configuration and works in conjunction with the corresponding POST endpoint that creates or updates those preference values.

GET /api/users/ws auth/ ​

GET /api/users/ws auth/ is the Catalyst API endpoint that generates the UUID v4 token used to authenticate a client before it opens a Catalyst WebSocket connection. It is used as part of the Catalyst Websockets API authentication flow, where the returned UUID is included in the WebSocket connection process for endpoints that deliver real time updates and buffered events. This endpoint matters to developers and integrators because it is the required bridge between standard API access and authenticated WebSocket sessions, enabling clients to establish trusted connections and receive live Catalyst event data correctly.

GET /ws/events/object records/ ​

GET /ws/events/object records/ is the Autologyx WebSocket events endpoint used to subscribe a client to the stream of Object Record change events across the platform. It is used by developers and integrators when building real-time integrations, monitoring services, or responsive user experiences that need immediate notification when Object Records are updated, including events such as object record created, deleted, value changed, assignee changes, owner changes, and document generation. This endpoint matters because it provides a live event feed for Object Record activity, enabling connected systems to react to record lifecycle and ownership changes without relying on polling or delayed synchronisation.

GET /ws/events/tasks/ ​

GET /ws/events/tasks/ is the Autologyx WebSocket endpoint used to subscribe a client to the platform’s real-time stream of Task change events. In practice, it is used by developers and integrators building live interfaces, dashboards, or connected services that need immediate notification when Tasks are created, deleted, updated, or reassigned, rather than polling for changes. The endpoint is documented in the Events WebSocket resources and sits within the platform’s real-time update mechanism, where event messages can include details such as the task ID, event timestamp, Object Class ID, and specific change types such as task status changed, task assignee added or removed, and task owner added or removed. This endpoint matters because it enables responsive integrations, supports event-driven automation, and helps external systems stay synchronised with Task activity across the Autologyx platform.

Global scope ​

Global scope is the top-level permission context in the Autologyx platform, used when access is evaluated for an entire resource type rather than for a specific individual object. It appears in permissions tables and related API documentation for platform-wide configuration and administration resources such as Single Sign On configuration, Company details, Files, and Integrations, where it governs actions like listing, viewing, creating, editing, or deleting at the collection or tenant level. Global scope matters because it determines whether a user, role, or integration can access or manage these capabilities across the environment before any object-specific permissions are considered, making it a key concept for configuration admins, super admins, and developers who design roles, enforce access control, or work with endpoints such as /api/integrations/ and /api/integrations/test/.

group permission ​

Group permission is the platform authorization that controls whether a user can reference a specific User Group when configuring assignees on an Object Class Permission Set or an Object Record Permission Set in Autologyx. It is enforced when configuration admins, super admins, or integrators add User Groups to assignee lists for object classes and object records, and if the user does not hold permission for the selected group the request is rejected with the message that they do not have permission for this Group. This matters because group permission governs who can use particular groups in access and assignment configuration, helping ensure that permission sets, assignee lists, and related object security settings are managed only by users who are allowed to work with those groups.

has system fields ​

Has system fields is a boolean property on an Object Class that indicates whether the class includes Autologyx system-managed fields. It is used in the Object Classes resource and API responses alongside other class-level metadata such as identifier, record count, display configuration, and meta.permissions. This setting matters when configuring or integrating object classes because it distinguishes platform-provided fields from custom object class fields, which affects how administrators and developers understand the structure of records, design UI and display behaviour, and work with object data through configuration and API-based solutions.

header key ​

In Autologyx, a header key is a string field used in an Authentication Object to define the HTTP header name that carries an API key when configuring integrations that authenticate through header-based credentials. It is used by configuration admins and developers when setting up the api key provider, alongside related values such as the API key itself and any URL key, so the platform can place the credential in the correct request header expected by the target service. This matters because external systems often require a specific header name for authorization, and the header key ensures Autologyx sends authenticated requests in the format required by that integration.

History Event microservice ​

The History Event microservice, also referred to as the API History Event microservice, is the Autologyx platform service that stores and retrieves historical activity for a client environment through the Event History API. It is used in developer and integration scenarios wherever platform events need to be written, queried, or reported, and its Events endpoints expose event data and event types in line with Autologyx API standards. For each client created in Autologyx, the platform provisions a client-specific ClickHouse history database and a related tenant entry in the default ClickHouse database, allowing history records to be managed per tenant. This service matters because it provides the structured event history needed for audit trails, compliance reporting, security review, operational analytics, and any integration that depends on reliable access to historical platform activity.

History Events ​

History Events are the event records managed by the Event History API microservice in Autologyx to capture and expose auditable changes and outputs associated with platform activity. They are used through the Event History API endpoints to create event records, retrieve paginated event histories with filtering, and generate presigned URLs for files referenced by those events, with records stored in ClickHouse and related file content held in S3. A History Event includes core metadata such as event ID, timestamp, event type, source type, source ID, and event data, and supports business and audit scenarios such as tracking actions like assignees added, assignees removed, and document generated. History Events matter because they provide a structured, queryable activity trail for integrations, compliance reporting, operational analytics, and secure access to event-linked files.

history storage ​

History storage is the S3-backed file storage used by the Autologyx API History Event microservice to hold files that are linked to history events. It is used in Event History API file-handling flows where a client first requests an upload URL, uploads the file directly to history storage using the returned presigned S3 URL, and then records or references the file in a history event by its file identifiers, such as the file id and file key prefix. This matters because history events that include documents or other attachments depend on the file being placed in history storage before the event is created, making it a required part of integrating file uploads with the platform’s event history capabilities.

ID based access ​

ID based access is the legacy compatibility method for working with object record merge fields in Autologyx, where a field returns lists of identifier values rather than full related objects. It is used in document templates and integrations that rely on existing configurations expecting user IDs and user group IDs, allowing established implementations to continue operating without redesign. This matters to configuration admins and developers because it preserves backward compatibility with older template logic and downstream processes, while also defining a clear contrast with object based access, which is used when richer related data is needed directly in the platform.

identifier ​

In Autologyx, an identifier, also shown as the object record identifier, is the Object-valued property on an object class that defines which field is used to identify records of that class. It is exposed in the Object Classes API and configuration responses as the **identifier** field on the object class, and it works alongside field-level properties such as is **identifier** and is unique that describe which object class field serves as the identifying value. This matters when configuring object classes and integrations because the identifier establishes the primary business-facing reference for records, supports consistent record selection and display across object class usage, and helps ensure each record can be distinguished correctly within the platform and through the ALX API.

Image embedding ​

Image embedding in Autologyx is the merge-field capability that inserts an image file stored in a document field attachment directly into generated DOCX content, using custom filters in document templates and supported document-generation contexts such as Send Message, Variable, API Call, and Doc Auto actors. It is configured by referencing the document field alias, a mandatory attachment index, and the image embedding property, with optional width and height filters to control dimensions in millimetres. PNG, GIF, and JPEG/JPG formats are supported, and sizing follows defined ratio-preservation rules depending on whether one or both dimensions are set. This matters because it allows configuration admins to build templates that place attached images accurately and consistently in output documents, while end-users benefit from correctly rendered embedded images instead of manual document editing.

Image Processing ​

IManage ​

IManage is an authentication object provider in the Autologyx platform used to store the connection details required for integrations that authenticate against iManage. It is configured in Authentication Objects by setting the provider to **imanage** and supplying the provider-specific credentials: username, password, client id, client secret, and host as a valid URL. This matters to configuration administrators and integrators because the iManage authentication object centralises the credentials and endpoint information Autologyx uses when an iManage integration is activated and enabled, allowing the platform to connect securely and consistently without hard-coding connection details into individual processes or services.

iManage integration type ​

The iManage integration type is an Autologyx integration configuration used to connect the platform to iManage and define how documents are created or filed through that external system. It is configured through the integrations API, including /api/integrations/ and /api/integrations/test/, where its type-specific details schema adds iManage fields such as folder, object class field, and dedupe, with available values exposed through details.schema by type and related authentication and authorization settings provided through authentication objects. This integration type matters to developers, configuration administrators, and Super Admins because it controls the structure and validation of iManage connection settings, determines which iManage object class is used, and ensures the platform can correctly authenticate, test, and manage iManage-specific integration behaviour.

index url ​

In Autologyx, the index url is a string field on a custom component record that stores the URL used as the component’s index or entry location within its Custom Components Repository definition. It is used alongside repository, repository url, version, publisher, status, and meta.permissions when developers or integrators view, register, or manage custom components in the platform. This field matters because it identifies the specific endpoint or resource location associated with the component, helping ensure the platform can reference the correct component source as part of custom component administration and lifecycle management.

initiated ​

In Autologyx, initiated is the status value assigned to an Object Record when it is created or updated through the Object Records API. It is used in Object Record payloads and responses as the record’s status field, where the documented value is initiated. This matters to developers and integrators because it defines the record state returned by the platform during Object Record operations, and it sits alongside key Object Record properties such as object class, ownership, and permission-controlled fields when building, syncing, or validating integrations.

integration configuration ​

An integration configuration is the Autologyx platform object that defines a specific external system connection and how Autologyx should interact with it. It is used in integration administration and API-driven setup through endpoints such as /api/integrations/ and /api/integrations/test/, where configuration admins, Super Admins, and developers create, view, edit, delete, and validate integrations under role-based permissions. An integration configuration typically combines the integration type, authorization method, authentication objects and AuthenticationObjectData, and the type-specific fields defined in details.schema, following ALX API standards. It matters because it is the operational record that enables outbound connectivity and controlled communication with third-party services, making correct configuration essential for secure, testable, and maintainable integrations.

integration type ​

Integration type is the required enum value on an Autologyx Integration that identifies the kind of connector being configured and determines the schema, field requirements, and validation rules applied to that integration. It is used when creating, viewing, and validating records through /api/integrations/, where the selected type controls the available configuration defined in details.schema by type, including supported authentication object and object class options. This matters to configuration admins, developers, and super admins because the type drives how an integration is structured, what data must be supplied, and whether the configuration will pass platform validation and operate correctly for the intended external service or capability.

Integrations ​

Integrations in the Autologyx platform are configurable connections that extend core ALX system features by linking the platform to external services or technical capabilities. They are used in platform configuration and administration, including integration management endpoints such as /api/integrations/ and /api/integrations/test/, where administrators and integrators create, view, edit, test, and delete integration configurations in line with ALX API standards and the required authentication and authorization settings for each integration type. Integrations matter because they provide the foundation for enabling platform features that depend on external connectivity, and effective configuration of the correct authentication objects, data structures, and type-specific schema details is essential for secure operation, successful service communication, and reliable feature enablement across the platform.

internal ​

In Autologyx, internal is the authentication method setting for internal user accounts within Security Rules, used in the authentication method configuration returned by and updated through the /api/security endpoint. It defines which sign-in methods internal accounts are permitted to use, with supported values any, password, and sso. This setting matters because it controls how internal users authenticate to the platform, allowing administrators and integrators to align access policies with organisational security requirements, standardise login behaviour across account types, and enforce whether internal users can sign in with passwords, single sign-on, or either method.

is available ​

In the Autologyx platform, is available is a boolean field used in API responses and filtering to indicate whether a resource is currently available for use within the system. It is exposed on resources such as object record document definitions and users, where it forms part of the returned metadata and can also be used as a filter parameter when querying records. For developers and integrators, this field matters because it provides a simple, machine-readable way to distinguish active, usable items from those that should not be presented, selected, or processed in integrations, user interfaces, and automated workflows.

is identifier ​

In Autologyx, is identifier is a Boolean property on an Object Class field that marks that field as an identifier for records of that object class. It is used when creating, retrieving, and updating Object Class fields through the Object Classes configuration and API responses, alongside related field properties such as is unique, is system, and has duplicates. This setting matters because it designates which field is used to identify an object in the platform’s object model and integrations, and it is governed by field-type validation so only supported field types can be marked as an identifier. For configuration admins, super admins, and developers, setting is identifier correctly is important for establishing consistent object definitions and ensuring fields intended to represent a record’s identifying value are explicitly configured as such.

is super admin ​

In Autologyx, is super admin is a Boolean user attribute that identifies whether a user account has Super Admin status. It is used in the Users area and related user management interfaces and APIs as a filterable field alongside properties such as account type, roles, and status, allowing administrators and integrators to find, segment, and manage privileged accounts. This field matters because Super Admin users typically hold the highest level of platform-wide administrative access, so distinguishing them from other account types and role assignments is essential for governance, access control, operational administration, and integration logic that needs to handle highly privileged users differently.

is system ​

  • Mostly relevant to: Configuration admins, Developers / Integrators, Super Admins
  • Closely related concepts: available system integration, app id, ALX API standards

In Autologyx, is system (or system flag) is a Boolean property on an Object Class field that marks the field as a platform-managed system field rather than a fully user-managed custom field. It is used in the Object Classes API request and response payloads when creating, updating, retrieving, or deleting fields, where it determines what administrators and integrators can change after the field exists. When is system is set to true, the field becomes restricted: it cannot be changed back from true, only its label, description, and order can be updated, and it cannot be deleted. This matters because the flag protects core schema elements that the platform depends on, helps preserve API and integration compatibility, and tells configuration admins, developers, and super admins which fields are reserved for stable system behaviour rather than normal lifecycle management.

is unique ​

In Autologyx, is unique is a Boolean property on an Object Class field that enforces uniqueness of that field’s value within the scope of the same Object Class. It is used when creating, viewing, or updating Object Class fields through Object Class configuration and related API responses, where it appears alongside properties such as is identifier, is system, and has duplicates. This setting matters to Configuration Admins and Super Admins because it controls whether duplicate values are allowed for a field across records of that Object Class, helping preserve data integrity, support clean record management, and define fields that must hold distinct values for operational or business purposes.

is word addin enabled ​

In Autologyx, is word addin enabled is an optional Boolean setting on a Single Sign On (SSO) configuration that indicates whether that Azure-based SSO configuration supports the Word Add-in. It is used in the SSO configuration API and related administration flows alongside settings such as client ID, tenant ID, auto create user, and logout URL, and it is returned in SSO configuration list and detail responses. This setting is valid only when the SSO provider is Azure; using it with a non-Azure provider returns a validation error, and the platform enforces the documented Azure application SSO constraint for this flag. For configuration administrators, super admins, and integrators, this setting matters because it determines whether a specific Azure SSO configuration can be used by the Word Add-in, ensuring the correct authentication path is available for Word-based platform access and preventing unsupported provider configurations.

Jinja template syntax ​

Jinja template syntax is the templating language syntax that Autologyx uses inside Object Class Document Templates to insert merge fields and define dynamic document content. It is used when uploading or verifying .docx document templates, where the platform validates the template file for correct Jinja syntax and checks referenced merge tags against related classes and class fields. This matters to configuration admins and developers because valid Jinja syntax is required for template acceptance and successful document generation: it controls how data from object classes is rendered into documents, and syntax or merge-tag errors are returned during template validation so they can be corrected before the template is used in production.

labels.object classes ​

In Autologyx, **labels.object classes** is a metadata field returned in the meta section of Task Group Template API responses that provides the display labels for the object classes associated with the object classes ID list. It is used alongside fields such as labels.task templates in endpoints for creating, updating, retrieving, and deleting Task Group Templates, where the main resource payload contains object class identifiers and the labels structure supplies the corresponding human-readable values. This matters to developers and integrators because it supports API consumers, admin tooling, and autocomplete or configuration interfaces that need to present meaningful names for linked object classes without resolving each ID separately, making Task Group Template configuration clearer and easier to render correctly in client applications.

labels.task templates ​

In the Autologyx API, **labels.task templates** is a metadata array returned under meta in Task Group Template responses that provides display labels for the task templates associated with the resource. It is used alongside fields such as task templates and labels.object classes in create, update, delete, and retrieval responses for task group templates, giving integrators a human-readable representation of related task template records in addition to their underlying IDs. This matters when building API-driven interfaces, autocomplete components, and administration tooling, because it lets developers present meaningful task template names to users while preserving the canonical relationship data required to configure and maintain task group templates correctly.

landing page ​

In the Autologyx platform, a landing page is a supported usage context for a Custom Component, represented by the available use.**landing page** boolean in the Custom Components API. When this setting is enabled, the component is configured for placement on landing pages rather than only within object class forms or task template forms. This matters to developers and configuration admins because it controls where a custom component can be deployed across the platform, affects how component availability is defined and retrieved through the API, and is reflected in component usage reporting, including counts of landing pages where the component is in use.

last task created ​

In Autologyx, last task created is a Task Template datetime field that records when the most recent task instance was generated from that template. It is used in Task Template listings and detail responses alongside related metadata such as num of tasks created, created at, and modified at, giving administrators and reporting users a direct view of template activity. This field matters because it helps configuration admins confirm that manual or automatic task creation is occurring as expected, identify inactive or recently used templates, and support operational monitoring, audit review, and analytics around task generation behaviour.

limit ​

In the Autologyx platform, a limit is the maximum permitted number of objects of a specific type that can exist within the system. It is used in the system Limits API, including responses for areas such as object classes, task group templates, task templates, and sequences, where it is presented alongside current counts to show allowed capacity. This matters to developers, integrators, and Super Admins because limits define the platform boundaries for configuration and automation, helping them monitor usage, plan deployments, and prevent attempts to create resources beyond the permitted threshold.

list edit view delete ​

List edit view delete is the full set of valid actions available for the object classes resource in Autologyx object class permission sets. Used by configuration and super administrators when defining Object Class level access, this permission combination controls whether a user can list available object classes, open and inspect an object class, modify its configuration, and remove it. It matters because object class permissions determine who can administer the structure and lifecycle of object classes in the platform, and the selected actions are enforced as part of the permission model, including any required permission dependencies applied during conversion of sent permissions.

list permission ​

List permission is the Files permission that controls whether a user can view the list of files stored in public storage in Autologyx. It is used when calling the public storage file-listing capability, such as the GET /api/files/public storage/ endpoint, which returns a paginated list of available files. This permission is disabled by default and is enabled only for Super Admins, making it an important access control for configuration and governance of publicly stored files. For administrators configuring file access, list permission determines who can browse public storage contents, and it works alongside related file permissions such as store and delete to define how users can interact with files.

list view ​

List view is the standard Autologyx API representation returned by a GET endpoint that lists multiple resource instances, such as a collection endpoint like /api/task templates/. It is used across resource collection endpoints and is defined alongside detail views in the API standards, with supporting OPTIONS metadata that describes list-view attributes, available filtering predicates, ordering behaviour, and related schema information. List view matters because it is the primary format developers and integrators use to browse, search, filter, sort, and paginate platform data efficiently, and because its field structure and helper metadata must remain consistent with the corresponding detail view to support reliable client implementations and predictable API integrations.

Local Variable ​

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

A Local Variable is a Sequencer actor in the Autologyx platform used to store a value during workflow execution so it can be reused by later steps and referenced through merge fields. It is used within Sequencer configurations alongside actors such as API Call and Send Message, where administrators and integrators define temporary runtime values to support message composition, data transformation, and step-to-step processing. Local Variables matter because they provide a controlled way to capture and pass operational data through a sequence without changing object records, making workflow logic easier to configure, maintain, and integrate with other actors and merge-field-enabled contexts.

logout url ​

In Autologyx, the logout URL (also called the logout callback URL) is the URL configured on a Single Sign On (SSO) provider record that defines where the user is sent when sign-out is completed. It is used in SSO configuration alongside settings such as provider, client ID, tenant ID, and redirect URI, and is particularly relevant when integrating identity providers such as Azure or Okta. This setting matters because it controls the post-logout return path for SSO sessions, helping ensure users exit authentication flows cleanly and are directed to the correct application location after signing out.

Loop actor ​

A Loop actor is a Sequencer actor that iterates over a collection of items and runs downstream actors once for each item in that collection. In Autologyx, it is used in workflow and Sequencer configurations when you need to process arrays, document picker results, or other multi-item sources one element at a time. During execution, the Loop actor exposes the current element through loop item merge fields, which are available inside actors connected directly or indirectly downstream of the Loop, enabling templates, scripts, notifications, and integrations to reference the item currently being processed. This matters to configuration admins and developers because the Loop actor is the standard mechanism for repeating actions over structured data, and correct configuration of its source, triggers, and downstream actor usage determines whether per-item processing and related merge fields work as intended.

loop item ​

In Autologyx, a loop item is the Sequencer merge field that exposes the current element being processed by a Loop actor during a single loop iteration. It is used in any actor that runs downstream of a Loop actor through the Loop item processed connection, where it provides the iteration-specific value from the configured loop source, including support for nested properties when the source contains structured data such as arrays or document representations. This matters because it lets configuration admins and end-users build actions, API calls, and other downstream steps that operate on each item individually rather than on the full collection, ensuring each iteration receives the correct context. Correct loop source and trigger configuration are essential, because the field is populated from the Loop actor’s current item and resolves to an empty string in invalid configurations; in testing scenarios with multiple Loop connections, Autologyx evaluates the most recently modified Loop actor.

Loop Item Context ​

Loop Item Context is the system merge field context that exposes the currently processed item inside a Loop actor, allowing templates and other merge-field-enabled components to reference data from each item as the loop runs. In Autologyx, it is used wherever merge fields are supported, including document templates, email templates, sequencer actors, API responses, workflow notifications, and custom scripts. This context matters because it enables dynamic, item-by-item output within iterative workflow steps, so administrators can configure documents, messages, and automated actions to use values from the active loop item without requiring a separate object record context.

Loop item processed ​

Loop item processed is the Loop actor trigger that runs connected downstream actors once for each element in the loop source, creating the execution context for a single loop iteration in the Autologyx Sequencer. It is used when an actor is connected directly to a Loop actor so that, on each pass, the downstream actor receives the current loop item and can use loop-specific merge fields such as the current element and its nested properties. This trigger matters to configuration admins and developers because it is the correct way to process array or document-based loop data item by item; using Loop item processed ensures per-item values render correctly in downstream actions and API calls, whereas using a different trigger such as Actor completed does not provide the per-iteration loop context.

loop iteration index ​

In the Autologyx platform, the loop iteration index, also referred to as the current iteration index, is the value exposed by a Loop actor during execution to identify the position of the current pass through a collection. It is used within the execution context of a single loop iteration, typically through merge fields in sequencer or workflow configuration, alongside related loop data such as the loop item and loop source. This index matters because it allows configuration admins and end-users to reference, label, sequence, or condition actions according to the current item’s position in the loop, which is essential when building repeatable process steps that depend on ordered iteration.

Loop source ​

INSUFFICIENT_EVIDENCE

Manageable via Roles ​

manual type Task Templates ​

max num of files ​

Max num of files is an integer property returned in the Object Record Documents resource that defines the maximum number of files permitted for a document entry associated with an object record. In Autologyx, it is used when developers and configuration administrators retrieve document metadata for object records, alongside values such as alias, label, and availability, to understand and enforce the file-count limit for a specific document field or document type field. This matters because it determines how document capture, upload validation, and integration logic should behave, ensuring users and connected systems do not submit more files than the platform allows for that document record.

max repeating chars ​

Max repeating chars is the password complexity setting in Autologyx Security Rules that defines the maximum number of times the same character can be repeated in a user password. It is used in the password complexity object returned by and submitted to the /api/security/ endpoint, alongside related controls such as min length, min letters, min numbers, min symbols, min lower case, and min upper case, with an allowed integer range of 0 to 128. This setting matters when configuring platform authentication and password policy because it helps enforce stronger password construction standards, supports security and compliance requirements, and gives configuration administrators and Super Admins precise control over how restrictive password creation rules are across the platform.

maximum number of Object Class Permission Sets per specific Object Class ​

The maximum number of Object Class Permission Sets per specific Object Class is a platform-enforced configuration limit in Autologyx that allows no more than 10 permission sets to be defined for a single object class. This limit applies when creating and managing Object Class Permission Sets at the Object Class level, including through the object class permission sets API and related administration workflows used by Configuration Admins and Super Admins. It matters because it defines the upper bound for how access rules can be segmented within each object class, so administrators must design permission models within this cap when configuring class-level security. If the limit is exceeded, Autologyx rejects the request with a 400 Bad Request response and the error code ERR LIMIT EXCEEDED.

members perm set ​

In Autologyx, the members perm set is a built-in permission set type used on object classes to grant access to all platform members as a predefined audience, rather than to a custom list of assignees. It is used in object class permission configuration alongside other permission set types such as everyone and assignee-driven permission sets, and it is important because its membership is system-defined: user group assignees cannot be added to or managed on the members perm set. For configuration admins and Super Admins, this distinction matters when setting object class access, because attempts to assign user groups to the members perm set are rejected by the platform, so it should be selected only when access is intended for the full members scope provided by Autologyx.

MEMBERS Permission Set ​

The MEMBERS Permission Set is a special Permission Set type used on the user groups resource to define the baseline access and behaviour that applies to members of a specific User Group in Autologyx. In configuration, each User Group must have exactly one MEMBERS Permission Set, making it the required, group-specific permission set that distinguishes member-level permissions from other permission set types and reserved system sets such as EVERYONE. This matters to Configuration Admins and Super Admins because the MEMBERS Permission Set is a core part of how user group access is structured and enforced: without the single required MEMBERS set, the group is not correctly configured, and with more than one, the configuration breaks the platform rule that a User Group can have only one MEMBERS Permission Set.

membership ​

In Autologyx, membership is the user’s membership classification within a User Group, returned as a string field in User Group member and user listing endpoints and available as a filterable value in the API. It is used when retrieving, sorting, and filtering the users associated with a group, alongside fields such as username, added at, and company name. For developers, configuration admins, and super admins, membership matters because it identifies each user’s relationship to the group in a machine-readable form, supporting integrations, administrative reporting, and group management workflows that depend on distinguishing different categories of group participants.

Merge Field Rendering ​

Merge Field Rendering is a custom merge field filter in the Autologyx platform that processes string content as merge field markup so nested merge fields can be resolved and rendered at runtime. It is used when configuring document templates or other merge-driven outputs that contain dynamically generated merge field expressions, and is documented as part of the custom filters available for merge fields. This matters to configuration admins and developers because it allows template content to be composed in layers and still render correctly during execution, enabling more flexible document generation while following the platform’s defined handling for invalid input and unsupported file scenarios.

Merge fields ​

Merge fields are dynamic placeholders, also called template tags or MFs, that use Jinja2 syntax to insert live contextual data from Autologyx records and system objects into rendered content at runtime. They are used across document templates, message templates, Send Message and API Call actors, Sequencer actors, AI actors, and other merge-field-enabled resources, where they can reference object record fields, related records, document data, company details, and other scoped context values, with optional filters for formatting and domain-specific processing. Merge fields matter because they are the mechanism that turns reusable templates and actor configurations into record-specific output, and they are validated against available classes, fields, relationships, permissions, and scope context to ensure templates render correctly and only expose data that is available in the current Autologyx context.

Show 2 more pages

merge tags ​

Merge tags are the placeholders used in Autologyx document templates to pull data from an object class and its related classes into generated .docx documents. They are used when creating, updating, and verifying Object Class Document Templates, alongside Jinja template syntax and class field references, so template authors and integrators can define exactly which platform data is inserted into a document at generation time. Merge tags matter because Autologyx validates them as part of template processing, including checks against related classes, helping ensure that document templates only reference valid data structures and can be generated successfully.

message templates ​

Message templates are a configurable platform resource in Autologyx used to define standardised message content for platform-driven communications. They are managed as an administrative configuration item and are controlled through role-based permissions, where the Roles configuration exposes message templates as a distinct permissionable resource. This matters because access to create, update, or govern message templates is determined by the permissions assigned to a user’s role, allowing Configuration Admins and Super Admins to control who can manage the messaging standards used across the platform.

meta result ​

INSUFFICIENT_EVIDENCE

meta.labels ​

meta.labels is a metadata object returned on many Autologyx API resources that provides human-readable labels for fields or related entities in that resource. It is used across endpoints such as object class forms, integrations, files, authentication configuration, and object model responses, where it can supply attribute labels or named mappings such as the object class label associated with a record or form. For developers and configuration admins, meta.labels matters because it separates display text from the underlying API field names and identifiers, enabling clients, admin tools, and integrations to present consistent UI labels without changing the core schema or business data. In practice, use meta.labels when rendering API-driven screens, summaries, or configuration views that need friendly names for attributes, object classes, or related records.

meta.labels.document ​

meta.labels.document is the document metadata object returned in the Object Record Documents API for a generated document, containing the core file attributes name, url, size, and type. In Autologyx, it is used within document-related responses under generated document when listing or retrieving documents for an object record, where it can appear as an object in a single-document response or as an array element in collection responses. This field matters to developers and integrators because it provides the values needed to identify the generated file, present it in user interfaces, link to or download it, and handle document outputs correctly as part of the document generation process and broader object record document workflows.

meta.labels.files ​

meta.labels.files is a response metadata object used on Object Class Document Template records in the Autologyx API to expose details of the template file associated with a document template. It is returned in document template create, retrieve, list, and update responses, and contains file-specific label data such as the template file name, download URL, size in bytes, and file type/extension. This field matters to developers and configuration administrators because it provides the display and retrieval information needed to identify the uploaded template, present it correctly in integrations or admin tooling, and support document-template download and verification workflows without relying only on the template file ID.

meta.permissions ​

meta.permissions is a standard metadata object returned in Autologyx API responses that describes the permissions the current user has for the specific resource being retrieved. It is used across many platform objects and configuration resources, including object classes, object models, object class forms, roles, task templates, custom components, integrations, uploads, users, and company or SSO settings, and it appears alongside other metadata such as meta.labels. For developers and administrators, meta.permissions matters because it provides a consistent, per-object view of what actions are allowed on that resource in the current context, which supports building integrations, controlling UI behaviour, validating administrative access, and checking whether a user can view, update, delete, assign, or otherwise manage a record or configuration item.

Show 8 more pages

Microsoft Client Credentials ​

Microsoft Client Credentials is an Authentication Object provider in the Autologyx platform that stores the Microsoft-specific client credentials needed for service-to-service authentication, using the authorization method value **microsoft client credentials**. It is used when creating and managing authentication objects through the Authentication Objects API and related integration configuration, where the credentials payload for this provider must include tenant, client id, client secret, and scope. This provider matters because it gives configuration admins and integrators a standard, validated way to register Microsoft authentication details for integrations, enabling Autologyx to authenticate outbound connections consistently and ensuring the correct credential structure is available when configuring and testing integrations.

min length ​

Min length is the password complexity setting in Autologyx Security Rules that defines the minimum total number of characters required for a password. It is used in the password complexity object returned by and submitted to the /api/security/ endpoint, alongside related controls such as min letters, min numbers, min symbols, min lower case, min upper case, and max repeating chars. Configuration admins, Super Admins, and integrators use this integer value when reviewing or updating platform security policy, with supported validation values from 0 to 128. This setting matters because it enforces a baseline password size across applicable authentication configurations and helps align Autologyx account security with organisational password standards and compliance requirements.

min letters ​

In Autologyx, min letters is the password complexity setting that defines the minimum total number of alphabetic characters required in a password. It is part of the password complexity object returned by and updated through the Security Rules API at /api/security/, alongside related controls such as min length, min lower case, min upper case, min numbers, min symbols, and max repeating chars. Configuration admins, Super Admins, and integrators use this field when reviewing or patching platform security rules to enforce password standards for supported account types and authentication configurations. This setting matters because it helps shape password policy in a precise, machine-readable way, allowing organisations to align Autologyx authentication controls with internal security requirements and compliance standards.

min lower case ​

Min lower case is the password complexity setting in Autologyx Security Rules that defines the minimum number of lowercase letters required in a user password. It is used in the password complexity object returned by and submitted to the /api/security/ endpoint, alongside related controls such as min upper case, min letters, min numbers, min symbols, min length, and max repeating chars. Configuration admins, Super Admins, and integrators use this integer value when viewing or updating platform security policy, with supported values validated from 0 to 128. This setting matters because it helps enforce password composition standards across the platform, supporting stronger account security and alignment with organisational authentication and compliance requirements.

min numbers ​

Min numbers is the password complexity setting in Autologyx Security Rules that defines the minimum number of numeric characters a password must contain. It is part of the password complexity object returned by GET /api/security/ and updated through PATCH /api/security/, where it is represented as an integer with a valid range of 0 to 128. This setting is used alongside related controls such as min length, min letters, min lower case, min upper case, min symbols, and max repeating chars to enforce password policy for platform accounts. It matters to administrators and integrators because it directly affects how password-based authentication is configured, helping standardise credential requirements across the environment and align account security settings with organisational security policies.

min symbols ​

Min symbols is the password complexity setting in Autologyx Security Rules that defines the minimum number of symbol characters a password must contain. It is used in the password complexity object returned by and submitted to the /api/security/ endpoint, alongside related controls such as min length, min numbers, min letters, and min upper and lower case, and it accepts integer values from 0 to 128. This setting matters when configuring platform authentication and password policy because it directly controls how strict password composition requirements are for applicable account types, helping administrators and integrators align Autologyx security configuration with organisational password standards and compliance requirements.

min upper case ​

Min upper case is the password complexity setting in Autologyx Security Rules that defines the minimum number of uppercase letters required in a user password. It is used in the password complexity object returned by and submitted to the /api/security/ endpoint, alongside related controls such as min length, min letters, min lower case, min numbers, min symbols, and max repeating chars. Configuration admins, Super Admins, and integrators use this integer value when reviewing or updating platform security settings, with supported validation values from 0 to 128. This setting matters because it enforces organisational password standards, helps align authentication controls with security and compliance requirements, and directly affects whether passwords meet the platform’s configured complexity policy.

modifiable multiplicity ​

In Autologyx Object Models, modifiable multiplicity is a Boolean property on a parent-child relation that determines whether the relation’s multiplicity can be changed in configuration. It is used when defining relationships between object classes in the relational model, alongside settings such as removable relation, children limit, and relation lookup behaviour. This property is set to False for all root classes and whenever the model already allows a single parent record to be related to multiple child records of the corresponding class, preventing further multiplicity changes that would conflict with the established relationship structure. For configuration admins, developers, and super admins, modifiable multiplicity matters because it controls whether relation cardinality remains editable as object models evolve, helping preserve consistent record relationships and avoid invalid model changes.

monitoring update ​

A monitoring update is a WebSocket event in the Autologyx file-processing workflow that the backend sends after an uploaded file has been uploaded, scanned, and unpacked to report the current monitoring state of that file. It is used on the files WebSocket resource alongside progress updates and upload-related events, and its payload includes a type plus a message object containing at least an attempt number and an ISO 8601 timestamp, with additional fields indicating success, error, or intermediate monitoring states. Monitoring updates matter to developers and integrators because they provide the authoritative stream of backend processing status needed to track file handling after upload completion, drive client-side status displays, coordinate downstream logic, and respond correctly to processing outcomes.

most recently modified Loop actor ​

In Autologyx, the most recently modified Loop actor is the Loop actor whose configuration was changed last, and it is the Loop context the Sequencer uses during testing when an actor, such as an API Call, is connected to multiple Loop actors. In this situation, the platform evaluates loop-scoped merge fields against that last modified Loop and ignores the other Loop connections for test-time evaluation. This matters because loop-dependent values, including the current loop item and its nested properties, are resolved from a single loop execution context, so understanding which Loop is selected is essential for configuring and troubleshooting downstream actors and ensuring test results reflect the intended Loop source.

multipart presigned URLs ​

Multipart presigned URLs are the set of time-limited S3 upload URLs that Autologyx returns when a file must be uploaded as a multipart upload rather than a single request. They are used by client applications and integrations during file transfer workflows, especially for ZIP uploads, and are delivered in the presigned URL response alongside the S3 key, S3 upload ID, chunk size, total parts, and a part URLs array. Each URL is used to upload one numbered part directly to S3, after which the client must send the uploaded part descriptors, including part number and ETag, back to Autologyx to complete the multipart upload. This matters because multipart presigned URLs enable reliable handling of large files, define exactly how many parts must be uploaded, and provide the information required for Autologyx to finalize the upload and continue downstream processing such as file extraction.

multiple Loop connections ​

Multiple Loop connections describes a Sequencer configuration in which a single downstream actor, such as an API Call actor, is connected to more than one Loop actor. In Autologyx, this matters wherever loop-scoped merge fields such as the current loop item are used, because those values are resolved from a Loop actor’s execution context. When multiple Loop actors feed the same downstream actor, testing mode evaluates merge fields using the most recently modified Loop actor, and ignores the other Loop connections for that test evaluation. This behaviour is important for configuration admins and integrators because it directly affects how merge fields are previewed, tested, and validated in actors placed downstream of loops, and it helps prevent incorrect assumptions when designing workflows that combine several Loop sources.

multiplicity ​

Multiplicity, also called relation multiplicity, is the object model setting that defines how many child records of one object class can be related to a parent record of another object class in Autologyx. It is configured on each relation in an Object Model definition and is supplied as the required **multiplicity** field for an object class/parent relationship, with supported values zero or one and zero or more. This setting is used when creating and retrieving object model relations through the Object Models API, alongside related controls such as modifiable **multiplicity** and removable relation, and it works within platform constraints such as children limits and relation depth limits. Multiplicity matters because it determines the allowed cardinality of related object records, directly shaping how data structures, relation lookups, integrations, and record-management behaviour are designed and enforced across the platform.

nested merge fields ​

Nested merge fields are merge field expressions contained inside string content that are resolved and rendered at runtime by the Autologyx merge field rendering process, typically through custom filters in document templates and other merge-enabled outputs. In Autologyx, this is used when a field value or template fragment itself includes merge field syntax and needs to be converted into final values during rendering rather than treated as plain text. This matters to configuration admins and developers because it enables dynamic template composition and reusable content patterns while enforcing important platform rules: processing is limited to a single level to prevent recursion, it applies only to string field types, and invalid or unsupported nested content follows the platform’s standard rendering and filter error-handling behavior.

nested properties ​

Nested properties are child fields within the current loop item object and are supported when using Sequencer merge fields downstream of a Loop actor in the Autologyx platform. In practice, this lets configuration admins and developers reference structured data from the current loop iteration—such as values inside an array item returned from an Array, API Call, or Variable source, or fields within a document representation from a Document Picker source—rather than being limited to the top-level item. Nested properties are used in actors that execute on the Loop item processed path, including API Call actors, where they render against the active item in the loop’s execution context. This matters because it enables precise access to deeply structured data during workflow execution and testing, ensuring loop-driven configurations can map, transform, and send the correct values for each iteration.

nested schema ​

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

In the Autologyx platform, a nested schema is an Autologyx API schema structure that groups multiple related fields into a single nested JSON object within endpoint metadata, particularly in OPTIONS responses that describe create and detail views. It is used wherever an attribute is defined not as one standalone field but as a grouped structure, and it contains at minimum a group alias and a list of child fields or further nested schemas; it can also include conditional schema-by-value rules and validators that apply to the group as a whole. Nested schemas matter to developers, integrators, and configuration admins because they define the exact JSON shape required for submitting and reading structured data, including how grouped values are organised, validated, and conditionally presented in API-driven configurations and integrations.

Next actions ​

Next actions is an array field returned by Autologyx API resources to describe the operations currently available for that specific record in its present state and permission context. It is used in responses for resources such as Tasks and Users, where it exposes the allowed follow-up actions a client or integration can present or trigger, for example task actions driven by ownership and assignment rules such as view, save, complete, take ownership, give up ownership, or change ownership. This matters because next actions provides a runtime contract between the platform and consuming applications: developers can use it to build interfaces and automation that only offer valid actions for the current user, current assignees, and related user groups, keeping behaviour aligned with Autologyx API standards and the record’s live permissions and workflow state.

nominated system administrator ​

In Autologyx, a nominated system administrator is the named administrative contact whose details can be stored in Company details at the tenant level, alongside the option to use a generic contact. This information is maintained through the single-instance Company details configuration and is available to users with the relevant Company details permissions, including through the administration API endpoints for retrieving and updating company details. The nominated system administrator matters because these contact details provide a consistent organisation-level point of contact that can be inserted into standard message templates and other global-scope communications by using merge fields, helping ensure system-generated content includes the correct administrative contact information.

non modifiable properties ​

Non modifiable properties are API resource fields in the Autologyx platform that clients cannot set or override in a request body. They are used within the Autologyx API schema, including endpoint payloads and nested schema structures, wherever a field is controlled by the platform rather than by the caller. If a value for a non modifiable property is included in a request body, Autologyx silently ignores it unless the endpoint documentation explicitly states different behaviour. This matters to developers and integrators because it determines which fields can be populated during create and update operations, prevents ineffective payload design, and helps distinguish client-editable data from platform-managed fields such as protected or system-controlled values.

notice type ​

In Autologyx, notice type is the required enum that defines the category of reminder or notice configured within a task template, used in the reminders section of the Task Templates API alongside time unit and time value to specify what kind of notice is sent and when it is triggered. It is used by configuration administrators and developers when creating, updating, or integrating task template definitions, particularly where task timing behaviour also includes complete by, expiry, renewals, and plugin config. Notice type matters because it controls how task-related notifications are classified within the template configuration, ensuring reminder schedules are set correctly and that downstream task execution and integration behaviour align with the intended notification model.

num of members ​

In Autologyx, num of members is an integer field on a User Group that records how many users are members of that group. It is used in the User Groups resource returned by the API and is available for filtering, sorting, and display in administration and integration scenarios where group records are listed or queried. This field matters because it gives administrators and integrators a direct measure of group size for reporting, validation, automation logic, and operational review, and it complements related group metadata such as num of owners and members when configuring access structures or building integrations that consume User Group data.

num of owners ​

In Autologyx, num of owners (number of owners) is an integer field on the User Groups resource that records how many users are designated as owners of a group. It is used in the User Groups API response schema and is available as a sortable and filterable field in accordance with ALX API standards, alongside related group metadata such as num of members and meta.permissions. This field matters when integrating with or configuring the platform because it provides a quick administrative indicator of group governance, supports API queries and ordered listings of groups, and helps administrators and developers identify groups by ownership structure when building automations, reports, and management views.

num of task templates ​

Num of task templates is the integer response field on a Task Group Template that shows how many task templates are contained within that group template in the Autologyx platform. It is used in Task Group Template API responses and as a supported ordering field on the tasks endpoint, where developers and integrators can sort returned results by this value. This field matters because it provides a quick measure of the size and composition of a task group template, helping users compare templates, validate configuration structure, and build integrations or reporting that depend on the number of task templates associated with each group template.

num of tasks created ​

In Autologyx, num of tasks created is an integer field on a Task Template that records the total number of task instances generated from that template. It is returned in Task Template responses alongside related metadata such as last task created, task creation, and template configuration, and is relevant in both API integrations and administrative views that expose template details. This field matters because it helps configuration administrators, developers, and compliance or analytics users understand how heavily a template is being used, monitor operational activity for automatically or manually created tasks, and validate that task generation behaviour aligns with the intended template configuration.

Object based access ​

Object based access is the Autologyx merge field access method that returns complete related objects, such as user or group records, instead of only their identifiers. It is used in document templates and other merge-field driven outputs when working with object record data, using object-aware syntax to access the full set of properties on those returned objects. This matters because it enables enhanced functionality over ID based access, allowing configuration admins and developers to reference richer data directly from the object model, simplify template design, and build outputs that rely on detailed attributes from associated users, groups, and other object classes.

Object Class Assignees ​

Object Class Assignees are the users or user groups explicitly attached to an Object Class Permission Set to grant that permission set to specific principals on a given object class. In Autologyx, they are managed through the Object Class Permission Set assignee endpoints, including the general assignees endpoint and the user- and user-group-specific variants, using an Object Class ID and Permission Set ID to create or retrieve assignments. This concept matters when configuring access control because it defines exactly who receives a permission set for an object class, is subject to platform validation and permission checks, cannot be used with the everyone or members permission set types, and enforces assignment limits per object class and permission set, with limit breaches returning ERR LIMIT EXCEEDED.

object class create form ​

In Autologyx, the object class create form is a form surface used when users create a new record for an object class, and in Custom Components it is represented as an available use flag that determines whether a custom component can be used on that create experience. This setting is configured through the custom components API alongside other placement options such as object class summary form, object class standalone form, task template form, and landing page. It matters to configuration admins and developers because it controls where a component can be assigned and rendered, helping ensure the right UI elements are available at object creation time and enabling administrators to track component dependencies through usage endpoints that list object class create forms using a given custom component.

Object Class Document File ​

An Object Class Document File is a document file stored and managed as part of an object class document template workflow in Autologyx. It is used when uploading, validating, or reusing a template file for a specific object class, where API operations accept either a temporary file token for a newly uploaded file or the ID of an existing Object Class Document File. This file provides the source content for document template processing, including Jinja syntax checks and merge tag validation against related classes and class fields. It matters to developers, integrators, and configuration administrators because it is the file-level asset that underpins object class document generation, template verification, and controlled reuse of template content across document template endpoints.

object class document templates ​

Object class document templates is the platform limit that defines how many document templates can be configured for a single object class in Autologyx. It is used in platform limits and capacity planning when Configuration Admins or Super Admins design and govern object classes, alongside related settings such as object class fields and object class permission sets. This limit matters because it sets the maximum number of templates available for generating or managing documents within that object class, directly affecting how document-heavy processes are structured and whether a configuration stays within supported platform boundaries.

Object Class Field options ​

Object Class Field options are the configured allowed values or selectable entities for a field on an object class in Autologyx. They are used when defining and validating Object Records, particularly for fields that accept users or groups, where submitted IDs must match existing platform users or user groups and must also be included in the field’s configured options. This matters to Configuration Admins and Super Admins because Object Class Field options directly control what data can be entered or supplied through the UI or Object Records API, helping enforce the intended scope of selectable users, groups, and other field values within a given object class.

object class fields ​

Object class fields are the individual data fields defined within an object class in Autologyx, such as text, number, enum, user, or document fields, and each field is created, validated, and managed through the object class field endpoints under /api/object classes/{objectClassId}/fields/. They are used throughout platform configuration and integrations, including UI configuration, object record uploads, and integration settings that require a specific field reference, where the field must exist, belong to the selected object class, and in some cases be a particular type such as document. Object class fields matter because they define the structure, validation rules, identifiers, uniqueness, ordering, and allowed values for records in an object class, which directly controls how data is captured, uploaded, displayed, and exchanged with connected systems; they are also subject to platform limits on the number of fields per object class.

Object Class Forms ​

Object Class Forms are the form definitions used in Autologyx to view, create, and update Object Records for a specific object class. They are used in object class configuration, can be rendered inside the Autologyx frontend application or exposed as standalone pages, and are managed through the Object Class Forms API at /api/object class forms/. Each form is associated with one object class and includes form configuration such as form type, custom components, labels, and permissions, making it a core mechanism for controlling how users interact with object data. Object Class Forms matter because they determine the structure, behaviour, and access rules of record-facing forms, enabling configuration admins, developers, and super admins to deliver consistent data capture and record management experiences for end-users.

Object Class ID ​

Object Class ID is the integer identifier for an Object Class in the Autologyx platform. It is used primarily in API and event interfaces to scope operations and data to a specific object class, including object-class permission set assignment endpoints where it is passed as a URL parameter alongside Permission Set ID, and WebSocket event payloads and filters where it identifies the related object class for object record and task events. This identifier matters because it ensures that assignee management, permission configuration, and event processing target the correct class definition, allowing developers, configuration admins, and Super Admins to integrate, automate, and administer object-class-specific behaviour accurately.

object class ID for Task Templates type ​

In Autologyx, the object class ID for the Task Templates type is the integer identifier that specifies the object class associated with a Task Template when Task Template records are returned or consumed by platform components such as autocomplete widgets and plugin configuration. It is used in Task Template resource payloads alongside the template ID and display text, and is populated only for Task Template entries rather than other result types. This value matters because it lets developers, integrators, and configuration administrators distinguish Task Template objects from other platform objects, apply the correct object-class-specific handling and permissions logic, and configure integrations or UI components that depend on object class metadata.

Object Class level ​

INSUFFICIENT_EVIDENCE

Object Class Owner relations ​

Object Class Owner relations are the ownership links that associate one or more users with an object class in the Autologyx platform. They are managed through the Object Class Owners capability, including the Object Class Owners API endpoint used to create owner relations for a specified class id and owner id, and they determine the owners list recorded against that object class. This matters to developers, configuration admins, and Super Admins because object class ownership is a core part of governing who is designated as responsible for a class, supporting administration, integration, and access-related configuration workflows; working with these relations typically also depends on the relevant user lookup capability such as the users.list permission.

Object Class Owners ​

Object Class Owners are user relationships assigned to a specific object class that give those users owner-level access to manage permissions for that class within the Autologyx platform. They are used in the Object Class Owners API under /api/object classes/{class id}/owners/, where administrators can create and retrieve owner assignments for an object class, subject to platform limits such as a maximum of 100 owners per class and the required permissions to assign users. This matters because Object Class Owners are a control point for object-class security administration: they can manage object class permission sets, are recognized in permission rules such as object class.edit perm set, and affect access to object class and object record permission set configuration, making them important for configuration admins, super admins, and integrators who design or govern access models.

Object Class Ownership ​

Object Class Ownership is the platform relationship that assigns one or more owners to an object class, giving those users class-level authority that is checked by Autologyx permissions when working with resources built from that class. It is configured through the Object Class Owners capability for a specific object class, where owner IDs can be added, listed, or removed, and it is used throughout the platform anywhere permissions depend on ownership of the class rather than ownership of an individual record. This matters because Object Class Ownership can grant access to create object records for the class and, in combination with other ownership and permission rules, can control who can edit or delete related object records and interact with class-related tasks, making it a key configuration for securing administration and operational access at the object-class level.

object class permission set assignees user groups ​

Object class permission set assignees user groups is the platform limit that defines how many user groups can be assigned to a single permission set within an object class in Autologyx. It is used in platform configuration and limits documentation when designing or administering object class security, alongside related limits for user assignees and other object class components. This limit matters to Configuration Admins and Super Admins because it determines how broadly group-based access can be applied through one permission set, which directly affects security model design, maintainability, and whether an object class configuration will fit within supported platform constraints.

object class permission set assignees users ​

Object class permission set assignees users is the platform limit that defines the maximum number of individual user accounts that can be assigned to a single permission set within an object class in Autologyx. It is used in platform limits and configuration contexts alongside related object class permission set limits, where Configuration Admins and Super Admins review and control how access can be granted at the object class level. This limit matters because it sets the scale at which permissions can be assigned directly to users for an object class, helping administrators design manageable access models, stay within configured platform limits, and determine when direct user assignment should be complemented by other assignment approaches such as user groups.

Object Class Permission Set permission ​

INSUFFICIENT_EVIDENCE

object class permission sets ​

Object class permission sets are configurable access-control definitions created at the object class level in Autologyx to specify what actions named groups of users can perform for that class. They are used in the Object Classes Permission Sets configuration and API endpoints under an individual object class, where administrators create, update, and manage permission sets and assign individual users or user groups as assignees, except for built-in permission set types that do not allow assignee changes. They matter because they control class-level access such as visibility and management of object-class-related capabilities, provide a reusable security model that can be applied to multiple users through direct assignment or user groups, and are subject to platform limits, including a maximum number of permission sets per object class and assignee limits that can trigger ERR LIMIT EXCEEDED during configuration.

object class standalone form ​

Object class standalone form is an available use setting for a custom component in Autologyx that identifies the component as usable on an object class standalone form. It is configured as the boolean field **object class standalone form** in the custom components API available use object, appears in component retrieval responses, and is reported in custom component usage data alongside the object classes and standalone form names where the component is used. This matters to developers and configuration admins because it controls whether a custom component can be placed in standalone form experiences for an object class, helps distinguish that placement from object class create forms and summary forms, and supports safe change management by showing where a component is currently in use before it is updated or removed.

object class summary form ​

Object class summary form is an available-use setting for a Custom Component in Autologyx that identifies the component as usable on an object class summary form. It is configured through the custom components API as the boolean field available_use.object_class_summary_form, and it is also reported in custom component usage endpoints, which list the object classes currently using the component in their summary forms. This matters to configuration administrators and developers because it controls where a custom component can be placed in the platform UI, supports governance of component reuse across object classes, and helps assess the impact of updating or deleting a component by showing whether it is used on summary forms.

Object Class usage ​

Object Class usage is the usage data returned by the Autologyx API for an object class, or for a specific object class field, through the /api/object classes/{id}/usage/ and related field usage endpoints. In the platform, it is used by developers, integrators, configuration administrators, and Super Admins to identify where an object class or field is referenced across configuration and process design so they can assess dependency impact before changing, reusing, or removing it. This matters because object classes underpin structured data in Autologyx, and accurate usage information helps teams manage configuration safely, avoid breaking dependent components, and maintain alignment with ALX API standards when automating or governing platform changes.

Object Class view ​

Object Class view is a permission in the Autologyx platform that allows a user to view an Object Class and access its fields where that class is referenced by platform features such as document templates and merge fields. It is used in permission configuration and is specifically required when generating or working with Object Record Documents that use template merge fields from one or more Object Classes, alongside Object Record view permission. This permission matters because users must have Object Class view for every Object Class used in a template in order for template-driven document functionality to work correctly and for class-level data referenced by merge fields to be available in the document generation process.

object class.edit perm set ​

object class.edit perm set is the permission that controls who can manage permission sets for an object class in Autologyx. It is used in the Object Classes Permission Sets and Object Record Permission Sets areas, including the APIs that list permission sets for a specific object class, and it is not manageable through roles; instead, it is granted to the Object Class owner. This permission matters because it governs administrative control over who can assign and maintain access rules tied to an object class and its related object records, making it a key dependency for configuring secure ownership-based access within object classes.

object class.view ​

object class.view is the permission that grants access to view lists of permission sets associated with an object class in Autologyx. It is used in object class permission set and object record permission set contexts, including the endpoints that return permission set lists for a specific object class, and it is manageable through roles as well as through object class or object record permission set ownership paths. This permission matters because it controls whether configuration users such as Configuration Admins and Super Admins can access and review the permission structures that govern an object class and its records, making it a foundational permission for administering object classes, validating access models, and managing related permission dependencies.

object classes ​

Object classes are the primary configuration-level data definitions in Autologyx that describe a business object type and provide the structure, behaviour, and access model for the records created under that type. They are used throughout the platform wherever administrators define object records, object class fields, forms, document templates, owners, permission sets, sequences, UI configuration, and integrations or APIs that reference a Class ID or Object Class ID. Each object class has its own metadata, display configuration, limits, and permissions, and acts as the scope for related configuration such as task templates and task group templates. This matters because configuring an object class correctly determines how records are created and identified, how users interact with them in the UI, what automation and templates can be attached, and which users or user groups can view or manage data at the class level.

Show 18 more pages

Object Classes Document Template ​

An Object Classes Document Template is a document-generation template attached to a specific Object Class in Autologyx and managed through the Object Class document templates API. It defines a named .docx template file, optional description, and an allow on demand generation setting, and it is validated when created to ensure the file is a supported Word document, the Jinja template syntax is correct, and merge tags reference valid related classes and class fields. It is used wherever teams configure document output for records of that Object Class, including listing, downloading, verifying, and generating class-specific documents, with file details exposed through fields such as meta.labels.files and operational feedback available through warning values. This matters because Document Templates control how object data is merged into formal documents, enforce template quality and relationship rules at configuration time, and set clear platform limits and behaviors, such as per-class template caps and on-demand generation availability.

Object Classes owned by user ​

Object Classes owned by user are the subset of Object Class definitions in Autologyx that are owned by the current authenticated user and are exposed through the GET /api/object classes/autocomplete/owned/ endpoint for use in autocomplete widgets. This term is used primarily in API integrations, configuration interfaces, and administrative tooling where users need to search and select only the Object Classes they own, rather than the full catalogue. It matters because it supports user-specific filtering in object class selection, aligns UI behaviour with platform ownership boundaries and permissions, and helps developers and administrators build forms and workflows that present relevant, valid Object Class options in line with Autologyx API standards.

Object Classes Permission Set ​

An Object Classes Permission Set is the permission configuration attached to a specific object class in Autologyx that defines who can access or act on items of that class, either through direct assignees or assigned user groups. It is used in object class administration and API configuration, particularly through the Object Class Permission Set assignee endpoints, where admins add users or user groups to a selected permission set for a given Object Class ID and Permission Set ID. This matters because it is the mechanism that controls object-class-level access in a structured, scalable way, allowing configuration admins and Super Admins to grant permissions to the right people or groups while respecting platform rules such as restrictions on everyone or members permission set types and limits on batch assignment sizes.

object classes resource ​

An object classes resource is the permission resource used in Autologyx Object Class Permission Sets to control what a user can do at the Object Class level for a specific Object Class. It is used when configuration administrators or Super Admins create or update permission sets through the Object Classes Permission Sets API, where the valid actions for this resource are list, edit, view, and delete. This resource matters because it defines access to Object Class-level capabilities separately from object records and tasks, enabling precise delegation of administration and visibility for each Object Class while supporting ownership rules, role-based access, and the platform’s limits and validation for permission set configuration.

Object Models ​

Object Models are the Autologyx configuration that defines the relationship structure between Object Classes, including parent-child links and multiplicity rules, so connected records can be created, navigated, and used consistently across the platform. They are used in relational model configuration and API endpoints for object model definitions, surfaced in Object Class metadata as the list of models a class belongs to, controlled through object model permissions in Roles, and consumed by features such as related records and document template merge fields that rely on those defined relationships. Object Models matter because they determine how business entities are connected, what related data users can access from a record, and how administrators and integrators design scalable data structures that support automation, templates, and user experience.

object name ​

Object name is the optional string field used in the Object Records API to assign a human-readable name to an individual Object Record within an object class. It is supplied in the request body when creating or updating a record and is returned in the API response alongside the record ID, object class, status, and configured fields. In Autologyx, object name matters because it provides a clear label for a record independent of its schema-defined data fields, making records easier to identify, display, and manage in integrations and custom implementations; the value must not exceed 255 characters.

Object Record and Permission Set assignee list ​

The Object Record and Permission Set assignee list is the platform-level list of assignees attached to a specific permission set on a specific Object Record, identifying which user groups have been granted that record-level access configuration. In Autologyx, it is used in the Object Records permission set APIs and related configuration workflows, where administrators and integrators reference an Object Record ID together with a Permission Set ID to retrieve or manage the user group assignees for that record-permission combination. This matters because it is the control point for record-specific access assignment, enabling precise administration of who can receive a defined permission set on an individual object record and supporting secure, scalable automation of access management across the platform.

Object Record Assignee ​

An Object Record Assignee is a user assigned to a specific permission set on a specific Object Record in the Autologyx platform, giving that user the access defined by that permission set for that individual record. This concept is used in Object Record permission management and is managed through the Object Record Permission Set Assignees and Assignees Users API endpoints, which let administrators and integrators list assignees and add one or more users against a record ID and permission set ID. Object Record Assignees matter because they are the record-level mechanism for granting access to individual users, controlling who can interact with a given Object Record under a defined permission model, and they are subject to platform rules such as assignee count limits and the restriction that 1 Time Completion accounts cannot be assigned.

object record assignee added ​

Object record assignee added is an Object Record event published by the Autologyx Catalyst WebSocket Object Record events endpoint when an assignee is added to an existing Object Record. It is used in real-time clients and integrations that subscribe to Object Record change notifications, alongside related events such as object record assignee removed, owner changes, value changes, creation, and deletion. This event matters because it signals an assignment update immediately, allowing user interfaces, workflow integrations, and custom services to keep task ownership and responsibility views in sync without polling, and to trigger any downstream processing that depends on assignee changes for a specific Object Record, Object Record ID, or Object Class ID.

object record assignee removed ​

Object record assignee removed is an Object Record event in Catalyst that is published on the Object Record WebSocket endpoint when an assignee is removed from an existing object record. It is used alongside other real-time Object Record events, including assignee, owner, value, document, creation, and deletion changes, so connected clients and integrations can react immediately without polling. This event matters to developers and integrators because it signals that record assignment state has changed, enabling user interfaces, workflow listeners, and downstream systems to update task routing, permissions-aware views, notifications, and assignment-related automation for the affected Object Record.

Object Record Assignees limit ​

Object Record Assignees limit is the platform-enforced maximum number of users that can be assigned to a single Object Record permission set in one Object Record context in Autologyx. It is used when configuring assignees through the Object Record Permission Set assignees API endpoint for GET and POST operations, where the documented maximum is 100 assignees per Object Record and Permission Set combination. This limit matters to configuration admins, super admins, and developers because it defines the supported scale for access assignment, shapes how bulk assignment requests must be structured, and triggers a 400 Bad Request with error code ERR LIMIT EXCEEDED and the message "Limit of 100 Permission Set Assignees has been exceeded" when the maximum is surpassed.

Object Record create permissions ​

Object Record create permissions are platform permissions granted through a Permission Set that allow a user to create new Object Records in Autologyx. In the Object Records area, these permissions work alongside Object Class ownership requirements to control who can add records for a given object class, making them a key part of securing record creation and managing user access. For configuration admins and Super Admins, this matters because create permissions determine which users, roles, or teams can introduce new business data into the platform, affecting how object-based processes, ownership, and API-driven record creation are governed.

object record created ​

Object record created is a WebSocket event in the Autologyx Catalyst Object Record events stream that is emitted when a new Object Record is created. It is used through the Object Record events endpoint to notify connected clients and integrations in real time, alongside related lifecycle events such as value changes, owner and assignee updates, document generation, and deletion. This event matters to developers and integrators because it provides the trigger point for reacting immediately to new records without polling, enabling responsive user interfaces, downstream automation, and event-driven processing keyed to the newly created record and its associated object class.

object record deleted ​

Object record deleted is an Object Record event published by the Catalyst WebSocket Object Record events endpoint to indicate that a specific Object Record has been deleted from the platform. It is used in real-time clients and event-driven integrations alongside related events such as object record created and object record value changed, and is received through the Object Record events stream documented for GET /ws/events/object records/. This event matters because it allows developers and integrators to immediately remove deleted records from user interfaces, synchronise downstream systems, stop processing against records that no longer exist, and maintain an accurate view of Object Records by reacting to deletion without polling or page refreshes.

object record document field ​

An object record document field, also referred to as a document field, is a file-type field on an Autologyx object record that stores a specific uploaded file as part of that record’s data. It is used when object records need to hold documents directly within the platform and is accessed through file-related API operations, including endpoints for downloading the file from the object record document field. This matters to developers and integrators because document fields determine how files are attached to business records, how those files are retrieved through API calls, and how file permissions are enforced for access to content associated with a given object record.

object record document generated ​

Object record document generated is an Object Record event in Catalyst that is published on the Object Record WebSocket events endpoint when a document is generated for a specific record. It is used by developers and integrators consuming the Object Record real-time event stream, alongside events such as object record created, value changed, ownership changes, assignment changes, and deletion, to detect and respond immediately to document-generation activity without polling. This event matters when building integrations, dashboards, or reactive user interfaces that need to keep document-related state synchronized with Object Records, trigger downstream processing, or update views as soon as generated documents become available for the record.

Object Record Documents ​

Object Record Documents are the documents generated for a specific Object Record in Autologyx by running a document template against that record’s data. They are used in the Object Record experience and through the Object Record Documents API to manually start the document generation process, producing generated documents that are linked to the record. This matters because it allows end-users to create record-specific outputs on demand, while configuration admins and developers control which templates are available, how document fields and merge fields are populated from object record fields and document type fields, and how settings such as availability and file limits are applied within the relevant Object Class view and document configuration.

Object Record edit permissions ​

Object Record edit permissions control whether a user can modify existing Object Records in Autologyx. Used in Object Record operations such as PATCH and bulk update actions, this permission works alongside Object Class Ownership and Object Record Ownership rules to determine whether a specific record can be updated, and only records that satisfy both the operation filter and the user’s edit entitlement are changed. For configuration admins and Super Admins, this matters because it is typically granted through a Permission Set and is a key part of securing object data, controlling who can update record content through the platform and the Object Records API.

object record field ​

An object record field is the slug name of a field defined on an ObjectClass that identifies a Document-type field on a specific Object Record. In Autologyx, it is used in the Object Record Documents API when generating documents, where the **object record field** parameter links the generated document to a document type field on the record rather than generating it without storing that field association. This field must exist on the same ObjectClass as both the object record and the document template, and using it requires object record edit permission in addition to record view access. It matters to configuration admins and developers because it controls how generated documents are targeted and stored against records, ensuring document generation is aligned with the correct schema, permissions model, and document-handling configuration.

Object Record History Events ​

Object Record History Events, also referred to as History Events, are the event entries that capture changes and actions performed against an Object Record in Autologyx. Used through the Object Records History Events API, they provide access to stored event data for a record, including changes such as field values changed, assignees added or removed, owner initialized, and document generated, across relevant object classes. This history is important for developers and integrators exposing record activity, for configuration administrators designing record-centric solutions, and for security, compliance, and analytics teams that need a reliable activity trail to review how Object Records have been updated and managed within the platform.

Object Record ID ​

Object Record ID is the integer identifier for a specific Object Record in Autologyx and is used as a required path or URL parameter when working with record-scoped APIs and events. It identifies the exact record targeted by operations such as managing object record owners, assigning or listing permission set assignees and user group assignees, and consuming object record event payloads from GET /ws/events/object records/, where it is returned as object record id. This ID matters because it is the key that links configuration and integration actions to the correct record, enables precise permission and ownership management, and ensures API requests and event handling are performed against the intended Object Record.

Object Record Merge Fields ​

Object Record Merge Fields are merge fields used in the Autologyx platform to retrieve and format data from a specific record and its related records, including linked users, documents, and custom model instances. They are used when configuring document templates, email templates, and other template-driven content that needs to insert record-specific values at runtime. For configuration admins, developers, and end-users working with generated content, Object Record Merge Fields are important because they enable templates to pull structured data from the correct object context, support relationships between records, and produce accurate, dynamic outputs without manual editing.

object record owner added ​

Object record owner added is an Object Record event published by the Catalyst WebSocket Object Records endpoint when an owner is added to an existing object record. It is used by developers and integrators consuming real-time record event streams, including the object record events feed and related integrations that monitor ownership changes alongside creation, value updates, assignments, document generation, and deletion. This event matters because ownership is part of how record responsibility and access are represented in the platform, so detecting when an owner is added allows connected applications and user interfaces to update record state immediately, trigger downstream processing, and keep external systems aligned with the current ownership of the object record.

Object Record Owner ID ​

Object Record Owner ID is the unique identifier for a specific owner entry within an Object Record Ownership relationship in the Autologyx platform. It is used primarily by developers and integrators in Object Record Owners endpoints as a URL parameter to target, retrieve, or manage an individual ownership record associated with an Object Record, distinct from the Object Record ID itself. This identifier matters because ownership records control how responsibility and access are represented at the record level, and using the correct Object Record Owner ID ensures API operations are performed against the intended owner relationship when configuring integrations or working with object record ownership data.

object record owner initialized ​

In Autologyx, object record owner initialized is an Object Record event emitted on the WebSocket Object Record events endpoint when the owner state for an Object Record is first established, allowing connected clients and integrations to synchronise the record’s ownership information as part of real-time change handling. It is used alongside other Object Record events exposed through GET /ws/events/object records/, including owner added and owner removed, and is relevant when building reactive user interfaces, event-driven integrations, or configuration that depends on ownership data being available from the start of a record’s tracked lifecycle. This event matters because ownership commonly drives visibility, routing, workload distribution, and downstream automation, so recognising the initial owner setup ensures systems present and process Object Records correctly without waiting for subsequent ownership changes.

Object Record Owner relations ​

Object Record Owner relations are the ownership link records created in Autologyx to associate one or more users with a specific Object Record through the Object Record Owners API. Used by developers and configuration admins when integrating or managing object data, these relations are created with the POST /api/object records/{objectRecordId}/owners/ endpoint and connect an Object Record ID to an owner ID as a distinct relation record. They matter because they define who is recorded as an owner of the object record, enabling ownership-driven behaviour, administration, and downstream platform processes that rely on Object Record Ownership data.

object record owner removed ​

Object record owner removed is a Catalyst WebSocket event published on the Object Record events endpoint when an ownership relationship is removed from an Object Record. It is used by developers and integrators consuming GET /ws/events/object records/ to detect real-time changes to record ownership alongside related events such as owner added, owner initialized, assignee changes, value changes, creation, and deletion. This event matters because ownership often drives responsibility, visibility, workflow behavior, and downstream integration logic, so handling it allows client applications and connected services to keep record state, user interfaces, and automation in sync as ownership is updated within the platform.

Object Record Owners ​

Object Record Owners are the user assignments that designate who owns a specific Object Record in Autologyx. They are used in the Object Record Owners API at /api/object records/{record id}/owners/, in Object Record permission handling, and alongside object classes and permission sets to control who can act on or access an individual record. Each Object Record supports a maximum of one owner, and assigning that owner requires the necessary permissions, including visibility of the target user through users.list. This matters to configuration admins, super admins, and integrators because record ownership is a core control point for record-level access and operational responsibility, affecting how permissions are granted, how integrations set owner id values, and how platform limits and validation rules are enforced for individual records.

Object Record Ownership ​

Object Record Ownership is an ownership assignment applied to an individual Object Record in the Autologyx platform, identifying the specific user or users who own that record and granting record-level control independently of broader object class ownership. It is used in the Object Record Owners functionality and related API endpoints for listing, adding, and managing owners for a given record, and it is also enforced in permission checks across Object Records and Tasks, where ownership can authorize actions such as editing or deleting a record. This matters because it provides precise access control at the single-record level, allowing administrators and users to delegate responsibility, secure sensitive records, and ensure that the right people can work with a record even when they do not own the entire object class.

object record permission set assignees user groups ​

Object record permission set assignees user groups is the platform limit that defines how many user groups can be assigned as assignees in object record permission sets in Autologyx. It is used in platform configuration and limits documentation when designing or administering record-level access controls for specific object records, alongside related limits for individual user assignees and object class permission assignments. This limit matters because it sets the maximum scale at which group-based permissions can be applied to records, affecting how configuration admins and Super Admins model access, structure user groups, and plan permission set designs that remain within supported platform capacity.

object record permission set assignees users ​

Object record permission set assignees users is the platform limit that defines how many individual users can be assigned as assignees within an object record permission set in Autologyx. It is used in platform configuration and limits documentation alongside related assignment and ownership limits, and applies when administrators or developers configure record-level access controls for specific object records. This limit matters because it sets the maximum number of named user assignees that can be included in a single object record permission set, which directly affects how access models are designed, how permissions are distributed, and whether broader assignment mechanisms such as user groups or object-class-level permissions are needed.

Object Record Permission Set permission ​

INSUFFICIENT_EVIDENCE

Object Record permission sets ​

Object Record permission sets are Autologyx access-control definitions applied at the individual Object Record level within an Object Class, used to grant and manage record-specific permissions separately from broader object class permission sets and role-based access. They are configured and managed through the Object Records Permission Sets APIs, including endpoints to create, update, list, and assign assignees or users to a permission set for a specific object class or record. These permission sets matter because they let configuration administrators and integrators control who can access or work with particular records, support direct assignment of users, can depend on User Groups that are tracked as in use by object record permission sets, and form part of the platform’s fine-grained permissions model exposed through permission resources such as meta.permissions.

Object Record Uploads ​

Object Record Uploads is the Autologyx API capability used to create and manage upload instances for importing object records into the platform in bulk. It is used by developers and configuration administrators through the Object Records Uploads API, including the POST /api/object records/uploads endpoint, to submit data that maps to object classes, object class fields, document types, and document field names in line with ALX API standards. This capability matters because it provides a structured ingestion path for creating object records at scale, exposes operational outcomes such as completed upload files, failed count, failed percent, and error reason, and supports controlled access through metadata such as meta.permissions, making it a key integration mechanism for loading and validating business data in Autologyx.

object record value changed ​

Object record value changed is an Object Record event exposed by the Catalyst WebSocket Object Records endpoint that is emitted when the value of an existing object record is updated. It is used by developers and integrators consuming real-time Object Record events, alongside related events such as record creation, deletion, ownership changes, assignment changes, and document generation, to keep client applications, dashboards, and integrations synchronized without polling. This event matters because it provides immediate notification that record data has changed, enabling responsive user interfaces, downstream processing, and event-driven automation that depends on current Object Record values.

Object Record view ​

Object Record view is the permission that allows a user to access and view an individual Object Record in Autologyx. It is used anywhere the platform needs record-level read access, including object record document operations such as listing document templates available for a record, viewing generated document details, and participating in document generation and cancellation workflows. This permission is applied alongside other permissions where needed, for example Object Record edit when writing a generated document back to a document-type field, and Object Class view for object classes referenced by template merge fields. It matters because it is a core access control setting for record visibility: without Object Record view, users and integrations cannot open the record or perform related document actions on that record.

Object Records ​

Object Records are the individual data entries created from an Object Class in Autologyx and represent the specific business items that users and integrations work with throughout the platform. They are created, viewed, and updated through Object Class Forms, identified by an Object Record ID in API endpoints and integrations, and used as the context for related capabilities such as tasks, document generation from templates, merge fields, history events, and record-level permission set assignees. Object Records matter because they are the core unit of operational data and access control in Autologyx: each record stores the configured fields for its Object Class, carries ownership and status information, and determines what documents, permissions, and downstream actions can be applied to that specific item.

Show 7 more pages

Object Records API ​

The Object Records API is the Autologyx REST interface used to create Object Records in the platform, exposed through the POST /api/object_records/ endpoint. It is used by developers and integrators to programmatically add records to configured object classes, and by configuration administrators when designing integrations that populate platform data without manual entry. This API matters because it connects external systems and automated processes to Autologyx object data, making correct alignment with object classes, field configuration, ownership settings, and create or edit permissions essential for successful record creation and controlled access within the platform.

Object Records changes ​

Object Records changes are the real-time event updates emitted by the Autologyx platform when Object Records are created or modified, including events such as object record created, object record assignee added, and object record assignee removed. They are used through the WebSocket events endpoint GET /ws/events/object records/, which subscribes clients to a stream of change notifications for up to 1,000 Object Records at 5-second intervals, and they relate closely to object classes, Object Class IDs, record creation, and class fields. This capability matters to developers and integrators because it enables external applications, dashboards, and automations to monitor Object Record activity as it happens, keep interfaces in sync with platform data, and respond immediately to updates generated during record creation and ongoing record management.

Object Records History Events API ​

The Object Records History Events API is the Autologyx endpoint used to retrieve the history of changes recorded against Object Records, exposing event data such as field value updates, assignees added or removed, owner initialization, and document generation. It is used by developers and integrators when connecting external applications to Autologyx, and by configuration administrators who need to understand how record activity can be accessed across object classes. This API matters because it provides a structured way to read the audit trail of Object Records, supporting integrations, reporting, operational visibility, and controls that depend on understanding how a record has changed over time, alongside the platform’s Object Record History Events model and applicable Object Records Permission Sets.

Object Records Owners API ​

The Object Records Owners API is the Autologyx REST endpoint used to create ownership relationships for object records by adding Object Record Owner relations to a specific Object Record ID. Used by developers and integrators, and relevant to configuration administrators and Super Admins managing record access models, this API is exposed as a POST operation on the object records owners route and is part of the platform’s object record management capability. It matters because object record ownership is a core control point for associating users or other owner entities with individual records, enabling downstream access, responsibility, and administration functions that depend on correctly maintained owner links.

object records per object class ​

Object records per object class is a platform limit in Autologyx that defines the maximum number of records that can be stored for a single object class. It is used in the Limits configuration and reference documentation as part of the platform’s count and limit controls, alongside other object-class-related limits. This limit matters to configuration admins, super admins, and developers because it governs the scale of data that each object class can hold, affecting solution design, data modelling, integrations, and long-term capacity planning when configuring or extending the platform.

Object Records Permission Sets ​

Object Records Permission Sets are configuration objects that define the access and allowed actions for Object Records within a specific Object Class in Autologyx. They are used by configuration and super administrators when creating, listing, and updating record-level permission sets through the Object Class and Object Record permission set APIs, and when assigning individual users or user groups as assignees to a specific permission set on an Object Record. This matters because permission sets provide the mechanism for controlling who can access or work with Object Records, support record-level ownership and sharing models, and enable administrators to apply consistent, class-specific security rules while managing assignees and available actions across object classes.

object records resource ​

In Autologyx, the object records resource is the permission-controlled resource that governs access to the individual records created from an object class. It is used in Object Class Permission Sets, where administrators assign the valid actions for object records—edit, view, and delete—to control what users can do with those records at the object-class level. This matters because object records permissions determine operational access to business data held in object classes, enabling configuration and super administrators to enforce the correct level of visibility and change control for each type of record in the platform.

Object Records Uploads API ​

The Object Records Uploads API is the Autologyx API endpoint used to create an Object Record Upload instance, providing a programmatic way for developers and integrators to submit upload jobs that create object records in bulk. It is used through the POST /api/object records/uploads/ operation and sits alongside object record configuration such as object classes, object class fields, document field name, and document type, as well as standard ALX API metadata including permissions. This API matters because it is the entry point for automated record ingestion workflows, enabling external systems to load structured data and associated documents into Autologyx at scale while tracking upload outcomes such as completed upload files, failed count, failed percent, and error reason for operational monitoring and troubleshooting.

object records.create ​

object records.create is the object-class-level permission in Autologyx that authorizes a user or integration to create Object Records for a specific Object Class. It is used when calling features and APIs that add new records, including Object Record Uploads, where the requesting user must hold object records.create for the target Object Class before an upload can be created against a document field in that class. This permission matters because it controls who can add data to each object model, supports secure integration design, and must be configured alongside related class and field settings so uploads and other record-creation processes succeed.

object records.edit permission ​

The object records.edit permission allows a user to update an Object Record in Autologyx and is specifically required in the Object Record Documents workflow when a generated document is written back to a document-type field on that record. It is used alongside record viewing and document access checks during document generation requests, where the platform validates that the target Object Record field exists, belongs to the same ObjectClass as the selected Document Template, is of type Document, and can be edited by the caller when that field is provided. This permission matters to Configuration Admins and Super Admins because it controls whether generated documents can be attached or saved to record fields as part of automated document generation, and missing it causes the request to fail even when the user can view the record or template.

object records.view permission ​

The object records.view permission allows a user to open and read a specific Object Record in Autologyx. It is enforced anywhere the platform needs access to an individual record, including Object Record Documents and the document generation process, where the selected record must be viewable before a generated document can be created or returned. This permission works alongside related access controls such as object records.edit when a document is written back to a document-type field, and it complements broader configuration permissions such as Object Class view. For configuration and super administrators, this permission matters because it directly controls whether users and integrations can access record-level content needed for document operations, and missing it causes record selection and document requests to fail with permission errors.

Object relation record ​

An object relation record is the individual relationship entry used by the Object Record Owners feature to link an object record to an owner in Autologyx. In practice, it is the record managed through the Object Records Owners API, where it is listed, filtered, sorted, and deleted as a distinct resource with fields such as id, owner id, name, created at, and created by. This matters to developers and integrators because it is the API-level representation of ownership assignments for object records, enabling integrations and platform configurations to identify specific owner relationships, manage them independently, and remove a single ownership link without changing the underlying object record itself.

object relations ​

In the Autologyx platform, object relations are the hierarchical links between related objects that define parent-child structures within data and configuration models. They are used where the platform builds, traverses, or returns related object hierarchies, and are governed by platform limits such as the maximum number of child objects, the maximum relation depth, and the maximum number of top-level parent objects. Object relations matter to configuration admins, super admins, and developers because these limits directly affect how complex object structures can be designed, queried, and processed, helping control performance, scale, and the shape of data returned or managed across the platform.

ObjectClass ​

ObjectClass is the Autologyx platform entity that defines the schema and type of a record, document-related data, or integration context, and is used to link compatible resources across APIs, templates, and configuration objects. It is used when working with object records and document templates, where the record and template must share the same ObjectClass for document generation, and in integration configuration, where an integration can be bound to a specific object class and related object class fields. ObjectClass matters because it controls structural compatibility, available fields, and access to class-scoped resources, ensuring that document templates, merge fields, records, and integrations operate against the correct business object definition and that users configuring the platform select valid combinations of records, fields, and connected services.

ObjectClassField ​

ObjectClassField is the platform record that defines a field on an object class in Autologyx, identified by an ObjectClassField id and used anywhere the system needs to reference, validate, secure, or report on a specific object field. It appears directly in API payload validation for integrations, where the object class field value must be a valid primary key, and it is exposed in user group usage reporting, which returns ObjectClassField ids, names, and their parent object class details. ObjectClassField matters because it connects object model configuration to runtime behaviour: integrations and related configuration depend on correct field references, and user groups can be linked to object class fields, which affects permissions, administration, and whether a group can be deleted while still in use.

ObjectRecordContext ​

ObjectRecordContext is the Autologyx context type that provides core access to the data of the current record being processed, making record values available for merge fields and other context-driven configuration. It is used in both Sequencer Actor and Document Generation scopes, where it sits alongside related record-level contexts such as TaskContext, UserContext, UserFieldContext, UserFieldMetaContext, UsersGroupContext, and DocumentContext. For configuration admins and developers, ObjectRecordContext matters because it is the primary mechanism for referencing the active business record consistently across workflow execution and document generation, enabling templates, automations, and integrations to read record-specific data in the correct scope.

Okta tenant (organization) domain ​

The Okta tenant (organization) domain is the Okta-specific value entered in the SSO configuration’s tenant id field to identify the customer’s Okta organization in Autologyx, typically as the full Okta domain such as acme.okta.com. It is used when configuring an Okta identity provider alongside other SSO settings such as client ID, enabled status, auto-create user behavior, roles, redirect URI, and logout URL. This value matters because it tells Autologyx which Okta organization to use for authentication, ensuring users are directed to the correct sign-in environment and that the SSO configuration operates against the intended Okta tenant.

OPTIONS /api/administration/company details/ ​

**OPTIONS /api/administration/company details/** is the API method on the single-instance Company details endpoint that exposes the permission requirements for working with organisation-level company details in Autologyx administration. It is used by developers, integrators, and administrators to inspect what access is required before calling related operations such as GET /api/administration/company details/ or PATCH /api/administration/company details/, and it is closely tied to meta.permissions and company details permission configuration. This matters because Company details controls core administrative information for the tenant, so checking the OPTIONS response helps confirm whether a user or integration has the required administrative access and supports correct UI behaviour, access control handling, and safe configuration of this platform-wide record.

ordering ​

Ordering, also referred to as sorting, is the Autologyx API convention for controlling the sequence of results returned by collection and autocomplete endpoints and for indicating which fields in a resource’s list-view schema can be used to sort those results. It is defined in the platform’s API standards alongside filtering rules, exposed through field metadata that identifies the alias used in sorting queries and whether sorting is allowed, and enforced through consistent validation that rejects unsupported ordering parameters with a 400 Bad Request error. Ordering matters to developers and integrators because it provides a predictable, reusable way to request stable result sets across REST resources, align client behaviour with list-view and schema definitions, and build integrations that follow Autologyx’s standard query patterns.

owner id ​

Owner id, also shown as Object Owner id, is the integer identifier used in Autologyx ownership APIs to specify a particular owner when working with Object Class Owners and Object Record Owners. It is used as a URL parameter in object class ownership endpoints, where it identifies the owner relation to retrieve or delete for a given class, and it also appears in object record owner payloads and filtering parameters to identify the owning user associated with a record. This field matters to developers, integrators, and configuration admins because it is the key value used to create, query, and remove ownership assignments, validate requests, and automate ownership management across object classes and object records.

owner initialized ​

Owner initialized is an event type recorded in Autologyx event and object record history when the initial owner set for an object record is established. It is used in Object Records History Events and the Event History API alongside related activity such as record created, owners added, owners removed, assignees added, and status initialized, and each event entry includes metadata such as the event datetime and source type. This event matters to developers, configuration admins, and compliance or analytics users because it marks the baseline ownership state of a record, helping integrations, audit reporting, and operational analysis distinguish the original ownership assignment from later ownership changes.

owners ​

owners added ​

In Autologyx, owners added is an object record history event type that records when one or more owners are added to an existing record after its initial ownership has been set. It is used in the Object Records History Events model and is stored and retrieved through the Event History API alongside other record lifecycle and access-related events, with associated metadata such as event id, event datetime, and source type (user, sequence, or system). This event matters to developers, configuration administrators, and compliance or analytics users because it provides a clear audit trail of ownership changes, supports reporting on record access and responsibility, and helps distinguish later ownership updates from the initial assignment captured by owner initialized.

owners list ​

In Autologyx, the owners list is the required request body field named list used in the Object Class Owners API to submit one or more owner IDs for a specific object class. It is used when configuring object class ownership through the /api/object_classes/{class id}/owners/ endpoint, where developers and integrators provide the set of users to assign as owners of that class. This field matters because it is the mechanism that establishes owner relationships for an object class, and it is strictly validated: it must contain valid owner ID values, it cannot be empty, only permitted user types can be assigned, the caller must have the necessary permissions, and both the payload and resulting ownership are limited to 100 owners per object class.

owners removed ​

Owners removed is an event type recorded in Autologyx history when one or more owners are removed from an object record. It is used in Object Records History Events and the Event History API alongside related event types such as owner initialized and owners added, and each event is stored with core metadata including event id, event datetime, and source type so consumers can identify when the change happened and whether it originated from a user, a sequence, or the system. This event matters to developers, configuration administrators, and compliance or analytics teams because it provides an auditable record of ownership changes on a record, supporting integrations, operational monitoring, reporting, and governance over who is responsible for a record at any point in its lifecycle.

owners type ​

Owners type is an Autologyx API field type used in resource schemas to represent ownership information for resources managed by owners. It is used in the platform’s structured schema definitions alongside other complex types such as user, user group, and permissions, and appears in API standards, schema design, and filtering contexts where fields are explicitly typed rather than treated as unstructured JSON. The owners value is a complex object that includes ownership metadata such as the total number of owners and the first assigned owner, determined by the date and time that owner was added. This matters to developers and configuration admins because it defines the expected structure, behaviour, and supported filtering semantics for ownership fields when integrating with the Autologyx API, designing schema-aware clients, or configuring features that depend on resource ownership.

Paragraph replacement syntax ​

Paragraph replacement syntax is a DOCX merge-field syntax variant in the Autologyx platform, used in document templates when rendering merged document content so that the entire paragraph containing the field is replaced rather than inserting content inline. It is available within merge field processing and custom filter scenarios, alongside the standard merge syntax, and follows the docxtpl paragraph-replacement behavior. This matters to configuration admins and developers because it determines how embedded or merged content is laid out in generated documents, ensuring paragraph-level replacement is used where full-block document content must be inserted cleanly without preserving the original template paragraph structure.

parameter options ​

Parameter options are the list-valued configuration field on a custom component parameter that defines the allowed selectable values for that parameter in Autologyx. They are used in custom component definitions managed through the Custom Components Repository and exposed through the custom components API alongside other parameter metadata such as name, description, type, and limit. In practice, parameter options are validated as a list, and invalid formats are rejected by the platform, which makes this field important when developers and configuration administrators are designing components that present controlled choices rather than free-text input. Defining parameter options correctly ensures custom components are validated consistently, configured with the intended set of values, and easier for users and administrators to use safely in the platform.

parameter type ​

In Autologyx, parameter type is the string field in a custom component parameter definition that specifies the data type expected for that parameter. It is used in the Custom Components API and related custom component configuration payloads alongside fields such as parameter name, parameter description, parameter limit, and parameter options. Parameter type matters because it defines how a parameter is interpreted, validated, and presented when a custom component is configured or invoked, helping developers and configuration administrators supply values in the correct format and build components that behave consistently across the platform.

parameters ​

Parameters, also shown as component parameters, are the object-valued configuration returned as part of a Custom Component definition in Autologyx and are used to describe the component’s configurable inputs and option structures. They are surfaced through the Custom Components API alongside fields such as custom component id, status, index url, and meta.permissions, and are validated strictly by the platform when components are created, updated, or retrieved. In practice, parameters matter to developers, integrators, and configuration administrators because they define how a custom component is configured for use in supported contexts such as forms and landing pages, and invalid parameter structures or nested parameter values cause explicit API validation errors that prevent the component from being accepted or used correctly.

Password Complexity ​

Password Complexity is the global Autologyx security rule set that defines the minimum requirements for user passwords across the platform, including min length, min letters, min lower case, min upper case, min numbers, min symbols, and max repeating chars. It is configured and retrieved through Security Rules at /api/security/ as the password complexity object, alongside related settings such as password prevent reuse, password rotation interval, activation link valid period, and authentication method controls for account types such as internal, external, full, and super admin. This setting matters because it determines the password standard enforced wherever password-based authentication is used in Autologyx, giving configuration administrators and security teams direct control over credential strength, policy consistency, and compliance with organisational security requirements.

password complexity requirements ​

Password complexity requirements are the password validation rules enforced by the Autologyx platform when a user password is created or changed through user management operations, including the Users API. They are used in account administration workflows for platform users such as configuration administrators and other account types, where an invalid password is rejected with a 400 Bad Request response and a password-specific validation message, for example when the password contains more repeated characters than allowed. These requirements matter because they define the accepted password standard for the platform, affect user provisioning and password update integrations, and must be accounted for by administrators and developers so that account creation, password resets, and user maintenance processes succeed without validation errors and align with organisational security controls.

password login only ​

Password login only is an account-level authentication restriction in the Autologyx platform that prevents a user from signing in through configured Single Sign On (SSO) providers and requires them to authenticate with their username and password instead. It is encountered in the platform’s authentication and SSO configuration context, including when SSO is enabled for services such as Azure application SSO or Okta, and is enforced at login with a 403 response if an SSO attempt is made for a restricted account. This setting matters because it determines which authentication path a user is permitted to use, allowing configuration admins and Super Admins to control access methods for specific users, preserve local login access where needed, and avoid login failures caused by mismatches between user account policy and the organisation’s SSO setup.

password prevent reuse ​

Password prevent reuse is an Autologyx password policy setting that blocks users from setting a new password that matches one of their previously used passwords. It is used in the platform’s user account validation rules alongside other password controls such as password rotation interval, minimum length, character requirements, and maximum repeating characters, particularly for configurable account types and admin-managed user accounts. This setting matters because it strengthens account security by ensuring password changes result in genuinely new credentials, supporting security and compliance requirements and reducing the risk of users cycling back to familiar passwords.

Password rotation interval ​

Password rotation interval is the Security Rules setting in Autologyx that defines, in days, how long a password can be used before the platform forces the user to change it. It is configured in the systemconf section of the security configuration, exposed through GET and PATCH /api/security/, and enforced when password-based accounts are created or updated under the platform’s password validation rules. This setting is used alongside password complexity, password reuse prevention, activation link valid period, and authentication method controls, and it matters because it helps configuration and security administrators enforce credential lifecycle policy, align user account management with organisational security standards, and control how often password-authenticated users must refresh their credentials.

PATCH /api/administration/company details/ ​

**PATCH /api/administration/company details/** is the Autologyx Administration API endpoint used to update the current tenant’s Company details record. It is a single-instance endpoint, so it operates on the platform’s one configured company details resource rather than on a list of records, and is typically used by developers, configuration administrators, and Super Admins when integrating or maintaining organisation-level settings. This endpoint sits alongside the corresponding GET and OPTIONS operations for reading the current configuration and inspecting supported behaviour, and its use is governed by Company details permissions, including permission information exposed through meta.permissions. It matters because Company details provide core organisational information used across the platform, and this endpoint is the supported mechanism for programmatically keeping that administrative configuration accurate and up to date.

permission actions ​

Permission actions are the valid operation values assigned to each resource within an Object Class Permission Set in Autologyx, defining exactly what a user can do at Object Class level. They are configured by Configuration admins and Super Admins when creating or updating permission sets for resources such as object classes, object records, and tasks, using action lists like list, edit, view, delete, create, complete, and assign according to the resource type. In this context, permission actions are used in the permissions structure of the Object Classes Permission Sets API and configuration, where only supported actions are accepted for each resource and unsupported values are rejected. They matter because they control functional access to platform objects and task activity, and because changes to the submitted action list can add or remove effective permissions through the platform’s dependency handling.

permission dependencies ​

INSUFFICIENT_EVIDENCE

permission fields ​

In the Autologyx platform, permission fields are API request fields used to submit permissions as a structured mapping between resources and the actions allowed for each resource. They are used in API payloads for endpoints that create or update permission-related settings, particularly where access must be defined for resource types, user groups, owners, or user-based assignments within nested schemas. Permission fields matter because they control how access rules are expressed and validated by the Autologyx API: requests must use valid permission keys, valid resource values, and list-formatted action data, otherwise the platform returns standard 400 Bad Request validation errors. For developers, configuration admins, and Super Admins, understanding permission fields is essential to configuring access correctly, integrating with permission-aware endpoints, and ensuring that platform security settings are applied in the intended structure.

Permission Set ​

A Permission Set in Autologyx is a named permission object used to grant users or user groups access to Object Records and related actions for a specific object class. It is used in Object Records configuration and APIs to control whether assignees can create, edit, delete, or otherwise access records, and it also appears in Object Record history and event data, where the assigned permission set and its assignees are returned as structured objects. Permission Sets matter because they are a core mechanism for implementing role-based access in the platform, determining which records a user can see and what operations they can perform, while allowing configuration admins and integrators to manage access consistently across individual users and groups.

permission set assignees ​

Permission set assignees are the users or user groups explicitly attached to a specific permission set on an Autologyx resource, defining exactly who receives that permission set when access is not inherited through broad system-wide set types. They are managed in configuration and integration workflows through resource-specific assignee endpoints such as object record permission set assignees, object class permission set user group assignees, and user group permission set assignees, typically using a Permission Set ID together with the target object ID. This concept matters because assignees are the mechanism for granting targeted access at runtime and in automation, while also being subject to platform rules such as unsupported assignment for everyone or members permission sets, per-request batch limits, per-resource assignee caps that can return ERR LIMIT EXCEEDED, and permission checks on the users or groups being assigned.

Permission Set Assignees limit ​

Permission Set Assignees limit is the maximum number of user assignees allowed on an Object Record permission set in Autologyx. It is enforced when configuring or integrating with the Object Record permission set assignees/users endpoint used to add or manage users assigned to a permission set, and when the limit is exceeded the platform returns a 400 Bad Request with the error code ERR LIMIT EXCEEDED and the message "Limit of 100 Permission Set Assignees has been exceeded." This limit matters to configuration admins, Super Admins, and developers because it directly affects how access to Object Records is designed and automated, requiring permission set structures and assignment processes to stay within the platform cap of 100 assignees per permission set.

Permission Set ID ​

Permission Set ID is the identifier of a specific permission set within Autologyx and is used as a required URL parameter when working with permission-set assignment endpoints for object classes, object records, and user groups. It is supplied alongside the relevant parent resource ID, such as an Object Class ID, Object Record ID, or Users Group ID, to target the exact permission set whose assignees you want to view, add, or remove through endpoints such as assignees, assignees/users, and assignees/user groups. This ID matters because it determines which permission set configuration is being updated, controls how access is granted to users or groups for a given resource, and is essential for integrations and administrators managing assignment rules, assignee limits, and permission-set-specific access behavior across the platform.

Permission Set Object ​

In the Autologyx platform, a Permission Set Object is the structured event data object that identifies the permission set referenced by an event, containing the permission set’s ID and name. It is used in Event History payloads and related API responses alongside user and event type data, particularly for permission-management events such as assignees added and assignees removed. This object matters because it gives developers, integrators, and security or compliance teams a consistent way to determine exactly which permission set was affected, enabling reliable audit reporting, downstream integrations, and analysis of access changes across the platform.

Permission Set type ​

Permission Set type is the system-defined classification that determines how a permission set behaves in Autologyx, including who it applies to and whether assignees can be configured. It is exposed as the type field on permission set records and is used in User Group Permission Sets and Object Class permission set administration. For user groups, Autologyx automatically creates two special permission set types when a User Group is created, and custom creation produces the custom user group permission set type; related Object Class permission set operations also enforce type-specific rules, such as rejecting assignee configuration for the special everyone and members types. This matters to configuration admins, Super Admins, and developers because the permission set type controls valid API operations, assignment behavior, and the effective access model for users and groups.

permissions ​

Permissions in the Autologyx platform are the structured access rights that control what actions a user can perform on API endpoints and specific resource instances, and they are represented in schemas as a complex object, commonly exposed as permission or permissions fields such as meta.permission or meta.permissions in API responses and request bodies. Permissions are used throughout platform configuration and integration APIs, including roles, object record permission sets, task group templates, and other permission-aware resources, where they define available operations and drive 403 Forbidden and related validation behaviour when access rules are not met. This matters because roles are built as sets of permissions, resource visibility and manageable actions are filtered by them, and developers, configuration admins, and Super Admins must understand the permissions object structure and valid keys when configuring access models, interpreting API metadata, or submitting permission-related payloads in line with Autologyx API standards.

permissions object ​

A permissions object is the structured data field used in Autologyx permission set definitions to hold the enabled permissions for platform resources. It appears in API responses and configuration payloads for Object Class Permission Sets and User Group Permission Sets, where it records which actions are granted for each resource, such as view, edit, delete, create, complete, or assign at the relevant scope. Configuration admins, Super Admins, and integrators use the permissions object when creating, reviewing, and maintaining permission sets because it is the canonical representation of access rules that determine what users, owners, members, or custom groups can do within specific Object Classes and User Groups.

plugin config ​

In Autologyx, plugin config (plugin configuration) is the JSON object that defines the task-type-specific settings for a task template or task instance. It is used in task template requests and responses as a required object, and it is carried into the task configuration on created tasks under configuration.plugin config, where it stores the detailed behaviour and options for the selected task type, such as task-type metadata, field configuration, prompts, object class settings, approval required, and approval conditions. Plugin config matters because it is the part of the task configuration that controls how a task behaves beyond the common task fields, enabling configuration admins, super admins, and integrators to tailor task creation and completion behaviour to the chosen task type and ensuring tasks are generated with the correct operational settings.

POST /api/authentication objects/ ​

**POST /api/authentication objects/** is the Autologyx API endpoint used to create authentication objects, which store the provider-specific credentials and connection settings that the platform uses to authenticate with external services such as DocuSign, Box, Adobe, Microsoft, Salesforce, API key-based services, and Autologyx itself. It is used by developers and configuration administrators when setting up or automating integrations, including submitting credentials, additional authorization headers, additional parameters, and provider-specific fields such as Box subject details or expiry settings. This endpoint matters because authentication objects are the foundation for secure outbound integration activity in Autologyx: they centralize how credentials are defined, managed, and later tested or reused by platform features and integration configurations.

POST /api/event_bridge/create_event ​

POST /api/event_bridge/create_event, also referred to as the create event endpoint, is an Autologyx API endpoint used to create a History Event record by sending event data through an AWS Event Bridge Lambda into the client’s event-history storage in ClickHouse. It is used by developers and integrators when external services or platform components need to write structured event records, including the event type and related payload, into the Autologyx history architecture. This endpoint matters because it provides the standard ingestion path for event data, supports tenant-specific history databases created for each client, and underpins downstream audit, analytics, compliance, and operational reporting capabilities across the platform.

POST /api/initialize tenant ​

POST /api/initialize tenant is the Event History service API endpoint used to initialise a tenant connection and create the corresponding tenant entry required for that tenant to use Event History within the Autologyx platform. It is used by developers, integrators, configuration administrators, and Super Admins when setting up or enabling the API History Event microservice for a tenant, typically alongside the tenant’s authentication details and database configuration such as client ID, client secret, API key, tenant database, and related history database settings. This endpoint matters because it establishes the tenant record that the Event History service depends on to connect to the Autologyx main system and store or retrieve tenant-specific history data; without this initialisation, the service is not configured for that tenant.

POST /api/users/preferences/{key}/ ​

**POST /api/users/preferences/{key}/** is the Autologyx API endpoint used to create or overwrite a preference value for the authenticated user under a specific preference key. It is used by developers and integrators when persisting frontend user-specific layout settings, such as table column configuration, sorting, filtering, and similar interface preferences, so those settings can be saved and reapplied consistently for that user. This endpoint is part of the User Preferences capability and works alongside retrieval endpoints such as GET /api/users/preferences/{key}/, making it important when configuring applications that need to store per-user interface behaviour and deliver a consistent personalised experience across sessions.

predefined values ​

Predefined values are the fixed, allowed options defined for API fields of type enum and set in the Autologyx platform. In API schema and metadata responses, they are provided as a list of JSON objects attached to the field definition, and can also be exposed through a relative API endpoint that returns the available options. Developers and integrators use predefined values when building requests, validating input, and configuring integrations so that submitted data matches the values the field accepts. This matters because these values define the permitted contents of constrained fields, support consistent filtering and selection behaviour, and allow client applications to generate reliable user interfaces and request payloads without hard-coding unsupported options.

preferences key ​

A preferences key is the string identifier used by the Autologyx User Preferences API to store and retrieve a specific authenticated user preference record at GET /api/users/preferences/{key}/ and POST /api/users/preferences/{key}/. In practice, the key names an individual preference value managed per user, commonly for frontend application settings such as table columns, sorting, filtering, and other layout configuration. It is used when developers or integrators persist user-specific interface state, and it matters because the key defines how preferences are organized, updated, and looked up consistently across the platform. Keys must be unique within a user’s preference set, comply with the platform’s validation rules, and are limited to 255 characters.

presigned S3 URL ​

A presigned S3 URL in the Autologyx platform is a temporary upload URL generated by the Event History API microservice through the GET /api/files/upload_url endpoint, using AWS credentials for the configured object storage location. It is used in the Event History file-handling flow before a history event that includes an associated file is recorded: an external service uploads the file directly to storage with the presigned URL, and the resulting file is then referenced in the related History Event by its file id and storage key information. This mechanism matters to developers and integrators because it provides the required, supported way to attach files to history records while keeping file transfer separate from event submission, enforcing the platform’s storage model, and enabling secure direct uploads without exposing underlying storage credentials.

presigned url ​

A presigned URL in the Autologyx platform is a time-limited S3 URL generated by the backend to let a client upload or download a file directly to or from the platform’s storage without routing the file through the application server. It is used in two main places: the Events API, where a GET file endpoint returns a presigned URL for downloading an event-related file from S3, and the file-upload WebSocket flow, where the backend returns a single presigned URL for one-part uploads or part-specific presigned URLs for multipart uploads, together with the upload session details such as upload ID and S3 key. This matters to developers and integrators because presigned URLs are the mechanism that powers secure file transfer in Autologyx integrations, and they determine how clients request upload access, send files to the correct S3 key, complete single-part or multipart upload workflows, and notify the backend so processing can continue.

Prevent password re use ​

Prevent password re use is a Security Rules setting in Autologyx that controls whether users are allowed to choose a password they have previously used. It is configured as a boolean value in the system configuration section of the Security Rules page and is exposed through the GET and PATCH /api/security/ endpoints as password prevent reuse. When enabled, Autologyx blocks a user from reusing an earlier password, making it an important control for configuration administrators, Super Admins, and security teams who are defining password policy alongside other settings such as password complexity, password rotation interval, activation link valid period, and authentication method.

private rsa key ​

In Autologyx, a private rsa key is a required string credential stored in an Authentication Object for the DocuSign provider, alongside the user id, client id, and host. It is used when configuration admins or integrators create or update DocuSign authentication settings through the platform’s authentication object configuration or API. This field matters because it is part of the credential set Autologyx requires to authenticate the DocuSign integration successfully; if it is missing or null, the authentication object is rejected, and if it exceeds 2000 characters, validation fails.

processing ​

In Autologyx, processing is the active status of a document generation job for a specific object record and document template pair. It is used in Object Record Documents workflows and related API operations to show that a generated document is currently being created and is not yet available for download or replacement. While a document is in processing, Autologyx prevents duplicate generation requests for the same record-template combination, returning an already processing response instead, and the job can be cancelled only while it remains in this status. This status matters to end-users and configuration admins because it controls how on-demand document generation behaves, helps avoid duplicate outputs, and determines when generated documents can be managed through Object Record Documents.

progress update ​

In the Autologyx platform, a progress update is a WebSocket event emitted by the backend during file-processing workflows to report the current state of long-running upload and ingestion steps, such as extracting and saving files and creating Object Records in a target Object Class. It is used on the files WebSocket resource by developers and integrators who need real-time visibility into processing activity, and its message payload includes the processing step name, upload session ID, completion status, total expected item count, processed item count, and a timestamp. Progress updates matter because they enable client applications and integrations to track execution stage by stage, present accurate status information to users, coordinate follow-on actions, and monitor whether backend processing has completed successfully.

provider ​

In Autologyx, a provider is the defined authentication source or integration type selected on an Authentication Object or Single Sign On configuration to tell the platform which external service, protocol, or credential model to use. It is configured through the **provider** field, which accepts supported values such as api key, autologyx, imanage, docusign, microsoft client credentials, box client credentials, adobe client credentials, salesforce client credentials, and oauth client credentials, and it determines which provider-specific settings and credential fields must be supplied, such as client IDs, secrets, token URLs, tenant details, or additional parameters. In SSO configuration, the SSO provider identifies the identity platform being used, such as Azure or Okta, and drives required values such as the Azure tenant identifier or Okta organization domain. This matters because the provider controls how Autologyx authenticates to connected systems and sign-in services, what validation rules apply during configuration, and whether the integration can be activated and used successfully.

provider authorization url ​

In Autologyx, the provider authorization URL is the Single Sign-On endpoint returned by the platform when initiating an external identity-provider login flow, exposed through the POST /api/single sign on/login/ operation. It is used during SSO configuration and authentication to direct a user from Autologyx to the configured provider, such as Azure AD or Okta, so the provider can authenticate the user and return control to Autologyx. This URL matters to configuration admins, super admins, and integrators because it is the entry point for the SSO handshake and must align with the tenant-specific identity provider setup, including related settings such as the Azure tenant identifier, Okta organization domain, logout URL, and auto-create-user behaviour.

provider integration ​

A provider integration in Autologyx is the platform-level connection definition for a supported external provider, such as DocuSign, iManage, Microsoft, Box, Adobe, or generic OAuth-based services, that governs whether Authentication Objects for that provider can be created, tested, listed, or used. It is used in authentication and integration configuration, where admins and integrators select a provider and supply provider-specific credentials, and for some providers also configure additional authorization headers or additional parameters. Provider integrations matter because they act as an enablement and control layer for external connectivity: if an integration is inactive or disabled, related authentication actions are blocked, so the integration must be activated and enabled before users or processes can authenticate against that provider.

public file limit ​

The public file limit is the maximum number of files that can be stored in Autologyx as Public Files, which are files intended to be accessible through supported file endpoints using the appropriate file token and permissions model. This limit is used in the platform’s file handling and upload configuration, particularly where public storage is enabled and files are created or managed through compatible endpoints. In standard platform documentation, the limit is up to 10,000 Public Files, with the exact cap configurable per build. This matters to configuration administrators, super admins, and developers because it defines the capacity available for publicly stored files, influences integration and storage design, and must be considered when planning file upload volumes, retention, and access patterns.

public files ​

Public files is a platform limit that defines the maximum number of files that can be made publicly accessible within an Autologyx environment. It is used in the Limits configuration area, where administrators review and manage count-based and additional platform limits. This setting matters because it controls how many files can be exposed through public access, helping Configuration Admins and Super Admins govern platform usage, apply appropriate access boundaries, and stay within the configured capacity for publicly available file content.

public storage ​

Public storage is the Autologyx file storage area for uploaded files that are saved permanently without a time limit and managed through the Files API. It is used by developers and configuration administrators when integrating file uploads, moving a previously uploaded file into persistent storage with POST /api/files/**public storage**/, listing stored files with GET /api/files/**public storage**/, and deleting files where the relevant permissions are granted. Access to public storage is controlled by the store, list, and delete file permissions, and operations use file tokens to identify uploaded files before they are stored. Public storage matters because it is the platform’s persistent file repository for API-driven document handling, so correct permission setup and endpoint usage determine who can retain, view, and remove uploaded content.

public theme ​

In the Autologyx platform, a public theme is a UI Config resource name that is exposed without authentication and can be requested publicly for a specified UI component. It is used through the UI Config interface and UI Config API, where the request identifies the target component by a case-insensitive component name in the URL. Public themes matter because they allow developers, integrators, and configuration administrators to deliver consistent component styling or presentation settings to unauthenticated experiences while still managing themes through the platform’s UI configuration model.

publisher url ​

Publisher URL is the URL field stored with a custom component record in Autologyx and identifies the web address associated with the component’s publisher. It is used in the Custom Components area alongside related metadata such as publisher, version, repository URL, index URL, status, and permissions, for both repository-level and component-level entries. For developers, configuration admins, and super admins, this field matters because it provides a direct, structured reference to the publisher behind a component, helping with component catalog administration, source identification, and governance when reviewing, importing, enabling, or maintaining custom components in the Custom Components Repository.

query string parameter authentication ​

Query string parameter authentication is the authentication method used by Autologyx WebSocket event endpoints, where the client supplies its authentication value in the connection URL’s query string when opening the socket. In the Autologyx platform, this is used on real-time Events endpoints such as GET /ws/events/object records/ and GET /ws/events/tasks/, which stream Object Record and Task change events to connected clients. This matters to developers and integrators because the WebSocket connection must be formed with the required query string authentication parameter for the subscription to succeed, making it a core part of configuring secure real-time updates for user interfaces and event-driven integrations.

real time update mechanism ​

In Autologyx, the real time update mechanism is the WebSocket-based event stream used to notify connected clients immediately when Task data changes, allowing interfaces and integrations to stay synchronised without polling or page refreshes. It is used through the task events endpoint, GET /ws/events/tasks/, where authenticated clients subscribe to Task-related events such as task created, task deleted, task status changed, task assignee added or removed, and task owner added or removed, with payload data including values such as the event timestamp, task id, and Object Class ID. This mechanism matters to developers and integrators because it supports responsive user experiences, event-driven processing, and accurate downstream system behaviour by delivering Task changes as they happen across the platform.

real time updates ​

Real time updates in the Autologyx platform are the WebSocket-delivered changes broadcast by Catalyst so connected clients can stay synchronised with the latest state of data without polling. They are used through the Catalyst Websockets API, where a client first obtains authentication from the GET /api/users/ws auth/ Catalyst API endpoint and then opens a WebSocket connection to receive update messages for items such as rows, cells, and record counts, including any buffered events needed to catch up. This matters to developers and integrators because it defines how applications subscribe to and process live platform events, and it matters to end-users because it enables immediate visibility of changes in the interface, supporting responsive, current views of Catalyst data.

record count ​

Record count is the integer value on an Object Class that shows how many records currently exist for that class in Autologyx. It is exposed in the Object Classes resource and related API responses as a standard field, where developers and configuration administrators can read, sort, and work with it alongside other object class metadata. Record count is also used by the Catalyst Websockets API, which keeps changes to rows, cells, and record counts synchronised in real time so user interfaces and integrations can reflect data volume changes without a page refresh. This matters because it provides a quick operational view of object class usage and supports building responsive configurations, dashboards, and integrations that depend on accurate current record totals.

record created ​

Record created is the event type logged in Autologyx history when a new object record is created. It is used in Object Records History Events and the Event History API alongside other record lifecycle events such as owner initialized, field values changed, and record deleted, and is returned with standard event metadata including event id, event datetime, event data, and source type. This event matters because it marks the start of a record’s lifecycle in the platform, providing a definitive audit point for integrations, configuration, reporting, and compliance use cases that need to track when a record first entered the system and what subsequent activity relates to that record.

record deleted ​

In Autologyx, record deleted is an event type recorded in object record history and exposed through the Event History API to indicate that an object record has been deleted. It appears alongside other lifecycle and change events such as record created, field values changed, and status initialized, and is stored with standard event metadata including event id, event datetime, and source type so teams can identify when the deletion occurred and whether it was initiated by a user, a sequence, or the system. This event matters to developers, configuration administrators, and compliance or analytics users because it provides a definitive audit trail entry for record removal, supports integrations and reporting that depend on historical activity, and helps validate governance, trace operational changes, and investigate record lifecycle outcomes across a client environment.

record id ​

In the Autologyx platform, a record id is the identifier used by the event history API to scope and retrieve history entries for a specific record, enabling clients to request only the events associated with that record rather than the full visible event set. It is used in API requests and responses alongside event metadata such as source type, event type, and field id, particularly when integrating with the client history database or consuming event data for reporting, compliance, and analytics. Record id matters because it is the key filter that links event history to an individual business record, supporting precise data access, efficient querying, and consistent integration with Autologyx API standards.

record permission sets ​

Record permission sets are a configurable platform resource in Autologyx that define access control for records and are tracked as a counted limit within the tenant’s platform limits. This term is used in the Limits documentation, where the records permission sets value specifies the maximum number of record permission sets that can exist, alongside related limits for the users and user groups assigned to object record permission sets. This matters to configuration admins, super admins, and developers because it directly affects how record-level access models can be designed, scaled, and governed across the platform, and it should be considered when planning security configuration, assignee structure, and overall solution capacity.

record properties ​

Record properties are the built-in system attributes of an Autologyx object record, such as its ID, Created timestamp, and Modified timestamp. In the platform, they are used in merge fields within document templates to pull record-level metadata directly into generated content using the documented merge field syntax, including supported shorthand forms. Record properties matter because they provide consistent, system-managed values that can be inserted into documents and communications without relying on custom document fields, helping users and configuration admins produce accurate, traceable output and design templates that reference core record metadata reliably.

Record Related Contexts are the set of merge-field contexts in Autologyx that are directly associated with an ObjectRecordContext and expose the data and metadata needed for work on a specific record. They include TaskContext, ObjectRecordContext, UsersGroupContext, UserContext, UserFieldMetaContext, UserFieldContext, and DocumentContext, and are used in scopes that operate on record-centric activity such as SequencerActorScope and DocumentGenerationScope. In practice, these contexts make record values, task details, user and group information, user-defined field definitions and values, and document-specific information available to templates, workflow steps, and document generation processes. This matters to configuration admins and developers because Record Related Contexts determine what record-level information is available in a given scope, which directly affects merge-field design, workflow configuration, and document output.

redirect uri ​

  • Mostly relevant to: Configuration admins, Developers / Integrators, Super Admins
  • Closely related concepts: Azure application SSO, app id

In Autologyx, the redirect URI (also shown as the login callback URL or redirect_uri) is the URL used in Single Sign-On configuration and authentication flows to receive the user back from the identity provider after login. It is configured as part of an SSO record alongside values such as client ID, tenant ID, provider, and logout URL, and it is also returned by the SSO login API response for initiating the sign-in process. This setting matters to configuration admins, super admins, and integrators because it must match the callback URL registered with the external identity provider, such as Azure or Okta, so that authentication completes successfully and users can be signed into the Autologyx platform.

refresh url ​

In Autologyx, refresh url is the URL field on an Authentication Object that defines the endpoint used to refresh an OAuth access token after the initial token has been obtained. It is used when configuring generic OAuth-based providers, including Generic Client Credentials and ROPC Generic oAuth authentication objects, alongside related settings such as token url, client credentials, scope, additional parameters, and additional authorization headers. For configuration admins and integrators, this setting matters because it controls how Autologyx maintains authenticated access to external services without recreating credentials manually; the value must be a valid URL and, when supplied, must meet the platform’s validation rules for authentication object configuration.

Related classes are object classes that are connected to the current object class and whose fields can be referenced in an Object Class Document Template. In Autologyx, the term is used during document template configuration and template verification, where the platform validates merge tags not only against the current class fields but also against fields exposed through these related classes. This matters to configuration admins because it determines which cross-object data can be merged into generated documents, helps structure document templates correctly, and ensures template uploads and updates pass validation for Jinja syntax and merge tag usage.

Related Object Records are the object record instances connected to a given object record through relationships defined in an Autologyx Object Model, and are exposed through the object model API endpoint used to list related records. In practice, developers and integrators use Related Object Records when retrieving data that spans linked object classes, with the returned results controlled by query parameters and the caller’s permissions. This concept matters because it is how the platform surfaces connected business data across the relational model, enabling integrations, lookups, and application logic to navigate defined relationships while respecting object model structure and access controls.

Related records are merge fields that expose object records connected to the current record through relationships defined in the Object Model for that record’s object class. In Autologyx, they are used primarily in document templates and other merge-field-supported contexts to display connected records, access a specific related record by index, iterate through multiple related records in loops, and chain into further relationships as part of the Document Object Structure. This matters because it allows configuration admins and end-users to pull structured data from linked business objects into generated content without duplicating information, enabling richer templates, cross-record data access, and automated documents that reflect the full relationship model of the platform.

In the Autologyx platform, related validators are schema validator definitions that include an attribute identifying the specific fields within a field group or nested schema that the validator applies to, rather than applying to every field in that group. They are used in API schema design and configuration where one field’s value affects the validation rules for other fields, with the validator definition including both the controlling field and a list of affected fields. This matters to developers, integrators, and configuration administrators because related validators make validation behaviour explicit, support precise control over grouped and nested field structures, and ensure the platform enforces the correct rules only on the intended fields.

relation depth limit ​

Relation depth limit is the maximum allowed number of parent-child levels in an Object Model relation hierarchy in Autologyx. It is enforced when configuration admins, super admins, or integrators create or update object class relationships in Object Models, specifically through the object model definition where each object class can be linked to a parent. If adding a relation would make the hierarchy deeper than the platform allows, the request is rejected with the validation error "Relation depth limit exceeded for Object Class ID "value"." This limit matters because it controls the structural complexity of Related Object Records, keeps object model hierarchies within supported platform boundaries, and must be considered alongside settings such as children limit, multiplicity, and removable or modifiable relations when designing or integrating relational models.

Relation Lookup ​

Relational fields ​

Relational fields are merge fields that expose data from records linked to the current record, allowing Autologyx to reference related entities when rendering content. In the platform, they are used anywhere standard merge fields are supported, including document templates and merge field custom filters, alongside basic fields, system fields, and constants. This matters because relational fields let users include connected business data in generated output without duplicating information, while administrators configuring templates and filters need to understand that they are treated as a standard merge field type and are subject to the same processing rules and field-type constraints as other supported merge fields.

relational MF ​

A relational MF (relational merge field) is a merge field in an Autologyx document template that pulls data through relationships between classes rather than only from the primary object record. It is used in document generation and Object Record Documents to include related information from connected records in the generated output. In practice, relational merge fields affect which document templates are available to a user, because access to a template can depend on permission to view all classes referenced by the relational merge fields in that document. This matters to configuration admins when designing templates and permissions, and to end-users when selecting or generating documents, because relational merge fields determine what related data can be merged into a document and whether the document can be accessed at all.

reminders ​

In Autologyx, reminders are an optional task template configuration that defines one or more scheduled notices sent in relation to a task’s completion deadline. They are configured on Task Templates as a reminders object or array, with each reminder entry specifying a notice type together with a time unit and time value, and they are returned as part of the template definition in task template API responses. Reminders matter because they control how the platform prompts users about upcoming task deadlines, allowing configuration admins and integrators to standardise deadline communications, align notices with complete by and expiry settings, and ensure task-driven processes include the right operational notifications without custom logic outside the template configuration.

removable relation ​

In Autologyx Object Models, a removable relation is a boolean property on a relation between a parent object class and a child object class that indicates whether that class-level relationship can be removed from the model configuration. It is used in the Object Models request and response payloads for object class relations, alongside settings such as parent and multiplicity. A value of false means the relation is not removable because a relation already exists between records of the corresponding parent and child classes. This matters to configuration admins, developers, and super admins because it identifies whether a structural change to the data model is permitted before updating an Object Model, helping protect existing related object records and preventing invalid changes to live relationships.

renewal time unit ​

Renewal time unit is the task template configuration field used within the renewals settings to define the unit of time for a renewal interval, paired with renewal time value. It is used in the Task Templates API when creating, updating, or retrieving templates, where it specifies how the platform interprets the numeric renewal period for generating repeat task activity. For configuration admins and developers, this field matters because it controls the schedule granularity of renewals and ensures renewal timing is configured consistently with related task timing settings such as expiry, complete by, reminders, notice type, last task created, and number of tasks created.

renewal time value ​

Renewal time value is the integer field in a Task Template’s renewals configuration that sets the numeric interval used with renewal time unit to define when a renewal-related action occurs for a task. In Autologyx, it is used in the Task Templates API on create, update, and response payloads for templates that include renewals, alongside related scheduling settings such as notice type, time unit, and time value. This field matters to configuration admins and developers because it controls the exact quantity for the renewal schedule, ensuring tasks are generated or managed at the intended renewal interval and that automated task lifecycle behaviour aligns with business timing rules.

renewals ​

In Autologyx, renewals are the optional task-template settings that define how a task should recur or be recreated on a renewal cycle, using renewal-specific timing fields such as renewal time unit and renewal time value. They are configured as part of a task template alongside related scheduling controls such as complete by, expiry, reminders, notice type, and plugin config, and they are returned in task template responses so integrations and administrators can read and manage the template’s renewal behaviour. Renewals matter because they let configuration admins design repeatable operational workflows for time-bound or expiring work, while giving developers and integrators a structured object to supply, validate, and consume when automating task creation and lifecycle management in the platform.

repository status ​

Repository status is the lifecycle state of the Custom Components Repository in Autologyx, used during repository import and installation operations to show whether the repository is being processed, has completed, or has failed. It is surfaced in the custom components API and related configuration workflows, where it drives the behaviour of component creation and availability: when the repository status is imported or processing, the associated custom component status is also set to processing while the background installation task runs, and a failed repository import prevents components from reaching a usable state. This matters to Configuration Admins, Super Admins, and Developers/Integrators because repository status indicates whether custom components are ready to use, still being installed, or require intervention to resolve an import failure.

request presigned url ​

In the Autologyx platform, **request presigned url** is a file-upload event type used on the Catalyst file upload WebSocket endpoint to ask the backend to generate a presigned URL for uploading a file to object storage. It is used by client applications and integrations after the WebSocket connection is established, as part of the workflow for uploading files to Object Records, alongside related events such as multipart presigned URL requests and upload completion notifications. This event matters because it is the mechanism that initiates secure direct upload, allowing the client to obtain the storage target needed to send file content without routing the file through the application server, which is essential when building or configuring custom file upload integrations.

reserved permission set names ​

Reserved permission set names are system-protected names that cannot be used when creating a User Group Permission Set in Autologyx because they are reserved for Special Permission Sets. In the User Group Permission Set configuration flow, the platform validates the name and blocks any value that matches a reserved system name, alongside other rules such as length and uniqueness within the user group. This matters to Configuration Admins and Super Admins because it preserves the integrity of built-in permission structures, prevents conflicts with restricted system sets such as EVERYONE and MEMBERS, and ensures custom permission sets remain distinct from platform-defined Permission Set types.

resource keys ​

Resource keys are the named entries in an Object Record Permission Set’s permissions object that identify which platform resources the permission set controls, such as object records and tasks. In Autologyx configuration, each resource key contains a list of valid actions for that resource, and these action lists determine the permissions granted to users assigned to the permission set. Resource keys are used when defining, reviewing, or updating Object Record Permission Sets, where administrators configure resource-specific actions such as view, edit, delete, create, complete, or assign. They matter because they provide the structure that links platform resources to allowed actions, ensuring permissions are configured consistently and applied correctly for users working with Object Records.

resources' permissions configuration ​

In Autologyx, resources' permissions configuration is the permissions object within an Object Class Permission Set that defines which actions are enabled for available resources in a given object class. It is used when creating or updating permission sets for object classes, where administrators and integrators configure saved permissions such as create, edit, view, delete, complete, and assign at Object Class level. This configuration matters because it controls the operational access granted through the permission set, determines how users and Object Class Owners can interact with resources for that object class, and supports scalable governance by allowing multiple permission sets per object class up to the configured platform limit.

Response state ​

In Autologyx, a Response state is the enum value on a task’s response.state field that shows the lifecycle stage of the response payload attached to that task, separate from the task’s overall status. It is used in the Tasks API and related task processing flows to indicate whether a response is at its initial value set, has been saved as a draft, or has been accepted on completion, with human-readable labels also exposed in response.meta.labels.state. Response state matters to developers, integrators, and configuration admins because it determines how task response data and files should be interpreted at each step, supports correct handling of save and complete actions, and helps align task behaviour with next actions, approval conditions, and other API-standard workflow logic.

restricted system set ​

INSUFFICIENT_EVIDENCE

Restriction Max Object Records in one Object Class ​

Restriction Max Object Records in one Object Class is the Autologyx platform limit on how many Object Records can exist within a single Object Class. It is enforced when creating Object Records, including through the Object Records API, and is surfaced in validation and error responses as: "Limit of 500 000 Object Records in this Object Class has been exceeded." This restriction matters to Configuration Admins and Super Admins because it sets the capacity boundary for each Object Class, directly affecting data model design, record creation behaviour, integration planning, and ongoing administration of permissions, ownership, and field configuration for high-volume object data.

restrictions ​

In the Autologyx platform, restrictions are the machine-readable rules exposed by an API endpoint that define enforced limits and non-modifiable behavior for that endpoint, such as creation limits or other endpoint-specific constraints. They are returned in API metadata and response structures, including OPTIONS responses that describe list views, detail schemas, and endpoint restrictions, and they can also appear alongside list and detail information in standard JSON responses. Restrictions matter to developers and integrators because they determine how clients must build requests, validate user actions, handle blocked operations, and respond to platform-enforced limits such as object-count caps that can produce errors like ERR LIMIT EXCEEDED.

Result Class filter ​

In the Autologyx platform, the Result Class filter is a required request parameter used when accessing Object Model endpoints to specify the object class, or result class, that the endpoint should return. It is used by developers and integrators in API requests against the relational model, particularly where object classes and related object records are exposed through a shared endpoint structure. This filter matters because it scopes the request to the correct record type, ensures the platform returns the intended set of objects, and supports correct endpoint access and data handling when working with relation lookups and class-specific object data.

Roles ​

Roles are the Autologyx platform’s reusable permission groups used to control user access across system endpoints and administrative capabilities. Instead of assigning individual permissions directly to each user, administrators assign one or more roles, and a user is granted access wherever any assigned role includes the required permission. Roles are used in platform configuration and security administration, including areas marked as manageable via Roles and in relation to object class permission management, and they are also subject to platform resource limits. This matters because roles provide the core mechanism for scalable, consistent access control, helping configuration teams, super admins, integrators, and compliance stakeholders manage permissions efficiently, enforce segregation of duties, and maintain governed access as the platform grows.

Roles API ​

The Roles API is the Autologyx REST API resource for listing, retrieving, creating, and updating role definitions through the /api/roles/ endpoints. It is used by developers and integrators building administrative or provisioning workflows, and by super admins or configuration admins who manage access models across the platform. The API exposes core role data such as name, description, assigned permissions, user counts, audit fields, and meta.permissions, and supports standard API behaviours including authentication, ordering, filtering, and object-level operations. Roles defined through this API control access to platform resources and configuration areas such as task templates, tasks, users, standard authentication, authentication objects, object classes, roles, sequences, single sign on, user groups, message templates, and object models, making the Roles API a key integration point for implementing and maintaining consistent permission management in Autologyx.

ROPC Generic oAuth ​

ROPC Generic oAuth is an Authentication Object provider in Autologyx used to connect to external services that issue OAuth access tokens through the Resource Owner Password Credentials flow. It is configured in Authentication Objects by selecting the provider and supplying the required credentials and endpoints, including token URL, refresh URL, username, password, client ID, client secret, and optionally scope; it is then available wherever the platform needs stored authentication details for an integration or automated connection. This provider matters to configuration admins, developers, and super admins because it defines how Autologyx obtains and refreshes access tokens for systems that depend on this OAuth pattern, and correct configuration of its credential fields, URLs, and related expiry settings is essential for reliable integration behaviour and uninterrupted access to connected services.

rows ​

In the Autologyx platform, rows are the individual entries displayed within tabular views, with each row representing a single record whose fields are shown across cells. Rows are used in user-facing lists and data grids and are specifically surfaced in the Catalyst Websockets API, where updates to rows, cells, and record counts are pushed in real time without requiring a page refresh. This matters to both end-users and developers because row-level updates keep on-screen data current, support responsive interfaces, and enable integrations or custom components to react immediately when records are added, changed, or removed.

s3 key ​

In the Autologyx platform, an s3 key is the full object path in the Amazon S3 bucket that identifies the file uploaded for a file upload session. It is used in the file upload flow exposed through the websocket file events, where clients send the s3 key back to the backend after uploading a file with a presigned URL, and it is also returned as the target key for single-part and multipart uploads alongside values such as the upload id and s3 upload id. This value matters because it is the canonical reference Autologyx uses to associate the uploaded object with the correct upload session, complete upload processing, and locate the file for subsequent platform operations.

s3 upload id ​

In the Autologyx platform, the s3 upload id is the Amazon S3 multipart upload identifier returned for a multipart file upload session and used to track and complete that upload. It is used by developers and integrations when handling file upload details provided through file-related events, alongside values such as the s3 key, part URLs, chunk size, and total parts. This field is not used for single PUT-based uploads and is present only when is multipart is true. The s3 upload id matters because it links all uploaded parts to the same S3 multipart session and is required when completing the multipart upload process correctly.

schema by value ​

Schema by value is an Autologyx configuration pattern in which the schema applied to one field is selected using the value held in a different field. It is used in configuration for nested schema structures, including scenarios where the shape, validation rules, or available properties of a field group change according to another field’s value. This matters to configuration admins and developers because it enables dynamic, value-driven form and data structures within a single configuration, allowing the platform to present and validate the correct schema for each case while supporting more flexible implementations for complex data types such as grouped or file-related fields.

schema by value from different field ​

Schema by value from different field is an Autologyx API pattern used when the schema applied to a field is determined by the value held in another field within the same payload or resource. It is used in API definitions for nested or conditional data structures, including detail view representations, where one field acts as the selector that defines how a related field must be structured, validated, and interpreted. This matters to developers and integrators because it establishes how dynamic payloads are modelled consistently across the platform, ensuring client applications send the correct object shape, process responses correctly, and align with Autologyx validation and schema rules.

Security Rules ​

Security Rules are the platform-level configuration settings in Autologyx that define how user authentication and password controls are enforced across the tenant. Used by configuration administrators and Super Admins through the security configuration area and the /api/security/ endpoint, Security Rules cover password complexity requirements such as minimum length, letters, numbers, symbols, upper and lower case, and maximum repeating characters, as well as password reuse prevention, password rotation interval, activation link valid period, and permitted authentication methods for internal, external, full, and super admin access. These settings matter because they establish the organisation’s security baseline, control how users sign in and manage credentials, support compliance and information security policies, and provide developers and integrators with a consistent API-driven way to read and update authentication-related controls.

send activation email ​

Send activation email is the Autologyx user-management action and API endpoint used to resend a user’s activation email after the account has been created. It is used in the Users area and through the POST /api/users/{id}/send activation email/ endpoint to trigger delivery of the activation message for a specific user, supporting onboarding and account access setup. This matters to configuration admins, super admins, and integrators because it provides a controlled way to complete or restart user activation without recreating the account, helping administrators manage access efficiently and supporting automated user provisioning workflows through API calls.

Send Message ​

Send Message is a Sequencer actor in the Autologyx platform used within workflow configuration to send messages as part of an automated sequence, alongside other actors such as API Call, Variables, and AI Actors. It is configured by admins and developers in sequencers, where it can use merge fields to insert dynamic values from object records, users, groups, and related records into message content. This matters because Send Message is the platform mechanism for generating contextual outbound communications from a process, allowing configured workflows to deliver the right information to the right recipients using data already held in Autologyx.

Send Message Actor ​

The Send Message Actor is an Autologyx actor used in workflows to send outbound messages, and it supports merge field rendering so message content can be populated dynamically from case and workflow data at runtime. It is used when configuring automated communications and integrates with the platform’s merge field system, including custom filters, in the same way as other merge-field-enabled features such as the API Call Actor. This matters to configuration admins and developers because the actor is a key point where dynamic values are assembled into outbound content, making correct use of merge fields and filters essential for producing accurate, formatted, and context-specific messages.

Sentry ​

Sentry is the monitoring and error-logging service used by the Autologyx platform to capture rendering failures and other background-processing errors that are not shown directly to end users. In practice, it is used when operations such as merge field evaluation or document rendering run in background tasks, including sequence-driven generation, where failures are written to Sentry logs instead of being returned in the user interface. This matters to developers, super admins, and configuration admins because Sentry is the place to investigate silent template and field-resolution issues, validate why automated document output failed, and support safe deployment by identifying problems that only occur outside interactive testing.

Sequencer ​

In Autologyx, the Sequencer is the platform capability used to define and run ordered sequences of actor-driven steps within a workflow, such as API Call, Send Message, Variables, and AI Actors, with tasks created by the Sequencer as part of that execution. It is used when configuring process automation and in any sequencer actor that supports merge fields, including places where document templates, email templates, API responses, workflow notifications, and custom scripts need dynamic data inserted at runtime. The Sequencer matters because it is the mechanism that coordinates how automated actions are executed, how data is passed between steps, and how user-defined values such as loop items remain available throughout the sequence, making it central to building, maintaining, and using structured workflow automation in Autologyx.

Sequencer actors ​

Sequencer actors are the executable workflow components within an Autologyx Sequencer where merge fields and runtime context are resolved during process execution, including actions such as API Call, Send Message, Local Variable, Variables, and AI Actors. In this scope, the platform combines default system contexts, record-related contexts, and workflow-specific variable context, so these actors can access data such as Admin Context, Client Context, Object Records, users, groups, dates, constants, and dynamic variables while operating on the current record. This matters to configuration admins, developers, and super admins because the Sequencer Actor scope determines which merge fields and context data are available when building integrations, messages, and automation steps, directly affecting how workflows populate content, pass data, and execute record-driven logic.

Sequencer merge fields ​

INSUFFICIENT_EVIDENCE

SequencerActorScope ​

SequencerActorScope is the merge-field context scope used during sequencer-driven workflow execution in Autologyx. It combines Default Contexts, record-related contexts associated with the current ObjectRecord being processed, and VariableContext for runtime workflow variables, giving templates, rules, and generated content access to system data, record data, user and group information, document metadata, and dynamic execution values within a single execution scope. It is used in configuration and integration scenarios where workflow steps need comprehensive context resolution, and it matters because it defines exactly which context types and merge-field data are available at runtime when building, troubleshooting, or extending sequencer-based automation.

Sequences ​

Sequences are a configurable Autologyx resource used to define and run platform-driven workflow or processing logic that acts as a distinct source within the system alongside users and system actions. They are administered through the Sequences API and permissions model, and they are referenced across configuration areas including object classes, object class fields, document templates, task group templates, and user groups, where usage endpoints and deletion safeguards show which assets are in use by specific sequences. Sequences also appear in object record history and event data as a source type, allowing administrators and integrators to identify actions initiated by a sequence. This matters because sequences are a central dependency in solution configuration: they require explicit access control, count against platform limits, influence whether related configuration items can be changed or deleted, and form part of the integration and governance model for automated behaviour in an Autologyx environment.

Show 3 more pages

Service External ​

Service External is an Autologyx user account type used for external service or integration accounts. It is configured in platform security settings as the **service external** authentication-method category alongside other account types such as External, Service Internal, and Super Admin, and it also appears in user management where the platform enforces a limit of 5 Service External accounts. In the Users configuration, Service External has the same permissions as the corresponding external account type except that it cannot change passwords, and password changes are restricted to Service accounts only. This matters to Configuration admins and Super Admins because Service External determines how external service identities are classified, what authentication rules apply to them, and how account limits and password-management controls are enforced across the platform.

Service Internal ​

Service Internal is an Autologyx user account type for internal service accounts, used in platform security configuration and user administration to define how non-human internal accounts authenticate and what limits apply to them. In Security Rules, Service Internal appears as a distinct account-type key under authentication method settings, where administrators set the allowed sign-in method for that account type alongside other account types such as Internal, External, Service External, Full, and Super Admin. In Users, Service Internal is listed as a separate account type with a platform limit of 1 account, and service accounts are the account type for which password changes are supported, making this setting important when configuring automation, integrations, and operational service identities. This matters because it controls how internal service identities are created, secured, and managed, and it must be configured correctly to align authentication policy, account-type limits, and service account administration.

single instance endpoint ​

In the Autologyx platform, a single instance endpoint is an API resource that represents one platform-wide record rather than a collection of multiple records. It is used where a configuration area has exactly one stored object for the tenant, such as Company Details, so requests interact with that single record directly through the endpoint instead of creating, listing, or selecting from many entries. This matters to developers, configuration administrators, and Super Admins because it changes how the endpoint is integrated and managed: the endpoint is treated as the authoritative source for that setting area, updates apply to the one existing record, and permissions and metadata for the resource govern access to that single shared configuration object.

Single level processing ​

Single level processing, also described as non recursive processing or one level processing, is the merge field rendering rule in Autologyx that evaluates only the first layer of merge field content and does not continue resolving merge fields found inside the rendered result. It is used in merge field custom filter behaviour, particularly when rendering string values within document templates and related template-driven outputs. This rule is important for configuration admins and developers because it prevents infinite loops, defines how nested content is handled, and sets clear expectations for template design: first-level merge fields are rendered, while deeper nested content remains as raw text unless it is handled through a different template structure or processing approach.

single sign on ​

Single sign on (SSO) in the Autologyx platform is an authentication capability that allows users to access Autologyx using an external identity provider instead of standard authentication managed directly in the platform. It is used in platform security and access configuration, and its administration is controlled through role permissions, where single sign on appears as a distinct permissioned resource alongside standard authentication and authentication objects. This matters to Configuration admins and Super Admins because SSO configuration determines how users sign in, how access is governed across the organisation, and which administrators are authorised to view, create, update, or manage SSO-related settings as part of the platform’s overall identity and permissions model.

Single Sign On Configuration permissions ​

Single Sign On Configuration permissions are the role-manageable permissions that control access to SSO configuration records in the Autologyx platform. Used by Configuration admins and Super Admins when setting up or maintaining identity provider integrations such as Azure application SSO or an Okta tenant domain, these permissions define whether a user can list, view, create, edit, or delete Single Sign On configurations. They are available at Global scope and for a specific single sign on context, and are exposed through the platform’s permissions model, including role configuration and permission checks. These permissions matter because they govern who can administer critical SSO settings such as tenant identifiers, logout URLs, and automatic user creation, helping organisations secure authentication setup while delegating configuration responsibilities appropriately.

single sign on configurations ​

Single sign on configurations are Autologyx authentication objects that define and manage how users sign in through an external identity provider, and are used by administrators and integrators through the Single Sign On Configuration resource and related API endpoints to list, view, create, edit, and delete SSO setups. They are part of platform authentication configuration, include provider-specific settings such as Azure-related options, and are governed by role permissions at global and object level. Single sign on configurations matter because they control how user access is integrated with enterprise identity services, affect related behaviours such as automatic user creation and Azure application SSO features, and are subject to platform limits, including a maximum number of configured SSO objects.

smtp settings ​

SMTP settings are the outbound email configuration for an Autologyx environment, used to define how the platform connects to an SMTP server to send emails from the system. In Autologyx, these settings are managed through the administration SMTP settings endpoints and include the host, port, TLS option, username and password or Microsoft client credentials authentication, the associated authentication object where required, and the from email and failure email addresses used for message delivery and delivery-failure handling. These settings matter because they control whether platform-generated emails are sent successfully, ensure the correct sender identity is used, route failure notifications to the right recipients, and allow administrators and integrators to test and validate email delivery as part of environment configuration and integration setup.

sorting ​

Sorting in the Autologyx platform is a user preference that stores how list or table data is ordered in the frontend application for an authenticated user. It is used alongside other layout settings such as table columns and filtering, and is managed under frontend-controlled user preference keys through the User Preferences API endpoints, including GET and POST requests to /api/users/preferences/{key}/. Sorting matters because it preserves each user’s preferred view of operational data across sessions, helping end-users work more efficiently and enabling developers and integrators to persist and restore consistent interface behaviour within custom or embedded experiences.

source id ​

In Autologyx Event History, source id is the integer identifier of the platform object that generated an event record, used together with source type to pinpoint the exact source of that event. It is returned in each event entry from the Events API and is also available as a filter parameter when querying history, alongside related fields such as event type, event data, and field id. Source id matters because it lets developers, integrators, and audit or analytics users trace events back to the originating record, correlate activity across systems, and build precise reporting, troubleshooting, and compliance workflows from event data.

source type ​

In Autologyx, source type is an event attribute that identifies what initiated a recorded platform action, with supported values of user, sequence, and system. It is used in event and object record history responses alongside fields such as event type, event data, source id, and event datetime, and it can also be used when filtering event-history API results. This matters because it lets developers, configuration administrators, and audit or compliance users distinguish between actions performed manually by a person, automatically by a Sequence, or internally by the platform, which is essential for interpreting record changes such as record creation, ownership updates, assignee changes, field value changes, document generation, status initialization, and record deletion.

Special Permission Sets ​

Special Permission Sets are the two system-created user group permission sets that Autologyx automatically adds whenever a User Group is created. They are used within the User Group Permission Sets configuration for that specific user group and represent reserved, built-in permission set names such as EVERYONE and MEMBERS, which cannot be reused for custom permission sets and, in the case of special sets, cannot have their reserved names changed. These sets matter because they provide the platform’s predefined access structure for user group membership and visibility, enforce naming and permission rules during create and update operations, and count toward the maximum number of permission sets allowed per user group, so configuration admins and Super Admins must account for them when designing user group access.

Specific Class ​

INSUFFICIENT_EVIDENCE

specific file ​

In the Autologyx platform, a specific file is the permission-check context used when access control is evaluated for one identified file rather than for files in general at the global scope. It is used in the Files resource model and API permission checks, where actions such as listing, storing, deleting, or otherwise interacting with an individual uploaded file are assessed against that file reference. This distinction matters to developers, integrators, and platform administrators because file operations often depend on both broad file capabilities and access to the exact file being targeted, including workflows that use file references or file tokens after upload. Configuring and understanding the specific file context ensures that integrations and administrative controls apply the correct file-level security for each file operation.

Specific integration configuration ​

Specific single sign on ​

Specific single sign on is the object-level permission context for an individual Single Sign On (SSO) configuration in the Autologyx platform. It is used in the Single Sign On Configuration permission model to check whether a user can perform actions such as view, edit, or delete a particular SSO configuration, distinct from permissions granted at Global scope across all SSO configurations. This context matters to Configuration admins and Super Admins because it supports precise access control for named SSO setups, including provider-specific configurations such as Azure application SSO or an Okta tenant domain, and works with role-managed permissions and meta.permissions to ensure administrative access is limited to the exact SSO configurations a user is responsible for.

SSO state parameter ​

In the Autologyx platform, the SSO state parameter is a security value used during Single Sign-On flows to bind the authentication request to the returning identity provider response and provide CSRF protection for the public access endpoint involved in sign-in. It is used in SSO configuration and operation alongside provider-specific settings such as Azure application SSO, Azure tenant identifier, Okta tenant domain, logout URL, and automatic user creation behaviour. This matters to configuration administrators, integrators, and security teams because it protects the sign-in transaction from forged or unsolicited responses, helping ensure that only authentication responses initiated by the platform are accepted.

standalone forms ​

Standalone forms, also called object class forms, are form configurations for an object class that are published as independent pages rather than embedded only within the Autologyx frontend application. In Autologyx they are used to view, create, and update object records, with the documented standalone scope focused on creating object records, and they are managed through object class form configuration and the /api/object class forms/ API. Standalone forms matter because they provide a direct, configurable entry point for working with object records outside the main application flow, which is important for administrators and integrators designing data capture experiences, access patterns, and integrations. Their use is also governed by object-class permissions and platform limits, including a maximum number of standalone forms allowed per object class.

standard authentication ​

Standard authentication is the role permission in Autologyx that controls access to the platform’s built-in username/password authentication configuration, and it is used in role definitions alongside other administrative permissions such as single sign on, authentication objects, and roles. Configuration admins and Super Admins encounter this permission when creating or managing roles through the platform or the Roles API, where it appears as an available entry in the permissions object and in meta.permissions responses. This permission matters because it determines which administrators can view or manage standard authentication settings, allowing organisations to separate responsibility for native sign-in administration from broader identity, security, and platform configuration tasks.

standard document generation workflows ​

Standard merge syntax ​

Standard merge syntax is one of the supported merge field syntaxes in the Autologyx document generation and merge framework. It is used when configuring merge fields in document templates, including scenarios that use custom filters, and is the syntax variant aligned with image embedding behavior. Within the platform, it sits alongside paragraph replacement syntax, which replaces an entire paragraph with merged document content; standard merge syntax is used where that paragraph-level replacement behavior is not required. This distinction matters to configuration admins, end-users, and developers because the selected syntax directly affects how merged content is rendered in DOCX templates and therefore how template output behaves during document creation and automation.

standard message templates ​

Standard message templates are the built-in communication templates used in the Autologyx platform to generate consistent outbound messages, and they can include merge fields so that system-held data is inserted automatically when a message is created. They are used wherever users or administrators configure or send standardised communications, with company details available for inclusion as merge fields within these templates. This matters because standard message templates help organisations maintain accuracy, consistency, and branding across communications while reducing manual editing and supporting scalable configuration of repeatable messaging.

standard predicates ​

Standard predicates are the predefined query operators used by Autologyx API endpoints to filter records in a consistent way according to the field type. In practice, they are applied as URL query parameters on resource endpoints such as Roles and other object-based APIs, where fields use standard predicate families including standard pk for primary key fields, standard string for text fields, standard datetime for date and time fields, and standard set for multi-value or membership filtering. These predicates work alongside endpoint-specific sortable fields and let developers and integrators perform exact matches, range queries, comparison filters, and inclusion checks using a common API pattern defined in the ALX API standards Developers guide. They matter because they provide a predictable filtering model across object classes and APIs, which simplifies integration design, reduces implementation errors, and ensures requests are constructed correctly when retrieving targeted subsets of platform data.

status initialized ​

Status initialized is an event type recorded in Autologyx history when a record’s status is first set as part of its lifecycle initialization. It is used in the Object Records History Events response and stored and retrieved through the Event History API alongside metadata such as event datetime, event data, and source type (for example user, sequence, or system). This event matters because it marks the point at which workflow status tracking begins for a record, giving developers, configuration administrators, and compliance or analytics users a clear audit trail entry for status establishment and a reliable trigger or reference point when integrating with history data, reviewing process activity, or analysing record progression.

store permission ​

In the Autologyx platform, the store permission controls whether a user can save an uploaded file into public storage through the Files capability and related file upload endpoints. It is used wherever files are uploaded and persisted in the ALX system, particularly in integrations and configurations that rely on a compatible endpoint supporting uploaded files. This permission matters because it governs access to storing files in a shared public storage area rather than simply handling an upload in transit, which affects how uploaded content becomes available within the platform. The Files documentation states that any authenticated user has this permission enabled, and it sits alongside other file access controls such as list, delete, and permissions on specific files.

successful count ​

Successful count is the integer field returned by the Object Records Uploads API that shows how many files in an object record upload were processed successfully when the upload has completed. It is used in the upload status and summary response alongside total files, successful percent, failed count, and failed percent, and helps developers and integrators confirm the outcome of a bulk upload, validate that the expected number of records or documents were accepted, and decide whether to retrieve completed upload files or investigate failures and error reasons for any files that did not succeed.

successful percent ​

Successful percent is the integer response field on the Object Record Uploads resource that shows the percentage of files in an upload that completed successfully. It is returned as part of the Object Records Uploads API response alongside total files, successful count, failed count, and failed percent, giving developers and integrators a quick summary of upload outcome without recalculating results from raw file data. This metric matters when monitoring bulk object record ingestion, validating integration behaviour, reporting upload health, and deciding whether to inspect the completed upload files list or error details for failed items.

super admin ​

In Autologyx, super admin is an account type within the platform’s security rules configuration that has its own authentication method setting, separate from other account types such as internal, external, and full users. It is used in the Security Rules configuration and the /api/security/ API response and update schema, where administrators define which authentication methods are permitted for super admin access using the supported enum values for authentication method, such as any, password, or sso. This matters because it allows organizations to enforce specific sign-in controls for the platform’s highest-privilege administrative accounts, ensuring that access to critical configuration and system-level capabilities follows the required authentication policy.

sync update ​

A sync update is an event type sent over the Catalyst file-upload WebSocket to report the status of a synchronisation step within the uploaded file processing workflow for Object Records. It is used alongside other event types such as progress update and monitoring update on the file upload events stream, where clients maintain a live connection to monitor backend activity after requesting upload URLs and completing uploads. This matters to developers and integrators because handling sync update events correctly allows client applications to track synchronisation stages in real time, keep user interfaces aligned with backend processing, and coordinate follow-on actions that depend on the platform completing sync-related work.

System fields ​

System fields are built-in Autologyx merge field values provided by the platform rather than defined in business data models, and they are used wherever merge fields can be inserted, including document templates and merge field rendering with custom filters. In practice, they sit alongside basic fields, relational fields, and constants as a standard supported merge field type, allowing template authors, configuration admins, and integrators to insert platform-supplied values consistently into generated content. System fields matter because they provide a reliable source of common platform context in template output and must be understood when configuring merge field behaviour, especially where rendering rules, field-type restrictions, and custom filter processing affect how merge content is resolved.

system limits API ​

The system limits API is the Autologyx platform endpoint used to retrieve configured system limit values through a GET request to /api/limits/. It is used by developers and integrators when building solutions that need to read platform limit settings programmatically, and by super admins and configuration admins who need visibility of the operational boundaries applied within an environment. In practice, it sits alongside related concepts such as limits, counts, additional limits, and API calls, providing a consistent way to inspect the thresholds that govern platform usage and behaviour. This matters because understanding current system limits helps teams design integrations correctly, avoid breaching configured thresholds, and align configuration and automation with the capacity rules enforced in Autologyx.

System merge fields ​

System merge fields are globally available merge fields in the Autologyx platform that provide system-level values independently of the current object context, so they can be used whether a workflow is processing a record, user, or another item. They are used anywhere merge fields are supported, including document templates, email templates, sequencer actors, API responses, workflow notifications, and custom scripts, and are organised into categories such as Admin Context, Client Context, Date and Time Context, Constants Context, and Loop Item Context. System merge fields matter because they let administrators, end-users, and developers insert consistent platform data such as administrator details, client information, current date and time, configured constants, and the active loop item into templates, notifications, and automation logic without needing object-specific field references.

system notifications ​

System notifications are Autologyx platform-generated messages used to communicate system events, workflow updates, and user-facing alerts, typically through configurable email content. They are used in areas where administrators manage messaging behaviour alongside email templates, and can include merge fields to insert dynamic data from the relevant process, case, or task into the notification content. For Configuration Admins and Super Admins, system notifications matter because they control how the platform informs users and stakeholders, helping ensure communications are accurate, consistent, and aligned with the underlying ALX system configuration.

systemconf ​

systemconf is the security-rules configuration object in Autologyx that stores system-level account security settings returned by and updated through the /api/security endpoint. It is used alongside password complexity and authentication method settings to define key controls such as password reuse prevention, password rotation interval, and activation link valid period. For configuration admins, super admins, and integrators, systemconf matters because it governs core password lifecycle and account activation behavior across the platform, helping enforce organisational security policy, control credential management standards, and ensure user onboarding and account administration operate within the required security parameters.

tables columns ​

Tables columns are the user-specific configuration settings that define how tabular data is presented in the Autologyx frontend, including which columns are shown and how that table layout is arranged as part of the user’s saved interface preferences. In the platform, table column settings are stored under frontend-managed user preference keys alongside related layout options such as sorting and filtering, and are accessed through the User Preferences capability, including the GET and POST /api/users/preferences/{key}/ endpoints. This matters because it enables a consistent, personalised working view for each authenticated user, allowing end-users to retain preferred table layouts across sessions and giving developers and integrators a standard way to read and persist those presentation settings.

Task assignee ​

In Autologyx, a task assignee is a user or user group assigned to work on a task alongside, or independently from, the task owner. Assignees are used within the Tasks area and Tasks API, where they are returned in task data as assignees.users and current assignees, and they directly affect the actions available on a task, such as viewing, saving, completing, taking ownership, or changing ownership. Assignee information is also important in configuration and integration scenarios because tasks can be filtered using current assignees users and current assignees user groups, including in complex filtering queries, allowing teams to route, find, and manage work accurately across users and groups.

task assignee added ​

Task assignee added is a Task event published by the Autologyx Catalyst WebSocket task events endpoint when an assignee is added to a task. It is used in the real-time task event stream alongside related events such as task assignee removed, task owner added, task status changed, task created, and task deleted, enabling connected clients and integrations to react immediately to assignment changes without polling. This event matters to developers and integrators because it supports responsive user interfaces, synchronized task views, notifications, and downstream automation that depend on knowing when responsibility for a task has been assigned to an additional user or participant.

task assignee removed ​

In the Autologyx platform, task assignee removed is a Task event emitted on the Tasks WebSocket endpoint when an existing assignee is removed from a task. It is used in the platform’s real-time task event stream alongside related events such as task assignee added, task deleted, and other task change notifications, enabling connected clients and integrations to receive assignment changes immediately without polling. This event matters to developers and integrators because it supports accurate live UI updates, synchronization of task responsibility in external systems, and event-driven logic that depends on who is currently assigned to a task.

Task assignment ​

Task assignment is an Autologyx platform configuration that uses users or user groups to determine who is assigned work on a task, making it a core part of how tasks are routed to the correct people during process execution. It is used in task and workflow configuration and interacts directly with user group definitions, which is why a user group that is referenced by Task assignment cannot be removed while that dependency exists. This matters to configuration admins and super admins because task assignment controls operational ownership and access to work, and it matters to end-users because it determines which users or groups receive and act on tasks in the platform.

task created ​

Task created is a Task event published by the Autologyx WebSocket task events endpoint (GET /ws/events/tasks/) when a new task is added in Catalyst. It is used by real time user interfaces and event-driven integrations that subscribe to task change notifications, alongside related events such as task status changes, assignee and owner updates, and task deletion. This event matters because it provides an immediate signal that a new task exists, allowing connected clients and downstream services to update task lists, trigger automation, and process the new task using the associated task identifier and event timestamp without relying on polling or manual refresh.

task creation ​

Task creation, also shown as task creation type, is a task template setting in Autologyx that defines how tasks are generated: automatic or manual. It is configured on the task template payload and returned in task template and task API responses as the task creation field, for example "manual". This setting is used when administrators design task templates and when developers integrate with the task template and task endpoints, because it controls whether tasks are created automatically by the platform from the template or are created manually as part of the process. It matters because it determines the operating model for a task, affects how and when users receive work, and should be configured alongside related template options such as complete by rules and the task type configuration.

task deleted ​

Task deleted is a Task event published by the Autologyx WebSocket Task events endpoint (GET /ws/events/tasks/) to signal that a Task has been deleted in Catalyst. It is used in the platform’s real time update mechanism alongside events such as task created, task status changed, and assignee or owner changes, enabling connected clients and integrations to identify the removal of a specific Task by its task id and process the event with its timestamp and related metadata such as Object Class ID. This event matters to developers and integrators because it allows user interfaces, downstream systems, and event driven automations to immediately remove, reconcile, or otherwise handle deleted Tasks without polling or page refreshes.

task group templates ​

Task group templates are reusable configuration objects in Autologyx that define a named set of task templates for one or more object classes, allowing related tasks to be created together in a consistent way. They are managed through the Task Group Templates configuration area and API endpoints such as /api/**task group templates**/ and /api/**task group templates**/autocomplete/, surfaced in object class relationships, role permissions, and sequence usage. A task group template includes a unique name, optional description, associated object classes, and a non-empty list of task templates, and it carries meta.permissions and label metadata in API responses. This matters because task group templates standardise how grouped work is attached to platform objects, control where those grouped tasks can be used, integrate with permissions and autocomplete-driven configuration screens, and are protected from deletion while in use by sequences.

task id ​

In the Autologyx platform, the task id is the integer identifier of a task and is used in the task events WebSocket feed as the field that identifies which task an event relates to. It appears in each item returned by the GET /ws/events/tasks/ real-time update mechanism alongside fields such as object class id, event, and timestamp, and it is present for task lifecycle and assignment events including task created, task deleted, task status changed, task assignee added or removed, and task owner added or removed. For developers and integrators, the task id matters because it provides the stable reference needed to associate incoming event messages with the correct task record in external systems, update task state accurately, and process task activity in event-driven integrations.

Task locking ​

Task owner ​

In Autologyx, the Task owner (also shown as the current owner or task ownership) is the specific user who currently holds ownership of a task and therefore has the ownership-level actions available for that task. It is used in task records and task API responses as the owner/current owner field, alongside current assignees for users and user groups, and it is exposed for filtering so tasks can be queried by current owner. Task ownership matters because it determines which task actions are available in practice, including ownership-specific actions such as take ownership, give up ownership, and change ownership, and it works alongside assignment and task permissions to control how a task progresses through next actions such as view, save, and complete.

task owner added ​

Task owner added is a Task event emitted by the Autologyx WebSocket task events endpoint (GET /ws/events/tasks/) when an owner is added to an existing task. It is used in the platform’s real time update mechanism so connected clients and integrations can detect ownership changes immediately without polling, alongside related task lifecycle and assignment events such as task owner removed, task assignee added, and task status changed. This event matters to developers and integrators because it enables interfaces, notifications, and downstream processing to stay synchronised with current task responsibility, using the event payload details such as task ID, event timestamp, and object class information, with access to the endpoint authenticated through query string parameters.

task owner removed ​

Task owner removed is a Task event published by the Autologyx WebSocket task events endpoint (GET /ws/events/tasks/) when an owner is removed from a task in Catalyst. It is used in the platform’s real-time update mechanism alongside related events such as task owner added, task assignee removed, task assignee added, task created, task deleted, and task status changed, allowing connected clients and integrations to detect and process ownership changes as they happen. This event matters because task ownership is a distinct part of task state, so applications that display task metadata, coordinate workflow responsibilities, or synchronize external systems need to handle task owner removed events using the task id and event timestamp to keep interfaces and downstream processing aligned with the current task record.

Task response ​

task response attachment ​

A task response attachment, also called a response attachment, is a file that has been submitted as part of a task’s response in the Autologyx platform and is exposed through the Files API for retrieval. It is used when a task outcome includes an uploaded document or other file that must be accessed programmatically, specifically through the endpoint for downloading files from task response attachments. This matters to developers and integrators because access to the file is governed by the permissions associated with the related task and file, so integrations must call a compatible file endpoint and ensure the requesting user or service has the required rights to download the specific attachment.

task stages ​

Task stages are the ordered stage records within an Autologyx task that represent how the task is structured and assigned as it progresses. In the platform, stages are returned in the task resource as the stages array and are also configured in sequence defaults, where each stage can define settings such as assignees, aligning task stages closely with default assignees, current assignees, task group templates, and approval configuration. Task stages matter because they control who owns work at each point in the task lifecycle, support multi-step task design and routing, and provide the framework for applying approval requirements and other stage-specific behavior when developers or configuration admins build and manage task-driven processes.

Task status ​

Task status is the enumerated lifecycle value on an Autologyx task that shows where the task is in its execution flow, such as created, not started, in progress, or completed. In the platform it is exposed on task records and task API responses as the status field, can be used for ordering and standard-set filtering in the Tasks endpoints, and is closely related to response state and next actions because the current status determines what users can do with the task and how it is presented in worklists and integrations. Task status matters to end-users for understanding whether work is pending or finished, to configuration admins for designing task-driven processes and ownership behaviour, and to developers and integrators for querying, filtering, and synchronising task progress consistently with Autologyx API standards.

task status changed ​

In the Autologyx platform, task status changed is a Task event published on the WebSocket task events endpoint (GET /ws/events/tasks/) when a task’s status is updated. It is used by connected clients, custom front ends, and integrations that subscribe to real time Task events so they can immediately detect workflow progress changes without polling or refreshing the page. This event matters because task status is a core indicator of where work is in its lifecycle, enabling interfaces to stay synchronised with live process activity and allowing event-driven integrations to trigger downstream actions whenever a task moves from one status to another.

task template form ​

Task Template permissions ​

Task Template usage ​

Task Template usage is the usage view for a specific Task Template, exposed through the Task Templates API at /api/task templates/{id}/usage/. In the Autologyx platform, it is used by configuration administrators, developers and super admins to see how a template is being consumed after it has been configured, including operational details such as the number of tasks created from the template, the last task created, and related metadata such as permissions and object class context. This matters because it helps administrators and integrators assess the impact of template changes, verify whether a template is active in live processes, support governance and cleanup decisions, and confirm that the correct access and object class settings are in place for ongoing task generation.

task templates ​

Task templates are reusable task definitions in the Autologyx platform that store the configuration for creating tasks, including the task type, plugin configuration, completion settings, reminders, renewals, expiry rules, and task creation behaviour. They are used in task template management through the Task Templates API, referenced by task group templates, and selected when creating tasks directly so the resulting task inherits a copy of the template configuration for a specific object record and object class. Task templates also integrate with object classes and object class fields, appear in autocomplete and usage relationships, and are controlled through dedicated role permissions and meta.permissions. They matter because they standardise how work is generated, enforce compatibility with the relevant object class, support repeatable and scalable task creation, and give configuration administrators and integrators a central way to manage task behaviour across the platform.

Show 1 more pages

Task Templates API ​

The Task Templates API is the Autologyx REST interface for creating, updating, validating, listing, and checking permissions for Task Template records through endpoints such as /api/task templates/. It is used by developers and configuration administrators when defining reusable task blueprints that control how tasks are generated and managed, including core settings such as name, description, plugin config, complete by rules, expiry rules, reminders, renewals, task creation behaviour, task type configuration, and approval conditions. The API also exposes validation metadata through OPTIONS and supports permission checks aligned with Task Template object class permissions and meta.permissions. This API matters because Task Templates standardise task behaviour across workflows, enabling consistent task setup, controlled automation, and maintainable integrations when configuring operational processes in the Autologyx platform.

Task Templates autocomplete ​

Task Templates autocomplete is the Autologyx API endpoint at /api/task templates/autocomplete/ that returns Task Template records filtered by query parameters for use in autocomplete widgets. It is used where the platform needs to present searchable Task Template suggestions in configuration or integration workflows, rather than requiring users to browse full lists manually. For developers and configuration admins, this endpoint matters because it supports responsive task-template selection in forms and custom interfaces, helps connect UI components to the platform’s Task Templates resource, and ensures users can quickly find and select the correct template when building or maintaining automated processes.

Task Templates JSON schema for OPTIONS request ​

task type ​

In Autologyx, task type is the task classification value used to identify what kind of task a task record represents and to control how that task is handled through the platform and API. It is used on the Tasks API as a standard set filter parameter, for example when querying /api/tasks/?**task type**=..., and it also appears in task configuration and plugin metadata where a task’s behaviour is defined, such as form or object record update tasks. Task type matters because it lets developers and configuration administrators reliably select, validate, and work with the correct subset of tasks, apply task-type-specific endpoints and logic, and avoid invalid requests where an operation is only supported for a particular task type.

task value changed ​

In the Autologyx platform, task value changed is a Task event emitted on the Catalyst WebSocket Tasks endpoint (GET /ws/events/tasks/) when the data values of an existing task are updated. It is part of the platform’s real-time update mechanism alongside events such as task created, task deleted, and task ownership or assignee changes, and is consumed by connected clients and integrations using query string parameter authentication. This event matters because it allows developers and integrators to detect and respond immediately to task data changes, keeping user interfaces, downstream systems, and event-driven processes synchronized without polling or page refreshes.

TaskContext ​

TaskContext is a merge-field context in the Autologyx platform that exposes task-specific information and metadata for the current record being processed. It is part of the record-related context set used when evaluating merge fields and is available in both the Sequencer Actor and Document Generation scopes, alongside contexts such as ObjectRecordContext and DocumentContext. TaskContext matters to configuration administrators and developers because it provides access to workflow task data within templates, generated documents, and sequence-driven processing, allowing configurations and integrations to use current task details consistently wherever those scopes are supported.

tasks ​

Tasks are workflow work items associated with an Object Record in Autologyx and are used wherever task-level operations, permissions, and template output need to identify or act on those items. In configuration and administration, tasks are a distinct resource in Object Records Permission Sets with their own supported actions—create, edit, view, delete, complete, and assign—which makes them central to controlling what users and integrations can do at the task level. In templating and merge fields, the Tasks value returns a list of task IDs ordered by ID descending, enabling documents, notifications, and integrations to reference the newest related tasks first. Tasks matter because they provide the operational layer of work on a record, and their IDs, permissions, and access rules are key to automation, filtering, and ID-based access patterns across the platform.

Tasks events ​

Task events are the real-time change notifications exposed by the Autologyx WebSocket endpoint GET /ws/events/tasks/, used by developers and integrators to monitor lifecycle and assignment updates for Task records in Catalyst. This event stream is used when building integrations, live user interfaces, or automation that must react immediately to task changes such as task created, task deleted, task assignee added or removed, and task owner added or removed. Clients connect to the endpoint using query string parameter authentication and consume event payloads that identify the affected task and related metadata, including values such as the task ID, event timestamp, and Object Class ID. Task events matter because they provide a push-based alternative to polling, enabling connected systems to stay synchronised with current task state and respond to changes as they happen.

tasks resource ​

In Autologyx, the tasks resource is the permission-controlled resource used in object class permission sets to govern what users can do with task items generated and managed within the platform. It is configured by administrators alongside other available resources such as object classes and object records, and supports the actions create, edit, view, delete, complete, and assign. This resource matters because it determines whether users and roles can work with tasks operationally, including creating new tasks, updating task details, completing work, and reassigning ownership, making it a core part of access control design for task-driven processes.

temp upload id ​

A temp upload id is a temporary client-side identifier included in file upload requests and echoed in the corresponding WebSocket file event response so the frontend can match an upload session response to the originating request. In Autologyx, it is used alongside the backend-generated upload id and presigned URL details returned during file upload workflows, particularly where uploads are initiated asynchronously and multiple requests can be in flight at the same time. This value matters to developers and integrators because it provides a reliable correlation key for request-response mapping in the client application, helping the UI or integration track the correct upload session before the platform’s internal upload id is used for subsequent processing.

template file ​

In Autologyx, a template file is the uploaded Microsoft Word .docx file that defines the content and structure of an Object Class Document Template. It is supplied as a file token when creating or updating a document template, stored as the template file for that template record, and exposed in API responses with file metadata such as name, URL, size, and type. Template files are used wherever document templates are configured for an object class and are validated to ensure the file is a single .docx document with correct Jinja template syntax and valid merge tags for related and class fields. This matters because the template file is the source document used for document generation and download workflows, so its format and field mappings directly determine whether generated documents can be parsed correctly and populated with the expected Autologyx data.

Templates panel ​

The Templates panel is the area of the Autologyx platform where document templates are managed and used for standard document generation workflows. It is used when configuring templates that contain merge fields, including scenarios that apply custom filters, render values into documents, and support embedded content such as images through document automation features. For configuration admins, the Templates panel is where template behaviour is set up so generated documents produce the correct output; for end-users, it is the source of the templates that drive consistent document creation in running processes. This matters because correct use of the Templates panel ensures document templates, merge field rendering, and related automation features work together reliably across the platform.

temporary file ​

A temporary file in the Autologyx platform is a file created by the POST /api/files/upload/ endpoint for short-term use elsewhere in the ALX system. It is used primarily by developers and integrators when an API workflow needs to upload a file first and then reference that uploaded content in a later action through the platform’s file handling mechanisms, such as a file token or a specific file reference supported by a compatible endpoint. This matters because temporary files provide the standard way to introduce external file content into Autologyx-driven processes, enabling integrations to pass documents and attachments between API calls in a controlled, platform-supported format.

tenant db ​

In the Autologyx platform, the tenant db (tenant database) is the client-specific ClickHouse database used by the Event History API microservice to store and retrieve history data for a particular client instance. It is used alongside a tenant entry held in the default ClickHouse database, which maps the client identity supplied in requests to the correct history database; this mapping is created during client setup in the main Autologyx system and managed through the tenant administration endpoints such as POST /api/initialize tenant and DELETE /api/delete tenant. The tenant db matters to developers, configuration admins, and Super Admins because correct tenant records, client identifiers, database names, and authentication details are required for the service to connect to the right database and serve event history successfully, while mismatches result in connection failures such as the returned error indicating that the client from the request header does not match any configured tenant.

tenant table ​

In the Autologyx Event History architecture, the tenant table is the table in the default ClickHouse database that stores tenant records linking each client environment in the main Autologyx system to its dedicated client history database. It is used by the Event History API microservice when a client is created and whenever historical activity must be written to or read from the correct ClickHouse database. This mapping matters because it provides the lookup needed to resolve the right history database for each tenant, ensuring event data is stored, queried, and governed against the correct client-specific history store.

Tenants ​

In Autologyx, a tenant is the identifier for a client instance used by platform services to resolve and isolate client-specific data and requests. It is used in the API History Event microservice, where a tenant entry in the default ClickHouse database maps requests to the correct client history database, and requests are identified through client headers; if the tenant cannot be matched, the service returns tenant-related errors such as tenant not found or client from header does not match any tenant. The term is also used in configuration for authentication providers, including Microsoft Client Credentials, where tenant is a required credential field. Tenants matter because they are the mechanism that connects inbound API requests and integration credentials to the correct client environment, ensuring the platform reads, writes, and secures data in the right client context.

Test button ​

The Test button is a platform action used in configuration and integration workflows to run an immediate synchronous validation of configured content, such as merge-field expressions or document template output, before that configuration is deployed into live sequences or automation. In Autologyx, it is used wherever administrators or developers need to verify that dynamic syntax resolves correctly and to see API response errors instantly during setup, rather than discovering failures later at runtime. This matters because it provides a fast, controlled way to confirm that templates and related API-driven configurations are valid, helping users identify syntax issues early, reduce deployment errors, and improve the reliability of automated document and workflow behaviour.

token url ​

In Autologyx, the token url is the required URL field in certain authentication objects that tells the platform which OAuth token endpoint to call when obtaining an access token for an external service. It is used when configuring generic client credentials and ROPC generic OAuth providers, alongside related settings such as client id, client secret, scope, refresh url, additional parameters, and additional authorization headers. This field matters because it defines the exact authorization server endpoint Autologyx uses to authenticate outbound integrations; if it is missing, null, too long, or not a valid URL, the authentication object is rejected and the integration cannot obtain tokens to connect successfully.

top parents limit ​

Top parents limit is the maximum number of root-level parent object classes that an Object Model Definition in Autologyx can contain. It is enforced when creating or updating Object Models through the platform and API, where exceeding the allowed number returns the validation error top parents exceeded, shown as "Limit of "limit" top parents exceeded." This limit controls how many object classes can exist without a parent in the model hierarchy, alongside related constraints such as children limit, relation depth limit, and multiplicity. It matters because it defines the permitted structure of the relational model, helps keep object hierarchies valid and manageable, and must be considered by configuration admins and integrators when designing object class relationships or submitting Object Model payloads.

total count ​

Total count is the integer value returned in Object Records Permission Sets responses that shows the full number of results the current user can see after Autologyx applies permission-based visibility rules. It is used alongside pagination fields such as limit and offset when listing Object Records Permission Sets, so developers, configuration admins, and Super Admins can understand the complete size of a result set rather than just the number of items returned on the current page. This matters when building integrations, configuring access, or validating platform behaviour, because total count confirms how many records are visible to the user under the active permissions and supports accurate paging, reporting, and access-control checks.

transaction creator ​

INSUFFICIENT_EVIDENCE

tt object record update ​

tt object record update is the internal task type used in Autologyx for tasks that capture and apply updates to an object record through a defined set of class fields. It is used in task configurations and task API payloads, where the task’s plugin config identifies the target object class and the specific object class fields that users can view, save, and complete as part of the task response. This matters to configuration admins and developers because it determines that the task is tied to object class data rather than a generic form, controls which fields are exposed for update, and governs the task-specific endpoints and validation rules used when retrieving class fields, uploading files, saving progress, and completing the task.

UI component ​

A UI component in the Autologyx platform is a uniquely named user interface element whose behaviour and content are defined through a UI Config and managed through the UI Config API. It is used when configuring the presentation layer of the platform, where administrators and developers create or update configuration for a specific component name, associate custom components, and supply the payload that determines what the component renders. Component names are stored in lowercase and must follow platform naming rules, making them a stable reference for configuration and integration. UI components matter because they are the unit through which UI customisation is organised, updated, and overridden, enabling controlled delivery of custom interfaces, upload-related elements, and themed user experiences across the platform.

UI Config ​

UI Config is the Autologyx configuration object used to define how a UI component is set up and rendered in the platform, and it is managed through the UI Config API. It is used by developers, integrators, and configuration administrators when creating or updating component-specific interface behaviour, including associating custom components and configuring upload components against object classes and document type fields. UI Config matters because it controls the runtime setup for reusable user interface elements, ensures the correct component content is applied for a given component identifier, and provides a governed way to maintain consistent, valid UI behaviour across implementations through API validation, permissions, and uniqueness rules.

UI Config API ​

The UI Config API is the Autologyx platform interface used to define, retrieve, and apply configuration for UI components. It is used wherever UI Config is managed for platform user interfaces, including standard and custom components such as upload components and public theme elements. For developers, integrators, and configuration administrators, the UI Config API is important because it provides the controlled mechanism for setting up how components behave and are presented, supporting consistent interface configuration, reusable component setup, and maintainable customization across the platform.

UI configurations ​

UI configurations are configurable user interface definitions in the Autologyx platform, used to control or extend how application screens and components are presented. They are managed by configuration-focused roles such as Configuration Admins and Super Admins, and are relevant when working with custom components and other platform configuration features. In platform limits documentation, UI configurations are counted as a governed resource, with the ui configs limit defining the maximum number of UI configurations permitted in an environment. This matters because the available limit affects how much interface customization can be created and maintained within a tenant.

unassign roles ​

Unassign roles is the user-management API operation that removes one or more roles from an existing Autologyx user account. It is used through the PATCH /api/users/{pk}/**unassign roles**/ endpoint as a batch action, allowing developers, configuration admins, and super admins to revoke previously assigned role memberships from a target user. This operation is relevant when maintaining access models, correcting user setup, or updating administrative responsibilities, and it works within the platform’s account and permission rules, including restrictions on which account types can hold roles and whether the caller has sufficient permission to perform the change.

Unauthorized API Key ​

Unauthorized Client ​

Unauthorized Client is an Event History API error returned when a request does not include the required client id header, so the service cannot identify which Autologyx tenant and history database the request belongs to. It is encountered on Event History microservice endpoints such as tenant and file-related operations, where requests must be associated with the correct client instance before data can be uploaded, recorded, or queried. This matters to developers, integrators, and configuration administrators because the client id is part of how Autologyx routes requests to the correct tenant context; if it is missing, the API rejects the call with a 400 Bad Request response and the detail message "Unauthorized Client."

upload complete ​

In the Autologyx platform, upload complete is a file-upload WebSocket event used in Catalyst object record upload workflows to tell the backend that a client has finished sending file data and that the upload can move to the next processing stage. It is used on the files WebSocket endpoint alongside related actions such as requesting presigned upload URLs and receiving progress updates, and it typically follows the client’s use of presigned URLs or multipart upload steps. This event matters to developers and integrators because it is the handoff point between storage upload and platform-side processing, ensuring Autologyx can validate, monitor, and continue handling the uploaded file within the wider object record workflow.

upload components ​

Upload components are UI configuration entries that connect a document-type object class field to an upload component identifier within the Autologyx platform. They are configured in UI Config, where each entry specifies the upload component value together with the object class and the object class field, and the selected field must belong to the specified object class and be of type document. Upload components are also referenced in Object Classes responses through counts such as num of upload components, showing where an object class is used by upload-related configuration. This matters to configuration admins and integrators because upload components control how document upload functionality is attached to business objects in the user interface, enforce valid mapping to the correct document fields, and help govern reuse and impact when object classes or fields are changed.

upload id ​

In the Autologyx platform, an upload id is the backend-generated UUID that uniquely identifies an upload session for a document upload operation. It is returned when an object record upload is created and is then used by clients and integrations to track that upload through subsequent steps, including notifying the platform that a single-part upload has completed, correlating WebSocket progress events, retrieving upload status and summary information, and requesting the list of completed upload files for that session. The upload id matters because it is the primary handle the platform uses to associate uploaded content, processing progress, finalization actions, and resulting files with the correct object class and document field, making it essential for implementing reliable upload workflows and API integrations.

upload process ​

In Autologyx, an upload process is the server-side process representing a file upload operation for an object record, exposed through the WebSocket endpoint GET /ws/object records/uploads/{id}/ so a client can connect to and monitor that specific upload. It is used during file-transfer workflows that involve requesting presigned URLs, uploading one or more file parts, completing multipart upload, and receiving progress updates tied to the upload’s S3 key and lifecycle. This matters to developers and integrators because the upload process provides the coordination point for tracking upload state in real time, keeping user interfaces synchronized with long-running or multipart transfers, and ensuring uploaded files are correctly associated with the intended Autologyx record.

upload session ​

An upload session is the backend-tracked lifecycle for a file upload into Autologyx, identified by an upload id returned when the platform generates a presigned URL and used to correlate the client upload, completion notification, progress events, and final processing outcome. It is used in the Object Record Uploads API, where users and integrators can retrieve a list of their upload sessions, and in the file upload WebSocket flow, where the upload id is sent when notifying the backend that a single-part upload has completed and is included in progress messages for processing steps. Upload sessions matter because they provide the operational record for managing uploads end to end, linking uploaded files to downstream actions such as extracting files, creating completed upload files, assigning document field names and document types, adding records, and reporting failures through counts and error reasons.

upload summary ​

In the Autologyx platform, an upload summary is the single-resource response returned by the Object Records Uploads API summary endpoint for a specific object record upload, providing the key outcome details for that upload operation in one place. It is used by developers and integrators when calling the GET /api/object records/uploads/{id}/summary/ endpoint to review the result of a completed upload, including operational fields such as failed count, failed percent, completed upload files, and error reason, together with standard API metadata such as meta.permissions where applicable. This matters because it gives a concise, structured view of upload processing status and exceptions, enabling integrations, monitoring, and post-upload handling logic to detect failures, report outcomes, and drive remediation workflows without retrieving the full upload record set.

uploaded file token ​

An uploaded file token, also described as a file token or Temporary File token, is the string identifier Autologyx uses to reference a file that has been uploaded and is available for immediate use in API operations without first being stored as a permanent object-linked document file. It is used in document template endpoints such as creating or updating an Object Class Document Template and in template validation workflows, where the template file field accepts the token as the file input. This matters to configuration administrators and developers because the token is the required mechanism for passing uploaded .docx template content into Autologyx for validation, merge-tag checking, and template creation, and an invalid token causes the request to fail with an Invalid token error.

url key ​

In Autologyx, a url key is a string field in an Authentication Object for the API key provider that defines the parameter name used to send the API key in the request URL rather than in a header. It is configured alongside related API key credentials such as header key and api key when setting up external service authentication, and is primarily used by configuration admins and integrators who need to match the exact authorization pattern required by a target system. This matters because Autologyx uses the configured key name to place the credential in the correct part of outbound requests, ensuring integrations authenticate successfully with services that expect API keys as URL query parameters.

usage endpoint ​

The usage endpoint is a read-only Autologyx API route exposed on supported resources such as Task Group Templates and User Groups to show where that resource is currently referenced elsewhere in the platform. It is used through endpoints such as /api/task group templates/{id}/usage/ and /api/user groups/{id}/usage/, and returns usage-specific data that helps administrators and integrators understand platform dependencies before making changes. For Task Group Templates, the endpoint returns sequence usage details, including the number of sequences and a list of sequence IDs and names; for User Groups, it is used to identify whether the group is in use by Sequences, permission sets, object class fields, task assignment, and other configuration elements. This matters because it supports safe configuration management, impact analysis, and troubleshooting by revealing downstream references that can block deletion, affect permissions, or change runtime behaviour across the platform.

user assignees ​

User assignees are the Autologyx users assigned to an Object Record permission set, defining which individual users receive the access granted by that permission set for a specific Object Record. They are managed through the assignees/users endpoint under an Object Record and permission set, where administrators and integrators can list current assignees, add new user assignees, and remove them in batch. This matters because user assignees are the direct mechanism for applying Object Record permissions to named users, enabling controlled access to record-level capabilities within the platform. When configuring or integrating this area, it is important to account for platform rules such as permission checks, valid Object Record and permission set identifiers, batch delete requirements, and the limit of 100 permission set assignees.

user group assignees ​

User group assignees are the user groups assigned to a specific permission set on an Object Class or Object Record in Autologyx, defining which grouped users receive that permission set for the target object. They are used in configuration and integration workflows through the Object Class and Object Record permission set assignee endpoints, where administrators or services can add, list, and remove user-group assignments for a given Object Class ID or Object Record ID and Permission Set ID. This matters because user group assignees provide a scalable way to grant access and operational permissions to multiple users at once, simplify permission administration, and support consistent access control across object classes and individual records, subject to platform validation such as permission checks and assignee limits.

user group ids ​

User group ids are the identifiers for the user groups that you include when assigning group-based access to an Object Record Permission Set in Autologyx. They are used in the request body of the Object Record Permission Set user group assignees endpoint, alongside the object record id and permission set id supplied in the URL, to specify exactly which user groups are being assigned as assignees for that permission set on that object record. This matters because the list of user group ids is the mechanism that connects permission configuration to real user group memberships, allowing configuration admins, super admins, and integrators to manage access consistently and at scale without assigning permissions user by user.

user group members ​

User group members is the platform limit that defines the maximum number of users that can belong to a user group in Autologyx. This value is used in platform configuration and limits management, where Configuration admins and Super Admins need to understand how many members can be assigned to a group when setting up access structures, permission-related group assignments, and default Task assignee groups. It matters because user groups are used to organise users for administration and assignment purposes, and this limit determines the maximum size of each group within the tenant’s configured platform capacity.

User group objects ​

User group objects are the structured group records returned by Autologyx object-based access merge fields when a field is configured to expose groups rather than only IDs, and they provide full group data for use in templates, sequencer actors, related record merge fields, and other merge-field-enabled contexts. Each user group object includes the group ID, group name, member count, and a members collection that can be accessed directly to retrieve the underlying user objects and their properties. This matters to configuration admins and developers because user group objects enable dynamic document generation, routing, notifications, and logic that depend on group attributes or iterating through group members, rather than relying on simpler ID-based access that exposes only identifiers.

user group owners ​

User group owners are users designated within a User Group’s permission model who receive owner-level access through User Group permission sets. In Autologyx, this concept is used when configuring and checking permissions for specific User Groups, including permissions such as viewing the group access list and owner-specific edit capabilities defined in User Group Permission Sets alongside special sets such as MEMBERS and EVERYONE. This matters to Configuration Admins and Super Admins because user group owners determine who can administer access and permissions for a group, and the platform also enforces a configured limit on the number of user group owners, which is tracked in system limits and can trigger limit-related errors such as ERR LIMIT EXCEEDED if exceeded.

user group permission sets ​

User group permission sets are permission set definitions configured at the individual user group level in Autologyx to control access and assignment behavior for that specific group. They are managed through the User Group Permission Sets API endpoints, with related assignee endpoints used to add one or more users to a given permission set for a user group, and they are also surfaced in user group usage information when a group is referenced by permission sets. This matters because configuration admins, super admins, and integrators use user group permission sets to structure group-specific access models, enforce reserved and custom permission set types correctly, and stay within platform limits for the number of permission sets allowed per group.

user groups ​

User groups are a platform object in Autologyx that define named collections of users, with their own attributes such as name, description, members, and owners, and are managed through the User Groups API and related administration features. They are used anywhere access, assignment, or selection needs to be applied to a set of users rather than to individuals, including object class permission set assignees, task assignee configuration, object record user-type fields, and response schemas or history events that return user group objects in nested structures. User groups matter because they provide a scalable way to manage permissions and assignments across the platform, reduce repetitive per-user configuration, and are subject to platform limits and permission controls that administrators and integrators must account for when configuring object classes, building API integrations, or designing access models.

Show 3 more pages

User Groups API ​

The User Groups API (also called the User Group API) is the Autologyx API interface for creating and managing user groups, which are used to organise platform users for administration and configuration purposes. It is used by developers, integrators, configuration admins, and Super Admins when integrating with Autologyx or automating platform setup, and follows standard Autologyx API call patterns, including endpoints such as POST /api/user groups/ to create a user group. This API matters because user groups underpin group membership and ownership structures in the platform, including values such as number of members and number of owners, enabling consistent control of how users are grouped and administered across Autologyx.

user groups resource ​

The user groups resource is the permissions resource in Autologyx that controls what actions can be granted against User Groups, with supported actions of view, edit, and delete. It is used when creating and managing User Group Permission Sets for a specific User Group through configuration interfaces and the corresponding permission set APIs, where permissions for the user groups resource are defined, validated, and expanded with any required permission dependencies. This resource matters because it determines who can access the User Group list, who can manage user-group-related configuration, and how ownership and special permission sets such as system-created sets are enforced, making it a core element for Configuration admins and Super Admins who need to govern access to User Groups safely and consistently.

user groups.edit perm set ​

**user groups.edit perm set** is the permission that controls whether a user can edit permission sets for a specific User Group in the Autologyx platform. It is used within the User Group Permission Sets model, where permissions are evaluated in the context of an individual User Group, and the documentation identifies it as a permission that is not manageable through Roles and is instead associated with the User Group owner. This permission matters because it governs who can change the access rules that apply to a group’s special and custom permission sets, making it a key control for delegated administration, ownership-based management, and the protection of group-level security configuration.

user groups.list permission ​

The "user groups.list" permission is the access control that allows a user or integration to view and reference specific User Groups in Autologyx when working with group-based assignment and permission set configuration. It is used wherever User Group records must be resolved from IDs, particularly in the User Group Permission Set assignees workflow and related assignees/user groups API operations. This permission matters because Autologyx validates not only that a supplied User Group exists, but also that the requesting user is allowed to list that group; without it, assignment requests that include those group IDs are rejected with a permission error. For configuration admins, super admins, and developers, this permission is essential for successfully configuring permission set assignees, integrating with User Group endpoints, and ensuring that only authorised groups can be selected or assigned.

user groups.view ​

In Autologyx, **user groups.view** is the permission that grants access to the user group list, allowing administrators and other authorised users to see available User Groups in the platform. It is defined within User Group Permission Sets and is manageable through Roles, with ownership control also supported through User Group permission sets. This permission is used when configuring access to User Group administration and visibility, and it matters because it separates the ability to view User Groups from higher-level change permissions, helping Configuration Admins and Super Admins control who can discover and navigate group structures without automatically granting edit access.

User Preferences ​

User Preferences are per-user settings stored by Autologyx to preserve an authenticated user’s frontend application layout and related interface configuration. They are used through the user preferences API endpoints, including POST /api/users/preferences/{key}/ to create or overwrite a named preference value and GET /api/users/preferences/{key}/ to retrieve it, with each preference identified by a key and stored as a string value. This matters because it enables the platform to maintain a consistent personalised user experience across sessions while giving developers and configuration administrators a defined mechanism for saving and reading user-specific UI state. User Preferences are also governed by platform limits, including limits on the number of preferences per user, key length, and value size, which are important when designing integrations or configuring features that persist user interface settings.

user type ​

User type is an Autologyx API object type that represents a system user as a structured, nested schema rather than a simple scalar value. It is used in platform request and response models wherever user information is exchanged as part of a resource, alongside other complex types such as owners, permissions, and user groups, and is defined in the API standards as a complex object of system user attributes. This matters to developers, integrators, configuration admins, and Super Admins because the user type determines the expected shape of user data in API payloads and responses, supports predictable validation and error handling, and ensures user-related fields are handled consistently when configuring permissions, ownership, and other user-referenced platform behaviour.

User type fields ​

User type fields are Object Record fields that store references to Autologyx users, user groups, or both, depending on how the field is configured. They are used in object data, object record API requests and responses, history events, and merge fields, where they return structured user and group objects rather than simple text values. In API payloads, user type fields are passed as an object containing users and/or user groups arrays of integer IDs, with validation enforcing allowed entity types and configured limits; in record responses, Autologyx also includes related user and user group objects for the first 50 unique referenced items from user type fields. These fields matter because they drive assignment-style data and participant relationships within records, support dynamic document and sequencer content through merge fields, and require correct configuration and payload structure for integrations to read, write, and audit user-linked record data reliably.

UserContext ​

UserContext is a merge-field context in the Autologyx platform that provides information about the current user and that user’s relationship to the record being processed. It is part of the record-related context set and is available in both Sequencer Actor and Document Generation scopes, allowing workflows, templates, and generated documents to access user-specific data alongside record and document context. UserContext matters because it enables administrators and integrators to design automations and document outputs that reflect the active user’s details consistently within supported scopes, making it an important component when configuring merge fields, context-aware content, and user-driven processing behaviour.

UserFieldContext ​

UserFieldContext is a merge-field context in the Autologyx platform that exposes the values of user-defined fields for the current record being processed. It is used wherever merge-field contexts are available for record-related data, specifically in both Sequencer Actor and Document Generation scopes, alongside related contexts such as ObjectRecordContext, UserFieldMetaContext, TaskContext, and UserContext. For configuration admins and developers, UserFieldContext matters because it provides direct access to custom field data captured against a record, enabling templates, workflow steps, and generated documents to reference organisation-specific information consistently without hard-coding record schema details into each implementation.

UserFieldMetaContext ​

UserFieldMetaContext is the merge-field context in Autologyx that exposes metadata for user-defined fields associated with the current record. It is used wherever record-related merge-field contexts are available, including Sequencer Actor and Document Generation scopes, alongside ObjectRecordContext, UserFieldContext, TaskContext, UserContext, and DocumentContext. This context is important when configuring templates, automations, or integrations that need information about the structure or definition of custom fields rather than their values, helping administrators and developers build record-aware outputs and logic that correctly reference and handle user-defined field configuration.

users combined autocomplete ​

Users combined autocomplete is a deprecated Autologyx API endpoint (GET /api/user groups/autocomplete/users combined/) that returns a single autocomplete result set containing both individual users and user groups for selector controls that support mixed membership targets. It is used in developer-built or configured experiences where a field such as task assignment, participant selection, or membership configuration needs to search and display people and groups together through a standard autocomplete interface, with support for ALX API-style ordering and filtering such as text sorting and user field search criteria. This endpoint matters because it standardises how mixed user and group options are retrieved and rendered in integrations and configuration work, but it is no longer supported from version 11.0.0, so implementations must be updated to use supported alternatives when maintaining or upgrading the platform.

Users Group Assignees ​

Users Group Assignees are the user accounts explicitly assigned to a specific permission set within a User Group in the Autologyx platform. They are managed through the user-group permission-set assignees API endpoint, which supports batch creation of one or more assignee records for a given Users Group ID and Permission Set ID, and is primarily used by configuration administrators, Super Admins, and integrations that automate access setup. This concept matters because it determines which individual users receive the permissions defined by that user group permission set, separate from broader permission-set types such as everyone or members, which do not support assignee lists. When configuring or integrating this feature, administrators must use valid user IDs, avoid unsupported account types such as 1 Time Completion accounts, and stay within platform limits, including request-size and maximum-assignee constraints enforced by the API.

Users Group ID ​

Users Group ID is the unique identifier for a user group in the Autologyx platform and is used as the group id URL parameter in user-group permission set and assignee API endpoints. It identifies the specific user group whose permission set assignments or assignee lists are being created, updated, or retrieved, alongside a Permission Set ID. This value is used in operations such as assigning users to a user group permission set and listing assignees for that permission set, making it essential for developers, configuration admins, and Super Admins when integrating with the assignees/user groups endpoint or administering user group access. Using the correct Users Group ID ensures changes are applied to the intended group and supports accurate management of user group permission sets within Autologyx.

users group permission set assignees user groups ​

In the Autologyx platform, users group permission set assignees user groups is a configuration limit that defines the maximum number of user groups that can be assigned as assignees within a permission set for a single user group. This limit is used in platform and tenancy configuration, particularly by Configuration Admins and Super Admins managing access models and assignment rules for groups of users. It matters because it constrains how broadly assignee groups can be attached to a permission set, helping administrators design permission structures that stay within supported platform limits and avoid configuration issues when setting up or scaling group-based access and task assignment behaviour.

users group permission set assignees users ​

In the Autologyx platform, users group permission set assignees users is a configuration limit that defines the maximum number of individual users who can be assigned as assignees within a single permission set for each user group. It is used in platform limits and is most relevant to configuration administrators and Super Admins when designing or maintaining permission models that control task assignment behaviour. This limit matters because it constrains how many named users can be attached to a permission set in the context of a user group, which directly affects how assignment structures are configured, how scalable those structures are, and whether a planned setup fits within supported platform boundaries.

users search in ​

**users search in** is an API query parameter used in Autologyx user and user-group autocomplete endpoints to control which user fields are searched when filtering the returned users. It is configured by passing one or more **users search in** values, each naming an allowed field, and Autologyx combines multiple uses of the parameter with an OR operator so a search term can match across different user attributes such as username or a composed name field. This parameter is used when building integrations, autocomplete widgets, and assignment or membership selection experiences that need to find users efficiently through the ALX API. It matters because it defines the search scope and behaviour of user lookups, helping configuration admins and developers deliver accurate user selection while avoiding invalid field names that result in a 400 Bad Request response.

users.list permission ​

The "users.list" permission in Autologyx is the user-visibility permission that allows a requesting user to reference specific platform users when assigning ownership or permission set access. It is enforced in configuration and API operations for Object Class Owners, Object Record Owners, and Object Class and Object Record Permission Set assignees, where the platform validates whether the acting user is allowed to list and therefore select the target user account. This permission matters because assignment actions can fail even when the object, record, or permission set itself is valid: without "users.list" access to the intended user, Autologyx rejects the request and prevents that user from being added as an owner or assignee. For Configuration admins, Super Admins, and integrators, this means user-listing access must be included in the acting account’s permissions whenever workflows or API integrations need to assign users by user ID.

UsersGroupContext ​

UsersGroupContext is a merge-field context type in the Autologyx platform that exposes user group information and permissions relevant to the current record. It is part of the record-related context set used alongside ObjectRecordContext, UserContext, UserFieldContext, and DocumentContext, and it is available in both Sequencer Actor and Document Generation scopes. This context matters when configuring templates, automations, or integrations that need to reference group-based access or role information connected to a record, because it allows administrators and developers to use consistent group and permission data across workflow execution and document output.

Variable Actor ​

Variable Actor, also referred to in some documentation as Local Variable Actor, is an Autologyx actor used within workflows to create, store, and transform local variable values that can be referenced later in the same process. It is used anywhere administrators or developers need dynamic data handling inside a workflow, and it supports merge fields and the same custom filters available in other merge-field-enabled features such as the API Call Actor, Send Message Actor, and AI Actors. This matters because it allows workflow designers to prepare and manipulate data in-platform before passing it to downstream steps, helping ensure values are in the correct format for messages, integrations, AI operations, and document generation.

Variable source ​

In Autologyx, a Variable source is a Loop actor source type that iterates over an array held in a workflow variable, making each array element available as the current loop item for actors executed downstream of the loop. It is used when configuring sequenced or repeated processing that should run once for each item already stored in platform data, rather than pulling items directly from an API call or a dedicated array source. Variable source matters because it determines the structure and content exposed through merge fields inside the loop, including support for nested properties on each item, which is essential when configuring downstream actors such as API Call actors to read, map, and process item-level data correctly.

VariableContext ​

VariableContext is the Autologyx context type that exposes dynamic workflow variables and other runtime data during sequence execution. It is used in merge-field and expression resolution within the Sequencer Actor scope, where workflows need access to values created, updated, or carried through the running process. VariableContext is not available in the Document Generation scope, so it should be used for workflow-time logic rather than document-only processing. This matters to configuration administrators and developers because it defines where dynamic variables can be referenced, how runtime data is made available to automations, and which context scope must be selected when designing solutions that depend on workflow-generated values.

VariableDocumentContext ​

VariableDocumentContext is the Autologyx context type that exposes a document’s merge-field data as structured properties, including the document ID, file name, file size, download URL, content type or format, and base64-encoded content. It is used when configuring merge fields and other context-driven expressions that need access to document variable data, and the platform’s context availability matrix shows it is available in the Sequencer Actor scope and not available in the Document Generation scope. This matters to configuration admins and developers because it determines where document-specific variable data can be referenced, how document metadata and content can be incorporated into workflow logic, and which scope must be selected when designing configurations that depend on document merge-field values.

Variables ​

Variables is a Sequencer actor in the Autologyx platform used to define and manage values that can then be consumed elsewhere in a process through merge fields. It is used when configuring workflows alongside other actors such as API Call, Send Message, and AI Actors, and provides a structured way to store process data, derived values, and reusable context for later steps. This matters because configuration admins and developers rely on Variables to make workflows dynamic, reduce duplication, and ensure that templates, integrations, and downstream actors can reference consistent data throughout execution.

WebSocket connection ​

A WebSocket connection in Autologyx is the authenticated, secure wss session used by the Catalyst Websockets API to deliver real-time updates from the platform to a client application. It is used by developers and integrators when connecting to the Catalyst API endpoint, typically after obtaining access through the GET /api/users/ws auth/ process, and it carries WebSocket responses containing event data as activity occurs. This connection matters because it enables near real-time event handling without repeated polling, and its runtime behaviour directly affects integration design: if event volume exceeds the documented threshold, excess events are buffered for delivery in a subsequent response, but any buffered events are discarded if the WebSocket connection is interrupted before they are broadcast.

WebSocket response ​

A WebSocket response in the Autologyx platform is the message payload sent from the Catalyst Websockets API to a connected client over an authenticated WebSocket connection, carrying real-time event updates for the platform. It is used by developers and integrators consuming live system activity, particularly where events are delivered at intervals or when configured thresholds are reached. WebSocket responses can include buffered events when prior event volume exceeded the delivery limit, so they are central to how Autologyx batches and broadcasts high-frequency updates. This matters when building or configuring integrations because client applications must process each response as a unit of event delivery, understand that buffered events are only sent in a subsequent response while the connection remains active, and account for the fact that buffered events are discarded if the connection is interrupted.

Word Add in plugin ​

Word Addin ​

In Autologyx, the Word Addin is the Microsoft Word integration that uses a dedicated Azure application Single Sign On (SSO) configuration to authenticate users from within the add-in experience. It is configured through the Single Sign On Configuration settings using the is word addin enabled flag, which is supported only for the Azure provider and is used alongside related SSO values such as client ID, Azure tenant identifier, redirect URI, and logout URL. This setting determines whether a specific Azure SSO configuration is available to the Word Addin, and the platform enforces that only one Word Addin-enabled configuration exists for each Azure application SSO. This matters to configuration administrators, super admins, and integrators because it controls whether users can sign in to Autologyx through the Word Addin and ensures the add-in is connected to the correct identity provider configuration.

Workflow notifications ​

Workflow notifications are platform-generated messages used within an Autologyx workflow to inform users or connected systems about workflow events, updates, or required actions. They are used as an output channel in workflow design and execution, alongside other templated content areas such as document templates, email templates, API responses, and custom scripts. Workflow notifications support merge fields, including globally available system merge fields, allowing notification content to be populated dynamically with workflow data at runtime. This matters because notifications are a core mechanism for delivering timely, context-aware communication from workflows, and correct configuration ensures recipients receive accurate, actionable information that reflects the current state of the process.

ws auth ​

ws auth is the Catalyst API authentication endpoint used to obtain the UUID v4 value required to establish an authenticated connection to the Autologyx Websockets API. It is used by developers and integrators when configuring real-time integrations, specifically as the GET /api/users/ws auth/ step that precedes opening a WebSocket session. This matters because WebSocket connections to Autologyx depend on this authentication flow, and the returned UUID v4 value enables clients to connect successfully and receive live platform event updates.