---
url: >-
  /knowledgebase/release-notes/release-notes-1.6/“relationship-created”-trigger-in-sequencer.md
---

# “Relationship created” trigger in Sequencer

Efficient task allocation often relies upon the establishment of meaningful relationships between parent and child records. Recognising this vital aspect of workflow management, we are thrilled to introduce our latest feature: the **"Relationship created" trigger** integrated into our Sequencer.

**Where it works**

The **"Relationship created" trigger** is designed to function within classes that are included in Relational Modeller as relational entities. This targeted approach ensures that the trigger operates seamlessly in contexts where relational data management is crucial.

![Relationship created\_article.gif](/knowledgebase/images/img_14581371863709_1776895667.png)

**What it does**

Upon the successful establishment of a relationship between parent and child records, this trigger acts as a catalyst, initiating subsequent actions within the sequence. This capability opens up a world of possibilities, enabling automation of diverse processes based on specified conditions. Whether it's assigning follow-up actions or tasks, sending notifications, or triggering specific workflows, the **"Relationship created" trigger** becomes the linchpin of your automation strategies.

**Outcome**

By integrating the **"Relationship created" trigger** into sequences, you not only enhance your workflow automation but also pave the way for a more streamlined, organised, and productive work environment.

---

---
url: /contributing/api-resource-template.md
---
# {%feature%}

> `TODO` Describe a `{%feature%}` here ...

> `TODO`
>
> * replace all placeholders {%placeholder%} with appropriate values.
> * `{text}` is not a placeholder (single brackets).
> * Do not remove \`\` chars if placeholder is between them, like `{%placeholder%}`.
> * Extend descriptions if needed.
> * **Remove this (and others) TODO block** - it's just a guide.

## Permissions

> `TODO` please describe permissions, including from what they come, like some permission sets, etc.

| Permission | Manageable via Roles | Manageable via {%other\_way%} | Description     |
|------------|----------------------|------------------------------|-----------------|
| {%perm%}   | {%bool%}             | {%description%}              | {%description%} |

Permissions for {%feature%} can be checked by:

| Context                        | Endpoint                      | Location                         | Available perms        |
|--------------------------------|-------------------------------|----------------------------------|------------------------|
| Global scope                   | `GET /api/users/permissions/` | `{%resource%}`                   | `{%perm%}`, `{%perm%}` |
| Specific {%name\_of\_an\_object%} | `GET /{%endpoint%}/`          | `_meta.permissions.{%resource%}` | `{%perm%}`, `{%perm%}` |

## References

* [{%name\_of\_other\_document%}]()

## POST /{%endpoint%}/

Creates {%object\_name%}.

### Permissions

Requires `authentication` and `{%resource%}.{%perm%}` permission.

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| uuid           | uuid    |             |

* Body parameters

| Key           | Type     | Notes       |
|---------------|----------|-------------|
| {%attribute%} | {%type%} |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> POST /{%endpoint%}/

```json

{
  "{%attribute%}": "{%str_value%}",
  "{%attribute%}": {%int_bool_value%}
} 
```

### Validations

* {%attribute%}
  * Max length: 100 (`TODO` it's a sample, remove if not relevant)
  * {%validation%}: {%value%}

### Restrictions

* `TODO` please describe limits enforced by the endpoint.

### Response

> `TODO` in table below there is `uuid`. Probably all new endpoints will use it instead of integer `id`.
>
> `TODO` please remove non-matching attributes.

| Key               | Type     | Notes                                    |
|-------------------|----------|------------------------------------------|
| uuid              | uuid     | Automatically generated by the backend.  |
| {%attribute%}     | {%type%} |                                          |
| created\_at        | datetime |                                          |
| created\_by        | user     |                                          |
| modified\_at       | datetime |                                          |
| modified\_by       | user     |                                          |
| \_meta.labels      | Object   | Object containing labels for attributes. |
| \_meta.permissions | Object   | Object describing permissions.           |

* Successful status `201 Created`
* Response body schema

```json
{
  "uuid": <uuid>,
  "{%attribute%}": {%type%},
  ...
  "created_at": <datetime>,
  "created_by": <user>,
  "modified_at": <datetime>,
  "modified_by": <user>,
  "_meta": {
    "labels": {
      "{%attribute%}": <string>,
      ...
    },
    "permissions": {
      "{%perm%}": <bool>,
      ...
    }
  }
} 
```

### Errors

| Cause                                                             | Response code    | Message                                                                                            |
|-------------------------------------------------------------------|------------------|----------------------------------------------------------------------------------------------------|
| "{%attribute%}" is missing                                        | 400 Bad Request  | "name": \["This field is required."]                                                                |
| "{%attribute%}" is empty string                                   | 400 Bad Request  | "name": \["This field may not be blank."]                                                           |
| "{%attribute%}" is null                                           | 400 Bad Request  | "name": \["This field may not be null."]                                                            |
| "{%attribute%}" has > {%limit%} chars                             | 400 Bad Request  | "name": \["Ensure this field has no more than {%limit%} characters."]                               |
| "{%attribute%}" is not unique                                     | 400 Bad Request  | "name": \["This field must be unique."]                                                             |
| "{%attribute%}" is not int                                        | 400 Bad Request  | "object\_class": \["Incorrect type. Expected pk value, received {type}."]                            |
| {%object%} with "{%attribute%}" does not exist                    | 400 Bad Request  | "object\_class": \["Invalid pk \\"{value}\\" - {%object%} does not exist."]                          |
| "{value}" for {%attribute%} is out of choices                     | 400 Bad Request  | "type": \["\\"{value}\\" is not a valid choice."]                                                   |
| Max {%limit%} {%object\_name%} per {%parent\_object\_name%} exceeded | 400 Bad Request  | "detail": \["Limit of {%limit%} {%object\_name%} for the {%parent\_object\_name%} has been exceeded."] |
| Insufficient permissions                                          | 403 Forbidden    | "detail": "You do not have permission to perform this action."                                     |

## GET /{%endpoint%}/

Returns list of {%object\_name%}.

### Permissions

Requires `authentication` and `{%resource%}.{%perm%}` permission.

> `TODO` below sentence is not relevant to each resource. Please remove if it's redundant.

Response contains only the {%object\_name%} for which the caller has `{%resource%}.{%perm%}` permission for the
associated {%parent\_object\_name%}.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> GET /{%endpoint%}/

```json
```

### Response

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

#### Response `results` array

| Key               | Type     | Notes                                    |
|-------------------|----------|------------------------------------------|
| uuid              | uuid     |                                          |
| {%attribute%}     | {%type%} |                                          |
| created\_at        | datetime |                                          |
| created\_by        | user     |                                          |
| modified\_at       | datetime |                                          |
| modified\_by       | user     |                                          |
| \_meta.labels      | Object   | Object containing labels for attributes. |
| \_meta.permissions | Object   | Object describing permissions.           |

* Successful status `200 OK`
* Response body schema

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str | null>,
  "previous": <str | null>,
  "results": [
    {
      "uuid": <uuid>,
      "{%attribute%}": {%type%},
      ...
      "created_at": <datetime>,
      "created_by": <user>,
      "modified_at": <datetime>,
      "modified_by": <user>,
      "_meta": {
        "labels": {
          "{%attribute%}": <string>
        },
        "permissions": {
            "{%perm%}": <bool>,
            ...
        }
      }
    }
  ]
}
```

### Sorting

| Parameter     | Example                                | Notes          |
|---------------|----------------------------------------|----------------|
| {%attribute%} | /{%endpoint%}/?ordering={%attribute%}  | Ascending      |
| {%attribute%} | /{%endpoint%}/?ordering=-{%attribute%} | Descending (-) |
| created\_at    | /{%endpoint%}/?ordering=created\_at     | Ascending      |
| created\_at    | /{%endpoint%}/?ordering=-created\_at    | Descending (-) |
| modified\_at   | /{%endpoint%}/?ordering=modified\_at    | Ascending      |
| modified\_at   | /{%endpoint%}/?ordering=-modified\_at   | Descending (-) |

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter     | Type     |
|---------------|----------|
| uuid          | uuid     |
| {%attribute%} | {%type%} |
| created\_at    | datetime |
| created\_by    | user     |
| modified\_at   | datetime |
| modified\_by   | user     |

### Errors

| Error                         | Response code   | Message                                                                             |
|-------------------------------|-----------------|-------------------------------------------------------------------------------------|
| Wrong ordering value          | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."] |

## GET /{%endpoint%}/`uuid`/

Returns single {%object\_name%} by `uuid`.

### Permissions

Requires `authentication` and `{%resource%}.{%perm%}` permission.

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| uuid           | uuid    |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> GET /{%endpoint%}/`uuid`/

```json
```

### Response

| Key               | Type     | Notes                                    |
|-------------------|----------|------------------------------------------|
| uuid              | uuid     |                                          |
| {%attribute%}     | {%type%} |                                          |
| created\_at        | datetime |                                          |
| created\_by        | user     |                                          |
| modified\_at       | datetime |                                          |
| modified\_by       | user     |                                          |
| \_meta.labels      | Object   | Object containing labels for attributes. |
| \_meta.permissions | Object   | Object describing permissions.           |

* Successful status `200 OK`
* Response body schema:

```json
{
  "uuid": <uuid>,
  "{%attribute%}": {%type%},
  "created_at": <datetime>,
  "created_by": <user>,
  "modified_at": <datetime>,
  "modified_by": <user>,
  "_meta": {
    "labels": {
      "{%attribute%}": <string>
    },
    "permissions": {
      "{%perm%}": <bool>,
      ...
    }
  }
}
```

### Errors

| Error                                      | Response code | Message                                                        |
|--------------------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions                   | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| {%object\_name%} with "uuid" does not exist | 404 Not Found | "detail": "Not found."                                         |

## PATCH /{%endpoint%}/`uuid`/

Updates single {%object\_name%}.

### Permissions

Requires `authentication` and `{%resource%}.{%perm%}` permission.

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| uuid           | uuid    |             |

* Body parameters

| Key           | Type     | Notes       |
|---------------|----------|-------------|
| {%attribute%} | {%type%} |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> PATCH /{%endpoint%}/`uuid`/

```json

{
  "{%attribute%}": "{%str_value%}",
  "{%attribute%}": {%int_bool_value%}
  ...
} 
```

### Response

| Key               | Type     | Notes                                    |
|-------------------|----------|------------------------------------------|
| uuid              | uuid     |                                          |
| {%attribute%}     | {%type%} |                                          |
| created\_at        | datetime |                                          |
| created\_by        | user     |                                          |
| modified\_at       | datetime |                                          |
| modified\_by       | user     |                                          |
| \_meta.labels      | Object   | Object containing labels for attributes. |
| \_meta.permissions | Object   | Object describing permissions.           |

* Successful status `200 OK`
* Response body schema:

```json
{
  "uuid": <uuid>,
  "{%attribute%}": {%type%},
  "created_at": <datetime>,
  "created_by": <user>,
  "modified_at": <datetime>,
  "modified_by": <user>,
  "_meta": {
    "labels": {
      "{%attribute%}": <string>
    },
    "permissions": {
      "{%perm%}": <bool>,
      ...
    }
  } 
```

### Errors

| Error                                      | Response code   | Message                                                              |
|--------------------------------------------|-----------------|----------------------------------------------------------------------|
| {%object\_name%} with "uuid" does not exist | 400 Bad Request | "detail": "You do not have permission to perform this action."       |
| "{%attribute%}" is empty string            | 400 Bad Request | "name": \["This field may not be blank."]                             |
| "{%attribute%}" is null                    | 400 Bad Request | "name": \["This field may not be null."]                              |
| "{%attribute%}" has > {%limit%} chars      | 400 Bad Request | "name": \["Ensure this field has no more than {%limit%} characters."] |
| "{%attribute%}" is not unique              | 400 Bad Request | "name": \["This field must be unique."]                               |
| Insufficient permissions                   | 403 Forbidden   | "detail": "You do not have permission to perform this action."       |

## DELETE /{%endpoint%}/`uuid`/

Deletes single {%object\_name%}.

### Permissions

Requires `authentication` and `{%resource%}.{%perm%}` permission.

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| uuid           | uuid    |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> DELETE /{%endpoint%}/`uuid`/

```json
```

### Response

* Successful status `204 No Content`

### Errors

| Error                                      | Response code | Message                                                        |
|--------------------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions                   | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| {%object\_name%} with "uuid" does not exist | 404 Not Found | "detail": "Not found."                                         |

## OPTIONS /{%endpoint%}/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> OPTIONS /{%endpoint%}/

```json
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
  "list": {
    "columns": [
      {
        "alias": "uuid",
        "type": "uuid",
        "predicates": [
          "exact"
        ],
        "sort_ok": false
      },     
      {
        "alias": "{%attribute%}",
        "type": "{%type%}",
        "predicates": [
          "{%predicate%}",
          ...
        ],
        "sort_ok": {%bool_value%}
      },
      ...
      {
        "alias": "created_at",
        "type": "datetime",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range"
        ],
        "sort_ok": true
      },
      {
        "alias": "created_by",
        "type": "user",
        "predicates": [
          "exact",
          "in"
        ],
        "sort_ok": false,
        "autocomplete": "/api/users/autocomplete/?text__icontains="
      },
      {
        "alias": "modified_at",
        "type": "datetime",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range"
        ],
        "sort_ok": true
      },
      {
        "alias": "modified_by",
        "type": "user",
        "predicates": [
          "exact",
          "in"
        ],
        "sort_ok": false,
        "autocomplete": "/api/users/autocomplete/?text__icontains="
      }
    ]
  },
  "details": {
    "schema": [
      {
        "alias": "{%attribute%}",
        "type": "{%type%}",
        "required": {%bool_value%},
        "validators": [
          {
            "type": "{%slug_name_for_validator%}",
            "length": {%value%}
          }
        ]
      },
      ...
    ]
  },
  "restrictions": {
    "{%restriction_slug%}": {%value%}
  }
} 
```

---

---
url: /api/merge-fields/resources/scopes.md
---
# 🎯 MF Context Scopes Availability

This section presents the availability of different contexts within various system scopes for merge fields.
It enables quick reference to determine which contexts are accessible in specific usage scenarios.

## 📋 Available Context Types

* `ClientContext`
* `DateAndTimeContext`
* `VariableContext`
* `ConstantContext`
* `TaskContext`
* `ObjectRecordContext`
* `UsersGroupContext`
* `UserContext`
* `UserFieldMetaContext`
* `UserFieldContext`
* `DocumentContext`
* `EmbeddedDocumentContext`

## 📊 Context Availability by Scope

| Context                  | Sequencer Actor | Document Generation |
|--------------------------|-----------------|---------------------|
| AdminContext             | 🟢              | 🟢                  |
| ClientContext            | 🟢              | 🟢                  |
| DateAndTimeContext       | 🟢              | 🟢                  |
| VariableContext          | 🟢              | 🔴                  |
| VariableDocumentContext  | 🟢              | 🔴                  |
| ConstantContext          | 🟢              | 🟢                  |
| TaskContext              | 🟢              | 🟢                  |
| ObjectRecordContext      | 🟢              | 🟢                  |
| UsersGroupContext        | 🟢              | 🟢                  |
| UserContext              | 🟢              | 🟢                  |
| UserFieldMetaContext     | 🟢              | 🟢                  |
| UserFieldContext         | 🟢              | 🟢                  |
| DocumentContext          | 🟢              | 🟢                  |
| EmbeddedDocumentContext  | 🔴              | 🟢                  |

## 📝 Legend

* 🟢 = Context is available in this scope
* 🔴 = Context is not available in this scope

### 🧩 Default Context Components:

The **DefaultScope** provides the foundational set of contexts available across the system:

* **AdminContext** - administrative context with system information
* **ClientContext** - client/organization information
* **DateAndTimeContext** - date and time related functions and variables
* **ConstantContext** (prefix: `constants`) - system and configuration constants

This baseline set of contexts forms the foundation that other specialized scopes build upon, ensuring consistent access to essential system data.

#### 📋 ObjectRecord-Related Contexts:

The following contexts are directly associated with **ObjectRecordContext** as they provide related data and metadata:

* **TaskContext** - task-specific information and metadata related to the current record processing
* **ObjectRecordContext** - core access to record data being processed
* **UsersGroupContext** - user group information and permissions relevant to the record
* **UserContext** - current user information and context in relation to the record
* **UserFieldMetaContext** - metadata about user-defined fields associated with the record
* **UserFieldContext** - access to user-defined field values for the current record
* **DocumentContext** - document-specific context and metadata when processing record-related documents

### ⚙️ SequencerActor Context Components:

The **SequencerActorScope** combines three types of contexts for comprehensive workflow execution:

* **Default Contexts**
* **Record-Related Contexts** - related to the record being processed in the sequence
* **Additional Context**: **VariableContext** - dynamic workflow variables and runtime data

This scope is designed for workflow execution scenarios where comprehensive access to system data, record information, and dynamic variables is essential.

### 📄 DocumentGeneration Context Components:

The **DocumentGenerationScope** combines three types of contexts for document creation:

* **Default Contexts**
* **Record-Related Contexts** - related to the record being processed in document generation
* **Additional Context**: **EmbeddedDocumentContext** - for embedding images in the generated document

This scope provides comprehensive access to both system information and record data needed for generating documents with proper administrative context.This scope provides comprehensive access to both system information and record data needed for generating documents with proper administrative context.

## 💡 Context Usage Patterns

Based on the scope comparison table:

**Universal Contexts:**

* `ClientContext` and `DateAndTimeContext` - Available in all scopes as they provide fundamental system information
* `ConstantContext` - Widely available across most scopes for configuration values

**Specialized Contexts:**

* `AdminContext` - Available in DefaultScope and DocumentGenerationScope for system-level operations
* `VariableContext` - Limited to SequencerActorScope for dynamic workflow variables
* `VariableDocumentContext` - Limited to SequencerActorScope for dynamic workflow variables. Represents document's merge fields data.
* `ObjectRecordContext` - Available in data-processing scopes (SequencerActorScope, DocumentGenerationScope)
* `DocumentContext` - Exclusive to DocumentGenerationScope for document-specific operations

**Workflow-Specific Contexts:**

* `TaskContext`, `UserContext`, `UserFieldContext`, `UserFieldMetaContext`, `UsersGroupContext` - Currently not used in the main scopes, likely reserved for specialized workflow or form-processing scenarios

### 🏗️ VariableDocumentContext

Represents document's merge fields data.:

| Property   | Type     | Description                       |
|------------|----------|-----------------------------------|
| `id`       | integer  | Unique document ID                |
| `name`     | string   | File name with extension          |
| `size`     | integer  | File size in bytes                |
| `uuid`     | string   | Download URL                      |
| `mimetype` | string   | Type and file format              |
| `base64`   | string   | Base64 encoded content - `hidden` |

### 🎯 Accessing Document Variable Properties

```jinja
{{variables.var1.id}}
{{variables.var1.name}}
{{variables.var1.size}}
{{variables.var1.uuid}}
{{variables.var1.mimetype}}
{{variables.var1.base}}
```

---

---
url: /api/merge-fields/resources/sequncer-merge-fields.md
---
# 🎯 MF used in sequencer

This section presents the merge fields that are specific to the Sequencer.\
They are designed to be used only within actors like Loop and API Call, and their behavior depends on the actor configuration and triggers.

# 📘 `loop_item` Merge Field Documentation

`loop_item` is a Sequencer-specific merge field available inside any actor
that is executed downstream of a Loop actor.
This includes actors connected directly or indirectly to the Loop actor.

During execution, the Loop actor iterates over a collection and exposes the
current element as `loop_item`.
Each downstream actor invocation receives the value corresponding to the
current iteration.

***

## 📑 Table of Contents

* [🔍 Overview](#-overview)
* [🎯 Availability](#-availability)
* [⚙️ Behavior](#️-behavior)
  * [1. Correct Rendering During API Call
    Test](#1-correct-rendering-during-api-call-test)
  * [2. Behavior with "Actor completed"
    Trigger](#2-behavior-with-actor-completed-trigger)
  * [3. Document Picker as Loop
    Source](#3-document-picker-as-loop-source)
  * [4. Exception Handling](#4-exception-handling)
  * [5. Multiple Loop Connections](#5-multiple-loop-connections)
* [👍👎 Good vs Bad Configuration
  Examples](#-good-vs-bad-configuration-examples)
  * [Loop with Array Source](#loop-with-array-source)
  * [Loop with Document Picker](#loop-with-document-picker)
  * [Incorrect Triggers](#incorrect-triggers)
* [📝 Summary](#-summary)

***

## 🔍 Overview

The merge field `loop_item` represents **the current item
processed by a Loop actor**.

It supports nested properties:

```jinja
    {{ loop_item.name }}
    {{ loop_item.mime_type }}
    {{ loop_item.size }}
```

Depending on the Loop's source, `{{ loop_item }}` may represent:

* an array item (Array source, API Call source, Variable source)
* a document representation (Document Picker source)

Example usage inside an API Call actor:

```jinja
    url="https://example.test/{{ loop_item.size }}"
    headers="?file={{ loop_item.name }}"
    params='{"type": "{{ loop_item.mime_type }}"}'
```

***

## 🎯 Availability

`loop_item` can be used in any actor executed downstream of a Loop actor.

* directly connected to a Loop actor triggered by **"Loop item processed"**
* indirectly connected through other actors

The merge field is available within the execution context of a single loop iteration,
meaning each downstream actor receives the value of `loop_item` corresponding to the currently processed element.

***

## ⚙️ Behavior

### 1. Correct Rendering During API Call Test

When testing an API Call actor connected via **"Loop item processed"**:

* `loop_item` resolves to the **actual current item**

* Nested properties render correctly

* If the Loop's source is misconfigured (not an array):

  * It attempts to use the **first item** of the provided data

  * If no usable item exists → **empty string**

***

### 2. Behavior with "Actor completed" Trigger

When the API Call actor is connected using **"Actor completed"**:

* During testing, `loop_item` → **empty string**

***

### 3. Document Picker as Loop Source

Assumptions:

* Loop actor uses **Document Picker**
* API Call actor is connected via **"Loop item processed"**
* API Call is configured correctly

Behavior:

Document Picker Input   `loop_item` result

***

Empty                   `""` (empty string)

Contains document       Document representation

***

### 4. Exception Handling

During API Call testing:

* If resolving `loop_item` throws **any exception**, it is rendered as **empty string**

***

### 5. Multiple Loop Connections

If the API Call actor is connected to **multiple Loop actors**, each potentially supplying a `{{ loop_item }}`:

* During testing, the Sequencer always uses **the most recently modified Loop actor**
* All other Loop connections are ignored for the purpose of `{{ loop_item }}` evaluation in testing mode

***

## 👍👎 Good vs Bad Configuration Examples

### Loop with Array Source

#### 👍 Good

```json
{
  "files": [
    { "name": "file1.txt", "size": 1200 },
    { "name": "file2.txt", "size": 3400 }
  ]
}
```

where json.path is `files`

#### 👎 Bad

```json
{}
```

or

```json
{
  "files": [
    { "name": "file1.txt", "size": 1200 },
    { "name": "file2.txt", "size": 3400 }
  ]
}
```

where json.path is not set

***

### Loop with Document Picker

#### 👍 Good

```jinja
    {{ loop_item.size }} → "312345"
    {{ loop_item.name }} → "invoice.pdf"
    {{ loop_item.mime_type }} → "application/pdf"
```

#### OR

```jinja
    {{ loop_item }} → 
    {
        "name": "invoice.pdf",
        "size": 312345,
        "mime_type": "application/pdf",
    }
```

***

### Incorrect Triggers

#### 👍 Good

* Loop item processed

#### 👎 Bad

* Actor completed

***

## 📝 Summary

**loop\_item** is a dynamic merge field tied to the execution context of a Loop actor:

* Available in any actor executed downstream of a Loop actor
* Represents the current element processed in a loop iteration
* Supports nested properties
* Handles arrays and documents
* In all error cases → resolves to an empty string
* When multiple Loops are connected, **the last modified Loop is used during testing**

# 📘 `loop_counter` Merge Field Documentation

`loop_counter` is a Sequencer-specific merge field available inside any actor
that is executed downstream of a Loop actor.
This includes actors connected directly or indirectly to the Loop actor.

During execution, the Loop actor iterates over a collection and exposes the
current iteration index as `loop_counter`.

The value starts from `1` for the first processed element and increases by 1
for each subsequent iteration.

## 🎯 Availability

`loop_counter` can be used in any actor executed downstream of a Loop actor.

This includes actors that are:

* directly connected to the Loop actor
* indirectly connected through other actors
* triggered during the execution of the Loop iteration

The merge field is available within the execution context of a single loop iteration,
meaning each downstream actor receives the `loop_counter` value corresponding to the current iteration.

## ⚙️ Behavior

* `loop_counter` represents the index of the current loop iteration.
* The value increments with every processed element.
* The first iteration returns 1, the second 2, and so on.
* The value is recalculated for each loop iteration.

---

---
url: /api/merge-fields/resources/object-record-merge-fields.md
---
# 📄 Autologyx – Merge Fields Guide

Merge fields let you dynamically insert values from Object Records into documents, emails, API Actor parameters, and other resources.

## 📌 Table of Contents

* [Introduction](#🧩-introduction)
* [Accessing Record Fields](#🔎-accessing-record-fields)
* [Field Types & Formatting](#🧷-field-types-formatting)
* [Conditional Logic](#🧪-conditional-logic)
* [Record properties](#🧾-record-properties)
* [Images and Document Fields](#🖼%EF%B8%8F-images-documents)
* [User and User Group Fields](#👤-user-and-👥-user-groups)
* [Related Records](#🔗-related-records)
* [Loops and Iteration](#🔁-loops)
* [Filtering Records](#🔍-filtering-records)
* [Images and Documents](#📄-images-documents)
* [Tasks](#📋-tasks)
* [Date & Time Formatting](#🕒-date-and-time-formatting)
* [Syntax Errors](#❌-syntax-errors)

***

## 🧩 Introduction

**Merge fields** (aka template tags) are used to dynamically access field values of Object Records using Jinja2 syntax. They are supported in:

* Document templates (e.g., DOCX),
* Email content and subject lines,
* API Actor parameter inputs,
* And any field where Object Record data is available.

***

## 🔎 Accessing Record Fields

To access a field value from a record, use:

```jinja
{{ record.field_<alias> }}
```

### Example:

If the field Date of Birth has alias date\_of\_birth, use:

```jinja
{{ record.field_date_of_birth }}
```

## 🧷 Field Types & Formatting

| Field Type   | Merge Field Example                       | Output Example                |
|--------------|-------------------------------------------|-------------------------------|
| String       | `{{ record.field_text }}`                 | `John`                        |
| Integer      | `{{ record.field_int }}`                  | `123`                         |
| Float        | `{{ record.field_float }}`                | `123.45`                      |
| Boolean      | `{{ record.field_bool }}`                 | `True` / `False`              |
| Enum         | `{{ record.field_enum }}`                 | `Apple`                       |
| Set          | `{{ record.field_set }}`                  | `['Apple', 'Pear']`           |
| Email        | `{{ record.field_email }}`                | `user@example.com`            |
| Phone        | `{{ record.field_phone }}`                | `123456789`                   |
| Date         | `{{ record.field_date }}`                 | `2023-04-17`                  |
| DateTime     | `{{ record.field_datetime }}`             | `2023-04-17 12:37:00+02:00`   |
| Time         | `{{ record.field_time }}`                 | `12:37:00`                    |
| URL          | `{{ record.field_url }}`                  | `https://autologyx.com`       |
| JSON         | `{{ record.field_json }}`                 | `{"key": "value"}`            |
| Document     | `{{ record.field_document }}`             | List of documents (with URLs) |
| User Field   | `{{ record.field_&lt;alias&gt;.users }}`        | List of user objects          |
| Group Field  | `{{ record.field_&lt;alias&gt;.user_groups }}`  | List of groups                |

::: info
🚀 **Complex types** such as Document, User, and Group require a detailed description of their structure and how to access their properties. Detailed information about these types can be found in the following sections of this guide.
:::

You can format the output using filters. These are applied by appending a pipe (`|`) and the filter name to the field.

| Filter              | Example                                            | Output Example                      |
|---------------------|----------------------------------------------------|-------------------------------------|
| `date`              | `{{ record.field_date \| date('%d %B %Y') }}`      | `17 April 2023`                     |
| `datetime`          | `{{ record.field_datetime \| datetime('%H:%M') }}` | `12:37`                             |
| `default`           | `{{ record.field \| default('N/A') }}`             | If field is empty → `N/A`           |
| `join`              | `{{ record.field_set \| join(', ') }}`             | `Apple, Pear`                       |
| `length`            | `{{ record.field_set \| length }}`                 | `2`                                 |
| `lower` / `upper`   | `{{ record.field_text \| upper }}`                 | `JOHN`                              |
| `capitalize`        | `{{ record.field_text  \| capitalize }}`           | `John`                              |
| `replace`           | `{{ record.field_text \| replace('a', 'b') }}`     | Replaces `a` with `b`               |

## 🧪 Conditional Logic

You can use `if` statements to show or hide parts of the template based on field values.

### Basic condition

```jinja
{% if record.field_status == 'active' %}
  Status: Active
{% endif %}
```

### If / Else

```jinja
{% if record.field_price > 0 %}
  Paid: {{ record.field_price }} €
{% else %}
  Free
{% endif %}
```

### Nested conditions

```jinja
{% if record.field_status %}
  {% if record.field_status == 'archived' %}
    Archived
  {% else %}
    Active
  {% endif %}
{% endif %}
```

You can also use in, not in, and, or, etc.

```jinja
{% if record.field_status in ['new', 'open'] and record.field_priority == 'high' %}
  Urgent!
{% endif %}
```

## 🧾 Record Properties

The following Object Record properties can be accessed using merge fields in templates:

| Property   | Merge Field Syntax       | Type        |
|------------|---------------------------|-------------|
| ID         | `{{ record.id }}`         | Integer     |
| Created    | `{{ record.created_at }}` | Date/time   |
| Modified   | `{{ record.modified_at }}`| Date/time   |

### ℹ️ Notes

The shorthand

```jinja
{{ record }}
```

will be automatically substituted with the `record.id` property.

::: info
🚀 Jinja merge fields **do not** support referencing the record identifier field using the syntax `<<record.identifier>>`.
:::

## 📄 Images & Documents

::: tip Image Fields
🖼️ Related records containing image fields can be processed using dedicated image filters. See **[Image Processing](/api/merge-fields/resources/custom-filters#🖼%EF%B8%8F-image-processing)** for details.
:::

Document fields store files (PDF, DOCX, images, etc.) and are accessible via:

```jinja
{{ record.field_<alias_document> }}
```

### 📤 Example Output

```json
[
  {
    "id": 53,
    "name": "template.docx",
    "size": 10151,
    "url": "https://url.to.the.file",
    "mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",
  },
  {
    "id": 54,
    "name": "certificate.png",
    "size": 2016000,
    "url": "https://url.to.the.file",
    "mimetype": "image/png"
  },
  {
    "id": 55,
    "name": "smash.gif",
    "size": 112296,
    "url": "https://url.to.the.file",
    "mimetype": "image/gif"
  }
]
```

### 🏗️ Document Object Structure

Each document field returns an array of document objects with the following properties:

| Property   | Type     | Description                       |
|------------|----------|-----------------------------------|
| `id`       | integer  | Unique document ID                |
| `name`     | string   | File name with extension          |
| `size`     | integer  | File size in bytes                |
| `url`      | string   | Download URL                      |
| `uuid`     | string   |                                   |
| `mimetype` | string   | Type and file format              |
| `base64`   | string   | Base64 encoded content - `hidden` |

### 🎯 Accessing Document Properties

```jinja
{{ record.field_document[0].name }} 
{{ record.field_document[0].url }}
{{ record.field_document[0].mimetype }}
{{ record.field_document[0].size }}
{{ record.field_document[0].base64 }}
```

### 💡  Examples

**Generate download links:**

```jinja
{% for doc in record.field_contracts %}
- [Download {{ doc.name }}]({{ doc.url }}) ({{ doc.size }} bytes) 
{% endfor %}
```

**Output:**

```text
- [Download contract_2023.pdf](https://url.to.the.file) (245760 bytes)
- [Download agreement_final.docx](https://url.to.the.file) (89432 bytes)
- [Download terms_conditions.pdf](https://url.to.the.file) (156890 bytes)
```

**Accessing Base64 Content:**

The `base64` property contains the Base64-encoded content of the document file, which allows you to embed or process the actual file data.

```jinja
{{ record.field_document[0].base64 }}
```

**Output:**

```text
JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PAovVHlwZSAvQ2F0YWxvZwovUGFnZXMgMiAwIFIKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL1BhZ2VzCi9LaWRzIFszIDAgUl0KL0NvdW50IDEKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KPj4KZW5kb2JqCjMgMCBvYmoK...
```

**Embed image directly in HTML:**

```jinja
{% for image in record.field_photos %}
    <img src="data:image/{{ image.name.split('.')[-1] }};base64,{{ image.base64 }}" alt="{{ image.name }}" />
{% endfor %}
```

**Output:**

```text
<img src="data:image/jpg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUfGhsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCAABAAEDASIAAhEBAxEB/8QAFQABAQAAAAAAAAAAAAAAAAAAAAv/xAAUEAEAAAAAAAAAAAAAAAAAAAAA/8QAFQEBAQAAAAAAAAAAAAAAAAAAAAX/xAAUEQEAAAAAAAAAAAAAAAAAAAAA/9oADAMBAAIRAxEAPwCdABmX/9k=" alt="profile_photo.jpg" />
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mNkYPhfDwAChAGA4nRuCwAAAABJRU5ErkJggg==" alt="avatar.png" />
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" alt="animation.gif" />
```

**Embed image directly in HTML:**

```jinja
{% for csv in record.field_attachments %}
<a href="data:text/csv;base64,{{ csv.base64 }}" download="{{ csv.name }}">
    Download {{ csv.name }}
</a>
{% endfor %}
```

**Output:**

```text
<a href="data:text/csv;base64,TmFtZSxBZ2UsQ2l0eQpKb2huLDI1LE5ldyBZb3JrCkphbmUsIDMwLCBMb3MgQW5nZWxlcwpCb2IsIDM1LCBDaGljYWdv" download="employees.csv">
    Download employees.csv
</a>
<a href="data:text/csv;base64,UHJvZHVjdCxQcmljZSxRdWFudGl0eQpBcHBsZSwxLjUwLDEwMApCYW5hbmEsMC43NSw1MApPcmFuZ2UsMi4wMCwyNQ==" download="inventory.csv">
    Download inventory.csv
</a>
<a href="data:text/csv;base64,RGF0ZSxSZXZlbnVlLEV4cGVuc2VzCjIwMjMtMDEtMDEsMTAwMDAsMjAwMApASDMjLTAyLTAxLDE1MDAwLDMwMDA=" download="financial_report.csv">
    Download financial_report.csv
</a>

```

::: warning ⚠️ Important Notes

* Empty document fields return an empty array `[]`
* Accessing invalid indices or non-existing properties returns an empty string
* Base64 property is only accessible through direct indexing: `{{ record.field_document[0].base64 }}`
* Legacy format `<<object_record.field_document>>` is supported but cannot be mixed with new syntax

## 👤 User and 👥 User Groups

User-type fields in Autologyx can contain references to both users and user groups. These fields support two different approaches for accessing data: **ID-based access** for compatibility with existing systems, and **object-based access** for enhanced functionality.

### 🔢 ID-Based Access (Legacy Compatibility)

The traditional approach returns lists of IDs, maintaining compatibility with existing configurations:

```jinja
{{ record.field_user }}
```

Returns an object containing both user IDs and user group IDs.

#### 📘 Example Output:

```json
{ "users": [123, 456, 789], "user_groups": [10, 20] }
```

```jinja
{{ record.field_user.user_groups }}
```

Returns an array of user group IDs only.

### 🎯 Object-Based Access (Enhanced Functionality)

For accessing full user and group objects with all their properties, use the `.meta` syntax:

```jinja
{{ record.field_user.meta.users }}
```

Returns an array of user objects only.

```jinja
{{ record.field_user.meta.meta.user_groups }}
```

Returns an array of user group objects only.

### 👤 User Object Properties

When using `.meta.users`, each user object contains:

| Property       | Type      | Description                  |
|----------------|-----------|------------------------------|
| `id`           | integer   | User ID                      |
| `first_name`   | string    | User's first name            |
| `last_name`    | string    | User's last name             |
| `username`     | string    | Email address                |
| `company_name` | string    | Company name                 |
| `phone`        | string    | Phone number                 |
| `mobile`       | string    | Mobile phone number          |
| `is_deleted`   | boolean   | Deletion flag - `hidden`     |
| `account_type` | enum      | Account type enum - `hidden` |

#### 📘 Complete User Object Example:

```json
  [
    {
      "id": 525,
      "first_name": "Bridget",
      "last_name": "Marquardt",
      "username": "bridget.marquardt826@example.com",
      "company_name": "",
      "phone": "16253372", 
      "mobile": "27363737" 
    },
    {
      "id": 591,
      "first_name": "Abelardo",
      "last_name": "Gutkowski",
      "username": "abelardo.gutkowski752@example.com",
      "company_name": "",
      "phone": "76235342", 
      "mobile": "93833722" 
    },
    {
      "id": 795,
      "first_name": "Aaron",
      "last_name": "Dalton",
      "username": "aaron@example.domain",
      "company_name": "",
      "phone": "999383833", 
      "mobile": "0002923832" 
    }
  ]
```

#### 📘 Example usage:

```jinja
{% for user in record.field_assignees.meta.users %}
  - {{ user.first_name }} {{ user.last_name }} ({{ user.username }})
{% endfor %}
```

#### 📌 Indexing Users

You can access specific users by index:

```jinja
{{ record.field_assignees.users[0] }} 
{{ record.field_assignees.users[0].username }} 
{{ record.field_assignees.users[1].first_name }}
```

#### 🕵️ Hidden Properties

Some properties are not returned by default but can be accessed explicitly:

```jinja
{{ record.field_assignees.users[0].is_deleted }} 
{{ record.field_assignees.users[0].account_type }}
```

### 🚫 Deleted Users Handling

When a user is deleted from the system:

* Only the `id` property is returned
* All other properties are **anonymized** for privacy
* The user object will look like: `{"id": 525}`

### 🔄 Iteration Examples

#### Basic User Loop

```jinja
{% for users in record.field_usertype.users %} 
    User ID: {{ users.id }}
    Account type: {{ users.account_type }}
{% endfor %}
```

#### Safe Property Access

```jinja
{% for user in record.field_assignees.users %} 
    {% if user.first_name %} 
        Active User: {{ user.first_name }} {{ user.last_name }} 
    {% else %} 
        Deleted User (ID: {{ user.id }}) 
    {% endif %} 
{% endfor %}
```

### 👥 User Group Object Properties

When using `.meta.user_groups`, each group object contains:

* `id` - User Group ID
* `name` - User Group name
* `num_of_members` - Number of group members
* `members` - User Group members (Property is hidden and direct access via .members is required)

#### 📘 Complete User Group Object Example:

```json
    [
    {
      "id": 525,
      "name": "Team ABC",
      "num_of_members": 20
    },
    {
      "id": 999,
      "name": "Lawyers united",
      "num_of_members": 400
    },
    {
      "id": 1249,
      "name": "Research team",
      "num_of_members": 6
    }
  ]
```

When using `.meta.user_groups[index].members`, each member object contains:

| Property       | Type      | Description                  |
|----------------|-----------|------------------------------|
| `id`           | integer   | User ID                      |
| `first_name`   | string    | User's first name            |
| `last_name`    | string    | User's last name             |
| `username`     | string    | Email address                |
| `company_name` | string    | Company name                 |
| `phone`        | string    | Phone number                 |
| `mobile`       | string    | Mobile phone number          |
| `is_deleted`   | boolean   | Deletion flag - `hidden`     |
| `account_type` | enum      | Account type enum - `hidden` |

#### 📘 User Group members example:

```json
  [
    {
      "id": 525,
      "first_name": "Bridget",
      "last_name": "Marquardt",
      "username": "bridget.marquardt826@example.com",
      "company_name": "",
      "phone": "16253372", 
      "mobile": "27363737" 
    },
    {
      "id": 591,
      "first_name": "Abelardo",
      "last_name": "Gutkowski",
      "username": "abelardo.gutkowski752@example.com",
      "company_name": "",
      "phone": "76235342", 
      "mobile": "93833722" 
    },
    {
      "id": 795,
      "first_name": "Aaron",
      "last_name": "Dalton",
      "username": "aaron@example.domain",
      "company_name": "",
      "phone": "999383833", 
      "mobile": "0002923832" 
    }
  ]
```

#### 📘 Example:

```jinja
{% for group in record.field_teams.meta.user_groups %}
  - {{ group.name }} ({{ group.num_of_members }} members)
{% endfor %}
```

#### 📌 Indexing User Groups

You can access a specific user group by index:

```jinja
{{ record.field_usertype.user_groups[0] }}
{{ record.field_usertype.user_groups[0].name }}
{{ record.field_usertype.user_groups[0].num_of_members }}
```

### 🔄 Mixed Access Example

You can combine both users and groups in a single iteration:

```jinja
{% for item in record.field_assignees.meta %}
  {% if item.username %}
    User: {{ item.first_name }} {{ item.last_name }}
  {% else %}
    Group: {{ item.name }} ({{ item.num_of_members }} members)
  {% endif %}
{% endfor %}
```

### ⚙️ Supported Contexts

User-type merge fields work in:

* Document templates
* Sequencer actors (API Call, Send Message, Local Variable)
* Related records merge fields
* All other contexts where merge fields are supported

### ⚠️ User and Group Filed Error Handling

* **Invalid index**: `{{ record.field_users.users[999] }}` → returns empty string
* **Non-existing property**: `{{ record.field_users.users[0].invalid_prop }}` → returns empty string
* **Empty field**: If no users are assigned, the array will be empty `[]`

## 🔗 Related Records

Related records provide access to **connected objects** based on relationships defined in the Object Model. The same merge field syntax works for retrieving records at any relationship level — parents, grandparents, children, grandchildren, etc.

### 🎯 Basic Concept

Related records are available based on the **relationships defined in the Object Model** for the Object Class of a given record. The relationship level doesn't affect the syntax — only the target Object Class ID matters.

### 📝 Syntax

```jinja
{{ record.related_records_<class_id> }}
```

Where `<class_id>` represents the **ID of the related Object Class**, which may be related to the current record by any degree of separation.

### 🏗️ Data Structure

When processed, the merge field returns an **array of Record objects** that can be:

* **Displayed directly**: Shows comma-separated record representations
* **Indexed**: Access specific records using array notation
* **Iterated**: Use loops to process multiple records
* **Chained**: Access related records of related records

### 💡 Basic Examples

#### Direct Access

```jinja
{{ record.related_records_2 }}
{{ record.related_records_1 }}
{{ record.related_records_4 }}
```

#### Indexed Access

```jinja
{{ record.related_records_1[0] }}
{{ record.related_records_2[1] }}
```

#### Field Access

```jinja
{{ record.related_records_1[0].field_first_name }}
{{ record.related_records_2[0].field_company_name }}
```

### 🔄 Nested Related Records

You can access related records of related records using chained syntax:

```jinja
{{ record.related_records_2[0].related_records_1 }}
{{ record.related_records_2[0].related_records_1[0].field_name }}
```

### 🔁 Iteration Examples

#### Basic Loop

```jinja
{% for related_record in record.related_records_4 %} 
    ID: {{ related_record.id }} Name: {{ related_record.field_name }} 
{% endfor %}
```

**Output:**

```text
ID: 42 Name: Project Alpha ID: 43 Name: Project Beta
```

#### Nested Loop with Related Records

```jinja
{% for parent in record.related_records_2 %} 
    Parent: {{ parent.field_name }} 
    {% for grandparent in parent.related_records_1 %}
        - Grandparent: {{ grandparent.field_name }} 
    {% endfor %} 
{% endfor %}
```

**Output:**

```text
- Grandparent: Company HQ Parent: Department B
- Grandparent: Company HQ
```

### ⚠️ Error Handling

* If the variable record is missing or misspelled, the merge field is removed (substituted by the empty string) from the generated document.
* If an undefined attribute is used record.\<unknown\_attr> , the merge field is removed (substituted by the empty string) from the generated document.
* If delimiters {{ }} contain syntax error (e.g. one of them is missing), the document is not generated. The sequence will stop executing.

### 🎯 Use Cases

#### Document Templates

```jinja
Contract between {{ record.field_company_name }} and: 
{% for client in record.related_records_3 %}
- {{ client.field_name }} ({{ client.field_email }}) 
{% endfor %}
```

**Output:**

```text
Contract between Acme Corporation and:
- Smith & Associates (contact@smith-associates.com)
- Global Solutions Ltd (info@globalsolutions.com)
- Tech Innovations Inc (hello@techinnovations.com)
```

#### API Responses

```jinja
{ 
    "main_record": "{{ record.field_name }}", 
    "related_items": "{{record.related_records_5 }}" 
}
```

**Output:**

```json
{ 
    "main_record": "Project Alpha", 
    "related_items": "[101, 102, 103]" 
}
```

#### Email Templates

```jinja
Dear {{ record.field_contact_name }},

Your order includes the following items:
{% for item in record.related_records_6 %}
- {{ item.field_product_name }}: ${{ item.field_price }}
{% endfor %}

Total: ${{ record.field_total_amount }}
```

**Output:**

```text
Dear John Smith,

Your order includes the following items:
- Wireless Headphones: $149.99
- Bluetooth Speaker: $89.99
- Phone Case: $24.99

Total: $264.97
```

::: tip Relationship Levels
🔗 The same syntax works for **any relationship level** — whether accessing immediate parents/children or records several degrees removed in the relationship hierarchy.
:::
::: warning Performance Consideration
⚡ Retrieving related records can be expensive for records with many relationships. Consider using filtering to fetch only the records you need.
:::
::: danger Syntax Errors
💥 Missing or malformed delimiters `{{ }}` will cause **document generation to fail** and stop sequence execution entirely.
:::

## 🔍 Filtering Records

Traversing relations and fetching related records from the database can be expensive — especially when a record has thousands of parents, grandparents, or children. Performance tests included in this spec have shown that unrestricted queries can result in significant delays.

Therefore, it’s crucial to **fetch only the records you need**, rather than retrieving all related records and filtering them later using `{% if %}` conditions.

To address this, a custom Jinja2 filter called `filter_by` is introduced.

***

### 🔧 Syntax

The `filter_by` filter allows passing **any number of named parameters** that correspond to field values. The filter returns only the records that match the given parameters.

```jinja
record.related_records_<class_id> | filter_by(field1='value1', field2='value2')
```

### 🔧 Allowed parameters

Only Record’s properties and fields are accepted.

### 🔗 Chaining Filters

Multiple filter\_by filters can be chained:

```jinja
record.related_records_<class_id>
| filter_by(field1='value1')
| filter_by(field2='value2')
```

Chained filters use AND logic — meaning the record must match all conditions across the chained filters.

#### 📘 Example 1

```jinja
{% for item in record.related_records_4 
               | filter_by(status='active', is_flagged=True) 
               | filter_by(category='urgent') %}
  - {{ item.name }} ({{ item.status }}, {{ item.category }})
{% endfor %}
```

In this example:

* The first filter\_by matches records with either status == 'active' or is\_flagged == True.
* The second filter\_by limits results further to only those with category == 'urgent'.

Thus, the result includes only records that:

* Have either status 'active' or are flagged

`and`

* Belong to category 'urgent'

#### 📘 Example 2

For a record of Object Class A, retrieve children of Object Class D, where:

* field\_country == "UK" or field\_country == "USA"

`and`

* field\_status == "Active"

```jinja
{{ record.related_records_4
   | filter_by(field_country="UK", field_country="USA")
   | filter_by(field_status="Active") }}
```

This fetches only children of class D that are from the UK or USA and have status set to Active.

::: info
🚀 This approach ensures efficient database queries and significantly reduces processing time for large record sets.
:::

## 📋 Tasks

Returns a list of task IDs ordered by ID descending (newest first).

```jinja
{{ record.tasks_<template_id> }}
```

#### 📘 Example Usage

**Display task IDs from template ID 5**

```jinja
{% for task_id in record.tasks_5 %}
    Task ID: {{ task_id }}
{% endfor %}
```

**Output:**

```text
Task ID: 1234
Task ID: 1233
Task ID: 1225
```

## 🕒 Date and Time Formatting

You can format date and time fields in your templates using the `strftime` filter, which is part of Jinja2’s standard functionality.

This allows you to display dates in a human-readable or locale-specific format.

***

### 🔤 Syntax

```jinja
{{ record.field_<alias>|strftime("%Y-%m-%d") }}
```

* `field_&lt;alias&gt;` – the field that contains a date/time value (e.g., field\_due\_date, created\_at, modified\_at).
* `strftime(...)` – a formatting function that takes a format string compatible with Python's `datetime.strftime()`.

## ❌ Syntax Errors

In the Autologyx Platform, MF syntax errors are handled in a practical and context-aware way, depending on where and how the rendering is triggered.

***

### ⚙️ General Behavior

* If a **merge field doesn't exist** (e.g., incorrect name or missing field), the platform usually replaces it with an empty string (`""`) instead of failing.
* If there's an **invalid Jinja syntax** (e.g., unclosed tag, bad logic), an error is **raised explicitly** during rendering.

***

### 🧪 Where Errors Are Handled

| Context                                               | Behavior                                                                                                            |
|-------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------|
| **Synchronous API test calls**  (e.g., “Test” button) | The syntax error is returned in the **API response**, so it can be seen immediately.                                |
| **Background task rendering** (e.g., sequences)       | The error is **not shown to the user directly** but is instead reported to **Sentry** for monitoring and debugging. |
| **Missing field or safe failure**                     | Returns `""` (empty string), so templates don't break for missing but optional values.                              |

***

### 🧵 Internal Logic

***

### 📌 Example

**Invalid field name (safe fail):**

```jinja
Hello {{ record.fake_field }}!
```

✅ Output:

```
Hello !
```

**Invalid syntax (error):**

```jinja
{{ record.name 
```

❌ Output (API response or Sentry):

```
TemplateSyntaxError: unexpected end of template, expected '}}'
```

### 🧠 Notes for Users

::: warning

* 🚀 Always test templates using the “Test” button or API call before deploying them in sequences.
* 🚀 Monitor Sentry for silent background rendering failures.
* 🚀 Avoid relying on automatic empty fallback if the field is critical.
  :::

---

---
url: /api/websockets.md
---

# 🔌 Catalyst WebSockets API

Welcome to the Catalyst WebSockets API reference.

This section documents the WebSocket-based APIs used to deliver real-time updates in Catalyst. These APIs are designed to provide immediate visibility into changes so that updates to rows, cells, and record counts can be reflected without requiring a page refresh.

The connection is secured using the `wss` protocol and requires authentication.

Authentication is based on a UUID v4 value generated by the Catalyst API endpoint:

* [GET /api/users/ws-auth/](/api/websockets/)

Example connection string:

```text
wss://catalyst.autologyx.com/ws/events/object-records/?uuid=eyJhbGciOi
```

::: info
A related technical design is available here: [Real time updates Technical Design](https://autologyx.sharepoint.com/:w:/s/Dev/EfhpAB9IoIVAk_SbXsWGaMIBgB-LgvAty0sFQXZpgx6cCQ?e=cNPmjT)
:::

## 📚 What this section covers

This section provides technical reference material for WebSocket endpoints that broadcast real-time Catalyst updates to connected clients.

Use these pages when you need to understand:

* how WebSocket authentication works
* how the connection is established
* what type of events are broadcast
* how batching, buffering, and reconnection behaviour work

## 🧩 General overview

Each endpoint broadcasts updates for up to 1,000 items every 5 seconds.

If the `message_limit` of 1,000 events is exceeded, the remaining events are stored in a buffer and included in the next WebSocket response when either:

* the next `message_time` interval is reached, or
* another `message_limit` threshold is triggered

If there are any events stored in the buffer when the WebSocket connection is interrupted, for example for example due to disconnection, those buffered events are discarded and are not broadcast when the client reconnects.

Only new events generated after the connection is re-established are sent to the client.

## 👥 Who this documentation is for

This section is primarily intended for:

* developers and integrators working with real-time Catalyst updates
* internal technical teams implementing event-driven UI behaviour
* engineers who need to understand connection, buffering, and delivery characteristics

## 🧭 How to use this documentation

A good way to use this section is:

1. start with the authentication flow for obtaining the WebSocket UUID
2. review the endpoint-specific page for the resource you want to subscribe to
3. check the documented batching and buffering behaviour before designing client-side handling
4. validate reconnection behaviour in any production-facing implementation

## ⚠️ Notes

::: warning
This section documents technical and service-level WebSocket APIs. It should be used as implementation reference material and not treated as end-user documentation.
:::

::: tip
Use the sidebar to navigate directly to the resource-specific WebSocket pages in this section.
:::

---

---
url: /api/merge-fields/merge-fields.md
---

# 🔧 What Are Merge Fields?

**Merge Fields (MF)** are dynamic placeholders—template tags—that allow the insertion of live, contextual data into documents, emails, and other templates rendered by the ALX system. They are powered by the **Jinja2** templating engine to provide greater flexibility and readability.

Merge Fields are resolved at render time and replaced with actual data pulled from records in the system (e.g., users, documents, tasks).

***

## 🔍 Basic Usage Example

```jinja
{{ user.first_name }} {{ user.last_name }}
{{ document.title }}
{{ base64(document.content) }}
```

Merge Fields can also contain conditional logic or loops:

```jinja
{% if user.is_admin %}
  Administrator: {{ user.email }}
{% endif %}

```

## 📦 Technical Foundation

Jinja2 Template Engine

Merge Fields in ALX are implemented using Jinja2, a fast and expressive templating engine for Python. It provides the syntax and context resolution needed to work with dynamic fields.

📚 [Jinja2 Official Documentation](https://jinja.palletsprojects.com/en/stable/templates/)

## 🎯 Purpose of Merge Fields in ALX

Merge Fields serve as a dynamic link between your data and rendered content in ALX. They are frequently used in:

1. Document generation - document templates
2. Email templates and system notifications
3. Sequencer Actors: API Call, Send Message, Variables, AI Actors
4. Web-based dynamic content views
5. Word Add-in plugin

Merge Fields allow you to write generic templates that adapt to the actual content of a record at runtime.
Merge fields allow inserting Object Record data in document templates, API call actor parameters, emails, and other resources relevant to Object Records.

## 🧩 Overview of Supported Merge Field Types

The ALX system supports a wide range of Merge Fields. Detailed sections will follow, but broadly, MF types include:

* `User merge fields` – full user objects, user groups, active-only users
* `Document merge fields` – metadata and file contents
* `Base64 merge fields` – useful for embedding files in templates
* `Record properties` – access any custom field from a record
* `System fields` – like current date, time, or logged-in user
* `Related records` – for accessing nested relationships
* `Loop Item` – for accessing items from Loop actor

## ⚙️ System Merge Fields

System merge fields are **global system variables** that are available in every context regardless of the currently processed object (record, user, etc.). They are not tied to any specific object and contain information about the system, environment, and execution context.
The system merge fields are organized into four main categories:

### 👤 Admin Context

Admin-related merge fields provide information about the system administrator:

### 📌 Example usage

```jinja
{{ admin_first_name }} 
{{ admin_last_name }} 
{{ admin_email_address }} 
{{ admin_phone_number }} 
{{ admin_job_title }} 
{{ admin_email_signature }}
```

### 🏢 Client Context

Client-related merge fields provide information about the current client:

```jinja
{{ client_name }} 
{{ client_url }}
```

### 📅 Date and Time Context

Date and time merge fields provide current temporal information:

```jinja
{{ current_date }} 
{{ current_datetime }}
```

### 🔧 Constants Context

Constants are user-defined values available throughout the system with special prefix `constants`:

```jinja
{{ constants.API_BASE_URL }} 
{{ constants.COMPANY_NAME }} 
{{ constants.SUPPORT_EMAIL }}
```

### 🔄 Loop Item Context

The loop\_item merge field is a dynamic reference to the currently processed item within a Loop actor.
Loop Item is user-defined value available throughout the system with special prefix `loop_item`:

```jinja
{{ loop_item }} 
{{ loop_item.name }} 
{{ loop_item.key1.key2 }}
```

### ⚙️ Usage Contexts

System merge fields work in all places where merge fields are supported:

* Document templates
* Email templates
* Sequencer (all actors)
* API responses
* Workflow notifications
* Custom scripts

### 📋 Complete Usage Example

**Template:**

```jinja
Dear {{ client_name }},
This email was sent by {{ admin_first_name }} {{ admin_last_name }} on {{ current_date }} from {{ client_url }}.
API endpoint: {{ constants.API_BASE_URL }}/users
Best regards, {{ admin_email_signature }}
```

**Output:**

```text
Dear Acme Corporation,
This email was sent by Joe Doe on 2020-02-05 from [http://client.testserve](http://client.testserve).
API endpoint: https://api.example.com/users
Best regards, Signature
```

::: tip Global Availability
🌐 All system merge fields are globally available and don't require any specific object context to function.
:::

::: warning Constants Prefix
⚠️ Constants merge fields require the `constants.` prefix, while other system merge fields can be used directly without prefixes.
:::

## 🧾 Summary

Merge Fields are a core part of dynamic content generation in ALX. Backed by Jinja2, they allow templates to remain generic and adaptable while still outputting rich, data-driven content. Understanding how they work is essential to building powerful document templates and user-facing messages.

## 📘 What's Next?

A specific and powerful category of merge fields relates to **Object Records**—these include field references, nested relationships, and dynamic access to custom properties.

> 🧭 These will be covered in detail in the [Object Record Merge Fields](/api/merge-fields/resources/object-record-merge-fields), where we explain how to access and format data from related records, such as linked users, documents, or custom model instances.

---

---
url: >-
  /knowledgebase/system-configuration/using-docusign-with-catalyst/1.-introduction.md
---

# 1. Introduction

DocuSign is a popular application among our customers for sending and signing documents. In the main, these tend to be agreements or contracts which require more than one individual to sign.

However, others use it to send multiple documents at the same time to one recipient for their signature.

**To ensure seamless integration with DocuSign**, we have developed a dedicated Authentication object in Catalyst. This allows the safe and secure storage of your DocuSign account credentials for use in automated document workflow.

The Authentication object ensures that the Catalyst system is always authenticated to access the DocuSign account. It does this by generating new access tokens before the previous ones expire.

**In practical terms**, this means that you can store a document template against an Object class and, at the appropriate point in your workflow sequence, generate the document for a record, create the DocuSign envelope, and send the document.

DocuSign will then ensure that the document is sent to the specified recipients, allowing them to sign in the order you have configured. Finally, Catalyst can be used to retrieve and store the fully signed document.

**Because manual intervention is not required** during this process, it will save time and effort, as well as providing documents of a high quality in terms of both format and data accuracy.

---

---
url: >-
  /knowledgebase/system-configuration/using-docusign-with-catalyst/2.-setting-up-a-free-developer-docusign-account.md
---

# 2. Setting up a free developer DocuSign account

If you are already a DocuSign customer, you will no doubt have a test environment in which to set up new document templates and test them out before switching them to your live account.

However, if you are not yet a DocuSign customer and want to try it out first, you can create a free developer account which you can use in your Catalyst dev environment.

Go to <https://go.docusign.com/o/sandbox/>

## Complete the form

Complete the form shown below:

![Screenshot](../../../images2/zendesk_17124516656797_001_d763ae1c6fdb.png)

Click **GET STARTED**.

You will then see the screen below asking you to activate your account from an email.

![Screenshot](../../../images2/zendesk_17124516656797_002_3584eabd5e87.png)

From the link in the email, you’ll need to choose a password and a password question/answer.

Once you are logged in, you’ll be taken to **Home**, which looks like this:

![Screenshot](../../../images2/zendesk_17124516656797_003_9165fa2615a5.png)

## Find the account details

Click **Settings** in the top menu, then in the left-hand navigation menu go to **Integrations / Apps and Keys**.

Here you will find **three key pieces of information**:

![Screenshot](../../../images2/zendesk_17124516656797_004_122feeb968dd.png)

* **User ID** — needed when setting up a DocuSign Authentication Object (auth object) in Catalyst.
* **API Account ID** — needed as a suffix to the URL in API calls from Catalyst.
* **Account Base URI** — the starting point for the URL in API calls from Catalyst. [https://demo.docusign.net](https://demo.docusign.net/)

## Next steps

The following articles explain how to:

```json
[Set up an Authentication object for DocuSign](/knowledgebase/system-configuration/using-docusign-with-catalyst/3.-creating-an-authentication-object-for-use-with-docusign/)
```

[Configure an API call to create a DocuSign envelope](/knowledgebase/system-configuration/using-docusign-with-catalyst/4.-configuring-an-api-call-to-create-an-envelope-in-docusign/)

## Useful info

Information for developers using DocuSign can be accessed here: <https://developers.docusign.com/>

---

---
url: >-
  /knowledgebase/system-configuration/using-docusign-with-catalyst/3.-creating-an-authentication-object-for-use-with-docusign.md
---

# 3. Creating an Authentication object for use with DocuSign

Before you start, it is important to understand the purpose of the auth object. In simple terms, it does two things:

* Provides refresh tokens to generate new access tokens before they expire, to ensure that the Catalyst system is always authenticated to “access” the DocuSign account
* Attaches the access token to the headers (the address for API calls)

## Create the authentication object

In the Catalyst main nav menu, go to **Administration / Authentication objects**.

**NB:** You must have either a Super admin account type or a Role where Create/Edit are enabled for Authentication Objects, as shown below:

![Picture 1.png](../../../images2/zendesk_17129255004573_001_643d257d4599.png)

From the Authentication objects list, click **+ Create**.

Give the auth object a name.

Bear in mind that you can set up your authentication object in your dev system with a dev/test/sandbox DocuSign account. This can be migrated to live and then changed to use the details for your live DocuSign account, but you will have to go through the following steps to make each authentication object live. [Click here](/knowledgebase/system-configuration/using-docusign-with-catalyst/8.-system-migrations-and-docusign-authentication-objects/) for more information.

![Picture 2.png](../../../images2/zendesk_17129255004573_002_8ea14f2f7e45.png)

In the **Provider** field, select **DocuSign**. The following fields will be presented:

![Picture 3.png](../../../images2/zendesk_17129255004573_003_44e72d392220.png)

## Copy values from DocuSign

From your DocuSign **Settings / Integrations / Apps and Keys**, copy and paste the **User ID** into the **User ID** field in the authentication object.

Back in DocuSign, click the blue **Add App and Integration Key** button. You will be prompted to give the new app a name; click **Create App**.

![Picture 4.png](../../../images2/zendesk_17129255004573_004_df772c59005c.png)

![Picture 5.png](../../../images2/zendesk_17129255004573_005_d498a0ef7ec4.png)

Copy the **Integration Key** into the **Client ID** field in the authentication object in Catalyst.

Go to the **Service Integration** section of your DocuSign app. Click **Generate RSA**.

A pop up will provide the Public and Private Keys.

![Picture 6.png](../../../images2/zendesk_17129255004573_006_d74fb5e78551.png)

Copy the **Private Key**. It is a good idea to save this to a notepad as once you close the window you will no longer be able to access these keys. Paste this into the **Private RSA Key** field in the auth object in Catalyst.

You won’t need the Public Key. This is used by DocuSign in the encryption and decryption process when the two systems are sending and receiving data.

## Add URIs and origin URLs

Go to **Additional settings** and click **Add URI**. You will need to add two.

* The first is the URL of the Catalyst instance for which you are creating the app.
* The second is: <http://localhost> – this is used to generate a one-time access token. Following this, Catalyst will use refresh tokens as previously described.

Click **Add origin URLs**; again, you will need to add the Catalyst instance URL as one and <http://localhost> as the second.

**NB:** Do not include trailing forward slash at the end of your URL.

This section is important because it acts as the allowed domains list. It provides an added security measure to stop hackers accessing the account; in other words, to prevent cross scripting attacks.

![Picture 7.png](../../../images2/zendesk_17129255004573_007_e6e2e3436cce.png)

Having selected the call types you require for your integration (most commonly used will be **GET**, **POST** and **PUT**), click **Save**. You will be taken to your Apps and Integration Keys list where your new app will appear in alphabetical order.

![Picture 8.png](../../../images2/zendesk_17129255004573_008_2578180eced7.png)

## Grant permissions to the app

**Next,** you need to grant permissions for the API to access to the new app.

You will need the link below but ensure that you copy and paste your Client ID (Integration Key from your DocuSign app) in place of the redacted one shown. The name, also highlighted in the link, can be anything you wish. Note the link shown here is for a developer or test account - the first part of the URL contacts....account-d.docusign.

<https://account-d.docusign.com/oauth/auth?>response\_type=code\&scope=openid signature impersonation\&client\_id=6810be95-f6d2-4db5-b686-baxxxxxxxxx\&state=clientvalue\&redirect\_uri=<http://localhost/>

Put this into a new browser tab/window.

You will see the following screen:

![Picture 9.png](../../../images2/zendesk_17129255004573_009_2af6aa0cc5b7.png)

Click **Allow Access**.

You will see the below screen. Don’t be concerned that it looks like it hasn’t worked. This is what you want to see.

![Picture 10.png](../../../images2/zendesk_17129255004573_010_610d8c14cd45.png)

## Test and save

**Finally,** return to your auth object.

Ensure that the selection in the **Host** field is **account-d.docusign.com** for a developer or test account. Alternatively, if your Authentication object is for a live account, use **account.docusign.com**.

![Picture 11.png](../../../images2/zendesk_17129255004573_011_fb79d9e0c36e.png)

Click **Test authentication object**.

You should see **Authentication success!**

![Picture 12.png](../../../images2/zendesk_17129255004573_012_4f547e4f100a.png)

Save the auth object.

Once the auth object has tested successfully, for security, it is recommended to remove <http://localhost> from the URI and the URL in your DocuSign app.

The following article will explain [how to configure an API call to create a DocuSign envelope](/knowledgebase/system-configuration/using-docusign-with-catalyst/4.-configuring-an-api-call-to-create-an-envelope-in-docusign/) where you will use your Authentication object.

## Useful info

The maximum number of Authentication objects you can have in your system is 100.

---

---
url: >-
  /knowledgebase/system-configuration/using-docusign-with-catalyst/4.-configuring-an-api-call-to-create-an-envelope-in-docusign.md
---

# 4. Configuring an API call to create an envelope in DocuSign

Before you go to the Sequencer, you will need an Object class with a document template. The template will need to be generated and saved to a field on the Record.

You might find this article about **[automatic document generation](/knowledgebase/system-configuration/working-with-document-templates/automatic-generation-of-documents-via-the-sequencer/)** useful, as it describes the steps required for the above scenario.

Alternatively, the API call might follow an "Update object record" type task where a user is required to upload a document to a field.

DocuSign uses “envelopes” to manage the sending and signing of documents. Therefore, the API call from Catalyst needs to be able to create an envelope.

This is a POST call using JSON Data.

![post.png](../../../images2/zendesk_17134457944477_001_3b5827d64777.png)

## Authentication

For Authentication, select Auth Object. In the Auth Object field, select your DocuSign authentication object.

Always give your API call a name that is descriptive of the content. This will help if debugging is ever necessary.

## URL structure

The URL is made up of:

* the Account Base URI (found at the top of your DocuSign account Apps and Keys page)
* followed by `/restapi/v2/accounts/`
* then the API Account ID (also found at the top of your DocuSign Apps ad Keys page)
* then `/envelopes`

So an example is:

<https://demo.docusign.net/restapi/v2.1/accounts/3ee6ec79-6dd7-409e-84f0-f8dxxxxxx/envelopes>

In this case, “demo” in the URL denotes that this is for test purposes rather than a “live” account.

The URL for a live DocuSign account will look like something like this:

<https://eu.docusign.net/restapi/v2.1/accounts/947229c3-c654-45xx-xxxx-xxxx/envelopes>

## API call body

The body of the API call (Parameters) must identify the following:

* Recipients, of whom Signers and Carbon Copies can both be subsets. The type of recipient will determine the email they are sent.
* The document(s) to be signed.

You can also use the API call to specify wording to be used in email notifications from DocuSign.

The following example call body is shown in a JSON editor so that you can view the full set of Parameters.

![json ex.png](../../../images2/zendesk_17134457944477_002_299bec99c1f3.png)

## Explanation of call parameters

* **Row 2** – email subject for notification to send the document to “signers”, asking them to sign. This can be any value. See 1 in below screenshot.

![Picture 14.png](../../../images2/zendesk_17134457944477_003_ce95553ba5b2.png)

Note: 2 in the above screenshot shows the name and email address of the DocuSign account holder.

* **Row 3** – this is the status for the envelope once the email has been sent.
* **Row 5** – email subject for notification to signers when signing is complete.
* **Row 7** – to have emails sent in English.
* **Row 9** – shows the start of “recipients”. Each recipient must have a unique ID.
* **Row 10** – subset “signers”, of which there are two.
* **Row 12** – first recipient’s email address, shown as merge field from Catalyst.
* **Row 13** – first recipient’s name. In this case “hard coded” but could be a merge field. See 3 in above screenshot.
* **Row 14** – `routingOrder` used to determine that recipient 1 will receive the document for signing first. (NB if you don’t have an order in which the document(s) must be signed, this can be omitted.
* **Row 15** – recipient ID. In this case, "1". See row 20 under “signHereTabs”. The `anchorString` `/s1/` is placed in the document template where this signer’s signature is to be positioned. Remember to use white text colour to hide the `anchorString` in the document template – shown in the sample template below.

![Screenshot 2024-02-26 at 17.17.26.png](../../../images2/zendesk_17134457944477_004_cb7779d45422.png)

When the recipient reviews the document from the email, they will find the sign button where the `anchorString` was positioned.

![Picture 15.png](../../../images2/zendesk_17134457944477_005_cfe3a5ad1937.png)

* **Row 27** – email address for second signer. This one is a merge field from a related object class as is the signer’s name shown on row 28.
* **Row 29** – `routingOrder` for second signer so that they will only receive the document(s) once the first signer has completed the signing process.
* **Row 35** – note the `anchorString` for the second signer includes their recipient ID, in this case "2".
* **Row 42** – subset of recipients is “carbonCopies”, of which there is one. Name and email address are hard coded for this team but could be merge fields.
* **Row 46** – recipient ID for this team ie "3".
* **Rows 47 to 50** – give the detail for the email the cc is to receive once signing is complete. See below screenshot.

![Picture 16.png](../../../images2/zendesk_17134457944477_006_612b91dd9a44.png)

* **Row 55** – “documents”. In this example, there is only one but a DocuSign envelope can contain up to 130 unique documents.
* **Row 58** – name. This is the name of the document as on the email to signers. See 4 in previous screenshot. You can use merge fields to personalise the document name, if required, with case, matter, candidate name or reference number.
* **Row 60** – the merge field for the generated document in base64 format.

## Useful info

1. Other tabs can be added. Another commonly used tab is `dateSignedTabs`, which will add the date the document is signed. The code refers to the `documentId` and also uses an `anchorString`:

"dateSignedTabs": \[

            {

              "documentId": "1",

              "anchorString": "/d1/",

              "fontSize": "Size10",

              "font": "Tahoma"

            },

            {

              "documentId": "2",

              "anchorString": "/d18/",

              "fontSize": "Size10",

              "font": "Tahoma"

            }

          ]

In this example, `/d1/` will position the date on which the recipient signs document ID 1 and `/d18/` will position the date on which they sign document ID 2.

If needed, font size and font type can be stipulated. Again, when the `anchorString` is added to the document template, white text should be used to hide it.

2. For more information on envelope/document limits: <https://support.docusign.com/s/articles/DocuSign-Document-and-Envelope-File-Size-Limitations?language=en_US>

---

---
url: >-
  /knowledgebase/system-configuration/using-docusign-with-catalyst/5.-monitoring-the-status-of-your-docusign-envelope.md
---

# 5. Monitoring the Status of your DocuSign Envelope

Having created your DocuSign envelope via an API call from Catalyst, the DocuSign application will handle the sending and signing of the document(s) on the basis of the Parameters in that API call.

However, you can use Catalyst to monitor the status of the envelope and use changes in the status to take further actions.

The following steps explain how to set up the API and variable actors needed to capture and monitor this status in the same sequence as where the DocuSign envelope is being created.

## Steps

1. **Capture the envelope ID.** Take a trigger from the API call which is creating the DocuSign envelope and connect it to a local variable. The trigger configuration will simply be “When Actor completed". This variable will be used to capture the DocuSign envelope ID. Give it a name in the Variable field and configure it as shown below using {{output.envelopeId}} as the Value.

![ss1.png](/knowledgebase/images/img_17196202032925_1776895869.png)

2. **Create the status-check API call.** Take a trigger from the variable and connect it to a new API actor. Again, the trigger configuration will be “When Actor completed". This API call will be used to get the signing status. It is a GET request using JSON Data. Having selected your DocuSign auth object, give the API call an appropriate name.

3. **Set the URL.** The URL is the same as for creating the envelope with the addition of /{{variables.Variable}}. In this case: https://demo.docusign.net/restapi/v2.1/accounts/3ee6ec79-6dd7-409e-84f0-f8dxxxxxx/envelopes/{{variables.contract\_env\_id}}

**NB:** You can right click at the end of the URL field and merge in the correct variable as shown in the screenshots above and below.

![ss2.png](/knowledgebase/images/img_17196202032925_1776895869.png)

4. **Save and test the API call.** As always, you will need to test the call to make it live. When successful, the test log will look similar to the below. Included in the data returned will be the status.

![ss3.png](/knowledgebase/images/img_17196202032925_1776895869.png)

5. **Capture the envelope status.** Take a trigger from the API and connect it to another local variable; the trigger configuration will be “When Actor completed". This variable will be used to capture the envelope status.

6. **Configure the status variable.** Configure the variable as below using {{output.status}} as the Value. Save this.

![ss4.png](/knowledgebase/images/img_17196202032925_1776895869.png)

7. **Loop back to re-check the status.** Take a trigger from this variable and loop back to the GET API call. This time the trigger condition will have a delay built in. You need to consider what is an appropriate timescale for the delay because effectively this determines the frequency by which the envelope status will be checked. We have used 4 hours.

![ss5.png](/knowledgebase/images/img_17196202032925_1776895870.png)

8. **Add supplementary trigger conditions.** The trigger will need supplementary conditions as shown below.

**Note that these conditions all:**

* refer to the value of the variable which holds the envelope status
* are all negative, ie not this value
* all values are in lower case

![ss6.png](/knowledgebase/images/img_17196202032925_1776895870.png)

**To clarify:** the sequence will now create the DocuSign envelope and capture the envelope ID. The envelope ID is used to get its status. The status is stored and 4 hours later the status is re-checked. The status value will be updated if it has changed. This cycle will repeat every 4 hours until the status is completed, declined or signed.

9. **Optionally update a record field with the status.** An update actor can be connected from the envelope status variable in order that the status can be held in a field on the record. This value can then be used:

* as a column header in the records list
* in task templates, document templates, send message actors and subsequent trigger conditions
* in reporting

The below trigger condition shows the field to be updated at 1 and the variable which will populate the field with its value at 2.

![ss7.png](/knowledgebase/images/img_17196202032925_1776895870.png)

**Field as a column header below.**

![ss8.png](/knowledgebase/images/img_17196202032925_1776895871.png)

10. **Optionally send messages based on status changes.** A send message actor can also be connected from the signing status variable in order that the status can be used to send messages to individuals or teams as this changes.

The below screenshot shows an email being sent to the contracts team on the basis of the status changing to “declined”.

![ss9.png](/knowledgebase/images/img_17196202032925_1776895871.png)

**Remember to save your sequence frequently.**

---

---
url: >-
  /knowledgebase/system-configuration/using-docusign-with-catalyst/6.-monitoring-the-signing-status-of-individual-recipients.md
---

# 6. Monitoring the signing status of individual recipients

*This section assumes that you have read the previous section about capturing the envelope status, as it is not as detailed here.*

Similar to the envelope status, you can use Catalyst to monitor the status of individual recipients of any document.

## Recipient status codes

![codes.png](../../../images2/zendesk_18617422889373_001_c452e1a5bc50.png)

Although DocuSign’s API documentation suggests that you can retrieve information about each individual recipient using /envelopes/{{variables.contract\_env\_id}}/recipients/1, for example, we have found that this errors.

Instead, take a trigger from the Local variable in which the envelope ID has been stored and connect it to a new API Call actor. **Configure it as a GET request** as shown below.

![1a.png](../../../images2/zendesk_18617422889373_002_e0ea279a94b5.png)

**URL suffix:** /envelopes/{{variables.contract\_env\_id}}/recipients. This effectively returns the status of each recipient of the envelope.

When successfully tested, the return will show information about the recipients and will include their ID from the original envelope creation, as well as the status you wish to capture.

![2.png](../../../images2/zendesk_18617422889373_003_0c4702803c16.png)

Take a trigger from this API Call actor and connect it to a new Local variable. The trigger configuration will be “When Actor completed".

**Configure the Local variable** as shown below.

*Note: The Recipient ID is used to capture the signing status for the relevant signee.*

![3.png](../../../images2/zendesk_18617422889373_004_d1c4f3573af5.png)

The Recipient status can then be transferred to a record field via an Update Record actor.

![4.png](../../../images2/zendesk_18617422889373_005_b9748e2fe2b2.png)

## Monitoring and rechecking recipient status

To monitor the Recipient status and have it update in Catalyst as the document moves through the DocuSign process, a loop back to the API call which GETS Recipient information is needed.

Take a trigger from the local variable and connect it to the API Call actor. **Add a delay**, but consider what is an appropriate timescale for the delay because, effectively, this determines the frequency by which the Recipient information will be checked. We have used 4 hours.

The trigger will require additional conditions to discount statuses which mean that a recheck is not needed. These are likely only to be “completed” and “declined”. However, see the table at the end of this section for an explanation of all recipient status codes.

*Note: all status values must be in lower case.*

*![5.png](../../../images2/zendesk_18617422889373_006_eb7de86845be.png)*

## Capturing additional recipients

The status for additional Recipients can be captured by adding further Local Variables and Update Record actors, as below.

![6.png](../../../images2/zendesk_18617422889373_007_3923d7f8b911.png)

*Note: this time the variable is looking for the signer.status for recipientId 2.*

It is important to list the signers in the correct order in the API call which creates the envelope, and give them related Recipient IDs, so that you can be sure which API call output relates to which signer.

The Recipient status fields can be displayed in the records list and used in task templates, document templates, send message actors and subsequent trigger conditions.

![7.png](../../../images2/zendesk_18617422889373_008_a84eaf4c94f2.png)

## Useful info: Recipient status code descriptions

The screenshot below provides descriptions of the recipient status codes.

![8.png](../../../images2/zendesk_18617422889373_009_b51af85a61b1.png)

---

---
url: >-
  /knowledgebase/system-configuration/using-docusign-with-catalyst/7.-how-to-retrieve-the-signed-document-and-store-within-catalyst.md
---

# 7. How to retrieve the signed document and store within Catalyst

*This section assumes that you have read section 5, about capturing the envelope status.*

## Retrieve the signed document

Take a trigger from the local variable which is storing the envelope status and connect to a new API Call actor.

The trigger configuration will be “When Actor completed” but with an additional condition referencing that the variable envelope status is “completed”, as shown below.

![doc1.png](../../../images2/zendesk_18618571866013_001_26e511e2efc6.png)

This API call will be used to retrieve the signed document when the envelope status is completed. It is a GET request using JSON Data. Having selected your DocuSign auth object, give the API call an appropriate name.

The URL is the same as for creating the envelope, with the addition of /{{variables.Variable}}/documents/ID/. In this case: <https://demo.docusign.net/restapi/v2.1/accounts/3ee6ec79-6dd7-409e-84f0-f8dxxxxxx/envelopes>/{{variables.contract\_env\_id}}/documents/1/

![doc2.png](../../../images2/zendesk_18618571866013_002_36dcedf0fe05.png)

The DocuSign envelope in this example has only one document.

Remember: the original envelope creation API call included details of the contract document only, as shown below.

![doc3.png](../../../images2/zendesk_18618571866013_003_5210144befac.png)

The “1” in the URL is the ID of that document.

## Pick the retrieved document

Take a trigger from the API Call actor and connect to a new Document Picker actor. The trigger configuration will be “When Actor completed”.

Right click on the Document Picker actor and select “Configure”.

In the Source field, select “API Call document”.

![doc4.png](../../../images2/zendesk_18618571866013_004_6d54a052ee0a.png)

**Important:** at this stage, note the check box, “Combine results”, in the Document Picker configuration.

![doc5.png](../../../images2/zendesk_18618571866013_005_7ec95bca1bcb.png)

If enabled (checked), the document picker will pick up all the documents in the sequence path leading to it. If not enabled (unchecked), the document picker will only pick the document from the immediately preceding sequence actor.

**For example, in the sequence workflow below:**

![doc6.png](../../../images2/zendesk_18618571866013_006_c1c87d10b8fb.png)

* The Update Record actor labelled 3 will update the document field with documents generated by:

  * the API call actor labelled 1
  * the DocAuto actor labelled 2

  because both the preceding Document Pickers have “Combine results” on.

* The Send Message actor labelled 4.2 will contain attachments from:

  * the API call actor labelled 1
  * the DocAuto actor labelled 2
  * the DocAuto actor labelled 4.1

  because all three of the preceding Document Pickers have “Combine results” ticked, ie ON.

* The Send Message actor labelled 5.2 will contain an attachment only from the DocAuto actor labelled 5.1 because the Document Picker immediately preceding this Send Message actor has “Combine results” unticked, ie OFF.

## Store the document on the record

Take a trigger from the Document Picker actor and connect to a new Update Record actor. The trigger configuration will be “When Actor completed”.

Right click on the Update Record actor and configure it to take the document from the picker and add or replace, as appropriate, in the required Document type field.

![doc7.png](../../../images2/zendesk_18618571866013_007_3c2407fa274d.png)

If your DocuSign envelope contains more than one document which you want to retrieve, you will need to configure separate API Call, Document Picker and Update Record actors for each one.

## View or use the retrieved document

The retrieved document can be attached to an email, as shown.

![doc8.png](../../../images2/zendesk_18618571866013_008_71693ffbcc8d.png)

It can be viewed in the field from the Records list.![doc9.png](../../../images2/zendesk_18618571866013_009_df5aba6eeaf1.png)

## Best practice

**Best practice:** when creating workflow in a sequence, it is helpful to label your actors. Simply right click and select “Properties”.

![doc10.png](../../../images2/zendesk_18618571866013_010_40749a3201da.png)

This will provide you with a free-text box, labelled “Name”, in which to enter a description for the actor. Doing this will mean that your sequence is easier to understand when other users have to refer to it or make amendments at a later date.

---

---
url: >-
  /knowledgebase/system-configuration/using-docusign-with-catalyst/8.-system-migrations-and-docusign-authentication-objects.md
---

# 8. System migrations and DocuSign Authentication objects

Authentication objects are mapped during a System Migration, but their configuration is not over-written.

**What this means:** You must have Authentication objects with the same name in both your dev and live systems, but they do not necessarily have to contain the same settings.

In other words, you could have a DocuSign auth object simply called “DocuSign” in your dev Catalyst system configured for Host account-d.docusign.com, and an auth object with the same name in your live Catalyst system configured for Host account.docusign.com.

However, some users find it easier to configure and manage two DocuSign Authentication objects in both dev and live systems. This is because the Account Base URI is usually different in a DocuSign test environment, and the API Account ID could potentially be different too.

## Example approach

**Test auth object:** In one auth object, using a test account, the Host selection would be account-d.docusign.com. This auth object would be used in your dev system to test all API calls and ensure that everything is working as expected.

![Screenshot 2024-02-26 at 22.10.22.png](/knowledgebase/images/img_17140401129885_1776895878.png)

**Live auth object:** Having completed this testing, you would then change the API configuration to use the second auth object, where the host selection is account.docusign.com and the credentials for your live DocuSign account are stored.

## Important

When using this method, you must ensure that the URL in the API call contains the correct Account Base URI and API Account ID. You will have to test the API call once more to make it active prior to a system migration.

---

---
url: >-
  /knowledgebase/system-configuration/sequences-for-relational-records/a-guide-to-using-the-relation-lookup-and-sequence-runner-actors-together.md
---

# A guide to using the Relation Lookup and Sequence Runner actors together

Before you can use the Relation Lookup actor, your Catalyst system must have a relational model defined.

Find out more about the [relational modeller and how to create one](/knowledgebase/system-configuration/relational-modeller/what-is-the-relational-modeller/).

For the purpose of this article, we will use the relational model shown below:

|  |  |
| --- | --- |
|  | Employee Management is the root parent object class; it has one child object class called Employees.  A record in this class can have none, one or more Employees records related to it. More than one Employee Management record can contain the same child record. |
| Employees is the middle object class of three levels in the model. Its parent is Employee Management and its child is object class, Employment Contracts.  A record in this class can have none, one or more children (Employment Contracts) related to it. More than one record can contain the same child record. |
| Employment Contracts is the child of Employees and grandchild of Employee Management.  A record in this class has no children. |

The scenario is that at some point in a sequence which is running against the Employee object class, we need to identify all Employment Contracts of the type PAYE.

"Contract Type" is a single select field on the Employment Contracts object class. It has three options, these are: PAYE, Limited Company and Agency Worker (temp), as shown below.

![](../../../images2/zendesk_11043287623965_002_9b7410c0aead.png)

We can use a Relation Lookup actor in the Employee sequence to find the required Employment Contract records.

However, as we want to assign a task for a user to review these contracts, we first need to prepare the sequence for object class Employment Contracts.

## Create the Employment Contracts sequence

From the main navigation menu, click System Configuration. Then click Sequences.

In the Sequences list, click the +Create button.

Enter the sequence properties: name; a description, if required; select the Employment Objects class, and if appropriate add one or more default task assignees.

![](../../../images2/zendesk_11043287623965_003_42196eb68768.png)

Click Save. Your sequence will appear at the top of the sequences list. It will be paused by default.

![](../../../images2/zendesk_11043287623965_004_dbf6e05fcce6.png)

Either double click on the row for your newly added sequence or, in the Actions menu, select **Edit design**.

The sequence canvas will be blank other than the Employee Contracts object class being shown at the top:

![](../../../images2/zendesk_11043287623965_005_e00435aa9d40.png)

Click **Edit** in the horizontal menu at the top of the sequence.

Select the Create task actor from the left-hand menu and drop it onto the canvas; right click on it, select configure and select the required task template; save.

Drag a trigger connector from Employment Contracts to the task actor. The Trigger configuration will open.

In the second field from the left, select "Sequence Activated".

![](../../../images2/zendesk_11043287623965_006_77d52cee0383.png)

This means that when we activate this sequence from the Employees sequence via the Sequence Runner actor, the selected task will be created for all Employment Contracts records which match the conditions we configure in the Relation Lookup actor.

Click Save in the trigger configuration dialog box, then click Save in the vertical menu at the top of the sequence.

![](../../../images2/zendesk_11043287623965_007_f9aad382299e.png)

When you see the "Sequence saved successfully" confirmation, you can click OK and navigate away from the sequence.

## Configure the Employees sequence

Go back to the sequences list and double click to open the Employees sequence in which you want to perform the lookup to the Employment Contracts object records.

Click **Edit**.

Drag and drop a Relation Lookup actor onto the canvas. Drag a trigger connector from the sequence object you wish to connect it from.

In this case, it is being triggered on completion of a task called "Performance Review".

Right click on the Relation Lookup actor and select **Configure**.

The Relation lookup configuration dialog box will open. Here you have the option to lookup Children or Parent records.

![](../../../images2/zendesk_11043287623965_008_e95d700abe81.png)

In this case we are only interested in the children records - Employment Contracts. Having selected this object class, the supplementary conditions we require are:

* **Field Contract Type = PAYE**, AND
* **Field Contract Status = Current**

The latter condition will ensure that we are not looking for old or archived Employee Contracts records.

![Screenshot 2024-02-22 at 16.15.51.png](../../../images2/zendesk_11043287623965_009_fa990993cf78.png)

Save the configuration.

## Add and configure the Sequence Runner

Next, drag and drop a Sequence Runner actor onto the canvas and take a trigger from the Relation Lookup object to the Sequence Runner.

**To prevent unnecessary processing**, the trigger can reference matched records. You should set this at greater than 0 unless you for instance want the sequence to run where there are 3 matching child records or some other matching condition.

![Screenshot 2024-02-22 at 15.57.06.png](../../../images2/zendesk_11043287623965_010_6362edc198b4.png)

In this example, the sequence will continue only if the number of found matched records is greater than zero.

We have to remember that our relational model allows for:

* No children
* 1 child
* Multiple children

In this specific relational model it is most likely that one of the first two possibilities will be found:

* No children found because the current contract for an Employee is not of type PAYE
* 1 child found because there is a current contract of that type

So, having stipulated that matched records must be greater than zero will mean that the sequence will not continue to the Sequence runner and activate the PAYE Contract Review where there is no contract of this type.

Next, right click on the Sequence Runner object and select **Configure**.

The Sequence runner configuration dialog box will open.

There are two fields:

**Record**: here you have a choice of Self or From Relation lookup.

*Self* - is chosen when you want to use the Sequence runner to activate a sequence for the object class in which this actor is being configured. Details about this use case can be found in a later article.

*From Relation lookup* - this is used when the Sequence Runner actor is connected from a Relation Lookup actor, as in this scenario.

![Screenshot 2024-02-22 at 17.03.03.png](../../../images2/zendesk_11043287623965_011_157fe1b4038a.png)

**Sequence**: the choices in this field are determined by the selection made in the Record field. The choices will be the names of sequences with a starting trigger of "When sequence activated" and which relate to either the current sequence (self) or the parent or child object class configured in the Relation Lookup actor.

![](../../../images2/zendesk_11043287623965_012_53ff1d745cc2.png)

Click Save on the dialog box and Save on the sequence itself.

## Resume both sequences

In order to ensure that your sequences can run as you want them to, you must go to the Actions menu for each one and select **Resume**.

![](../../../images2/zendesk_11043287623965_013_636a5a222ef9.png)

The sequence State will change to Running, as below.

![](../../../images2/zendesk_11043287623965_014_b4bd157bf87a.png)

## Example outcome

We can see this process working by starting with an Employees record which has the Performance Review task already assigned.

Record ID 1697, Sid Vicious is one such Employee record.

![](../../../images2/zendesk_11043287623965_015_4f91809ff42a.png)

Having checked the Employment Contracts records, we can see that he has a PAYE type contract, and there are no tasks assigned against the Employee Contract record.

![](../../../images2/zendesk_11043287623965_016_a1dc1cb79fc7.png)

If we complete the Performance Review task against Sid Vicious' Employee record:

![](../../../images2/zendesk_11043287623965_017_2781a6c7ec13.png)

and check his Employee Contract record, we will see that the PAYE Contract Review task has been assigned:

![](../../../images2/zendesk_11043287623965_018_947ef6d5eb49.png)

View an article which explains [how you can use the sequence runner for one object class](/knowledgebase/system-configuration/sequence-actors/sequence-runner-actor/).

---

---
url: /knowledgebase/administration/about-administration.md
---

# About Administration

If you are reading this article from the Autologyx application, you are likely to have a Super Admin account type.

Alternatively, you may have a Role that gives you access to create, edit, or delete one or more Administration areas.

## Administration access

Administration areas can be grouped into single page configuration and multiple page configuration.

| **Single page configuration** | **Multiple page configuration** |
| --- | --- |
| Company details | User groups |
| Standard authentication | Single sign-on settings |
|  | Authentication objects |

If a user with a Standard account type is given a Role with limited Administration permissions, they will see the Administration section in the left-hand navigation menu, but only the areas they have access to.

For example, a user with access to **User groups** and **Authentication objects** would see only those links.

![Administration menu showing limited access options for a Standard user](/knowledgebase/images/administration/about-admin-1.png)

![Administration landing page showing available administration tiles](/knowledgebase/images/administration/about-admin-2.png)

## What you will see

If your Role gives you access to all Administration areas, the Administration landing page is divided into three sections containing five tiles.

Each tile provides quick access to create or manage configuration, such as:

* Authentication objects
* Single sign-on settings
* Standard authentication
* Company details
* User groups

If you have a Super Admin account type, you will see additional tiles for:

* Users
* Roles
* Outbound mail setup

You can create new users and Roles, and use the **Manage** button to open the appropriate list where you can edit or delete existing items.

You can also enter the credentials for the mail service used to send emails from the system.

## Tile counters

Tiles for multiple page areas may show a number in the top-right corner. This number tells you how many items exist in that area.

If there is no number, either:

* the tile represents a single page setting
* there are no items in the list

## Summary of buttons on Administration tiles

Administration tiles can include the following buttons:

* **Configure** - shown on tiles for single page settings
* **Create** - shown on multiple page settings where the user has permission to create items, such as Authentication objects
* **Manage** - shown on multiple page settings where the user has permission to edit or delete items, such as Single sign-on settings

## Things to remember

1. The Administration areas you can see depend on your account type and permissions.
2. Users with limited Administration access see only the areas included in their Role.
3. Super Admin users can access additional areas such as Users, Roles, and Outbound mail setup.
4. Tile counters show how many items exist in multiple page configuration areas.
5. Single page settings usually show **Configure**, while list-based areas usually show **Create** and **Manage**.

---

---
url: >-
  /knowledgebase/system-configuration/about-system-configuration/about-system-configuration.md
---

# About System configuration

If you are reading this article from the Autologyx application, the likelihood is that your role in your organisation is Business Analyst, Implementation Specialist, or similar.

You are probably responsible for building applications within the platform, so you will want to understand why we have Object classes and be able to configure great Task templates and efficient workflows.

You will either have a Super admin account or a Role which probably gives you access to 4 of the 5 configuration areas.

If this is the case, your System configuration page will have **3 sections with 4 tiles**.

|  |  |
| --- | --- |
| A User with a Standard account type who has been given these permissions for a slightly limited Role will have the below tiles available to them on the System configuration page.    The menu links in the left hand navigation will correspond to these tiles. | mceclip0.png |
| mceclip0.png | mceclip2.png |
| mceclip1.png | |

**Tile counts**

Each tile has a number in the top right-hand corner which tells you how many instances are in the list. If there is no number, there are no instances in the list.

The Sequences tile has **2 numbers**:

* the top one shows how many running sequences are in the system
* the bottom number is for paused sequences

## Summary of buttons on System configuration tiles

**Create** - present where the User has permission to create, eg Create Task template.

**Manage** - present where the User has permission to edit or delete, eg Edit Sequence properties or design.

## Useful info

1. The Landing page can only be configured by a User with the Super admin account type.

---

---
url: /knowledgebase/system-configuration/about-system-configuration.md
---
# About System Configuration

**Browse the sections below:**

* [About System Configuration](/knowledgebase/system-configuration/about-system-configuration/about-system-configuration/)
* [Managing Authentication Methods By User Account Type](/knowledgebase/system-configuration/about-system-configuration/managing-authentication-methods-by-user-account-type/)

---

---
url: /knowledgebase/system-configuration/theme/about-the-theme.md
---

# About the Theme

The Theme is used to style your Catalyst system to match your own brand.

If you are using the system for a specific client, you can brand it with their logo and company colours.

Using a Theme will allow you to achieve a more consistent look with existing systems and therefore provide familiarity to users.

## Access

**Who can access it**

Only users with a Super admin account type will be able to create the Theme. It will be found in the System configuration section of the main menu.

**Direct URL**

Alternatively, you can reach the page by entering the URL into the browser:
https://systemname.autologyx.com/system-configuration/theme

**Access restrictions**

The Access Denied page will be presented if anyone trying to reach this page does not have a Super admin account.

## What the Theme Includes

**What you can configure**

In addition to being able to add your own logo and colours, there are some text overrides for the login page.

**How it is applied**

Once created and enabled, the Theme is applied across the system and all users will see it.

## Useful info

1. The application will eventually allow for the creation of multiple themes. However, the initial implementation allows for the creation of a single “brand” theme.

---

---
url: >-
  /knowledgebase/system-configuration/sequences/adding-conditions-for-sequence-commencement.md
---

# Adding conditions for Sequence commencement

The methods for activating a sequence are described HERE.

However, in many instances you will want to add extra conditions so that the workflow is applied only to relevant Records, in other words a subset of the Object class.

After you have established the appropriate starting condition, open the dropdown on the second line of the trigger configuration:

![mceclip2.png](/knowledgebase/images/img_6268930692765_1776895991.png)

There are 7 options. These are easier to understand if you look at the available options in the next field once you have selected one of them.

## RECORD

For instance, **RECORD** has the following 3 options:

**![mceclip3.png](/knowledgebase/images/img_6268930692765_1776895991.png)**

* **ID** - this relates to the Record ID number applied on creation of the Record. The operators in the following dropdown allow you to add conditions such as:

  Record ID > (is greater than) 789

  Record ID = 151

* **Created at** - this relates to the date/time stamp applied to the Record on creation. The operators allow you to add a condition such as:

  Record Created at (date/time) < (is less than) 14/08/2022 00:00

* **Modified at** - this relates to the date/time the Record was last updated.

## FIELD

**FIELD** gives you access to all the Object class fields. After you have searched for and selected one, in this case Employment status which is a single-select field, you can then select = or != (not equal to) a value.

![mceclip4.png](/knowledgebase/images/img_6268930692765_1776895992.png)

So the following trigger condition will only activate the next item in the Sequence when a Record is created and the value in the Employment status field is "Employed - full-time".

![mceclip5.png](/knowledgebase/images/img_6268930692765_1776895992.png)

The operators will change for different field types, and depending on your configuration another field will be displayed for you to select or enter a value:

|  |  |
| --- | --- |
| **Text field** | mceclip6.png |
| **Decimal and Integer field** | mceclip7.png |
| **Date field** | mceclip8.png |

## TASK

**TASK** - this option allows you to set a value for a specific attribute of a Task. Start typing the Task name into the search bar at the top of the selection to easily find the required one.![mceclip9.png](/knowledgebase/images/img_6268930692765_1776895993.png)

The available attributes are:

* **Created** - relating to whether this Task has been created for the Record
* **Creation Date** - relating to the date the Task was created for the Record
* **Completed** - relating to whether the Task has been completed for the Record
* **Completion Date** - relating to the date the Task was completed for the Record
* **Expiry Date** - relating to the date the Task is due to expire for the Record
* **Status** - relating to the current status of the Task for this Record eg Not created, Outstanding, Overdue or Completed

## TASK GROUP

**TASK GROUP** - this option allows you to set a value for the State of a Task Group. Start typing the Task group template name into the search bar at the top of the selection to easily find the required one. Available States are Not assigned, Not started, In progress and Completed.

## VARIABLE

**VARIABLE** allows you to reference data in the Variables on your Sequence, like the below:

![mceclip10.png](/knowledgebase/images/img_6268930692765_1776895993.png)

The operators will vary depending on the type chosen in the Variable configuration.

## UPDATED FIELDS and PREVIOUS FIELD VALUE

**The final two options** are often used together:

* **UPDATED FIELDS**
* **PREVIOUS FIELD VALUE**

Both give access to the Object class fields so that you can reference which field or fields have been updated and what the current value of the field is. In the below example, the Sequence will create the Sanctions Check Task when a Record is updated AND

* the updated field is Risk level AND
* the field Risk level is equal to the value High

![mceclip0.png](/knowledgebase/images/img_6268930692765_1776895993.png)

You can make use of many of these additional trigger conditions anywhere in your Sequence so that, based on field data, the response to a Task which has already been completed, or the State of a Task, you can create different routes for subsets of Records.

---

---
url: /knowledgebase/administration.md
---
# Administration

**Administration** is where system-wide settings are managed in Autologyx.

This section is most relevant to Super Admins, platform administrators, and others responsible for managing users, access, authentication, communications, and other shared controls that apply across the environment.

**In contrast:**

* the Workspace is where end users carry out day-to-day work with records, tasks, and documents
* System configuration is where builders configure the solution itself, including the data model, workflows, tasks, forms, and integrations

Administration is about managing the environment and the people who use it.

## What you will find in this section

### Understand Administration

Start here for an overview of what Administration is for and how it fits into the wider platform.

* [About Administration](/knowledgebase/administration/about-administration/)

### Manage users, access, and governance

These areas are about managing Users, User Groups, Roles, and the relationships between them.

* [All about users](/knowledgebase/administration/all-about-users/)
* [User Groups](/knowledgebase/administration/user-groups/)
* [Roles and Permissions](/knowledgebase/administration/roles-and-permissions/)

### Authentication, sign-in, and communication

These areas cover identity, authentication, sign-on behaviour, and system-level communication settings.

* [Authentication Objects](/knowledgebase/administration/authentication-objects/)
* [Communication](/knowledgebase/administration/communication/)

### Platform components and advanced admin features

These pages cover more specialist administrative or platform-extension capabilities.

* [Elements](/knowledgebase/administration/elements/)

## Suggested path

If you are new to Administration, a sensible order is:

1. **Understand** the purpose of the Administration area
2. **Review** users, Roles, and User Groups
3. **Review** authentication and communication settings
4. **Explore** any advanced platform-specific administrative features you need

## Notes

::: info
Administration is focused on system-wide controls and shared platform settings, rather than day-to-day operational work or solution-building configuration.
:::

::: tip
If you are managing access to the platform, a good place to begin is **About Administration**, then **All about users**, **User Groups**, and Roles and Permissions.
:::

---

---
url: /knowledgebase/getting-started/platform-admin-administrators/administration.md
---

# Administration

As someone responsible for administering Catalyst, you will typically have a Super admin account type. Your responsibilities may include managing users, roles, permissions, authentication settings, and outbound communications.

In practice, your interaction with Catalyst will focus on ensuring the platform is configured correctly and maintained as company policies, integrations, and user access requirements evolve.

## Quick checklist of global settings

You will find the following under Administration:

* [**Users, Roles and User groups**](/knowledgebase/administration/users-roles-and-user-groups/) - this section of the Knowledgebase will help you to create and manage your users. Most of your users will only interact with records and tasks in their Workspace; they probably won't need a Role but are likely to be in one or more User groups.

* \[**Company details**] - details entered here are available as merge fields and will be used in message templates.

* [**Standard authentication**](/knowledgebase/administration/communication/how-do-i-configure-user-activation-rules/) - this area allows you to set the user login password rules for the system. This article will show you what the user sees when they activate their account, and how you set the password rules.

* [**Single sign-on**](/knowledgebase/administration/communication/how-do-i-configure-single-sign-on-for-users/) - if you use this feature it will allow you to configure a single sign on provider such as Microsoft or Google. Users can select this method of authentication on the login page instead of entering their email address and password.

* \[**Authentication Objects**] - these are used to hold sensitive login details which are required to connect to third party systems via API calls.

* [**Outbound mail setup**](/knowledgebase/administration/communication/outbound-mail-setup/) - this is where you will define and configure the mail service used for all outgoing notifications. See outbound mail setup.

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.6/“relationship-created”-trigger-in-sequencer/index.agent.md
---
# Agent guide: “Relationship created” trigger in Sequencer

* **Page path:** `release-notes/release-notes-1.6/“relationship-created”-trigger-in-sequencer/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces the "Relationship created" trigger in Sequencer. It explains where the trigger works and that it starts sequence actions when a parent-child relationship is successfully created.

## User intent

* Understand what the "Relationship created" trigger does in Sequencer
* Learn where this trigger can be used
* Determine when sequence automation can start based on record relationships
* Identify possible automation scenarios such as task assignment, notifications, or workflow initiation

## Key terms

* Relationship created trigger
* Sequencer
* parent and child records
* relationship establishment
* Relational Modeller
* relational entities
* sequence actions
* workflow automation

## Terminology links

* [Relationship Created trigger](/knowledgebase/terminology/#relationship-created-trigger)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [parent and child records](/knowledgebase/terminology/#parent-and-child-records)
* [Relational modeller](/knowledgebase/terminology/#relational-modeller)
* [relational entities](/knowledgebase/terminology/#relational-entities)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Sequencer
* Familiarity with parent-child record relationships
* Awareness of Relational Modeller and relational entities

## Not covered

* Setup or configuration steps for the trigger
* Detailed examples or implementation guidance
* Conditions, limitations, or edge cases beyond relational entities
* Other Sequencer triggers or broader Sequencer functionality

---

---
url: /api-agent-guides/merge-fields/resources/scopes/index.agent.md
---
# Agent guide: 🎯 MF Context Scopes Availability

* **Page path:** `merge-fields/resources/scopes.md`
* **Page type:** explanation

## What this page is about

This page is a quick-reference matrix showing which merge-field context types are available in different system scopes, specifically Sequencer Actor and Document Generation. It also summarizes how each scope is composed from default, record-related, and scope-specific contexts.

## User intent

* Check whether a specific merge-field context is available in Sequencer Actor or Document Generation
* Understand which contexts are part of DefaultScope, SequencerActorScope, and DocumentGenerationScope
* Identify which contexts are universal versus scope-specific
* See how VariableContext, VariableDocumentContext, and EmbeddedDocumentContext differ by scope
* Review the basic properties exposed by VariableDocumentContext

## Key terms

* merge fields
* context scopes
* Sequencer Actor
* Document Generation
* DefaultScope
* SequencerActorScope
* DocumentGenerationScope
* AdminContext
* ClientContext
* DateAndTimeContext
* ConstantContext
* VariableContext
* VariableDocumentContext
* TaskContext
* ObjectRecordContext
* UsersGroupContext
* UserContext
* UserFieldMetaContext
* UserFieldContext
* DocumentContext
* EmbeddedDocumentContext
* record-related contexts
* context availability

## Terminology links

* [Merge fields](/api/terminology/#merge-fields)
* [Context scopes](/api/terminology/#context-scopes)
* [Sequencer actors](/api/terminology/#sequencer-actors) (matched from `Sequencer Actor`)
* [Document Generation](/api/terminology/#document-generation)
* [DefaultScope](/api/terminology/#defaultscope)
* [SequencerActorScope](/api/terminology/#sequenceractorscope)
* [DocumentGenerationScope](/api/terminology/#documentgenerationscope)
* [AdminContext](/api/terminology/#admincontext)

## Related topics

* 🎯 MF used in sequencer
* 📄 Autologyx – Merge Fields Guide
* Merge fields Custom Filters

## Prerequisites

* Basic familiarity with merge fields
* Awareness of system usage scenarios like sequencer workflows and document generation
* Some understanding of context objects used to expose system, record, user, and document data

## Not covered

* Detailed syntax for using merge fields
* How to write expressions or filters with these contexts
* Implementation details of each context beyond brief descriptions
* Examples of merge-field templates in real documents or workflows
* Explanation of the workflow/form-processing contexts noted as not used in the main scopes
* Detailed instructions for accessing document variable properties beyond the heading reference

---

---
url: /api-agent-guides/merge-fields/resources/sequncer-merge-fields/index.agent.md
---
# Agent guide: 🎯 MF used in sequencer

* **Page path:** `merge-fields/resources/sequncer-merge-fields.md`
* **Page type:** explanation

## What this page is about

This page explains Sequencer-specific merge fields available downstream of a Loop actor, especially the current loop item and the current loop iteration index. It describes where they are available, how they behave in testing and execution, and configuration-dependent edge cases.

## User intent

* Understand which merge fields can be used inside Sequencer actors downstream of a Loop
* Use the current loop item inside actors such as API Call and Loop-related flows
* Use nested properties from the current loop item
* Understand how the loop item behaves with different Loop sources such as arrays and Document Picker
* Know when the merge field resolves to an empty string during testing or misconfiguration
* Understand the effect of using "Loop item processed" versus "Actor completed" triggers
* Determine which Loop is used in testing when multiple Loop actors are connected
* Use the current loop iteration index in downstream actors

## Key terms

* Sequencer
* merge fields
* Loop actor
* downstream actor
* API Call actor
* Loop item processed
* Actor completed
* current loop item
* nested properties
* Document Picker source
* array source
* variable source
* API Call source
* execution context
* current iteration index
* testing mode
* empty string on error

## Terminology links

* [Sequencer](/api/terminology/#sequencer)
* [Merge fields](/api/terminology/#merge-fields)
* [Loop actor](/api/terminology/#loop-actor)
* [downstream actor](/api/terminology/#downstream-actor)
* [API Call actor](/api/terminology/#api-call-actor)
* [Loop item processed](/api/terminology/#loop-item-processed)
* [Actor completed](/api/terminology/#actor-completed)
* [nested properties](/api/terminology/#nested-properties)

## Related topics

* 🎯 MF Context Scopes Availability
* 📄 Autologyx – Merge Fields Guide
* Merge fields Custom Filters

## Prerequisites

* Basic understanding of Sequencer actors and connections
* Familiarity with Loop actor configuration and triggers
* Basic knowledge of merge fields and API Call actor testing

## Not covered

* General merge field syntax beyond these Sequencer-specific Loop-related fields
* Detailed setup instructions for Loop, API Call, or Document Picker actors
* Custom filters behavior
* Broader merge field scope rules outside the downstream Loop context

---

---
url: >-
  /api-agent-guides/merge-fields/resources/object-record-merge-fields/index.agent.md
---
# Agent guide: 📄 Autologyx – Merge Fields Guide

* **Page path:** `merge-fields/resources/object-record-merge-fields.md`
* **Page type:** explanation

## What this page is about

This page explains how to use Autologyx merge fields with Jinja2 syntax to insert Object Record data into templates and other supported resources. It covers field access, record properties, documents, users/groups, related records, filtering, tasks, date formatting, and error handling.

## User intent

* Access Object Record fields in documents, emails, API Actor parameters, and other supported contexts
* Understand how different field types are returned and formatted
* Use conditional logic in templates
* Read built-in record properties like ID, created, and modified timestamps
* Work with document and image fields, including document object properties and Base64 content
* Access user and user group fields using legacy ID-based or object-based syntax
* Loop through users, groups, documents, or related records
* Traverse related records across relationship levels
* Filter related records efficiently using the custom filter
* Retrieve task IDs
* Format date/time values with Jinja2 date formatting
* Understand safe failures versus syntax errors in different rendering contexts

## Key terms

* merge fields
* template tags
* Jinja2 syntax
* Object Records
* field aliases
* filters
* conditional logic
* record properties
* document fields
* image fields
* user fields
* user group fields
* ID-based access
* object-based access
* related records
* relationship levels
* iteration
* filter by
* tasks
* date/time formatting
* syntax errors
* safe failure
* Sentry

## Terminology links

* [Merge fields](/api/terminology/#merge-fields)
* [Object Records](/api/terminology/#object-records)
* [record properties](/api/terminology/#record-properties)
* [Document fields](/api/terminology/#document-fields)
* [User type fields](/api/terminology/#user-type-fields) (matched from `user fields`)
* [Related records](/api/terminology/#related-records)
* [filter by](/api/terminology/#filter-by)
* [tasks resource](/api/terminology/#tasks-resource) (matched from `tasks`)

## Related topics

* Merge fields Custom Filters
* 🎯 MF Context Scopes Availability
* 🎯 MF used in sequencer

## Prerequisites

* Basic familiarity with Object Records and Object Model relationships
* Basic understanding of Jinja2 template syntax
* Knowing the aliases/IDs of the fields or related Object Classes you want to access

## Not covered

* Detailed image processing behavior beyond noting dedicated image filters
* Full examples of every field type’s exact syntax and output
* General Jinja2 tutorial content beyond the merge-field use cases shown here
* Definition or setup of Object Model relationships themselves
* Operational guidance for Sentry beyond noting that background errors are reported there

---

---
url: /api-agent-guides/websockets/index.agent.md
---
# Agent guide: 🔌 Catalyst WebSockets API

* **Page path:** `websockets/index.md`
* **Page type:** explanation

## What this page is about

This page introduces the Catalyst WebSockets API reference for real-time updates in Catalyst. It explains the purpose of the WebSocket APIs, authentication via a UUID v4 from a Catalyst API endpoint, and high-level delivery behavior such as batching, buffering, and reconnection handling.

## User intent

* Understand what the Catalyst WebSockets API is used for
* Learn how WebSocket authentication works at a high level
* Find out how the WebSocket connection is established
* Understand what kinds of real-time events are broadcast
* Learn the batching and buffering behavior of WebSocket updates
* Understand what happens to buffered events on disconnection and reconnection
* Identify which endpoint-specific pages to read next

## Key terms

* Catalyst WebSockets API
* real-time updates
* WebSocket endpoints
* authentication
* UUID v4
* GET /api/users/ws auth/
* connection string
* batching
* buffer
* reconnection behaviour
* rows
* cells
* record counts
* broadcast
* connected clients

## Terminology links

* [Catalyst Websockets API](/api/terminology/#catalyst-websockets-api)
* [real time update mechanism](/api/terminology/#real-time-update-mechanism) (matched from `real-time updates`)
* [GET /api/users/ws auth/](/api/terminology/#get-apiusersws-auth)
* [buffered events](/api/terminology/#buffered-events) (matched from `buffer`)
* [rows](/api/terminology/#rows)
* [cells](/api/terminology/#cells)
* [record count](/api/terminology/#record-count) (matched from `record counts`)

## Related topics

* Real time updates Technical Design
* authentication flow for obtaining the WebSocket UUID
* resource-specific WebSocket pages

## Prerequisites

* Basic understanding of WebSockets
* Familiarity with Catalyst APIs
* Ability to authenticate to Catalyst services
* Understanding of client-side handling for real-time events

## Not covered

* Detailed endpoint-specific subscription documentation
* End-user documentation
* Full connection string details
* Implementation examples for client applications
* Behavior of events generated before reconnect beyond the stated discard rule
* Non-WebSocket Catalyst APIs

---

---
url: /api-agent-guides/merge-fields/merge-fields/index.agent.md
---
# Agent guide: 🔧 What Are Merge Fields?

* **Page path:** `merge-fields/merge-fields.md`
* **Page type:** explanation

## What this page is about

This page explains what Merge Fields are in ALX: dynamic Jinja2-based placeholders that insert live contextual data into templates at render time. It also outlines their purpose, broad supported types, and the globally available system merge field contexts.

## User intent

* Understand what Merge Fields are and how they work in ALX
* Learn where Merge Fields can be used, such as documents, emails, sequencer actors, API responses, and web content
* See that Merge Fields are resolved at render time from system records and context
* Understand that ALX Merge Fields are powered by the Jinja2 templating engine
* Get a high-level overview of supported Merge Field categories, including system, record, nested relationship, metadata, and loop-related fields
* Learn what system merge fields are and which global contexts they cover
* Know that constants require a special prefix while other system merge fields do not

## Key terms

* Merge Fields
* MF
* Jinja2
* render time
* template tags
* dynamic placeholders
* system merge fields
* Admin Context
* Client Context
* Date and Time Context
* Constants Context
* Loop Item Context
* Object Records
* document templates
* email templates
* Sequencer actors

## Terminology links

* [Merge fields](/api/terminology/#merge-fields)
* [System merge fields](/api/terminology/#system-merge-fields)
* [Admin Context](/api/terminology/#admin-context)
* [Client Context](/api/terminology/#client-context)
* [Date and Time Context](/api/terminology/#date-and-time-context)
* [Constants Context](/api/terminology/#constants-context)
* [Loop Item Context](/api/terminology/#loop-item-context)
* [Object Records](/api/terminology/#object-records)

## Related topics

* Object Record Merge Fields

## Prerequisites

* Basic familiarity with templates or placeholders is helpful
* Some awareness of ALX objects or records, such as users, documents, and tasks, is useful
* No deep Jinja2 knowledge is stated as required

## Not covered

* Detailed syntax examples for each merge field type
* Complete lists of specific merge field names or variables
* Step-by-step instructions for configuring templates
* Detailed Object Record Merge Fields behavior and formatting
* Expanded documentation for nested relationships or custom properties
* In-depth Jinja2 usage beyond identifying it as the underlying engine

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/using-docusign-with-catalyst/1.-introduction/index.agent.md
---
# Agent guide: 1. Introduction

* **Page path:** `system-configuration/using-docusign-with-catalyst/1.-introduction/index.md`
* **Page type:** explanation

## What this page is about

This page introduces how Catalyst integrates with DocuSign for automated document workflows. It explains that Catalyst uses a dedicated Authentication object to securely store DocuSign credentials and keep access authenticated by refreshing tokens automatically.

## User intent

* Understand the purpose of the DocuSign integration in Catalyst
* Learn how Catalyst handles DocuSign authentication securely
* See the high-level workflow for generating, sending, signing, and retrieving documents through DocuSign
* Understand the business value of automating document signing processes

## Key terms

* DocuSign
* Catalyst
* Authentication object
* account credentials
* access tokens
* automated document workflow
* document template
* Object class
* workflow sequence
* record
* envelope
* recipients
* signed document

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `Authentication object`)
* [access tokens](/knowledgebase/terminology/#access-tokens)
* [automated document workflow](/knowledgebase/terminology/#automated-document-workflow)
* [Document Templates](/knowledgebase/terminology/#document-templates) (matched from `document template`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [workflow sequence](/knowledgebase/terminology/#workflow-sequence)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `record`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of DocuSign as a document sending and signing platform
* Basic familiarity with Catalyst workflows and object classes

## Not covered

* Step-by-step setup or configuration instructions
* How to create or configure the Authentication object
* How to map templates to object classes in detail
* How envelope configuration or recipient signing order is set up
* Technical implementation details of token refresh or API usage

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/using-docusign-with-catalyst/2.-setting-up-a-free-developer-docusign-account/index.agent.md
---
# Agent guide: 2. Setting up a free developer DocuSign account

* **Page path:** `system-configuration/using-docusign-with-catalyst/2.-setting-up-a-free-developer-docusign-account/index.md`
* **Page type:** explanation

## What this page is about

This page explains how to create a free DocuSign developer account for use in a Catalyst development environment and where to find the account details needed for integration. It also identifies the key values required for Catalyst auth setup and API calls.

## User intent

* Create a free DocuSign developer account
* Use DocuSign in a Catalyst dev environment
* Activate a new DocuSign developer account from email
* Locate the User ID, API Account ID, and Account Base URI in DocuSign
* Find the values needed to configure DocuSign authentication and API calls in Catalyst

## Key terms

* DocuSign developer account
* Catalyst dev environment
* User ID
* API Account ID
* Account Base URI
* DocuSign Authentication Object
* auth object
* Integrations / Apps and Keys
* API calls
* https://demo.docusign.net

## Terminology links

* [Catalyst dev environment](/knowledgebase/terminology/#catalyst-dev-environment)
* [User ID field](/knowledgebase/terminology/#user-id-field) (matched from `User ID`)
* [API Account ID](/knowledgebase/terminology/#api-account-id)
* [Account Base URI](/knowledgebase/terminology/#account-base-uri)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `DocuSign Authentication Object`)
* [API calls](/knowledgebase/terminology/#api-calls)

## Related topics

* Configure an API call to create a DocuSign envelope

## Prerequisites

* Access to email to activate the DocuSign account
* Basic familiarity with Catalyst
* Need to test DocuSign without an existing customer/test account

## Not covered

* Detailed steps for configuring the DocuSign Authentication Object in Catalyst
* How to build or send API calls beyond identifying required account values
* How to create DocuSign templates
* How to switch from test/developer to a live DocuSign account
* Detailed troubleshooting for account creation or activation

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/using-docusign-with-catalyst/3.-creating-an-authentication-object-for-use-with-docusign/index.agent.md
---
# Agent guide: 3. Creating an Authentication object for use with DocuSign

* **Page path:** `system-configuration/using-docusign-with-catalyst/3.-creating-an-authentication-object-for-use-with-docusign/index.md`
* **Page type:** explanation

## What this page is about

This page explains how to create and configure a Catalyst Authentication object for DocuSign so Catalyst can stay authenticated, refresh access tokens, and attach access tokens to API requests. It also covers the matching DocuSign app setup, permission grant, testing, and save steps.

## User intent

* Understand what the DocuSign authentication object does in Catalyst
* Create a new Authentication object in Catalyst for DocuSign
* Find which DocuSign values must be copied into Catalyst fields
* Generate and use an RSA key for the DocuSign integration
* Add required URI and origin URL entries in DocuSign
* Grant API permissions to the new DocuSign app
* Choose the correct DocuSign host for test/developer versus live accounts
* Test that the authentication object works before saving

## Key terms

* Authentication object
* DocuSign
* refresh token
* access token
* headers
* User ID
* Client ID
* Integration Key
* Private RSA Key
* Apps and Keys
* Service Integration
* URI
* origin URLs
* allowed domains
* cross scripting attacks
* Allow Access
* Host field
* account-d.docusign.com
* account.docusign.com

## Terminology links

* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `Authentication object`)
* [refresh tokens](/knowledgebase/terminology/#refresh-tokens) (matched from `refresh token`)
* [access tokens](/knowledgebase/terminology/#access-tokens) (matched from `access token`)
* [column headers](/knowledgebase/terminology/#column-headers) (matched from `headers`)
* [User ID field](/knowledgebase/terminology/#user-id-field) (matched from `User ID`)
* [Client ID](/knowledgebase/terminology/#client-id)
* [Private RSA Key field](/knowledgebase/terminology/#private-rsa-key-field) (matched from `Private RSA Key`)
* [Host field](/knowledgebase/terminology/#host-field)

## Related topics

* Not provided.

## Prerequisites

* Access to Catalyst Administration / Authentication objects
* A Super admin account type or a Role with Create/Edit enabled for Authentication Objects
* Access to a DocuSign account and its Settings / Integrations / Apps and Keys area
* Knowledge of whether the setup is for a developer/test account or a live account
* Catalyst instance URL(s) needed for URI and origin URL configuration

## Not covered

* Detailed instructions for migrating a dev authentication object to live; only a brief note is given
* The full exact permission-grant URL; the page shows a partially redacted/example form
* How to configure the subsequent API call to create a DocuSign envelope
* Broader DocuSign integration concepts beyond creating and testing the authentication object
* Any setup beyond the stated maximum of 100 Authentication objects

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/using-docusign-with-catalyst/4.-configuring-an-api-call-to-create-an-envelope-in-docusign/index.agent.md
---
# Agent guide: 4. Configuring an API call to create an envelope in DocuSign

* **Page path:** `system-configuration/using-docusign-with-catalyst/4.-configuring-an-api-call-to-create-an-envelope-in-docusign/index.md`
* **Page type:** explanation

## What this page is about

This page explains how to configure a Catalyst API POST call that creates a DocuSign envelope using JSON data. It covers required setup, authentication selection, URL construction, and the key JSON body elements for recipients, signing order, tabs, and documents.

## User intent

* Configure a Catalyst API call to create a DocuSign envelope
* Understand what must exist before building the envelope call
* Choose the correct authentication method for DocuSign in Catalyst
* Build the DocuSign API URL from the base URI and API account ID
* Structure the JSON body for signers, carbon copies, and documents
* Set signing order and recipient IDs
* Place DocuSign anchor tags in document templates for signatures or dates
* Include a generated document or uploaded file in the envelope payload

## Key terms

* Catalyst
* DocuSign
* envelope
* POST call
* JSON data
* Auth Object
* DocuSign authentication object
* Account Base URI
* API Account ID
* recipients
* signers
* carbonCopies
* recipient ID
* routing order
* signHereTabs
* dateSignedTabs
* anchorString
* document template
* merge field
* base64 format
* documents

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst)
* [Envelope](/knowledgebase/terminology/#envelope)
* [JSON Data](/knowledgebase/terminology/#json-data)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `Auth Object`)
* [Account Base URI](/knowledgebase/terminology/#account-base-uri)
* [API Account ID](/knowledgebase/terminology/#api-account-id)
* [Recipient ID](/knowledgebase/terminology/#recipient-id)
* [Document Templates](/knowledgebase/terminology/#document-templates) (matched from `document template`)

## Related topics

* automatic document generation
* Update object record type task

## Prerequisites

* An Object class with a document template
* A template generated and saved to a field on the Record, or a document uploaded to a field via an Update object record task
* A configured DocuSign authentication object
* Access to the DocuSign Apps and Keys page to obtain the Account Base URI and API Account ID
* Basic understanding of Catalyst merge fields and document templates

## Not covered

* Step-by-step creation of the document template itself
* Detailed setup of automatic document generation
* How to configure the DocuSign authentication object
* A full working JSON example payload
* General DocuSign account setup beyond where to find the URI and account ID
* Envelope/document limits details beyond noting that more information exists elsewhere

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/using-docusign-with-catalyst/5.-monitoring-the-status-of-your-docusign-envelope/index.agent.md
---
# Agent guide: 5. Monitoring the Status of your DocuSign Envelope

* **Page path:** `system-configuration/using-docusign-with-catalyst/5.-monitoring-the-status-of-your-docusign-envelope/index.md`
* **Page type:** explanation

## What this page is about

This page explains how to monitor a DocuSign envelope’s status in Catalyst after the envelope has been created via API. It shows how to capture the envelope ID, poll DocuSign for status changes, loop the check on a delay, and optionally use the status in updates or notifications.

## User intent

* Capture the DocuSign envelope ID from an envelope creation API call
* Set up a Catalyst API actor to check envelope signing status
* Build the GET request URL for a specific envelope
* Store the returned envelope status in a local variable
* Create a loop to recheck status at a chosen interval
* Stop polling when the envelope reaches terminal statuses such as completed, declined, or signed
* Update a record field with the current envelope status
* Send messages when the envelope status changes

## Key terms

* DocuSign envelope
* envelope ID
* status
* Catalyst
* API actor
* local variable
* trigger
* When Actor completed
* GET request
* JSON Data
* DocuSign auth object
* {{output.envelopeId}}
* {{output.status}}
* {{variables.Variable}}
* delay
* trigger conditions

## Terminology links

* [Envelope](/knowledgebase/terminology/#envelope) (matched from `DocuSign envelope`)
* [DocuSign envelope ID](/knowledgebase/terminology/#docusign-envelope-id) (matched from `envelope ID`)
* [envelope status](/knowledgebase/terminology/#envelope-status) (matched from `status`)
* [Catalyst](/knowledgebase/terminology/#catalyst)
* [API Call actor](/knowledgebase/terminology/#api-call-actor) (matched from `API actor`)
* [Local Variable Actor](/knowledgebase/terminology/#local-variable-actor) (matched from `local variable`)
* [Triggers](/knowledgebase/terminology/#triggers) (matched from `trigger`)
* [When Actor completed](/knowledgebase/terminology/#when-actor-completed)

## Related topics

* Not provided.

## Prerequisites

* A DocuSign envelope is already being created via an API call from Catalyst
* A DocuSign auth object is available in Catalyst
* Basic familiarity with Catalyst actors, triggers, variables, and sequence configuration
* Knowledge of the DocuSign account-specific API base URL used for envelope creation

## Not covered

* How to create the original DocuSign envelope API call in detail
* How to configure DocuSign authentication from scratch
* A full list of possible DocuSign envelope status values
* Webhook or event-driven alternatives to polling
* Advanced error handling, retries, or failure scenarios for the status API call

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/using-docusign-with-catalyst/6.-monitoring-the-signing-status-of-individual-recipients/index.agent.md
---
# Agent guide: 6. Monitoring the signing status of individual recipients

* **Page path:** `system-configuration/using-docusign-with-catalyst/6.-monitoring-the-signing-status-of-individual-recipients/index.md`
* **Page type:** explanation

## What this page is about

How to use Catalyst with DocuSign to retrieve, store, and repeatedly recheck the signing status of individual recipients on an envelope. It explains the API call pattern, looping logic, and how recipient IDs map to signer statuses.

## User intent

* Check the signing status of a specific DocuSign recipient in Catalyst
* Retrieve all recipient statuses for an envelope via the DocuSign API
* Store recipient status in a Catalyst Local variable
* Update a record field with a recipient's signing status
* Set up a loop to periodically recheck recipient status until completion or decline
* Capture statuses for multiple recipients on the same envelope
* Understand which recipient status values should stop rechecking

## Key terms

* Catalyst
* DocuSign
* envelope status
* recipient status
* recipient status codes
* envelope ID
* API Call actor
* Local variable
* Update Record actor
* GET request
* /envelopes/{{variables.contract env id}}/recipients
* recipientId
* signer.status
* delay
* trigger conditions
* completed
* declined

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst)
* [envelope status](/knowledgebase/terminology/#envelope-status)
* [Recipient status](/knowledgebase/terminology/#recipient-status)
* [DocuSign envelope ID](/knowledgebase/terminology/#docusign-envelope-id) (matched from `envelope ID`)
* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [Local Variable Actor](/knowledgebase/terminology/#local-variable-actor) (matched from `Local variable`)
* [Update Record actor](/knowledgebase/terminology/#update-record-actor)
* [Recipient ID](/knowledgebase/terminology/#recipient-id) (matched from `recipientId`)

## Related topics

* Previous section about capturing the envelope status

## Prerequisites

* Reading the previous section on capturing envelope status
* An envelope ID already stored in a Local variable
* Basic familiarity with Catalyst actors, triggers, and Local variables
* A DocuSign envelope already created with recipients in a known order

## Not covered

* Detailed setup of envelope-status monitoring
* Full recipient status code table contents beyond noting that a table/screenshot exists
* General DocuSign API usage outside the specific recipients endpoint described here
* How to create the envelope in detail
* How to authenticate DocuSign API requests

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/using-docusign-with-catalyst/7.-how-to-retrieve-the-signed-document-and-store-within-catalyst/index.agent.md
---
# Agent guide: 7. How to retrieve the signed document and store within Catalyst

* **Page path:** `system-configuration/using-docusign-with-catalyst/7.-how-to-retrieve-the-signed-document-and-store-within-catalyst/index.md`
* **Page type:** explanation

## What this page is about

Explains how to retrieve a completed DocuSign signed document in a Catalyst sequence and store it on a record. It covers the API Call, Document Picker, and Update Record actors, plus how Document Picker "Combine results" affects downstream documents.

## User intent

* Retrieve a signed DocuSign document after envelope status becomes completed
* Configure a sequence trigger based on a stored envelope status variable
* Set up the DocuSign GET API call to fetch a document from an envelope
* Use a Document Picker to select the retrieved API Call document
* Store the retrieved document into a Catalyst record document field
* Understand when to enable or disable the Document Picker "Combine results" option
* Handle envelopes with multiple documents by configuring separate retrieval paths
* Use the retrieved document later, such as attaching it to email or viewing it on the record

## Key terms

* DocuSign envelope status
* completed
* local variable
* API Call actor
* GET request
* JSON Data
* DocuSign auth object
* envelope ID
* document ID
* Document Picker actor
* API Call document
* Combine results
* Update Record actor
* Document type field
* sequence workflow

## Terminology links

* [envelope status](/knowledgebase/terminology/#envelope-status) (matched from `DocuSign envelope status`)
* [Local Variable Actor](/knowledgebase/terminology/#local-variable-actor) (matched from `local variable`)
* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [JSON Data](/knowledgebase/terminology/#json-data)
* [DocuSign auth object](/knowledgebase/terminology/#docusign-auth-object)
* [DocuSign envelope ID](/knowledgebase/terminology/#docusign-envelope-id) (matched from `envelope ID`)
* [Document Picker actor](/knowledgebase/terminology/#document-picker-actor)
* [API Call document](/knowledgebase/terminology/#api-call-document)

## Related topics

* Not provided.

## Prerequisites

* Have read section 5 about capturing the envelope status
* Have a local variable storing the envelope status
* Have a DocuSign auth object configured
* Have already created the envelope and know the envelope/document IDs used
* Basic familiarity with Catalyst sequence actors such as API Call, Document Picker, and Update Record

## Not covered

* How to capture the envelope status itself beyond referencing section 5
* How to create the DocuSign envelope in detail
* General DocuSign authentication setup
* How to retrieve envelope metadata other than documents
* Advanced error handling or retry logic for document retrieval
* How to dynamically enumerate multiple documents; it only states separate actors are needed for each document

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/using-docusign-with-catalyst/8.-system-migrations-and-docusign-authentication-objects/index.agent.md
---
# Agent guide: 8. System migrations and DocuSign Authentication objects

* **Page path:** `system-configuration/using-docusign-with-catalyst/8.-system-migrations-and-docusign-authentication-objects/index.md`
* **Page type:** explanation

## What this page is about

This page explains how DocuSign Authentication objects behave during a System Migration. It clarifies that authentication objects are mapped by name but their settings are not overwritten, and outlines a common dev/test versus live configuration approach.

## User intent

* Understand how DocuSign Authentication objects are handled in a System Migration
* Determine naming requirements for authentication objects across dev and live systems
* Decide whether to use one shared-name auth object or separate test/live DocuSign auth objects
* Configure DocuSign host settings appropriately for test and live environments
* Ensure API calls use the correct Account Base URI and API Account ID before migration

## Key terms

* System Migration
* DocuSign Authentication objects
* mapped during migration
* configuration not overwritten
* dev system
* live system
* Host
* account-d.docusign.com
* account.docusign.com
* Account Base URI
* API Account ID
* API call

## Terminology links

* [System Migrations](/knowledgebase/terminology/#system-migrations) (matched from `System Migration`)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `DocuSign Authentication objects`)
* [configuration is not over written](/knowledgebase/terminology/#configuration-is-not-over-written) (matched from `configuration not overwritten`)
* [dev system](/knowledgebase/terminology/#dev-system)
* [live system](/knowledgebase/terminology/#live-system)
* [Host selection](/knowledgebase/terminology/#host-selection) (matched from `Host`)
* [Account Base URI](/knowledgebase/terminology/#account-base-uri)
* [API Account ID](/knowledgebase/terminology/#api-account-id)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of dev and live Catalyst systems
* Familiarity with DocuSign authentication and API configuration
* Awareness of test versus live DocuSign environments

## Not covered

* Detailed steps for creating Authentication objects
* Full DocuSign API setup instructions
* General System Migration process beyond auth object mapping behavior
* Troubleshooting migration failures or DocuSign API errors

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequences-for-relational-records/a-guide-to-using-the-relation-lookup-and-sequence-runner-actors-together/index.agent.md
---
# Agent guide: A guide to using the Relation Lookup and Sequence Runner actors together

* **Page path:** `system-configuration/sequences-for-relational-records/a-guide-to-using-the-relation-lookup-and-sequence-runner-actors-together/index.md`
* **Page type:** explanation

## What this page is about

Explains how to use a Relation Lookup actor in one sequence to find related child records in a relational model, then use a Sequence Runner actor to activate a second sequence for those matched records. The example uses Employees to find current PAYE Employment Contracts and create review tasks on those contract records.

## User intent

* Set up Relation Lookup and Sequence Runner to work together across related object classes
* Find child records that meet conditions in a relational model
* Trigger a sequence on matched related records rather than on the current record
* Create tasks on related Employment Contracts records from an Employees sequence
* Configure triggers so processing only continues when matching records exist
* Understand the difference between Sequence Runner options Self and From Relation lookup

## Key terms

* Relation Lookup actor
* Sequence Runner actor
* relational model
* object class
* root parent object class
* child object class
* Employee Management
* Employees
* Employment Contracts
* Sequence Activated
* Create task actor
* matched records
* children records
* parent records
* Contract Type
* Contract Status
* PAYE

## Terminology links

* [Relation Lookup](/knowledgebase/terminology/#relation-lookup) (matched from `Relation Lookup actor`)
* [Sequence Runner](/knowledgebase/terminology/#sequence-runner) (matched from `Sequence Runner actor`)
* [relational model](/knowledgebase/terminology/#relational-model)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [Sequence Activated](/knowledgebase/terminology/#sequence-activated)
* [Create task actor](/knowledgebase/terminology/#create-task-actor)
* [Matched Records](/knowledgebase/terminology/#matched-records)
* [children records](/knowledgebase/terminology/#children-records)

## Related topics

* Not provided.

## Prerequisites

* A Catalyst system with a relational model already defined
* Basic familiarity with the relational modeller and creating relational models
* Existing object classes and fields such as Contract Type and Contract Status
* Ability to create and edit sequences
* A task template to use with the Create task actor

## Not covered

* How to define the relational model itself in detail
* General Sequence Runner use for the same object class beyond a brief mention
* The later article about using Sequence Runner for one object class
* Broader actor behavior outside this specific Relation Lookup to Sequence Runner scenario

---

---
url: >-
  /knowledgebase-agent-guides/administration/about-administration/about-administration/index.agent.md
---
# Agent guide: About Administration

* **Page path:** `administration/about-administration/about-administration/index.md`
* **Page type:** explanation

## What this page is about

This page explains who can access the Administration area in Autologyx and what they will see based on account type or Role permissions. It summarizes the available administration sections, tiles, counters, and the meaning of tile actions like Configure, Create, and Manage.

## User intent

* Understand who can access the Administration section
* Determine what Administration options appear for Super admin versus Standard users with admin Roles
* Identify which system areas can be created, edited, or deleted from Administration
* Understand what the Administration intro page tiles represent
* Interpret tile counters and action buttons such as Configure, Create, and Manage

## Key terms

* Administration
* Super admin account
* Standard account type
* Role
* Single page configuration
* Multiple page configuration
* Company details
* User groups
* Standard authentication
* Single sign on settings
* Authentication objects
* Users
* Roles
* Outbound mail setup
* tile counters
* Configure
* Create
* Manage

## Terminology links

* [Administration Sections](/knowledgebase/terminology/#administration-sections) (matched from `Administration`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin account`)
* [Standard account type](/knowledgebase/terminology/#standard-account-type)
* [Roles](/knowledgebase/terminology/#roles) (matched from `Role`)
* [Single page configuration](/knowledgebase/terminology/#single-page-configuration)
* [Multiple page configuration](/knowledgebase/terminology/#multiple-page-configuration)
* [Company details](/knowledgebase/terminology/#company-details)
* [User Groups](/knowledgebase/terminology/#user-groups)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx account types
* Basic understanding of Roles and permissions in Autologyx
* Access to the Autologyx application

## Not covered

* Step-by-step configuration instructions for any Administration area
* Detailed behavior of Users, Roles, Authentication objects, or Single sign on settings
* How to assign Roles or permissions
* How outbound mail setup works beyond entering credentials
* Any non-Administration application areas

---

---
url: /knowledgebase-agent-guides/administration/about-administration/index.agent.md
---
# Agent guide: About Administration

* **Page path:** `administration/about-administration/index.md`
* **Page type:** explanation

## What this page is about

This page is a minimal landing page for the Administration section. It indicates that users should browse the sections below, but provides no substantive administrative guidance itself.

## User intent

* Understand what the Administration section is
* Locate further administration-related sections to browse

## Key terms

* Administration
* Autologyx
* Classification: Unrestricted, Public

## Terminology links

* [Administration Sections](/knowledgebase/terminology/#administration-sections) (matched from `Administration`)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Specific administration tasks or procedures
* Administrative roles, permissions, or settings
* Step-by-step instructions
* Detailed explanations of administration features

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/about-system-configuration/about-system-configuration/index.agent.md
---
# Agent guide: About System configuration

* **Page path:** `system-configuration/about-system-configuration/about-system-configuration/index.md`
* **Page type:** explanation

## What this page is about

This page explains what the System configuration area is for, who typically uses it, and how access, tiles, counts, and button availability vary by account type and permissions. It also notes a key restriction around configuring the Landing page.

## User intent

* Understand who the System configuration area is intended for
* Learn what access a Super admin or role-based user typically has
* Interpret the sections, tiles, and tile counts on the System configuration page
* Understand what the numbers on tiles mean, including Sequences counts
* Know when Create and Manage buttons appear based on permissions
* Identify the limitation that only a Super admin can configure the Landing page

## Key terms

* System configuration
* Business Analyst
* Implementation Specialist
* Object classes
* Task templates
* workflows
* Super admin account
* Role
* Standard account type
* tiles
* tile counts
* Sequences
* running sequences
* paused sequences
* Create
* Manage
* Landing page

## Terminology links

* [System configuration](/knowledgebase/terminology/#system-configuration)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [Task templates](/knowledgebase/terminology/#task-templates)
* [Catalyst workflows](/knowledgebase/terminology/#catalyst-workflows) (matched from `workflows`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin account`)
* [Roles](/knowledgebase/terminology/#roles) (matched from `Role`)
* [Standard account type](/knowledgebase/terminology/#standard-account-type)
* [System configuration tiles](/knowledgebase/terminology/#system-configuration-tiles) (matched from `tiles`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the Autologyx application
* A user account with configuration permissions or awareness of assigned role/account type
* General understanding of platform-building concepts such as object classes, task templates, and workflows

## Not covered

* Detailed instructions for configuring any specific area
* How to create or manage object classes, task templates, sequences, or workflows step by step
* Definitions of all 5 configuration areas
* Role setup or permission assignment details beyond general access behavior
* Landing page configuration steps

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/about-system-configuration/index.agent.md
---
# Agent guide: About System Configuration

* **Page path:** `system-configuration/about-system-configuration/index.md`
* **Page type:** explanation

## What this page is about

This page is a brief navigation overview for system configuration. It points readers to sections about system configuration in general and managing authentication methods by user account type.

## User intent

* Find where to browse system configuration documentation
* Locate information about managing authentication methods
* Understand that authentication configuration may vary by user account type

## Key terms

* System Configuration
* Managing Authentication Methods
* User Account Type
* Authentication Methods

## Terminology links

* [System configuration](/knowledgebase/terminology/#system-configuration)
* [Authentication Methods](/knowledgebase/terminology/#authentication-methods) (matched from `Managing Authentication Methods`)
* [User Account Types](/knowledgebase/terminology/#user-account-types) (matched from `User Account Type`)
* [authentication method management](/knowledgebase/terminology/#authentication-method-management) (matched from `Authentication Methods`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with system administration concepts
* Awareness of user accounts and authentication

## Not covered

* Specific system configuration procedures
* Detailed authentication setup steps
* Definitions of user account types
* Any configuration examples or troubleshooting guidance

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/theme/about-the-theme/index.agent.md
---
# Agent guide: About the Theme

* **Page path:** `system-configuration/theme/about-the-theme/index.md`
* **Page type:** explanation

## What this page is about

This page explains what the Theme feature is in Catalyst and how it is used to brand the system with a logo, company colours, and some login page text overrides. It also states who can access it, where to find it, and that an enabled theme applies system-wide to all users.

## User intent

* Understand what the Theme feature is for
* Learn how branding can be applied to Catalyst
* Find out who is allowed to create or access a Theme
* Locate the Theme page in the system or via direct URL
* Know what parts of the system can be configured by a Theme
* Confirm how broadly an enabled Theme is applied
* Understand current limitations, such as support for only one theme initially

## Key terms

* Theme
* Catalyst system
* brand
* logo
* company colours
* login page text overrides
* Super admin
* System configuration
* Access Denied
* system-wide application
* single brand theme
* multiple themes

## Terminology links

* [Theme](/knowledgebase/terminology/#theme)
* [Catalyst system](/knowledgebase/terminology/#catalyst-system)
* [Text overrides](/knowledgebase/terminology/#text-overrides) (matched from `login page text overrides`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [System configuration](/knowledgebase/terminology/#system-configuration)
* [Access denied](/knowledgebase/terminology/#access-denied)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst
* Access to the system
* A Super admin account to create or access the Theme page

## Not covered

* Step-by-step instructions for creating or editing a Theme
* Detailed configuration options beyond logo, colours, and some login page text overrides
* How to enable, disable, or manage themes in practice
* Support for multiple themes beyond noting it is planned for the future
* Any technical implementation details or branding design guidance

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequences/adding-conditions-for-sequence-commencement/index.agent.md
---
# Agent guide: Adding conditions for Sequence commencement

* **Page path:** `system-configuration/sequences/adding-conditions-for-sequence-commencement/index.md`
* **Page type:** explanation

## What this page is about

This page explains how to add extra trigger conditions to control when a Sequence starts or progresses, so it only applies to relevant Records. It outlines the available condition types and the kinds of field/operator/value choices each supports.

## User intent

* Add extra conditions to Sequence commencement or trigger configuration
* Restrict a workflow to a subset of Records within an Object class
* Use Record attributes like ID or Created at as trigger conditions
* Use Object class field values to control Sequence activation
* Trigger based on Task attributes such as status, created date, or completion
* Trigger based on Task Group state
* Reference Sequence Variables in trigger logic
* Use Updated Fields and Previous Field Value to react to record updates
* Create branching routes in a Sequence based on field data or task state

## Key terms

* Sequence commencement
* trigger configuration
* starting condition
* Record
* Object class
* Object class fields
* Record ID
* Created at
* Task
* Task Group
* State
* Variable
* Updated Fields
* Previous Field Value
* operators
* subset of Records

## Terminology links

* [trigger configuration](/knowledgebase/terminology/#trigger-configuration)
* [starting conditions](/knowledgebase/terminology/#starting-conditions) (matched from `starting condition`)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `Record`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Object class fields](/knowledgebase/terminology/#object-class-fields)
* [ALX ID](/knowledgebase/terminology/#alx-id) (matched from `Record ID`)
* [Created at](/knowledgebase/terminology/#created-at)
* [Tasks](/knowledgebase/terminology/#tasks) (matched from `Task`)

## Related topics

* Not provided.

## Prerequisites

* A Sequence and its starting condition have already been established
* Basic understanding of Records, Object classes, Tasks, Task Groups, and Variables
* Knowledge of the field types configured on the Object class

## Not covered

* The methods for activating a Sequence in general; this is referenced as covered elsewhere
* A full list of all 7 condition option names
* Detailed configuration steps for creating Tasks, Task Groups, Variables, or Object class fields
* Exhaustive operator/value behavior for every field type beyond the examples shown

---

---
url: /knowledgebase-agent-guides/administration/index.agent.md
---
# Agent guide: Administration

* **Page path:** `administration/index.md`
* **Page type:** explanation

## What this page is about

Overview of the Administration area in Autologyx, which manages system-wide settings, shared controls, and the people who use the environment. It explains how Administration differs from Workspace and System configuration, and points to the main admin topics to review.

## User intent

* Understand what Administration is for in Autologyx
* Learn how Administration differs from Workspace and System configuration
* Find where to manage users, user groups, roles, and permissions
* Locate authentication, sign-in, and communication settings
* Identify advanced administrative or platform extension features
* Follow a recommended path for getting started with Administration

## Key terms

* Administration
* system-wide settings
* shared controls
* Super Admins
* platform administrators
* users
* access
* authentication
* communications
* Workspace
* System configuration
* User Groups
* Roles
* Permissions
* Authentication Objects
* Elements
* governance

## Terminology links

* [Administration Sections](/knowledgebase/terminology/#administration-sections) (matched from `Administration`)
* [Super Admins](/knowledgebase/terminology/#super-admins)
* [Users list](/knowledgebase/terminology/#users-list) (matched from `users`)
* [Authentication](/knowledgebase/terminology/#authentication)
* [Communication](/knowledgebase/terminology/#communication) (matched from `communications`)
* [Workspace](/knowledgebase/terminology/#workspace)
* [System configuration](/knowledgebase/terminology/#system-configuration)
* [User Groups](/knowledgebase/terminology/#user-groups)

## Related topics

* About Administration
* All about users
* User Groups
* Roles and Permissions
* Authentication Objects
* Communication
* Elements

## Prerequisites

* Basic familiarity with the Autologyx platform areas
* An administrative responsibility such as managing users, access, or shared platform settings

## Not covered

* Day-to-day end-user work with records, tasks, and documents in the Workspace
* Solution-building configuration such as data model, workflows, tasks, forms, and integrations
* Detailed procedures for each linked administration topic

---

---
url: >-
  /knowledgebase-agent-guides/getting-started/platform-admin-administrators/administration/index.agent.md
---
# Agent guide: Administration

* **Page path:** `getting-started/platform-admin-administrators/administration/index.md`
* **Page type:** getting-started

## What this page is about

Introduces the responsibilities of a Catalyst Super admin and gives a quick checklist of the global Administration settings available in the platform. It outlines the main areas admins manage, such as users, authentication, company details, sensitive connection credentials, and outbound mail.

## User intent

* Understand what a Catalyst administrator is responsible for
* Find the main settings available under Administration
* Learn where to manage users, roles, and user groups
* Identify where to configure password rules and account activation behavior
* See where to set up single sign-on providers like Microsoft or Google
* Understand where company details are stored and how they are used in merge fields and message templates
* Locate Authentication Objects for storing sensitive third-party API login details
* Find where outbound mail services are configured for notifications

## Key terms

* Administration
* Catalyst
* Super admin
* Users
* Roles
* User groups
* Workspace
* Company details
* merge fields
* message templates
* Standard authentication
* password rules
* Single sign on
* Authentication Objects
* API calls
* Outbound mail setup

## Terminology links

* [Administration Sections](/knowledgebase/terminology/#administration-sections) (matched from `Administration`)
* [Catalyst](/knowledgebase/terminology/#catalyst)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Users list](/knowledgebase/terminology/#users-list) (matched from `Users`)
* [Roles](/knowledgebase/terminology/#roles)
* [User Groups](/knowledgebase/terminology/#user-groups)
* [Workspace](/knowledgebase/terminology/#workspace)
* [Company details](/knowledgebase/terminology/#company-details)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst
* Administrative access, typically a Super admin account
* General understanding of user access, authentication, and platform configuration

## Not covered

* Step-by-step procedures for each Administration area
* Detailed instructions for creating users, roles, or user groups
* Specific SSO provider configuration steps
* Technical details of third-party API integrations
* Detailed outbound mail configuration beyond pointing to the setup area
* Non-administrative workspace record or task usage

---

---
url: >-
  /knowledgebase-agent-guides/applied-ai/applied-ai-and-the-sequencer/index.agent.md
---
# Agent guide: AI and the Sequencer

* **Page path:** `applied-ai/applied-ai-and-the-sequencer/index.md`
* **Page type:** reference

## What this page is about

This page explains how Autologyx Catalyst uses the Sequencer to initiate, manage, and consume AI interactions inside controlled workflows. It positions Catalyst as a model-agnostic orchestrator that keeps responsibility for workflow control, data, permissions, routing, tasks, and auditability while AI supports specific processing steps.

## User intent

* Understand when to use AI from within a Catalyst workflow
* Learn how the Sequencer pattern starts and controls AI requests
* Decide whether to use native AI actors or the API Call actor for AI integration
* Design workflows that store, route, and act on AI responses
* Assess when human review is needed before using AI outputs
* Understand the difference between AI-and-Sequencer workflows and MCP services
* Plan model-agnostic AI workflow designs across providers or endpoints

## Key terms

* Sequencer
* Catalyst
* AppliedAI
* model agnostic orchestrator
* AI services
* workflow routing
* structured inputs and outputs
* native AI connectivity
* dedicated actors
* API Call actor
* REST endpoint
* playbook style prompt functions
* Object Class
* Loop Actor
* structured record data
* human in the loop review
* deterministic checks
* hallucinated content
* audit trail
* MCP services

## Terminology links

* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Autologyx Catalyst](/knowledgebase/terminology/#autologyx-catalyst) (matched from `Catalyst`)
* [AppliedAI](/knowledgebase/terminology/#appliedai)
* [model agnostic orchestrator](/knowledgebase/terminology/#model-agnostic-orchestrator)
* [dedicated actors](/knowledgebase/terminology/#dedicated-actors)
* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [playbook functions](/knowledgebase/terminology/#playbook-functions) (matched from `playbook style prompt functions`)
* [Object Classes](/knowledgebase/terminology/#object-classes) (matched from `Object Class`)

## Related topics

* Using the API Call actor with AI services
* MCP services

## Prerequisites

* Basic understanding of Autologyx Catalyst workflows and the Sequencer
* Familiarity with records, tasks, documents, notifications, and routing in Catalyst
* Basic understanding of AI prompts, responses, and provider integrations

## Not covered

* Detailed setup steps for any specific AI provider
* Full configuration details for native AI actors
* Implementation details of 'Using the API Call actor with AI services'
* Detailed MCP services behavior beyond the high-level comparison
* Guarantees of AI accuracy or deterministic behavior
* General-purpose agent-led interaction patterns where the AI initiates requests into Autologyx

---

---
url: >-
  /knowledgebase-agent-guides/finding-your-way-around/ui-and-navigation/all-about-panels/index.agent.md
---
# Agent guide: All about Panels

* **Page path:** `finding-your-way-around/ui-and-navigation/all-about-panels/index.md`
* **Page type:** explanation

## What this page is about

This page appears intended to explain panels in Autologyx, but the provided content only includes the title and a classification label, with no substantive information.

## User intent

* Find information about what panels are in Autologyx
* Understand how panels relate to the UI and navigation

## Key terms

* Panels
* Autologyx
* UI and navigation
* Classification: Unrestricted, Public

## Terminology links

* [Panels](/knowledgebase/terminology/#panels)
* [UI and Navigation](/knowledgebase/terminology/#ui-and-navigation)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx
* General awareness of UI/navigation concepts

## Not covered

* Definition of panels
* How to use or configure panels
* Types of panels
* Panel behavior in the interface
* Any procedural or conceptual details beyond the title

---

---
url: >-
  /knowledgebase-agent-guides/administration/all-about-users/all-about-users/index.agent.md
---
# Agent guide: All about users

* **Page path:** `administration/all-about-users/all-about-users/index.md`
* **Page type:** explanation

## What this page is about

This page explains the Users list, including its default and optional columns, what information it shows for each user, and what actions you can take from the list. It also notes limits for users and roles and points to related help articles for account types, status, activation, and SSO.

## User intent

* Understand what information is available in the Users list
* Identify the most important user fields, especially Account Type and Status
* Learn which columns are shown by default and which can be added
* Find out what actions can be performed on a user from the list
* Understand how user IDs and usernames are used
* Create a new user from the list
* Check system limits for total users and roles

## Key terms

* Users list
* ID
* Username
* Account Type
* Status
* Roles
* Actions
* Pending
* Resend activation email
* Config admin
* list page
* filter editor
* single sign on

## Terminology links

* [Users list](/knowledgebase/terminology/#users-list)
* [Identifier](/knowledgebase/terminology/#identifier) (matched from `ID`)
* [Username](/knowledgebase/terminology/#username)
* [account type](/knowledgebase/terminology/#account-type)
* [envelope status](/knowledgebase/terminology/#envelope-status) (matched from `Status`)
* [Roles](/knowledgebase/terminology/#roles)
* [Actions menu](/knowledgebase/terminology/#actions-menu) (matched from `Actions`)
* [Pending status](/knowledgebase/terminology/#pending-status) (matched from `Pending`)

## Related topics

* How do I create a user account?
* What can I edit in a user account?
* How do I configure user activation rules?
* What happens when an individual uses single sign on?

## Prerequisites

* Basic familiarity with list pages in the system
* Understanding that users have account types and statuses
* Access to the Users list

## Not covered

* Full explanation of the 5 account types
* Detailed explanation of account status values
* Step-by-step instructions for creating a user account
* Detailed configuration of activation rules
* Detailed behavior of single sign on
* General list page features and filter editor usage beyond brief references

---

---
url: /knowledgebase-agent-guides/administration/all-about-users/index.agent.md
---
# Agent guide: All About Users

* **Page path:** `administration/all-about-users/index.md`
* **Page type:** explanation

## What this page is about

An overview hub for user-related documentation in Catalyst, listing key topics about user accounts, task assignment, authentication, and account management. It points readers to specific sections for common user administration questions.

## User intent

* Find how to create a user account
* Understand assigning tasks to 1 Time Completion Users
* Learn how a 1 Time Completion User interacts with Catalyst
* Understand service accounts
* See what can be edited in a user account
* Learn what happens when a user uses the Forgot Your Password link
* Understand what happens when an individual uses Single Sign On

## Key terms

* Users
* 1 Time Completion Users
* User account
* Catalyst
* Service Accounts
* Forgot Your Password
* Single Sign On

## Terminology links

* [Users list](/knowledgebase/terminology/#users-list) (matched from `Users`)
* [1 time completion user](/knowledgebase/terminology/#1-time-completion-user) (matched from `1 Time Completion Users`)
* [User account](/knowledgebase/terminology/#user-account)
* [Catalyst](/knowledgebase/terminology/#catalyst)
* [Service Accounts](/knowledgebase/terminology/#service-accounts)
* [Forgot Your Password](/knowledgebase/terminology/#forgot-your-password)
* [Single sign on](/knowledgebase/terminology/#single-sign-on)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst user management concepts

## Not covered

* Detailed procedures or explanations for each listed topic are not included on this page
* Role/permission models are not mentioned
* No step-by-step configuration details are provided

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.10/analytics-database/index.agent.md
---
# Agent guide: Analytics Database

* **Page path:** `release-notes/release-notes-1.10/analytics-database/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces the Analytics Database, a ClickHouse-based reporting database that unifies data from the Resource Database and History Events Database through ETL. It explains the included tables, sync behavior, analytical uses, and BI-tool connectivity for organizations with the feature enabled.

## User intent

* Understand what the Analytics Database is and why it was introduced
* Learn which source systems feed the Analytics Database
* See what tables are available for reporting and analysis
* Understand how often data is refreshed and how performance is handled
* Identify what kinds of SQL analysis and BI reporting are possible
* Assess practical use cases such as due diligence, audit trails, workflow bottlenecks, and task tracking
* Determine whether standard BI tools like Power BI and Tableau can connect to it

## Key terms

* Analytics Database
* ClickHouse
* ETL
* Extract, Transform, Load
* Resource Database
* PostgreSQL
* History Events Database
* single source of truth
* incremental updates
* 30-minute sync
* chunked processing
* Object Records
* Tasks
* Fields
* Object Records History
* Permission Sets
* User Groups
* Users
* SQL
* Views
* BI tools
* Power BI DirectQuery
* Tableau

## Terminology links

* [Analytics Database](/knowledgebase/terminology/#analytics-database)
* [Resource Database](/knowledgebase/terminology/#resource-database)
* [History Events Database](/knowledgebase/terminology/#history-events-database)
* [Object records](/knowledgebase/terminology/#object-records)
* [Tasks](/knowledgebase/terminology/#tasks)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `Fields`)
* [Object Records History](/knowledgebase/terminology/#object-records-history)
* [Permission Sets](/knowledgebase/terminology/#permission-sets)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with operational and historical data concepts
* Basic understanding of SQL and BI reporting tools
* Awareness of Catalyst data such as object records, tasks, users, and permissions

## Not covered

* Step-by-step setup or configuration instructions for enabling the feature
* Connection details such as credentials, endpoints, or network requirements
* Full database schema, field definitions, or example SQL queries
* Administration, security, or access-control configuration for the Analytics Database
* Troubleshooting guidance for ETL, sync failures, or BI integrations
* Licensing or availability criteria beyond noting that it applies to organizations with the feature enabled

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/apis-and-variables/api-call-actor/index.agent.md
---
# Agent guide: API Call Actor

* **Page path:** `system-configuration/apis-and-variables/api-call-actor/index.md`
* **Page type:** reference

## What this page is about

Reference for configuring and testing the API Call Actor, which sends HTTP requests from a Sequence to external systems or Autologyx endpoints. It explains configuration fields, testing behavior, debugging use, and platform nuances that affect execution.

## User intent

* Understand what the API Call Actor is used for
* Configure an API Call Actor in a Sequence
* Choose the correct template, HTTP method, data type, and authentication
* Build dynamic URLs, headers, parameters, and payloads with Merge fields and Jinja
* Attach files to API calls and know the difference between live execution and test execution
* Test an API Call with a Record ID and test document
* Review logs and troubleshoot failed or misrendered API calls
* Use the API Call Actor as a debugging tool inside a Sequence
* Understand why an API Call Actor is red/yellow and when retesting is required
* Avoid unintended side effects when API calls update Autologyx records

## Key terms

* API Call Actor
* Sequence
* Standard Configuration
* iManage
* HTTP method
* GET
* POST
* PUT
* PATCH
* DELETE
* Data Type
* Form Data
* Multipart Data
* JSON Data
* XML Data
* Binary Data
* Authentication
* Auth Object
* Authentication Object
* Merge fields
* Jinja expressions
* URL Parameters
* Headers
* Parameters (Payload)
* Document Picker Actor
* Retry
* Notify
* Record ID
* Object Record
* Object Class
* Test Call
* API test call history
* Show Log
* Local Variable Actor
* Update Record Actor
* Actor Completed triggers
* Record Updated
* Activity Log

## Terminology links

* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequence`)
* [Standard Configuration](/knowledgebase/terminology/#standard-configuration)
* [iManage template](/knowledgebase/terminology/#imanage-template) (matched from `iManage`)
* [Delete permission](/knowledgebase/terminology/#delete-permission) (matched from `DELETE`)
* [Data Type](/knowledgebase/terminology/#data-type)
* [Form Data](/knowledgebase/terminology/#form-data)
* [Multipart Data](/knowledgebase/terminology/#multipart-data)

## Related topics

* Not provided.

## Prerequisites

* Familiarity with Sequences
* Familiarity with Merge fields
* Familiarity with Authentication Objects
* Familiarity with Object Records
* Depending on the integration, familiarity with Local Variable Actor, Document Picker Actor, and Update Record Actor

## Not covered

* Detailed iManage integration guidance beyond selecting the iManage template
* How to create or configure Authentication Objects themselves
* General HTTP/API design concepts beyond the listed request options
* Detailed behavior of Local Variable Actor, Document Picker Actor, or Update Record Actor
* Broader Sequence design outside the API Call Actor

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.9/api-for-delaying-user-account-activation/index.agent.md
---
# Agent guide: API for delaying user account activation

* **Page path:** `release-notes/release-notes-1.9/api-for-delaying-user-account-activation/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces an API-only way to delay user account activation so administrators can create and configure users before sending the activation email. It explains the new parameter behavior, resulting user statuses, email restrictions, and limitations.

## User intent

* Understand how to create a user via API without immediately sending an activation email
* Learn what user status is assigned when delayed activation is enabled or not enabled
* Find out when activation emails can be sent and how they affect user status
* Check whether delayed activation is supported for 1TC users
* Confirm whether this feature is available in the UI or only via API
* Understand what emails are blocked for non-active users

## Key terms

* delayed account activation
* API
* activation email
* Created status
* Pending status
* 1TC (One Time Completion) users
* non-active users
* user creation
* account type change

## Terminology links

* [delayed account activation](/knowledgebase/terminology/#delayed-account-activation)
* [API](/knowledgebase/terminology/#api)
* [activation email](/knowledgebase/terminology/#activation-email)
* [Created status](/knowledgebase/terminology/#created-status)
* [Pending status](/knowledgebase/terminology/#pending-status)
* [1TC (One Time Completion) users](/knowledgebase/terminology/#1tc-one-time-completion-users)
* [non active users](/knowledgebase/terminology/#non-active-users) (matched from `non-active users`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of creating and managing users via API
* Familiarity with user statuses such as Created and Pending
* Awareness of 1TC user account types

## Not covered

* Specific API endpoint names or full request/response examples
* UI-based configuration, since the feature is API-only
* Detailed steps for role assignment, task designation, or workflow design
* Behavior for statuses beyond Created, Pending, and non-active users
* General email system behavior outside activation and blocked non-active-user emails

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.10/api-for-groups-in-record-permission-sets/index.agent.md
---
# Agent guide: API for Groups in Record Permission Sets

* **Page path:** `release-notes/release-notes-1.10/api-for-groups-in-record-permission-sets/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces API support for assigning, viewing, and unassigning User Groups in Record Permission Sets. It explains the new group-specific endpoints, their behavior, limits, and how they complement existing individual-user permission endpoints.

## User intent

* Understand how to manage User Groups in Record Permission Sets via API
* Find what new endpoints exist for group-based permission management
* Learn how to assign User Groups by passing group IDs
* Check how to view which User Groups are assigned to a permission set
* Learn how to unassign User Groups from a permission set
* Understand limits, duplicate-handling, permission visibility rules, and audit logging
* Confirm whether existing individual-user endpoints are still supported

## Key terms

* User Groups
* Record Permission Sets
* API endpoints
* assign User Groups
* view assigned User Groups
* unassign User Groups
* group IDs
* individual users
* object history
* permission inheritance
* access control

## Terminology links

* [User Groups](/knowledgebase/terminology/#user-groups)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `Record Permission Sets`)
* [API endpoints](/knowledgebase/terminology/#api-endpoints)
* [Assign User Groups](/knowledgebase/terminology/#assign-user-groups)
* [Unassign User Groups](/knowledgebase/terminology/#unassign-user-groups)
* [group IDs](/knowledgebase/terminology/#group-ids)
* [object history](/knowledgebase/terminology/#object-history)
* [inherit permissions](/knowledgebase/terminology/#inherit-permissions) (matched from `permission inheritance`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Record Permission Sets
* Familiarity with API-based permission management
* Awareness of User Groups and group IDs
* Understanding of existing endpoints for managing individual users

## Not covered

* Exact endpoint URLs or full request/response schemas are not clearly specified in the text
* Authentication/authorization setup for calling the API
* How to create or manage User Groups themselves
* Broader permission model details beyond Record Permission Sets
* Implementation examples in specific programming languages

---

---
url: /api-agent-guides/standards/index.agent.md
---
# Agent guide: API standards

* **Page path:** `standards/index.md`
* **Page type:** reference

## What this page is about

Defines platform-wide Autologyx API standards so endpoints behave consistently across services, covering typing, request/response conventions, validation, filtering, sorting, schemas, and common method-specific behaviors.

## User intent

* Understand the baseline rules for designing or reviewing Autologyx API endpoints
* Check supported data types and structural schema concepts
* Apply standard POST, PATCH, GET, DELETE, and OPTIONS behaviors
* Implement consistent validation and error handling
* Use standard filtering and sorting predicates for list endpoints
* Understand how strongly typed fields, enums, sets, users, owners, and permissions should be represented

## Key terms

* strong typing
* data types
* data structures
* request and response conventions
* validation
* error handling
* filtering predicates
* sorting
* schema definitions
* POST standards
* PATCH standards
* GET standards
* DELETE standards
* OPTIONS standards
* enum
* set
* owners
* permissions
* non modifiable properties
* labels
* nested schema
* validators
* restrictions
* autocomplete

## Terminology links

* [filtering predicates](/api/terminology/#filtering-predicates)
* [ordering](/api/terminology/#ordering) (matched from `sorting`)
* [owners type](/api/terminology/#owners-type) (matched from `owners`)
* [permissions](/api/terminology/#permissions)
* [non modifiable properties](/api/terminology/#non-modifiable-properties)
* [nested schema](/api/terminology/#nested-schema)
* [restrictions](/api/terminology/#restrictions)
* [autocomplete relative url](/api/terminology/#autocomplete-relative-url) (matched from `autocomplete`)

## Related topics

* API standards

## Prerequisites

* General understanding of HTTP methods and REST-style APIs
* Familiarity with JSON payloads and response schemas
* Basic knowledge of types such as integers, UUIDs, strings, booleans, dates, and enums

## Not covered

* Endpoint-specific business rules or exceptions beyond documented standards
* Complete concrete examples for every response body or status where placeholders appear
* Authentication mechanisms in detail
* Full definitions of nearby pages beyond this standards reference

---

---
url: /api-agent-guides/standards/index_old/index.agent.md
---
# Agent guide: API standards

* **Page path:** `standards/index_old.md`
* **Page type:** reference

## What this page is about

Reference for Autologyx API standards, covering allowed data types and structures, URL conventions, and expected behavior for POST, PATCH, GET, LIST, DETAIL, DELETE, and OPTIONS endpoints. It also defines common error responses, filtering predicates, handling of non-modifiable fields, and OPTIONS response metadata.

## User intent

* Check which primitive and complex data types are allowed in the API
* Understand standard success and error responses for POST/PATCH/GET/DELETE/OPTIONS
* Find canonical validation error messages for invalid payloads, permissions, files, and missing resources
* Learn URL naming conventions such as using dashes instead of underscores
* See how non-modifiable fields should be handled in requests
* Understand list filtering predicates and which operators apply to which data types
* Understand how enum/set labels and helper parameters are represented in list vs detail responses
* Implement or consume OPTIONS responses describing list fields, detail schemas, validators, nested schemas, and restrictions

## Key terms

* data types
* data structures
* int
* uuid
* string
* url
* date
* datetime
* enum
* set
* bool
* email
* json
* user
* user group
* owners
* permissions
* Array
* Object
* POST standards
* PATCH standards
* GET standards
* List standards
* Detail standards
* DELETE standards
* OPTIONS standards
* non modifiable properties
* filtering predicates
* ordering
* permissions fields
* file fields
* nested schema
* schema by value
* validators
* restrictions
* autocomplete

## Terminology links

* [user type](/api/terminology/#user-type) (matched from `user`)
* [user groups](/api/terminology/#user-groups) (matched from `user group`)
* [owners type](/api/terminology/#owners-type) (matched from `owners`)
* [permissions](/api/terminology/#permissions)
* [non modifiable properties](/api/terminology/#non-modifiable-properties)
* [filtering predicates](/api/terminology/#filtering-predicates)
* [ordering](/api/terminology/#ordering)
* [file fields](/api/terminology/#file-fields)

## Related topics

* API standards

## Prerequisites

* Basic REST API concepts and HTTP methods
* Understanding of JSON objects and arrays
* Familiarity with HTTP status codes such as 400, 403, 404
* General knowledge of serializer/validation concepts

## Not covered

* Endpoint-specific business rules beyond the listed generic standards
* Full definitions of all complex object types such as user, owners, or permissions
* Complete examples for every OPTIONS schema sample referenced in the text
* Authentication mechanisms beyond permission-related error outcomes
* Detailed sorting rules for all fields; mainly filtering and metadata behavior are described

---

---
url: /api-agent-guides/terminology/index.agent.md
---
# Agent guide: Api terminology index

* **Page path:** `terminology/index.md`
* **Page type:** reference

## What this page is about

A terminology index built from a saved terminology store. It lists Autologyx API and platform terms with short summaries, audience relevance, statuses, and closely related concepts.

## User intent

* Look up the meaning of a specific API or platform term
* Understand how a term is used in Autologyx APIs or configuration
* Find related concepts or endpoints connected to a term
* Check who a term is most relevant to and why it matters

## Key terms

* /api/integrations/
* /api/integrations/test/
* /api/object class forms/
* 1 Time Completion
* 1 Time Completion account
* account type
* actions
* Activation link valid period
* Actor completed
* add roles
* adding records
* additional authorization headers
* additional limits
* additional parameters
* Admin Context
* AdminContext

## Terminology links

* [/api/integrations/](/api/terminology/#apiintegrations)
* [/api/integrations/test/](/api/terminology/#apiintegrationstest)
* [/api/object class forms/](/api/terminology/#apiobject-class-forms)
* [1 Time Completion](/api/terminology/#1-time-completion)
* [1 Time Completion account](/api/terminology/#1-time-completion-account)
* [account type](/api/terminology/#account-type)
* [permission actions](/api/terminology/#permission-actions) (matched from `actions`)
* [Activation link valid period](/api/terminology/#activation-link-valid-period)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx platform concepts
* Some understanding of REST APIs and configuration terminology

## Not covered

* Detailed endpoint schemas or full request/response examples
* Step-by-step procedures for using the referenced APIs
* Comprehensive coverage of all related standards or concepts beyond the brief summaries shown

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/apis-and-variables/index.agent.md
---
# Agent guide: Apis And Variables

* **Page path:** `system-configuration/apis-and-variables/index.md`
* **Page type:** explanation

## What this page is about

This page is a simple index for topics related to APIs and variables. It points readers to sections on API Call Actor, Local Variable Actor, and namespace usage in Jinja2 for local variables.

## User intent

* Find where to learn about the API Call Actor
* Find where to learn about the Local Variable Actor
* Understand namespace usage in Jinja2 for local variables
* Navigate documentation related to APIs and variables

## Key terms

* APIs
* Variables
* Api Call Actor
* Local Variable Actor
* Namespace
* Jinja2
* Local Variables

## Terminology links

* [API](/knowledgebase/terminology/#api) (matched from `APIs`)
* [local variables](/knowledgebase/terminology/#local-variables) (matched from `Variables`)
* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [Local Variable Actor](/knowledgebase/terminology/#local-variable-actor)
* [Namespace in Jinja2](/knowledgebase/terminology/#namespace-in-jinja2) (matched from `Namespace`)
* [Jinja2](/knowledgebase/terminology/#jinja2)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with APIs
* Basic understanding of variables
* Some awareness of Jinja2 templating may be helpful

## Not covered

* Detailed explanation of the API Call Actor
* Detailed explanation of the Local Variable Actor
* How namespace works in Jinja2 beyond linking to the topic
* Implementation steps, examples, or configuration details

---

---
url: /knowledgebase-agent-guides/applied-ai/index.agent.md
---
# Agent guide: Applied AI

* **Page path:** `applied-ai/index.md`
* **Page type:** reference

## What this page is about

An overview of AppliedAI in Autologyx: how AI is embedded within governed Catalyst workflows to understand, summarise, extract, classify, and act on information. It explains the main AppliedAI patterns—Sequencer-driven AI orchestration, MCP services for assistants/agents, and the security, audit, and governance principles around them.

## User intent

* Understand what AppliedAI means in Autologyx
* Decide whether to use the Sequencer pattern or MCP services for an AI use case
* Learn how AI fits into Catalyst workflows, records, tasks, and configuration guidance
* See typical AppliedAI use cases such as extraction, classification, summarisation, triage, and routing
* Understand how AI assistants and agents can interact with live Autologyx data and services
* Review governance, permissions, auditability, and control expectations for AI-enabled workflows
* Identify the different MCP service families: MCP Work, MCP Success, and future MCP Build
* Understand Autologyx's model-agnostic approach to AI providers and deployments

## Key terms

* AppliedAI
* Autologyx Catalyst
* Sequencer
* Sequence
* MCP services
* MCP Work
* MCP Success
* MCP Build
* AI assistants
* co pilots
* autonomous agents
* agentic workflows
* model agnostic
* workflow orchestration
* deterministic workflow automation
* auditability
* governance
* granular permissions
* human in the loop
* live Catalyst data
* Object records
* Task templates

## Terminology links

* [AppliedAI](/knowledgebase/terminology/#appliedai)
* [Autologyx Catalyst](/knowledgebase/terminology/#autologyx-catalyst)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [MCP services](/knowledgebase/terminology/#mcp-services)
* [Autologyx MCP Work](/knowledgebase/terminology/#autologyx-mcp-work) (matched from `MCP Work`)
* [Autologyx MCP Success](/knowledgebase/terminology/#autologyx-mcp-success) (matched from `MCP Success`)
* [Autologyx MCP Build](/knowledgebase/terminology/#autologyx-mcp-build) (matched from `MCP Build`)
* [co pilot pattern](/knowledgebase/terminology/#co-pilot-pattern) (matched from `co pilots`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst workflows
* Understanding of Sequences, records, tasks, and related workflow concepts
* General awareness of AI assistants, models, or API-based AI services is helpful

## Not covered

* Detailed setup or configuration steps for any specific AI feature
* Provider-specific implementation details beyond examples of supported integration patterns
* Full guidance for Sequencer usage, MCP services, AI assistants, or governance controls—these are referenced as separate pages
* Detailed instructions for OpenAI GPT Actor configuration
* Complete documentation for future MCP Build capabilities

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-classes/object-class-permission-set-assignees/index.agent.md
---
# Agent guide: Assigning for Object Classes Permission Set

* **Page path:** `catalyst/resources/object-classes/object-class-permission-set-assignees.md`
* **Page type:** reference

## What this page is about

Reference for the Object Class Permission Set assignees API endpoints. It covers batch adding, listing, and removing user assignees for a specific object class permission set, along with request rules, limits, and errors.

## User intent

* Add one or more users as assignees to an object class permission set
* List current assignees for a specific object class and permission set
* Remove assignees from an object class permission set in bulk
* Understand validation rules, limits, and error responses for assignee operations
* Check which HTTP methods are supported or not supported for assignees endpoints

## Key terms

* Object Class
* Permission Set
* Assignees
* POST /api/object classes/{object class id}/permission sets/{permission set id}/assignees/
* GET /api/object classes/{object class id}/permission sets/{permission set id}/assignees/
* DELETE /api/object classes/{object class id}/permission sets/{permission set id}/assignees/
* OPTIONS
* batch operation
* user IDs
* 1 Time Completion account
* everyone or members permission set type
* max 100 items per request
* limit of 100 permission set assignees
* users.list permission
* created at
* created by

## Terminology links

* [object classes](/api/terminology/#object-classes) (matched from `Object Class`)
* [object class permission sets](/api/terminology/#object-class-permission-sets) (matched from `Permission Set`)
* [Object Class Assignees](/api/terminology/#object-class-assignees) (matched from `Assignees`)
* [1 Time Completion account](/api/terminology/#1-time-completion-account)
* [Permission Set Assignees limit](/api/terminology/#permission-set-assignees-limit) (matched from `limit of 100 permission set assignees`)
* [users.list permission](/api/terminology/#userslist-permission)
* [created at](/api/terminology/#created-at)
* [created by](/api/terminology/#created-by)

## Related topics

* Assigning User Groups for Object Classes Permission Set
* Assigning Users for Object Classes Permission Set
* Object Classes Permission Sets
* Object Classes

## Prerequisites

* Know the target Object Class ID
* Know the target Permission Set ID
* Have authentication
* Have the required permissions for the relevant Object Class and assignment action
* Have valid user IDs to add or assignee record IDs to remove

## Not covered

* How to create or configure Object Classes
* How to create permission sets themselves
* User group assignment details
* Sorting or filtering assignees beyond noting that sorting is unavailable and filters do not exist
* Behavior of unsupported detail endpoints beyond stating they are not allowed
* UI workflows; this page is API-focused

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-records/object-record-permission-set-assignees/index.agent.md
---
# Agent guide: Assigning for Object Records Permission Set

* **Page path:** `catalyst/resources/object-records/object-record-permission-set-assignees.md`
* **Page type:** reference

## What this page is about

This page defines the API for managing assignee users on an Object Record Permission Set. It covers listing assignees, adding users in batch, removing assignees in batch, and the OPTIONS schema endpoint.

## User intent

* List assignees for a specific object record permission set
* Add one or more users as assignees to an object record permission set
* Remove one or more assignees from an object record permission set
* Understand request/response formats, limits, and error cases for assignee management
* Check which assignee-related endpoints are supported or not allowed

## Key terms

* Object Record
* Permission Set
* Assignees
* record id
* permission set id
* GET /api/object records/{record id}/permission sets/{permission set id}/assignees/
* POST /api/object records/{record id}/permission sets/{permission set id}/assignees/
* DELETE /api/object records/{record id}/permission sets/{permission set id}/assignees/
* OPTIONS /api/object records/{record id}/permission sets/{permission set id}/assignees/
* batch operation
* limit
* offset
* total count
* filtered count
* results
* created at
* created by
* 1 Time Completion account
* users.list permission
* max 100 items
* limit of 100 permission set assignees

## Terminology links

* [Object Records](/api/terminology/#object-records) (matched from `Object Record`)
* [object class permission sets](/api/terminology/#object-class-permission-sets) (matched from `Permission Set`)
* [Object Class Assignees](/api/terminology/#object-class-assignees) (matched from `Assignees`)
* [Object Record ID](/api/terminology/#object-record-id) (matched from `record id`)
* [Permission Set ID](/api/terminology/#permission-set-id)
* [limit](/api/terminology/#limit)
* [total count](/api/terminology/#total-count)
* [filtered count](/api/terminology/#filtered-count)

## Related topics

* Assigning User Groups for Object Records Permission Set
* Assigning Users for Object Records Permission Set
* Object Records Permission Sets
* Object Records

## Prerequisites

* Know the target Object Record ID and Permission Set ID
* Have authentication
* Understand Object Record Permission Sets
* Know relevant permissions, including per-object-record or per-object-class checks as referenced
* For assigning users, have permission to list/assign the target users

## Not covered

* Managing Permission Set endpoints themselves; those are described in a separate document
* Implementation details beyond the referenced external technical design
* Sorting options, because sorting is not available
* Filtering options, because no filters are supported
* Single-item assignee detail/update routes, which are explicitly not allowed

---

---
url: >-
  /api-agent-guides/catalyst/resources/user-groups/user-group-permission-set-assignees/index.agent.md
---
# Agent guide: Assigning for User Groups Permission Set

* **Page path:** `catalyst/resources/user-groups/user-group-permission-set-assignees.md`
* **Page type:** reference

## What this page is about

Reference for API endpoints that manage assignees on a User Groups Permission Set. It covers batch add/list/remove operations for both user assignees and user-group assignees, plus limits, permissions, and error cases.

## User intent

* Add one or more users as assignees to a specific user-group permission set
* List current user assignees for a user-group permission set
* Remove user assignees from a user-group permission set
* Add one or more user groups as assignees to a specific user-group permission set
* List current user-group assignees for a user-group permission set
* Remove user-group assignees from a user-group permission set
* Understand request body expectations, response fields, and batch-size limits
* Check which errors occur for invalid IDs, wrong payload types, missing permissions, or unsupported permission set types

## Key terms

* User Groups Permission Set
* assignees
* users assignees endpoint
* user groups assignees endpoint
* batch operation
* group id
* permission set id
* OPTIONS
* POST
* GET
* DELETE
* 1 Time Completion account
* everyone or members perm set
* ERR LIMIT EXCEEDED
* Requires authentication only
* no filtering
* no sorting

## Terminology links

* [Object Class Assignees](/api/terminology/#object-class-assignees) (matched from `assignees`)
* [Users Group ID](/api/terminology/#users-group-id) (matched from `group id`)
* [Permission Set ID](/api/terminology/#permission-set-id)
* [delete permission](/api/terminology/#delete-permission) (matched from `DELETE`)
* [1 Time Completion account](/api/terminology/#1-time-completion-account)
* [everyone or members perm set](/api/terminology/#everyone-or-members-perm-set)
* [ERR LIMIT EXCEEDED](/api/terminology/#err-limit-exceeded)

## Related topics

* User Group Permission Sets
* User Groups

## Prerequisites

* Know the target Users Group ID and Permission Set ID
* Understand User Groups Permission Sets conceptually
* Be authenticated for OPTIONS and have required permissions for POST/GET/DELETE
* Know whether you are assigning individual users or user groups

## Not covered

* Managing or defining permission sets themselves; the page says those endpoints are documented separately
* Implementation details beyond the API contract; those are in an external technical design document
* PATCH/PUT or detail endpoints for individual assignee records, which are explicitly not allowed
* Filtering or sorting behavior beyond stating that filtering is unavailable and results are unsorted

---

---
url: >-
  /knowledgebase-agent-guides/administration/all-about-users/assigning-tasks-to-1-time-completion-users/index.agent.md
---
# Agent guide: Assigning tasks to 1-time completion Users

* **Page path:** `administration/all-about-users/assigning-tasks-to-1-time-completion-users/index.md`
* **Page type:** explanation

## What this page is about

Explains how to assign automated and manual tasks to 1-time completion users, with emphasis on creating manual tasks from a record and limitations when assigning them. It also notes how these users can be targeted in sequence workflows.

## User intent

* Understand whether 1-time completion users can receive automated and manual tasks
* Learn how to assign a new manual task to a 1-time completion user from a record
* Know which task templates appear when creating manual tasks
* Understand assignment restrictions, such as not being able to add further assignees
* See why adding extra instructions is useful for 1-time completion users
* Understand how 1-time completion users can be assigned tasks via a sequence

## Key terms

* 1-time completion user
* manual task
* automated task
* Task tab
* Record
* Create task
* Task type
* Complete standalone form
* Update object records
* Task template
* Task creation mechanism
* Manual
* assignee
* notification
* additional instructions
* sequence workflow
* default task assignee

## Terminology links

* [1 time completion user](/knowledgebase/terminology/#1-time-completion-user) (matched from `1-time completion user`)
* [Manual Tasks](/knowledgebase/terminology/#manual-tasks) (matched from `manual task`)
* [Tasks tab](/knowledgebase/terminology/#tasks-tab) (matched from `Task tab`)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `Record`)
* [Create task actor](/knowledgebase/terminology/#create-task-actor) (matched from `Create task`)
* [Task type](/knowledgebase/terminology/#task-type)
* [Complete standalone form](/knowledgebase/terminology/#complete-standalone-form)
* [Update object records](/knowledgebase/terminology/#update-object-records)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with records and the Task tab in the sidebar
* Understanding of task templates and task creation mechanisms
* General awareness of sequences/workflows in Catalyst

## Not covered

* Detailed steps for how the 1-time completion user completes or interacts with tasks beyond noting a separate page exists
* How to configure or create task templates
* How to create or manage 1-time completion user accounts
* Full sequence setup instructions
* Any permissions, security, or notification customization details

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-classes/object-class-permission-set-user-group-assignees/index.agent.md
---
# Agent guide: Assigning User Groups for Object Classes Permission Set

* **Page path:** `catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.md`
* **Page type:** reference

## What this page is about

Describes the API endpoints for managing user-group assignees on an Object Class permission set. It covers batch create, list, schema discovery, and batch delete operations for user-group assignees tied to a specific object class and permission set.

## User intent

* Add one or more user groups as assignees to an Object Class permission set
* List current user-group assignees for a specific Object Class permission set
* Remove one or more user-group assignees from a permission set
* Understand request/response formats, limits, permissions, and error cases for these endpoints

## Key terms

* Object Class
* Permission Set
* Assignees
* User Groups
* POST /api/object classes/{object class id}/permission sets/{permission set id}/assignees/user groups/
* GET /api/object classes/{object class id}/permission sets/{permission set id}/assignees/user groups/
* DELETE /api/object classes/{object class id}/permission sets/{permission set id}/assignees/user groups/
* OPTIONS
* object class id
* permission set id
* batch operation
* assignee id
* user group id
* everyone or members permission set type
* limit of 10 items
* 403 Forbidden
* 404 Not Found
* 400 Bad Request

## Terminology links

* [object classes](/api/terminology/#object-classes) (matched from `Object Class`)
* [object class permission sets](/api/terminology/#object-class-permission-sets) (matched from `Permission Set`)
* [Object Class Assignees](/api/terminology/#object-class-assignees) (matched from `Assignees`)
* [user groups](/api/terminology/#user-groups)
* [Permission Set ID](/api/terminology/#permission-set-id)

## Related topics

* Assigning Users for Object Classes Permission Set
* Assigning for Object Classes Permission Set
* Object Classes Permission Sets
* Object Classes

## Prerequisites

* Know the target Object Class ID and Permission Set ID
* Understand Object Class permission sets and assignees
* Be authenticated for OPTIONS and have required object-class-level permissions for POST/GET/DELETE
* Have valid user group IDs or assignee IDs depending on the operation

## Not covered

* How to create or manage user groups themselves
* How permission set types are defined beyond the restriction that assignees cannot be set for everyone or members types
* Any sorting or filtering options beyond stating that GET has no sorting and no filters
* Detailed example payloads/responses, despite placeholders indicating examples
* User assignee management; that is covered by the separate users-assignment page

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-records/object-record-permission-set-user-group-assignees/index.agent.md
---
# Agent guide: Assigning User Groups for Object Records Permission Set

* **Page path:** `catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`
* **Page type:** reference

## What this page is about

Reference for the Object Records Permission Set user-group assignees API. It describes how to add, list, inspect schema for, and remove user groups assigned to a specific object record permission set.

## User intent

* Add one or more user groups as assignees to an object record permission set
* List current user-group assignees for a given object record and permission set
* Remove one or more user-group assignees from a permission set
* Check request/response structure for the user-group assignees endpoints via OPTIONS
* Understand limits, validation rules, and error responses for batch assignment/removal

## Key terms

* Object Record ID
* Permission Set ID
* user group assignees
* batch operation
* POST /api/object records/{object record id}/permission sets/{permission set id}/assignees/user groups/
* GET /api/object records/{object record id}/permission sets/{permission set id}/assignees/user groups/
* DELETE /api/object records/{object record id}/permission sets/{permission set id}/assignees/user groups/
* OPTIONS
* assignee
* created at
* created by
* limit
* offset
* total count
* filtered count
* everyone or members permission set
* max 10 items allowed
* ERR LIMIT EXCEEDED

## Terminology links

* [Object Records](/api/terminology/#object-records) (matched from `Object Record ID`)
* [Permission Set ID](/api/terminology/#permission-set-id)
* [user group assignees](/api/terminology/#user-group-assignees)
* [Object Class Assignees](/api/terminology/#object-class-assignees) (matched from `assignee`)
* [created at](/api/terminology/#created-at)
* [created by](/api/terminology/#created-by)
* [limit](/api/terminology/#limit)
* [total count](/api/terminology/#total-count)

## Related topics

* Assigning Users for Object Records Permission Set
* Assigning for Object Records Permission Set
* Object Records Permission Sets
* Object Records

## Prerequisites

* Know the target Object Record ID
* Know the target Permission Set ID
* Have authentication for OPTIONS
* Have the required permission checks for POST, GET, and DELETE on the individual Object Record
* Know relevant user group IDs for assignment, or assignee IDs for deletion

## Not covered

* How to create user groups
* How permission sets themselves are created or configured
* Sorting options, since sorting is not available for GET
* Filtering options, since no filters are supported for GET
* Detailed definitions of the permission names referenced as 'Perm to check'
* User assignee management beyond the related title for assigning users

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-classes/object-class-permission-set-user-assignees/index.agent.md
---
# Agent guide: Assigning Users for Object Classes Permission Set

* **Page path:** `catalyst/resources/object-classes/object-class-permission-set-user-assignees.md`
* **Page type:** reference

## What this page is about

This page documents the API endpoints for managing user assignees on an Object Classes Permission Set. It covers batch POST, GET, DELETE, and OPTIONS behavior, request/response shapes, limits, and error cases.

## User intent

* Add one or more users as assignees to a specific object class permission set
* List current user assignees for a specific object class permission set
* Remove one or more user assignees from a permission set
* Understand request body requirements, limits, and supported methods
* Check which validation and permission errors can occur when assigning or removing users

## Key terms

* Object Class
* Permission Set
* Assignees
* Users
* Batch operation
* object class id
* permission set id
* 1 Time Completion account
* users.list permission
* limit of 100 assignees
* OPTIONS
* POST
* GET
* DELETE

## Terminology links

* [object classes](/api/terminology/#object-classes) (matched from `Object Class`)
* [object class permission sets](/api/terminology/#object-class-permission-sets) (matched from `Permission Set`)
* [Object Class Assignees](/api/terminology/#object-class-assignees) (matched from `Assignees`)
* [user type](/api/terminology/#user-type) (matched from `Users`)
* [Permission Set ID](/api/terminology/#permission-set-id)
* [1 Time Completion account](/api/terminology/#1-time-completion-account)
* [users.list permission](/api/terminology/#userslist-permission)
* [delete permission](/api/terminology/#delete-permission) (matched from `DELETE`)

## Related topics

* Assigning User Groups for Object Classes Permission Set
* Assigning for Object Classes Permission Set
* Object Classes Permission Sets
* Object Classes

## Prerequisites

* Know the target Object Class ID and Permission Set ID
* Be authenticated
* Have the required permission checks for the individual Object Class
* For assigning users, have users.list permission for the user being assigned

## Not covered

* How to create or configure Object Classes themselves
* How permission set types such as everyone or members are defined
* Any sorting or filtering options for assignee listing beyond noting they are unavailable
* Behavior of item-level endpoints under /assignees/users/{id}, which are listed as not allowed
* Detailed permission names are not clearly specified in the page text

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-records/object-record-permission-set-user-assignees/index.agent.md
---
# Agent guide: Assigning Users for Object Records Permission Set

* **Page path:** `catalyst/resources/object-records/object-record-permission-set-user-assignees.md`
* **Page type:** reference

## What this page is about

Reference for the API endpoints that manage user assignees on an Object Record Permission Set. It covers listing, adding in batch, removing in batch, schema discovery via OPTIONS, permissions, limits, and error responses.

## User intent

* List users assigned to a specific permission set for a specific object record
* Add one or more users as assignees to an object record permission set
* Remove one or more user assignee relations from an object record permission set
* Check request/response schema for GET and POST via OPTIONS
* Understand limits, validation rules, and error cases for assignee management

## Key terms

* Object Record
* Permission Set
* assignees
* users
* record id
* permission set id
* Object Record Users Assignees id
* batch operation
* limit
* offset
* total count
* filtered count
* next
* previous
* results
* created at
* created by
* 1 Time Completion account
* Insufficient permissions
* ERR LIMIT EXCEEDED

## Terminology links

* [Object Records](/api/terminology/#object-records) (matched from `Object Record`)
* [object class permission sets](/api/terminology/#object-class-permission-sets) (matched from `Permission Set`)
* [Object Class Assignees](/api/terminology/#object-class-assignees) (matched from `assignees`)
* [user type](/api/terminology/#user-type) (matched from `users`)
* [Object Record ID](/api/terminology/#object-record-id) (matched from `record id`)
* [Permission Set ID](/api/terminology/#permission-set-id)
* [limit](/api/terminology/#limit)
* [total count](/api/terminology/#total-count)

## Related topics

* Assigning User Groups for Object Records Permission Set
* Assigning for Object Records Permission Set
* Object Records Permission Sets
* Object Records

## Prerequisites

* Know the target Object Record ID and Permission Set ID
* Understand Object Record Permission Sets from the separate permission set documentation
* Be authenticated for all endpoints; mutation/list endpoints also require the relevant permission check
* Know that permission checks may be verified via Object Classes details/meta.permissions as referenced

## Not covered

* Managing Permission Sets themselves; that is in a separate document
* Implementation details beyond this API reference; those are in the external technical design
* Any sorting options; sorting is explicitly not available
* Filtering options for the GET list; no filters are supported
* Single-item assignee detail/update/delete endpoints; item-level GET/PATCH/PUT/DELETE/OPTIONS are not allowed
* User group assignee management; covered by a separate related page

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.14/authentication-security/index.agent.md
---
# Agent guide: Authentication & Security

* **Page path:** `release-notes/release-notes-1.14/authentication-security/index.md`
* **Page type:** release-notes

## What this page is about

Release notes for authentication and security updates in version 1.14. It covers enhanced OPTIONS responses for managing authentication methods and refreshed expiry notification emails for Authentication Objects.

## User intent

* Understand what changed in authentication-related API behavior in release 1.14
* Learn how OPTIONS responses now expose authentication configuration details
* Determine how to programmatically identify allowed login methods for different user types
* Review changes to Authentication Object expiry notification emails
* See what changed in expiry date presentation in notification emails

## Key terms

* OPTIONS response
* authentication method management
* authentication configuration
* allowed login methods
* user types
* authentication workflows
* API integration
* Authentication Object
* expiry notification emails
* upcoming expiries
* expired Authentication Objects
* expiry date format

## Terminology links

* [OPTIONS response](/knowledgebase/terminology/#options-response)
* [authentication method management](/knowledgebase/terminology/#authentication-method-management)
* [authentication configuration](/knowledgebase/terminology/#authentication-configuration)
* [different user types](/knowledgebase/terminology/#different-user-types) (matched from `user types`)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `Authentication Object`)
* [expiry notification emails](/knowledgebase/terminology/#expiry-notification-emails)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with authentication concepts
* Basic understanding of API OPTIONS responses
* Awareness of Authentication Objects in the platform
* General knowledge of login method configuration

## Not covered

* Detailed example payload content for the updated OPTIONS response
* Implementation steps for configuring authentication methods
* Full email template text for expiry notifications
* Broader security features outside these specific release-note changes
* Migration or backward-compatibility guidance

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.13/authentication-object-changes/index.agent.md
---
# Agent guide: Authentication object changes

* **Page path:** `release-notes/release-notes-1.13/authentication-object-changes/index.md`
* **Page type:** release-notes

## What this page is about

This release note describes changes to authentication objects that improve credential lifecycle management: automatic expiry notifications, visibility into where credentials are used, and protection against deleting credentials that are still in use.

## User intent

* Understand what changed for authentication objects in release 1.13
* Learn how expiry notifications for credentials now work
* Check what usage information is shown for an authentication object
* Find out whether in-use authentication objects can be deleted
* Assess how these changes reduce workflow breakage from expired or removed credentials

## Key terms

* authentication objects
* authentication credentials
* automatic expiry notifications
* credential expiry
* usage panel
* sequencer integrations
* system email configuration
* deletion protection
* creator notification

## Terminology links

* [Authentication Objects](/knowledgebase/terminology/#authentication-objects)
* [Automatic expiry notifications](/knowledgebase/terminology/#automatic-expiry-notifications)
* [usage panels](/knowledgebase/terminology/#usage-panels) (matched from `usage panel`)
* [Sequencer integrations](/knowledgebase/terminology/#sequencer-integrations)
* [System email configuration](/knowledgebase/terminology/#system-email-configuration)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of authentication objects/credentials used for integrations
* Familiarity with sequences and system email configuration

## Not covered

* How to create or edit authentication objects
* How to refresh tokens or update passwords
* Detailed email notification configuration or customization
* Any migration steps, API details, or UI walkthroughs beyond the described changes

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.9/authentication-objects/index.agent.md
---
# Agent guide: Authentication objects

* **Page path:** `release-notes/release-notes-1.9/authentication-objects/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces enhancements to Authentication Objects, including pre-configured provider-specific fields for providers like Salesforce, Adobe, and Box, plus built-in testing. It also introduces a Generic OAuth 2.0 template for client credentials flow and lists its configuration fields.

## User intent

* Understand what changed in Authentication Objects in release 1.9
* Learn which providers have pre-configured authentication fields
* See what the Generic OAuth 2.0 template supports
* Identify the fields required to configure OAuth 2.0 client credentials authentication
* Understand how built-in testing helps validate an authentication configuration before go-live

## Key terms

* Authentication Objects
* pre-configured fields
* provider-specific fields
* Salesforce
* Adobe
* Box
* built-in testing
* Generic OAuth 2.0 template
* OAuth 2.0
* client credentials flow
* Token URL
* Refresh URL
* Client ID
* Client Secret
* Additional Parameters
* Additional Authorization Headers

## Terminology links

* [Authentication Objects](/knowledgebase/terminology/#authentication-objects)
* [pre configured fields](/knowledgebase/terminology/#pre-configured-fields) (matched from `pre-configured fields`)
* [built in testing feature](/knowledgebase/terminology/#built-in-testing-feature) (matched from `built-in testing`)
* [Generic OAuth 2.0 template](/knowledgebase/terminology/#generic-oauth-20-template)
* [Authentication client credentials flow](/knowledgebase/terminology/#authentication-client-credentials-flow) (matched from `client credentials flow`)
* [Token URL](/knowledgebase/terminology/#token-url)
* [Refresh URL](/knowledgebase/terminology/#refresh-url)
* [Client ID](/knowledgebase/terminology/#client-id)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of integrations with external providers
* Familiarity with OAuth 2.0 concepts
* Awareness of client credentials flow
* Knowledge of provider-specific application credentials such as client ID and client secret

## Not covered

* Step-by-step setup instructions for any specific provider
* Detailed OAuth 2.0 background or security guidance
* Other OAuth flows beyond standard client credentials flow
* Exact testing workflow or validation criteria
* Troubleshooting or error handling details

---

---
url: >-
  /api-agent-guides/catalyst/resources/authentication/authentication-objects/index.agent.md
---
# Agent guide: Authentication Objects

* **Page path:** `catalyst/resources/authentication/authentication-objects.md`
* **Page type:** reference

## What this page is about

Reference documentation for creating Authentication Objects via the POST /api/authentication objects/ endpoint. It defines supported providers, request fields, provider-specific credential schemas, permissions, and validation/error responses.

## User intent

* Create a new Authentication Object through the API
* Find which provider values are supported
* Determine which credential fields are required for a given provider
* Understand optional expiry fields and their validation rules
* Troubleshoot 400/403 errors when submitting authentication object payloads
* Check field length, nullability, uniqueness, date, enum, and URL validation constraints
* Understand provider activation/enablement and object limit errors

## Key terms

* Authentication Objects
* POST /api/authentication objects/
* provider
* credentials
* expiry at
* expiry applies to
* permissions
* IManage
* DocuSign
* Autologyx
* api key
* Microsoft Client Credentials
* Box Client Credentials
* Adobe Client Credentials
* Salesforce Client Credentials
* oauth client credentials
* ROPC Generic oAuth
* token url
* refresh url
* additional parameters
* additional authorization headers

## Terminology links

* [authentication objects](/api/terminology/#authentication-objects)
* [POST /api/authentication objects/](/api/terminology/#post-apiauthentication-objects)
* [provider](/api/terminology/#provider)
* [credentials](/api/terminology/#credentials)
* [expiry at](/api/terminology/#expiry-at)
* [expiry applies to](/api/terminology/#expiry-applies-to)
* [permissions](/api/terminology/#permissions)
* [iManage integration type](/api/terminology/#imanage-integration-type) (matched from `IManage`)

## Related topics

* Single Sign On Configuration

## Prerequisites

* Ability to call the API endpoint with headers and request body
* Required permission to create authentication objects
* Knowledge of the target provider and its credential values
* Understanding of JSON objects, URLs, enums, and date formatting

## Not covered

* Authentication Object retrieval, update, delete, or listing operations
* Detailed successful response schema beyond noting a successful status/response body
* How to obtain provider credentials such as client IDs, secrets, RSA keys, or scopes
* Business meaning of every provider-specific enum value
* Single sign-on setup steps themselves

---

---
url: >-
  /knowledgebase-agent-guides/administration/authentication-objects/index.agent.md
---
# Agent guide: Authentication Objects

* **Page path:** `administration/authentication-objects/index.md`
* **Page type:** explanation

## What this page is about

This page is a navigation overview for Authentication Objects. It points readers to sections on listing, configuring, using, and understanding the effects of editing authentication objects.

## User intent

* Find where to view a list of authentication objects
* Learn how to use an authentication object in an API call
* Understand what happens if an authentication object is edited
* Learn what an authentication object is and how to configure it

## Key terms

* Authentication Objects
* Authentication Objects List
* Using An Authentication Object In An Api Call
* What Happens If I Edit An Authentication Object
* What Is An Authentication Object And How Do I Configure It

## Terminology links

* [Authentication Objects](/knowledgebase/terminology/#authentication-objects)
* [Authentication objects list](/knowledgebase/terminology/#authentication-objects-list)
* [Using An Authentication Object In An Api Call](/knowledgebase/terminology/#using-an-authentication-object-in-an-api-call)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with authentication concepts
* Basic understanding of API calls

## Not covered

* Detailed procedures for listing authentication objects
* Step-by-step API call examples
* Specific edit behaviors or impacts
* Full configuration instructions

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.5/authentication-objects---api-keys/index.agent.md
---
# Agent guide: Authentication Objects - API Keys

* **Page path:** `release-notes/release-notes-1.5/authentication-objects---api-keys/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces Authentication/Authorization Object API Keys in Autologyx Catalyst for securely generating, storing, and managing API keys used to access APIs. It highlights supported authentication methods, secure storage in Vault, and the ability to edit keys and related settings.

## User intent

* Understand what the new API Keys authentication object does
* Learn how API keys are generated and managed in Autologyx Catalyst
* See which authentication methods are supported for API keys
* Find out how API keys are stored and secured
* Understand whether API key settings can be edited after creation

## Key terms

* Authentication Objects API Keys
* Authorization Object API Key
* API keys
* Send in header
* Send in query string
* Vault
* authentication sequences
* key name
* description

## Terminology links

* [Authorization Objects API Keys](/knowledgebase/terminology/#authorization-objects-api-keys) (matched from `Authentication Objects API Keys`)
* [Authentication Object API Keys](/knowledgebase/terminology/#authentication-object-api-keys) (matched from `Authorization Object API Key`)
* [Send in header](/knowledgebase/terminology/#send-in-header)
* [Send in query string](/knowledgebase/terminology/#send-in-query-string)
* [Vault](/knowledgebase/terminology/#vault)
* [authentication sequences](/knowledgebase/terminology/#authentication-sequences)
* [Description](/knowledgebase/terminology/#description)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of APIs and API keys
* Familiarity with authentication/access control concepts
* Some awareness of Autologyx Catalyst authentication objects

## Not covered

* Detailed step-by-step UI instructions
* Exact additional fields for each authentication method
* How to use the generated API key in specific external APIs
* Key rotation, revocation, or lifecycle policies
* Broader authentication object types beyond API Keys

---

---
url: >-
  /knowledgebase-agent-guides/administration/authentication-objects/authentication-objects-list/index.agent.md
---
# Agent guide: Authentication objects list

* **Page path:** `administration/authentication-objects/authentication-objects-list/index.md`
* **Page type:** explanation

## What this page is about

Explains the specific columns and action menu behavior for the Authentication objects list in Autologyx, including permissions and when delete is available.

## User intent

* Understand which columns are shown by default and which additional columns can be displayed
* Interpret metadata such as created/edited dates, expiry date, and usage count
* Know what actions are available from the list for authentication objects
* Determine when an authentication object can be deleted
* Understand how permissions affect visibility of Edit and Delete actions

## Key terms

* Authentication objects list
* Default columns
* Available columns
* ID
* Name
* Provider
* Description
* Actions
* Created
* Created By
* Expiry date
* Last Edited
* Last Edited By
* Usage
* API Actors
* Super Admin
* Role permissions
* Administration tab
* Edit
* Delete

## Terminology links

* [Authentication objects list](/knowledgebase/terminology/#authentication-objects-list)
* [Identifier](/knowledgebase/terminology/#identifier) (matched from `ID`)
* [providers](/knowledgebase/terminology/#providers) (matched from `Provider`)
* [Description](/knowledgebase/terminology/#description)
* [Actions menu](/knowledgebase/terminology/#actions-menu) (matched from `Actions`)
* [Created status](/knowledgebase/terminology/#created-status) (matched from `Created`)
* [Created by](/knowledgebase/terminology/#created-by)
* [Expiry Date feature](/knowledgebase/terminology/#expiry-date-feature) (matched from `Expiry date`)

## Related topics

* What is an Authentication object and how do I configure it?
* What happens if I edit an Authentication object?
* Using an Authentication object in an API call

## Prerequisites

* Basic familiarity with Autologyx administration
* Understanding of authentication objects and API Actors
* Relevant permissions under the Administration tab or Super Admin access

## Not covered

* Step-by-step creation of authentication objects
* Detailed editing procedure beyond noting that details can be updated
* How authentication objects are used in API calls
* Full permission setup instructions
* General list features shared by all Autologyx lists

---

---
url: /knowledgebase-agent-guides/release-notes/release-notes-1.16/index.agent.md
---
# Agent guide: Autologyx Catalyst 1.16 release notes

* **Page path:** `release-notes/release-notes-1.16/index.md`
* **Page type:** release-notes

## What this page is about

These are the Catalyst 1.16 release notes for May 2026. The page summarizes new features and improvements around Service Accounts, user IP restrictions, configurable task labels, Sequencer and API/loop behaviour, formatting/help updates, browser compatibility, and platform maintenance.

## User intent

* Understand what changed in Catalyst 1.16
* Learn how Service Accounts work and when to use them for integrations or automation
* Find out how IP restrictions for users behave and what risks to consider
* See what task action label text can now be customized
* Review Sequencer improvements for Send Message, Loop, API Call, triggers, and templates
* Understand new troubleshooting details in API Call notification emails
* Check usability, formatting, Safari compatibility, and version visibility improvements
* Identify recommended actions before using 1.16 features in live processes

## Key terms

* Catalyst 1.16
* Service Accounts
* Service Internal
* Service External
* user administration
* username and password authentication
* SSO
* IP restrictions
* allowed IP ranges
* Super Admin
* Theme Text Overrides
* Task buttons
* Actionable tasks label
* View only tasks label
* Send Message actor
* Loop actor
* loop item
* loop counter
* API Call actor
* API Call notification emails
* Force Download
* Sequence Designer
* Task Template
* Task Group Template
* Instruction text formatting
* Knowledgebase help panel
* custom components
* Safari
* Admin Portal
* frontend application version

## Terminology links

* [Service Accounts](/knowledgebase/terminology/#service-accounts)
* [Internal Service account](/knowledgebase/terminology/#internal-service-account) (matched from `Service Internal`)
* [External Service account](/knowledgebase/terminology/#external-service-account) (matched from `Service External`)
* [Single sign on](/knowledgebase/terminology/#single-sign-on) (matched from `SSO`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super Admin`)
* [Send Message Actors](/knowledgebase/terminology/#send-message-actors) (matched from `Send Message actor`)
* [Loop actors](/knowledgebase/terminology/#loop-actors) (matched from `Loop actor`)
* [Loop Item](/knowledgebase/terminology/#loop-item)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst administration and configuration
* Understanding of users, account types, and authentication policies
* Working knowledge of sequences and actors such as Send Message, Loop, and API Call
* Awareness of task configuration, themes, and templates

## Not covered

* Step by step procedures for configuring each feature
* Detailed API or integration implementation guidance
* Full security or maintenance update details
* Broader product overview beyond 1.16 changes
* Support policies or escalation processes

---

---
url: >-
  /knowledgebase-agent-guides/applied-ai/mcp-services/mcp-customer-success/index.agent.md
---
# Agent guide: Autologyx MCP Customer Success

* **Page path:** `applied-ai/mcp-services/mcp-customer-success/index.md`
* **Page type:** reference

## What this page is about

This page describes Autologyx MCP Customer Success, an MCP service that gives approved AI assistants access to Autologyx-specific knowledge for analysis, design, planning, and implementation guidance. It explains what the service is for, how it differs from Autologyx MCP Work, and how to use it effectively for requirements analysis and solution design.

## User intent

* Understand what Autologyx MCP Customer Success does
* Learn how this service differs from Autologyx MCP Work
* Use an MCP-capable assistant to answer Autologyx-specific configuration and design questions
* Analyse client requirements, discovery notes, or process documents through an Autologyx lens
* Generate solution designs, implementation plans, migration plans, and configuration cut lists
* Identify candidate Object Classes, fields, relationships, tasks, Sequences, permissions, integrations, and reporting needs
* Get better prompt patterns for planning configuration changes or new process designs
* Understand governance expectations and review requirements for AI-generated recommendations

## Key terms

* Autologyx MCP Customer Success
* MCP service
* Autologyx knowledge base
* implementation guidance
* configuration patterns
* API documentation
* best practice advice
* analysis
* design
* planning
* requirements analysis
* cut list
* Object Class
* Object Record
* related record
* field
* task
* task template
* Sequence
* document template
* roles
* user groups
* permissions
* governance
* migration
* integrations
* reporting
* Autologyx MCP Work

## Terminology links

* [Autologyx MCP Customer Success](/knowledgebase/terminology/#autologyx-mcp-customer-success)
* [cut list](/knowledgebase/terminology/#cut-list)
* [Object Class](/knowledgebase/terminology/#object-class)
* [Object Record](/knowledgebase/terminology/#object-record)
* [related record](/knowledgebase/terminology/#related-record)
* [task template](/knowledgebase/terminology/#task-template)
* [Sequence](/knowledgebase/terminology/#sequence)
* [document template](/knowledgebase/terminology/#document-template)

## Related topics

* Getting started with MCP
* Autologyx MCP Work

## Prerequisites

* Access to an approved MCP-capable AI assistant or agent
* Ability to connect that assistant to the Autologyx MCP endpoint
* Basic familiarity with Autologyx concepts such as Object Classes, fields, tasks, Sequences, roles, and records is helpful
* Human review by an experienced Autologyx user or implementation team is expected for important outputs

## Not covered

* Detailed step-by-step connection instructions for specific MCP clients
* Live operational interaction with records or tasks; that belongs to Autologyx MCP Work
* Any guarantee that AI-generated recommendations are correct
* Replacement of professional judgement for architecture, security, permissions, migration, contractual scope, or production changes
* Detailed implementation of specific example prompts, which are referenced but not expanded in the page

---

---
url: /knowledgebase-agent-guides/applied-ai/mcp-services/index.agent.md
---
# Agent guide: Autologyx MCP Work

* **Page path:** `applied-ai/mcp-services/index.md`
* **Page type:** reference

## What this page is about

Autologyx MCP Work is a tool collection that lets approved AI assistants and agents perform live operational work in Autologyx, such as working with records, tasks, and document automation. It explains what MCP Work is for, what it is not for, the main record and task capabilities, and the governance, permissions, and audit considerations for safe use.

## User intent

* Understand what Autologyx MCP Work is and when to use it
* Determine whether MCP Work is for operational actions or platform configuration
* See what approved agents can do with records, tasks, and documents
* Learn which teams and users benefit from MCP Work
* Understand co-pilot versus autonomous agent usage patterns
* Review permissions, audit, and human review considerations for agentic workflows
* Identify the available record tool and task tool endpoint capabilities
* Design a safe, narrow-permission MCP Work deployment

## Key terms

* MCP Work
* operational work
* approved agents
* Autologyx
* Object Classes
* Object Records
* record relationships
* Tasks
* Task Templates
* document templates
* document generation
* co pilot pattern
* autonomous pattern
* permissions
* audit logging
* role based access model
* human review
* service accounts

## Terminology links

* [Autologyx MCP Work](/knowledgebase/terminology/#autologyx-mcp-work) (matched from `MCP Work`)
* [live operational work](/knowledgebase/terminology/#live-operational-work) (matched from `operational work`)
* [approved agent](/knowledgebase/terminology/#approved-agent) (matched from `approved agents`)
* [Object Classes](/knowledgebase/terminology/#object-classes)
* [Object Records](/knowledgebase/terminology/#object-records)
* [record relationships](/knowledgebase/terminology/#record-relationships)
* [Task](/knowledgebase/terminology/#task) (matched from `Tasks`)
* [Task Templates](/knowledgebase/terminology/#task-templates)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Autologyx as a live operational system
* Familiarity with records, tasks, documents, and Object Classes in Autologyx
* Awareness of permissions, governance, and audit requirements for operational systems

## Not covered

* How to configure or administer Autologyx
* Creating Object Classes, forms, Sequences, Sequence Actors, roles, or permissions
* Changing administration settings or redesigning the data model
* Detailed configuration guidance, which belongs to Autologyx MCP Customer Success
* Implementation details of guardrails or confirmation behavior in the AI assistant client

---

---
url: /knowledgebase-agent-guides/applied-ai/mcp-services/mcp-work/index.agent.md
---
# Agent guide: Autologyx MCP Work

* **Page path:** `applied-ai/mcp-services/mcp-work/index.md`
* **Page type:** reference

## What this page is about

This page explains Autologyx MCP Work, a set of tools that lets approved AI assistants and agents perform live operational work inside Autologyx. It defines what MCP Work is for, who it benefits, the main record and task capabilities it exposes, and the governance, permissions, and audit considerations for using it safely.

## User intent

* Understand what Autologyx MCP Work is and when to use it
* Determine whether MCP Work is for operational activity or product configuration
* Learn which kinds of users and teams benefit from MCP Work
* See what approved agents can do with records, tasks, and document automation
* Understand co-pilot versus autonomous usage patterns
* Review permissions, audit, and safety considerations before enabling agents
* Understand how record tools and task tools work together in workflows
* Identify the kinds of tool actions available for Object Records, Tasks, and documents

## Key terms

* Autologyx MCP Work
* approved agents
* operational work
* Object Records
* Object Classes
* Tasks
* Task Templates
* document automation
* record relationships
* co pilot pattern
* autonomous pattern
* permissions
* audit logging
* role based access model
* live process
* tool catalogue
* record tool endpoints
* task tool endpoints
* human review
* governance

## Terminology links

* [Autologyx MCP Work](/knowledgebase/terminology/#autologyx-mcp-work)
* [approved agent](/knowledgebase/terminology/#approved-agent) (matched from `approved agents`)
* [live operational work](/knowledgebase/terminology/#live-operational-work) (matched from `operational work`)
* [Object Records](/knowledgebase/terminology/#object-records)
* [Object Classes](/knowledgebase/terminology/#object-classes)
* [Task](/knowledgebase/terminology/#task) (matched from `Tasks`)
* [Task Templates](/knowledgebase/terminology/#task-templates)
* [document automation](/knowledgebase/terminology/#document-automation)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Autologyx as a platform for live operational processes
* Familiarity with records, tasks, document templates, and permissions in Autologyx
* For advanced use: understanding of agent design, workflow controls, and risk management

## Not covered

* Detailed getting-started instructions for using agents with Autologyx
* Product configuration activities such as creating Object Classes, designing forms, building Sequences, configuring permissions, or changing administration settings
* Implementation details for agent guardrails or confirmation behavior outside MCP Work tools
* Full technical endpoint specifications beyond the summarized tool descriptions on this page

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/working-with-document-templates/automatic-generation-of-documents-via-the-sequencer/index.agent.md
---
# Agent guide: Automatic generation of documents via the Sequencer

* **Page path:** `system-configuration/working-with-document-templates/automatic-generation-of-documents-via-the-sequencer/index.md`
* **Page type:** explanation

## What this page is about

This page explains how to automatically generate documents from a document template within a workflow sequence using the Sequencer. It covers how to generate the document, optionally email it, and store it on the object record for later use in APIs or tasks.

## User intent

* Set up automatic document generation in a sequence workflow
* Understand which actors are needed for document generation
* Configure DocAuto to use a document template
* Use Document Picker to access the generated document
* Store a generated document on a record field with Update Record
* Attach a generated document to an outgoing email
* Make a generated document available for API use or in a task

## Key terms

* Sequencer
* sequence
* document template
* object class
* DocAuto actor
* Document Picker
* Update Record actor
* Document type field
* Send Message actor
* trigger conditions
* Field from Document Picker
* DocAuto Actor
* Document Field
* Add
* Replace
* task template
* API call
* base64

## Terminology links

* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Document Templates](/knowledgebase/terminology/#document-templates) (matched from `document template`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [DocAuto actor](/knowledgebase/terminology/#docauto-actor)
* [Document Picker actor](/knowledgebase/terminology/#document-picker-actor) (matched from `Document Picker`)
* [Update Record actor](/knowledgebase/terminology/#update-record-actor)
* [document type fields](/knowledgebase/terminology/#document-type-fields) (matched from `Document type field`)
* [Send Message Actors](/knowledgebase/terminology/#send-message-actors) (matched from `Send Message actor`)

## Related topics

* Not provided.

## Prerequisites

* A document template already created for the relevant object class
* Access to Sequencer workflow creation
* Super admin account type or a role with permission to create sequences
* If storing the generated file, a suitably named Document type field on the same object class as the template

## Not covered

* How to create a document template
* General sequence-building concepts beyond the document-generation flow
* Detailed API setup beyond noting that documents are sent from a record field in base64 format
* Detailed task template configuration beyond sequencing requirements

---

---
url: >-
  /knowledgebase-agent-guides/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.agent.md
---
# Agent guide: Available MCP Work tools

* **Page path:** `applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`
* **Page type:** reference

## What this page is about

Reference for Autologyx MCP Work tools that approved AI assistants can use to interact with live operational work, especially records, relationships, and document automation. It explains common usage concepts, permissions, and the purpose/inputs/constraints of each available tool, while explicitly excluding configuration and administration capabilities.

## User intent

* Understand which MCP Work tools exist and what each tool does
* Find which tools to use for searching, reading, creating, updating, or relating Object Records
* Learn required and optional inputs for record and document tools
* Understand how to handle asynchronous operations such as hierarchy creation and document generation
* Check permission, safety, and review considerations for write/action tools
* Learn field alias, filter, pagination, and Object Class/Object Record ID conventions

## Key terms

* MCP Work
* Autologyx
* Object Class
* Object Record
* Object Class ID
* Object Record ID
* field aliases
* field slug
* filters
* lookup suffixes
* pagination
* ordering
* write actions
* role based access
* Document Template
* document generation
* document UUID
* transaction ID
* asynchronous operation
* record hierarchy

## Terminology links

* [Autologyx MCP Work](/knowledgebase/terminology/#autologyx-mcp-work) (matched from `MCP Work`)
* [Object Classes](/knowledgebase/terminology/#object-classes) (matched from `Object Class`)
* [Object Records](/knowledgebase/terminology/#object-records) (matched from `Object Record`)
* [Object Class ID](/knowledgebase/terminology/#object-class-id)
* [Object Record ID](/knowledgebase/terminology/#object-record-id)
* [field aliases](/knowledgebase/terminology/#field-aliases)
* [field slug](/knowledgebase/terminology/#field-slug)
* [lookup suffixes](/knowledgebase/terminology/#lookup-suffixes)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Object Classes and Object Records
* Access to approved MCP Work tools and appropriate permissions
* Understanding of role-based access and safe handling of write actions
* Knowing or discovering relevant Object Class IDs, Object Record IDs, field aliases, and template IDs

## Not covered

* Autologyx configuration tools
* Creating Object Classes
* Building forms
* Configuring Sequences
* Managing roles
* Changing administration settings
* General configuration/administration outside normal Autologyx configuration experience
* Detailed response schemas, which may vary by environment, permissions, configuration, and product version

---

---
url: >-
  /knowledgebase-agent-guides/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.agent.md
---
# Agent guide: AWS Bedrock

* **Page path:** `applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`
* **Page type:** reference

## What this page is about

Explains how AWS Bedrock is used in Autologyx Sequencer workflows to call foundation models through AWS, and what the Bedrock actor does. It also outlines when to use Bedrock, required AWS preparation, common actor settings, and workflow design considerations such as testing and structured outputs.

## User intent

* Understand when to use AWS Bedrock instead of a direct provider integration
* Configure or plan use of the Bedrock actor in an Autologyx Sequence
* Check prerequisites for using Bedrock with Autologyx
* Understand how Bedrock fits into Sequencer-controlled workflow execution
* Choose a provider/model combination available through AWS Bedrock
* Use Anthropic Claude models via AWS Bedrock in Autologyx
* Prepare an AWS environment and authentication approach for Bedrock use
* Design prompts and outputs so model responses can be validated and used in workflow routing
* Know what to test before using Bedrock in production workflows

## Key terms

* AWS Bedrock
* Bedrock actor
* Sequencer
* Sequence
* foundation models
* AWS region
* model provider
* model availability
* Authentication Object
* Object Record
* merge fields
* system prompt
* structured outputs
* Test Integration
* Anthropic Claude
* Amazon models
* deterministic checks
* human review

## Terminology links

* [Bedrock actor](/knowledgebase/terminology/#bedrock-actor)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Authentication Object](/knowledgebase/terminology/#authentication-object)
* [Object Records](/knowledgebase/terminology/#object-records) (matched from `Object Record`)
* [Merge fields](/knowledgebase/terminology/#merge-fields)
* [Test Integration](/knowledgebase/terminology/#test-integration)
* [human review task](/knowledgebase/terminology/#human-review-task) (matched from `human review`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Autologyx Sequences and the Sequencer
* Permission to edit the relevant Sequence
* An AWS account with Amazon Bedrock access
* Required model/provider enabled in the relevant AWS region
* Authentication details available via an Autologyx Authentication Object

## Not covered

* Detailed AWS account setup or direct configuration of the customer's AWS environment
* Definitive current lists of supported models, regions, model IDs, pricing, or provider-specific access requirements
* Provider-specific inference parameters beyond noting that settings vary by model/provider
* Guarantees of model accuracy, completeness, or deterministic behavior
* Broader Autologyx AI concepts beyond how Bedrock fits into Sequencer workflows

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/integrations/aws-bedrock-integration/index.agent.md
---
# Agent guide: AWS Bedrock integration

* **Page path:** `system-configuration/integrations/aws-bedrock-integration/index.md`
* **Page type:** explanation

## What this page is about

Explains how the AWS Bedrock integration lets Catalyst workflows use multiple AI providers via Amazon Bedrock, and outlines supported model families, common use cases, configurable generation settings, and model-selection guidance.

## User intent

* Understand what the AWS Bedrock integration enables in Catalyst workflows
* See which AI providers/models may be available through Amazon Bedrock
* Identify common workflow use cases for Bedrock-backed models
* Learn which AI generation parameters can be configured
* Choose an appropriate model for a given task
* Understand practical cautions such as model variability and need for human review

## Key terms

* AWS Bedrock integration
* Catalyst workflows
* Amazon Bedrock
* Amazon Nova
* Anthropic Claude
* Meta Llama
* Mistral AI
* temperature
* Top P
* Top K
* maximum length
* stop sequences
* contract analysis
* document summarisation
* legal research
* compliance analysis

## Terminology links

* [AWS Bedrock integration](/knowledgebase/terminology/#aws-bedrock-integration)
* [Catalyst workflows](/knowledgebase/terminology/#catalyst-workflows)
* [temperature](/knowledgebase/terminology/#temperature)
* [Top P](/knowledgebase/terminology/#top-p)
* [Top K](/knowledgebase/terminology/#top-k)
* [Maximum Length](/knowledgebase/terminology/#maximum-length)
* [Stop Sequences](/knowledgebase/terminology/#stop-sequences)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Catalyst workflows
* Familiarity with AI models/providers
* Awareness of AWS Bedrock availability/configuration in your organisation

## Not covered

* Setup or installation steps for the integration
* Detailed AWS Bedrock account or configuration instructions
* Provider-specific model capabilities beyond brief examples
* Prompt design guidance
* Operational governance beyond the note that outputs should be reviewed before use

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.11/aws-bedrock-integration/index.agent.md
---
# Agent guide: AWS: Bedrock integration

* **Page path:** `release-notes/release-notes-1.11/aws-bedrock-integration/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces the AWS Bedrock actor integration, which lets users access multiple AI model families in one actor: Amazon Nova, Anthropic Claude, Meta Llama 3, and Mistral. It also outlines common legal/compliance use cases for each model and the key configuration parameters available for tuning output behavior.

## User intent

* Understand what the AWS Bedrock integration adds in release 1.11
* See which AI model families are available through the Bedrock actor
* Choose an appropriate model for legal, contract, compliance, or document automation tasks
* Learn how to tune model behavior using temperature, Top P, Top K, maximum length, and stop sequences
* Assess how Bedrock helps avoid relying on a single AI provider

## Key terms

* AWS Bedrock actor
* Amazon Nova
* Anthropic Claude
* Meta Llama 3
* Mistral AI
* model configuration
* temperature
* Top P
* Top K
* maximum length
* stop sequences
* legal text analysis
* contract automation
* compliance monitoring
* document categorisation
* risk assessments

## Terminology links

* [AWS Bedrock actor](/knowledgebase/terminology/#aws-bedrock-actor)
* [model configuration](/knowledgebase/terminology/#model-configuration)
* [temperature](/knowledgebase/terminology/#temperature)
* [Top P](/knowledgebase/terminology/#top-p)
* [Top K](/knowledgebase/terminology/#top-k)
* [Maximum Length](/knowledgebase/terminology/#maximum-length)
* [Stop Sequences](/knowledgebase/terminology/#stop-sequences)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of AI model selection for business workflows
* Familiarity with legal, contract, or compliance document automation use cases
* General awareness of model tuning concepts such as temperature and sampling controls

## Not covered

* Step-by-step setup or installation instructions for the AWS Bedrock integration
* Detailed API usage, authentication, or deployment guidance
* Exact model version lists, pricing, quotas, or regional availability
* Benchmark comparisons between the supported model families
* Troubleshooting or operational limitations of the integration

---

---
url: >-
  /knowledgebase-agent-guides/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.agent.md
---
# Agent guide: Azure OpenAI

* **Page path:** `applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`
* **Page type:** reference

## What this page is about

This page explains how to use the Azure OpenAI actor in Autologyx Sequences to call OpenAI models through a customer's Azure OpenAI endpoint. It covers when to use it, required Azure and Autologyx setup, actor configuration, testing, and how to use model responses safely in workflow logic.

## User intent

* Understand when Azure OpenAI should be used instead of the public OpenAI API in Autologyx
* Prepare the required Azure environment and authentication for Azure OpenAI in a Sequence
* Configure the Azure OpenAI actor settings such as endpoint, model type, model, auth object, prompt, context, and temperature
* Test an Azure OpenAI call with record data before enabling it in a live workflow
* Use Azure OpenAI responses in downstream Sequence steps for routing, record updates, tasks, or generated outputs
* Design structured JSON outputs and validation patterns for more deterministic workflow automation
* Understand the limits and risks of model outputs and when human review is recommended

## Key terms

* Azure OpenAI
* Azure OpenAI actor
* Sequencer
* Sequence
* Azure OpenAI endpoint
* Authentication Object
* Object Record
* prompt
* context
* temperature
* Record ID
* Test Azure OpenAI
* merge fields
* Local Variable actor
* JSON outputs
* deterministic processing
* human review
* Azure AI Foundry

## Terminology links

* [Azure OpenAI actor](/knowledgebase/terminology/#azure-openai-actor) (matched from `Azure OpenAI`)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Authentication Object](/knowledgebase/terminology/#authentication-object)
* [Object Records](/knowledgebase/terminology/#object-records) (matched from `Object Record`)
* [Record ID](/knowledgebase/terminology/#record-id)
* [Test Azure OpenAI](/knowledgebase/terminology/#test-azure-openai)
* [Merge fields](/knowledgebase/terminology/#merge-fields)
* [Local Variable actor](/knowledgebase/terminology/#local-variable-actor)

## Related topics

* Not provided.

## Prerequisites

* Azure OpenAI integration enabled in the Autologyx environment
* An Azure subscription with access to Azure OpenAI
* A created Azure OpenAI resource and model deployment
* The Azure OpenAI endpoint details
* Authentication details available via an Authentication Object
* Permission to edit the relevant Sequence
* Basic familiarity with Sequences, actors, records, and merge fields in Autologyx

## Not covered

* Detailed Azure-side provisioning, pricing, quotas, supported regions, and current model availability beyond pointing to Microsoft documentation
* General-purpose support for every model or service available through Azure AI Foundry
* Guidance for privately hosted non-Azure OpenAI models except by referring to other private hosting or generic API integration patterns
* Guarantees of deterministic, complete, or accurate model outputs

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.11/azure-openai-integration/index.agent.md
---
# Agent guide: Azure OpenAI integration

* **Page path:** `release-notes/release-notes-1.11/azure-openai-integration/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces the Azure OpenAI actor in Catalyst and summarizes its supported model types, use cases, and configuration options. It highlights compatibility with Azure OpenAI Service, including standard models and custom deployments.

## User intent

* Understand what the Azure OpenAI integration in Catalyst provides
* See which chat, instruct, and embedding models are supported
* Determine which business use cases fit each model type
* Learn what fields are needed to configure the Azure OpenAI actor
* Check whether custom Azure OpenAI deployments can be used
* Confirm availability conditions for the feature

## Key terms

* Azure OpenAI actor
* Catalyst
* Azure OpenAI Service
* Chat models
* Instruct models
* Embedding models
* GPT-4o
* GPT-4o mini
* GPT-4
* GPT-3.5 Turbo
* o1
* o1 mini
* GPT-3.5 Turbo Instruct
* text-embedding-3-large
* text-embedding-3-small
* text-embedding-ada-002
* endpoint
* model type
* specific model
* custom deployment
* authentication
* prompt
* context
* temperature
* encoding format
* vector dimensions
* user parameter

## Terminology links

* [Azure OpenAI actor](/knowledgebase/terminology/#azure-openai-actor)
* [Catalyst](/knowledgebase/terminology/#catalyst)
* [endpoint field](/knowledgebase/terminology/#endpoint-field) (matched from `endpoint`)
* [model type](/knowledgebase/terminology/#model-type)
* [Authentication](/knowledgebase/terminology/#authentication)
* [temperature](/knowledgebase/terminology/#temperature)
* [encoding format](/knowledgebase/terminology/#encoding-format)
* [vector dimensions](/knowledgebase/terminology/#vector-dimensions)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst
* Basic understanding of Azure OpenAI Service
* Awareness of model categories such as chat, instruct, and embeddings
* Access to the feature being enabled for the customer organization

## Not covered

* Step-by-step setup instructions beyond a high-level configuration summary
* Detailed authentication object setup
* Pricing, quotas, or licensing details
* Examples of requests, responses, or workflows
* Operational limits, performance characteristics, or error handling
* How to enable the feature for customers

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/integrations/azure-openai-integration/index.agent.md
---
# Agent guide: Azure OpenAI integration

* **Page path:** `system-configuration/integrations/azure-openai-integration/index.md`
* **Page type:** explanation

## What this page is about

This page explains the Azure OpenAI integration in Catalyst, which lets organisations use Azure-hosted OpenAI models directly in workflows using their own Azure OpenAI Service deployments. It outlines supported model types, configuration options, common use cases, and key considerations.

## User intent

* Understand what the Azure OpenAI integration does in Catalyst
* Check which Azure OpenAI model categories and example models are supported
* Learn what configuration options are available for the Azure OpenAI actor
* Identify common enterprise use cases for Azure OpenAI in workflows
* Understand important limitations and deployment-dependent considerations

## Key terms

* Azure OpenAI integration
* Catalyst workflows
* Azure OpenAI Service deployments
* Azure OpenAI actor
* chat models
* instruct models
* embedding models
* GPT 4o
* GPT 4o mini
* GPT 4
* GPT 3.5 Turbo
* GPT 3.5 Turbo Instruct
* text embedding 3 large
* text embedding 3 small
* endpoint
* model type
* model selection
* custom deployments
* authentication
* objects
* prompts
* context
* temperature
* encoding format
* vector dimensions

## Terminology links

* [Azure OpenAI actor](/knowledgebase/terminology/#azure-openai-actor) (matched from `Azure OpenAI integration`)
* [Catalyst workflows](/knowledgebase/terminology/#catalyst-workflows)
* [endpoint field](/knowledgebase/terminology/#endpoint-field) (matched from `endpoint`)
* [model type](/knowledgebase/terminology/#model-type)
* [model selection](/knowledgebase/terminology/#model-selection)
* [Authentication](/knowledgebase/terminology/#authentication)
* [Objects](/knowledgebase/terminology/#objects)
* [temperature](/knowledgebase/terminology/#temperature)

## Related topics

* Not provided.

## Prerequisites

* Access to Azure OpenAI Service
* An existing Azure deployment for the models you want to use
* Basic familiarity with Catalyst workflows

## Not covered

* Step-by-step setup or installation instructions
* Detailed authentication procedures
* Full compatibility matrix for all Azure OpenAI models
* Pricing, licensing, or Azure provisioning details
* Prompt design guidance or workflow implementation examples

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.10/bug-fixes-and-improvements/index.agent.md
---
# Agent guide: Bug fixes and improvements

* **Page path:** `release-notes/release-notes-1.10/bug-fixes-and-improvements/index.md`
* **Page type:** release-notes

## What this page is about

This release-notes page summarizes 100+ bug fixes and platform improvements in version 1.10. It highlights upgrades across error handling, database performance, APIs, Sequencer behavior, and UI reliability.

## User intent

* Understand what bug fixes and improvements are included in release 1.10
* See what changed in platform error visibility and debugging
* Learn about new API capabilities and authentication features
* Review Sequencer reliability and usability improvements
* Check UI stability fixes that may affect daily workflows
* Identify backend infrastructure improvements such as the PostgreSQL upgrade

## Key terms

* Enhanced Error Visibility
* Show details
* App version
* error location URL
* error code
* backend message
* PostgreSQL RDS
* version 16
* Personal Authentication Object API
* authentication tokens
* GET endpoint
* document generation errors
* sorting enhancement
* Listing parent records
* User Groups API search
* Sequencer
* trigger conditions
* Edit Mode
* Local Variable Actor
* Authentication Objects
* Update Record actor
* Document type field
* summary panel
* filters
* side panels

## Terminology links

* [Personal Authentication Object API](/knowledgebase/terminology/#personal-authentication-object-api)
* [authentication token](/knowledgebase/terminology/#authentication-token) (matched from `authentication tokens`)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Sequence commencement conditions](/knowledgebase/terminology/#sequence-commencement-conditions) (matched from `trigger conditions`)
* [Edit mode](/knowledgebase/terminology/#edit-mode)
* [Local Variable Actor](/knowledgebase/terminology/#local-variable-actor)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects)
* [Update Record actor](/knowledgebase/terminology/#update-record-actor)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the platform
* Awareness of APIs and GET endpoints
* Some knowledge of Sequencer concepts and actors
* General understanding of records, user groups, and UI filtering

## Not covered

* Step-by-step implementation guidance for the new API features
* Exact endpoint names or full request/response examples
* Migration instructions for PostgreSQL or infrastructure changes
* Detailed troubleshooting procedures beyond the new error visibility summary
* Complete release notes for features outside bug fixes and improvements

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.11/bug-fixes-and-improvements/index.agent.md
---
# Agent guide: Bug fixes and improvements

* **Page path:** `release-notes/release-notes-1.11/bug-fixes-and-improvements/index.md`
* **Page type:** release-notes

## What this page is about

This release note highlights version 1.11 improvements focused on performance, security, and reduced manual configuration effort. It introduces Constants for managing environment-specific values across migrations and summarizes additional platform hardening and optimization work.

## User intent

* Understand what was improved in release 1.11
* Learn what Constants are and why they were added
* See how to create a constant in the Resource Database
* Understand naming rules and validation constraints for constants
* Learn how constants behave during environment migration
* Find where constants can be referenced in the Sequence Designer
* Review the release’s security and performance improvements

## Key terms

* Constants
* Resource Database
* Sequence Designer
* Sequencer
* API Call Actor
* environment-specific values
* configuration migrations
* migration behavior
* naming rules
* URL
* Parameters
* security improvements
* performance optimisations
* user and group management

## Terminology links

* [Constants](/knowledgebase/terminology/#constants)
* [Resource Database](/knowledgebase/terminology/#resource-database)
* [Sequence designers](/knowledgebase/terminology/#sequence-designers) (matched from `Sequence Designer`)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [configuration migrations](/knowledgebase/terminology/#configuration-migrations)
* [URL](/knowledgebase/terminology/#url)
* [Element parameters](/knowledgebase/terminology/#element-parameters) (matched from `Parameters`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with environments such as development and production
* Basic understanding of sequences and API Calls
* Awareness of the Resource Database and Sequence Designer

## Not covered

* Detailed step-by-step UI navigation for creating or editing constants
* Support for constant data types beyond the currently supported enum value mentioned on the page
* Use of constants outside the listed API Call Actor fields
* Detailed migration configuration or conflict-resolution options beyond the stated behavior
* Technical details of the security vulnerabilities fixed
* Benchmarks or quantitative results for the performance improvements

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.13/bug-fixes-and-improvements/index.agent.md
---
# Agent guide: Bug fixes and improvements

* **Page path:** `release-notes/release-notes-1.13/bug-fixes-and-improvements/index.md`
* **Page type:** release-notes

## What this page is about

This release-notes page summarizes bug fixes and platform improvements in Catalyst 1.13, with emphasis on security hardening, Sequencer usability, testing enhancements, visibility restrictions, and better error handling. It highlights practical changes that improve reliability, protection, and workflow configuration.

## User intent

* Understand what bug fixes and improvements were introduced in release 1.13
* See security-related changes such as Trivy issue cleanup and antivirus scanning for uploads
* Learn where constants can now be used inside the Sequencer
* Confirm changes to access for External users viewing the Activity Log
* Find out that Field IDs are now visible in the Class fields list
* Check that the Document Picker no longer limits output to five files
* Understand new testing capabilities for Local Variables and file-based API Calls
* Learn how invalid or deleted resources are now surfaced in Sequences

## Key terms

* Catalyst platform
* Trivy
* vulnerability scanner
* antivirus scanning
* uploads
* Sequencer
* constants
* context menus
* API Call
* Local Variable
* Send Message
* OpenAI GPT
* OpenAI Embeddings
* Activity Log
* External users
* Field ID
* Class fields list
* Document Picker actor
* document limits
* Local Variables testing
* API Calls testing
* document field sample upload
* Sequences
* invalid resources
* warning icon
* broken fields
* Invalid Actors
* Best Practice

## Terminology links

* [Autologyx Catalyst platform](/knowledgebase/terminology/#autologyx-catalyst-platform) (matched from `Catalyst platform`)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Constants](/knowledgebase/terminology/#constants)
* [API Call actor](/knowledgebase/terminology/#api-call-actor) (matched from `API Call`)
* [Local Variable Actor](/knowledgebase/terminology/#local-variable-actor) (matched from `Local Variable`)
* [Send Message Actors](/knowledgebase/terminology/#send-message-actors) (matched from `Send Message`)
* [OpenAI GPT](/knowledgebase/terminology/#openai-gpt)
* [OpenAI: Embeddings](/knowledgebase/terminology/#openai-embeddings) (matched from `OpenAI Embeddings`)

## Related topics

* Invalid Actors
* Best Practice

## Prerequisites

* Basic familiarity with Catalyst
* Understanding of Sequencer actors and workflow configuration
* Awareness of object classes, fields, and document fields
* Basic knowledge of API Calls, Local Variables, and document-based integrations

## Not covered

* Step-by-step setup instructions for any feature
* Detailed remediation list for the Trivy issues that were resolved
* Configuration details for antivirus scanning
* Full documentation for Sequencer constants syntax or management
* Exact platform limits for document fields or third-party services
* Detailed guidance from the referenced Invalid Actors and Best Practice pages
* Any features outside the listed bug fixes and improvements

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.2/bug-fixes-and-improvements/index.agent.md
---
# Agent guide: Bug fixes and improvements

* **Page path:** `release-notes/release-notes-1.2/bug-fixes-and-improvements/index.md`
* **Page type:** release-notes

## What this page is about

A high-level release-notes summary of bug fixes and platform improvements in Autologyx 1.2. It highlights performance work, form builder enhancements, data integrity and security improvements, and a few new sequence-triggering features.

## User intent

* Understand what was improved in this release
* Check whether performance and bug fixes were included
* See what changed in the form builder
* Learn about data integrity and security improvements
* Identify newly added sequence trigger capabilities

## Key terms

* bug fixes
* performance improvements
* form builder enhancements
* data integrity
* security
* new features
* Sequence
* trigger by another Sequence
* related Record update

## Terminology links

* [data integrity measures](/knowledgebase/terminology/#data-integrity-measures) (matched from `data integrity`)
* [Authentication Security](/knowledgebase/terminology/#authentication-security) (matched from `security`)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequence`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the Autologyx platform
* General understanding of forms, records, and sequences in Autologyx

## Not covered

* Detailed technical descriptions of each fix or improvement
* Step-by-step instructions for using the new features
* A complete changelog or issue-by-issue bug list
* Configuration details, limitations, or implementation guidance

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.3/bug-fixes-and-improvements/index.agent.md
---
# Agent guide: Bug fixes and improvements

* **Page path:** `release-notes/release-notes-1.3/bug-fixes-and-improvements/index.md`
* **Page type:** release-notes

## What this page is about

This release-notes page summarizes bug fixes and performance/usability improvements in Autologyx 1.3. It highlights resolved issues across permissions, tasks list performance, file downloads, Sequencer behavior, task actor configuration, and record-related UI behavior.

## User intent

* Understand what bugs were fixed in this release
* Check whether a specific issue has been resolved, such as Object Classes visibility, slow tasks lists, or file download problems
* Review performance and usability improvements included in Autologyx 1.3
* Identify changes affecting permissions, Sequencer triggers, record views, and user preferences

## Key terms

* Object model permissions
* edit object model permission
* Object Classes
* Tasks list performance
* standard users
* file downloads
* U+2014 character
* Sequencer triggers
* predicates
* conditions
* set task actor configuration
* task template names
* user preferences
* role permissions
* Relational modeller
* child record control
* Create/Edit record view
* Records list
* column configuration resets
* Record access panel

## Terminology links

* [edit object model permission](/knowledgebase/terminology/#edit-object-model-permission)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [standard users](/knowledgebase/terminology/#standard-users)
* [File Download](/knowledgebase/terminology/#file-download) (matched from `file downloads`)
* [Sequencer triggers](/knowledgebase/terminology/#sequencer-triggers)
* [predicates and conditions](/knowledgebase/terminology/#predicates-and-conditions) (matched from `predicates`)
* [Filter conditions](/knowledgebase/terminology/#filter-conditions) (matched from `conditions`)
* [set task actor configuration](/knowledgebase/terminology/#set-task-actor-configuration)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the Autologyx platform and its interface
* Awareness of components such as Object Classes, tasks list, Sequencer, records, and permissions

## Not covered

* Detailed implementation or technical root causes of the fixes
* Step-by-step instructions for using the affected features
* Any new features beyond the listed fixes and enhancements
* Version upgrade, installation, or migration guidance

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.8/bug-fixes-and-improvements/index.agent.md
---
# Agent guide: Bug fixes and improvements

* **Page path:** `release-notes/release-notes-1.8/bug-fixes-and-improvements/index.md`
* **Page type:** release-notes

## What this page is about

This release-notes page summarizes bug fixes and product improvements in Catalyst 1.8. It highlights usability, logging, backup, permissions, sequence behavior, and standalone form enhancements.

## User intent

* See what was fixed or improved in this release
* Understand changes to User Groups behavior in Send Message Actors
* Learn how the Document Picker actor Combine option affects sequence file handling
* Check what is now included in API Call test logs
* Review UI changes to API test call history
* Understand the AWS backup improvement using Vault Variables
* Learn about separated list and view permissions in Object classes
* See what new capabilities were added to Standalone forms

## Key terms

* Catalyst
* User Groups usage panel
* Send Message Actors
* Document Picker actor
* Combine option
* sequence connections
* API Call logs
* API Call test log
* API test call history
* AWS backup
* Vault Variables
* Object classes
* list permissions
* view permissions
* Standalone forms
* Elements
* dynamic submit button control

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst)
* [User Groups Usage Panel](/knowledgebase/terminology/#user-groups-usage-panel)
* [Send Message Actors](/knowledgebase/terminology/#send-message-actors)
* [Document Picker actor](/knowledgebase/terminology/#document-picker-actor)
* [Combine option](/knowledgebase/terminology/#combine-option)
* [Sequence Connections](/knowledgebase/terminology/#sequence-connections)
* [API Call logs](/knowledgebase/terminology/#api-call-logs)
* [API Call test log](/knowledgebase/terminology/#api-call-test-log)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst
* Awareness of actors, sequences, and forms in the platform
* Some understanding of Object classes, permissions, and API testing features

## Not covered

* Step-by-step setup or configuration instructions
* Detailed migration guidance for the AWS backup changes
* Complete technical specifications for permission behavior
* Examples or workflows showing the new Standalone form capabilities in practice
* Any features outside the listed release improvements

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.9/bug-fixes-and-improvements/index.agent.md
---
# Agent guide: Bug fixes and improvements

* **Page path:** `release-notes/release-notes-1.9/bug-fixes-and-improvements/index.md`
* **Page type:** release-notes

## What this page is about

This release-notes page summarizes backend and product improvements in Catalyst focused on stability, user experience, performance, and data security. It highlights the Django 4.2 LTS upgrade, bug fixes in the Sequencer and UI, and enhanced backup and monitoring.

## User intent

* Understand what was improved in this Catalyst release
* See the impact of the Django 4.2 LTS upgrade
* Check whether Sequencer and UI bugs were addressed
* Learn about backup and monitoring enhancements
* Assess expected benefits such as security, performance, and stability

## Key terms

* Catalyst
* Django 4.2 LTS
* security patches
* performance improvements
* Sequencer
* UI
* bug fixes
* history database enhanced backup solution
* monitoring
* data integrity
* sequence execution

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [UI](/knowledgebase/terminology/#ui)
* [data integrity measures](/knowledgebase/terminology/#data-integrity-measures) (matched from `data integrity`)
* [sequence execution](/knowledgebase/terminology/#sequence-execution)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst
* General understanding of the Sequencer and UI components
* Awareness that this is a release-notes summary rather than a detailed technical guide

## Not covered

* Detailed technical steps for the Django upgrade
* Specific bug-by-bug change list for Sequencer or UI
* Configuration details for backup or monitoring
* Migration instructions, rollout steps, or upgrade procedures
* Any features outside the stated stability, UX, and security improvements

---

---
url: >-
  /api-agent-guides/catalyst/resources/platform-administration/build-limits/index.agent.md
---
# Agent guide: Build Limits

* **Page path:** `catalyst/resources/platform-administration/build-limits.md`
* **Page type:** reference

## What this page is about

Reference for the Platform Administration API endpoints that retrieve and update system resource limits for a specific build (tenant) using its build domain. It documents authentication, request path parameters, response field types, and possible errors for GET and PATCH /api/builds/{build\_domain}/limits/.

## User intent

* Find the API endpoint to view a build's current system limits
* Update system limits for a specific build
* Understand which limits return count+limit objects versus flat integer values
* Know the required authentication and permissions for build limits endpoints
* Check validation and error responses when updating limits
* Identify the path parameter used to resolve the tenant

## Key terms

* Platform Administration API
* build limits
* build domain
* tenant
* API key
* HTTPS
* GET /api/builds/{build\_domain}/limits/
* PATCH /api/builds/{build\_domain}/limits/
* count
* limit
* flat limit fields
* allowed file extensions
* 401 Unauthorized
* 403 Forbidden
* 404 Not Found
* 400 Bad Request

## Terminology links

* [Tenants](/api/terminology/#tenants) (matched from `tenant`)
* [api key](/api/terminology/#api-key)
* [count](/api/terminology/#count)
* [limit](/api/terminology/#limit)

## Related topics

* Not provided.

## Prerequisites

* Access to a valid Platform Administration API key
* Knowledge of the target build's domain name
* Basic understanding of HTTP headers, path parameters, and JSON API requests

## Not covered

* How to obtain or manage Platform Administration API keys
* Full sample request/response payloads
* Other Platform Administration API endpoints beyond build limits
* Business meaning or operational guidance for choosing specific limit values
* Detailed deployment/build discovery beyond noting the external list of deployed builds

---

---
url: >-
  /knowledgebase-agent-guides/getting-started/building-applications-analysts/index.agent.md
---
# Agent guide: Building Applications Analysts

* **Page path:** `getting-started/building-applications-analysts/index.md`
* **Page type:** getting-started

## What this page is about

This page is a brief starting point for building applications in Analysts. It indicates that it covers common setup items shared across applications and what a typical application contains.

## User intent

* Find a checklist of setup steps common to all system applications
* Understand what goes into a typical Analysts application
* Use this page as a starting point for building applications

## Key terms

* Building Applications
* Analysts
* checklist
* common setup
* typical application
* Autologyx

## Terminology links

* [Building applications](/knowledgebase/terminology/#building-applications)
* [Analysts](/knowledgebase/terminology/#analysts)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the Analysts system and application-building context

## Not covered

* Detailed setup instructions
* Step-by-step application-building guidance
* Specific components of a typical application
* Advanced configuration or troubleshooting

---

---
url: >-
  /api-agent-guides/capacity-and-system-limits/capacity_and_system_limits/index.agent.md
---
# Agent guide: Capacity and System Limits

* **Page path:** `capacity-and-system-limits/capacity_and_system_limits.md`
* **Page type:** explanation

## What this page is about

This page summarizes the standard documented capacity limits for Autologyx and explains how to interpret them in solution design. It also clarifies that some limits may be adjustable on request after technical review.

## User intent

* Check default platform limits for key Autologyx resources
* Plan solution design, data architecture, and scale assumptions
* Size test data for performance and scale testing
* Understand what is supported as standard versus what may be configurable
* Identify when an implementation may need architectural review or a limit increase request

## Key terms

* capacity and system limits
* standard limits
* enterprise scale
* Object Classes
* Object class fields
* Object Records
* owners
* class permission sets
* record permission sets
* Task Group Templates
* Task Templates
* task form fields
* Sequences
* Users
* User Groups
* Roles
* SSO configurations
* Authentication Objects
* standalone forms
* Document Templates
* JSON field maximum characters
* architecture review
* technical review
* performance and scale testing

## Terminology links

* [object classes](/api/terminology/#object-classes)
* [object class fields](/api/terminology/#object-class-fields)
* [Object Records](/api/terminology/#object-records)
* [owners type](/api/terminology/#owners-type) (matched from `owners`)
* [record permission sets](/api/terminology/#record-permission-sets)
* [task group templates](/api/terminology/#task-group-templates)
* [task templates](/api/terminology/#task-templates)
* [Sequences](/api/terminology/#sequences)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx platform concepts such as Object Classes, Object Records, forms, permissions, tasks, users, roles, and document templates
* General understanding of solution design, data modelling, and scale testing

## Not covered

* Detailed architecture guidance for exceeding limits
* Performance guarantees or benchmarking methodology
* How to request and approve specific limit increases in practice
* Design patterns for optimizing around particular limits
* Any limits beyond the documented standard values on this page

---

---
url: /api-agent-guides/catalyst/index.agent.md
---
# Agent guide: Catalyst API

* **Page path:** `catalyst/index.md`
* **Page type:** explanation

## What this page is about

This page is the entry point to the Autologyx Catalyst API documentation. It explains what the API docs cover, who they are for, how to navigate them, and which technical reference areas are available.

## User intent

* Find where to start when integrating with Catalyst services
* Understand the structure and conventions used across Catalyst APIs
* Locate documentation for the Catalyst Platform API, Event History API, or WebSockets
* Learn where to find merge field reference material
* Identify which part of the docs is relevant for real-time, event-driven, reporting, or audit use cases
* Determine whether to use the API docs or the Catalyst Knowledgebase

## Key terms

* Catalyst API
* Catalyst Platform API
* Event History API
* WebSockets
* Monitoring and infrastructure
* API Standards
* Merge Fields
* API conventions
* payload structure
* request and response structures
* real time updates
* event driven interactions
* historical event data

## Terminology links

* [Catalyst API Reference](/api/terminology/#catalyst-api-reference) (matched from `Catalyst API`)
* [Event History API](/api/terminology/#event-history-api)
* [Merge fields](/api/terminology/#merge-fields)
* [real time updates](/api/terminology/#real-time-updates)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with API integration concepts
* Some understanding of platform resources, requests, and responses
* Relevant technical context if working with merge fields, event history, or WebSockets

## Not covered

* Detailed implementation specifics for any individual API service
* Exact request and response schemas
* Current service-specific behavior beyond what is documented in the linked reference pages
* Broader platform guidance and configuration workflows covered by the Catalyst Knowledgebase
* Restricted monitoring and infrastructure API details beyond noting their existence

---

---
url: /knowledgebase-agent-guides/index.agent.md
---
# Agent guide: Catalyst Knowledgebase

* **Page path:** `index.md`
* **Page type:** explanation

## What this page is about

This is the landing page for the Catalyst Knowledgebase, outlining where to find practical help for using, configuring, and administering Autologyx Catalyst. It directs users to starting sections based on their role and explains how links and terminology references work in the knowledgebase.

## User intent

* Find the right documentation section for a specific role or task in Autologyx Catalyst
* Get started as a new Catalyst user
* Locate guidance for day-to-day work in Workspace
* Find configuration or administration documentation
* Understand how navigation links and highlighted terminology work in the knowledgebase

## Key terms

* Catalyst Knowledgebase
* Autologyx Catalyst
* Getting Started
* Workspace
* System Configuration
* Administration
* Using Help and Support
* Autologyx Terminology
* Release Notes
* Record and Task Forms

## Terminology links

* [Catalyst Knowledgebase](/knowledgebase/terminology/#catalyst-knowledgebase)
* [Catalyst](/knowledgebase/terminology/#catalyst) (matched from `Autologyx Catalyst`)
* [Workspace](/knowledgebase/terminology/#workspace)
* [System configuration](/knowledgebase/terminology/#system-configuration)
* [Administration Sections](/knowledgebase/terminology/#administration-sections) (matched from `Administration`)
* [Help and Support](/knowledgebase/terminology/#help-and-support) (matched from `Using Help and Support`)
* [Release Notes](/knowledgebase/terminology/#release-notes)
* [Record and Task Forms](/knowledgebase/terminology/#record-and-task-forms)

## Related topics

* Not provided.

## Prerequisites

* No explicit prerequisites are stated
* Basic awareness of your role in Catalyst (user, configurator, or administrator) is helpful

## Not covered

* Detailed instructions for any specific feature or task
* Definitions beyond directing users to the Terminology section
* Actual configuration, administration, or workspace procedures
* Release details beyond linking to Release Notes

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.3/catalyst-word-add-in/index.agent.md
---
# Agent guide: Catalyst Word Add-in

* **Page path:** `release-notes/release-notes-1.3/catalyst-word-add-in/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces the Catalyst Word Add-in for Autologyx. It explains that the add-in helps users generate documents by inserting merge fields populated from record data, after configuration by a system administrator.

## User intent

* Understand what the Catalyst Word Add-in does
* Learn how document merge fields can be populated from record data
* See what setup is required before users can access the add-in
* Understand how users connect to a data source using a domain and object class
* Know that class fields and built-in functions can be inserted into documents

## Key terms

* Catalyst Word Add-in
* merge fields
* records
* admin managed add ins
* System Administrator
* permissions
* domain
* object class
* class fields
* functions
* document creation

## Terminology links

* [Catalyst Word Add in](/knowledgebase/terminology/#catalyst-word-add-in) (matched from `Catalyst Word Add-in`)
* [merge fields](/knowledgebase/terminology/#merge-fields)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `records`)
* [admin managed add ins](/knowledgebase/terminology/#admin-managed-add-ins)
* [System Administrators](/knowledgebase/terminology/#system-administrators) (matched from `System Administrator`)
* [Class permissions](/knowledgebase/terminology/#class-permissions) (matched from `permissions`)
* [selected domain](/knowledgebase/terminology/#selected-domain) (matched from `domain`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)

## Related topics

* Not provided.

## Prerequisites

* Access to Autologyx records/data
* System Administrator setup of the add-in in admin managed add-ins
* Appropriate user permissions within the organisation
* Basic familiarity with document creation in Word

## Not covered

* Detailed installation or configuration steps
* Specific permission model details
* A full list of available functions
* Technical troubleshooting guidance
* Examples of supported object classes or domains
* Step-by-step instructions for inserting merge fields

---

---
url: >-
  /knowledgebase-agent-guides/getting-started/building-applications-analysts/checklist-of-things-to-set-up-which-are-common-across-all-applications-of-the-system/index.agent.md
---
# Agent guide: Checklist of things to set up which are common across all applications of the system

* **Page path:** `getting-started/building-applications-analysts/checklist-of-things-to-set-up-which-are-common-across-all-applications-of-the-system/index.md`
* **Page type:** getting-started

## What this page is about

This page is a setup checklist for items commonly needed across all applications of the system. It distinguishes between one-time administration setup and foundational components needed for the first process and later expansion.

## User intent

* Identify the common system components that need to be configured before building applications
* Understand which setup items are one-time administrative tasks versus process-specific foundations
* Check what needs to be ready for testing, including outbound mail
* Coordinate with other people involved in setup to ensure all required areas are configured
* See which core areas to prepare for an initial process and future scaling

## Key terms

* Administration
* Company details
* Standard authentication
* Single sign on
* Outbound mail setup
* Data Model
* Object classes
* Fields
* Relational modeller
* parent/child relationships
* Documents
* Template areas
* User Roles and Groups
* Permission set
* User group
* Role
* Sequencer
* Workspace
* Task templates
* Task group templates
* Sequence
* Record
* Complete self contained form
* Update object record

## Terminology links

* [Administration Sections](/knowledgebase/terminology/#administration-sections) (matched from `Administration`)
* [Company details](/knowledgebase/terminology/#company-details)
* [Standard authentication page](/knowledgebase/terminology/#standard-authentication-page) (matched from `Standard authentication`)
* [Single sign on](/knowledgebase/terminology/#single-sign-on)
* [Outbound mail setup](/knowledgebase/terminology/#outbound-mail-setup)
* [Catalyst data model](/knowledgebase/terminology/#catalyst-data-model) (matched from `Data Model`)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `Fields`)

## Related topics

* Not provided.

## Prerequisites

* Access to the relevant areas depends on the user's account type and role
* Basic familiarity with processes, records, tasks, and users in the system is helpful
* Some setup may be owned by different people, so coordination may be required

## Not covered

* Step-by-step instructions for configuring each component
* Detailed guidance on document automation, users and roles, or task management beyond brief references
* Specific procedures for account activation, password rule configuration, or single sign-on provider setup
* Detailed design patterns for data models or relational structures

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/formbuilder-components/child-object-classes/index.agent.md
---
# Agent guide: Child Object Classes

* **Page path:** `record-and-task-forms/formbuilder-components/child-object-classes/index.md`
* **Page type:** explanation

## What this page is about

Explains when the Child Object Class component appears for an object class in Form Builder and how to configure and use it on create/edit forms. It covers selecting direct child classes, configuring displayed columns, and adding or creating related child records from the form.

## User intent

* Understand when the Child Object Class component is available in the form builder
* Determine which child object classes can be selected based on the relational model
* Add a Child Object Class component to a form section
* Configure which record properties and class fields appear in the child component
* Use the child component to search for and attach existing child records
* Create new child records from within a parent record form
* Understand how parent:child ratio and permissions affect adding related records

## Key terms

* Child Object Class component
* Object class
* Parent
* Direct child
* Root parent
* Relational model
* Create and edit view
* Records list
* Record properties
* Class fields
* Identifier
* Related records
* ALX ID
* Parent:child ratio
* 1:1
* N
* Permissions

## Terminology links

* [child object class component](/knowledgebase/terminology/#child-object-class-component)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [parent object class](/knowledgebase/terminology/#parent-object-class) (matched from `Parent`)
* [direct child](/knowledgebase/terminology/#direct-child)
* [root parent object class](/knowledgebase/terminology/#root-parent-object-class) (matched from `Root parent`)
* [relational model](/knowledgebase/terminology/#relational-model)
* [Create and edit view](/knowledgebase/terminology/#create-and-edit-view)
* [Records list](/knowledgebase/terminology/#records-list)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of object classes and the relational model
* Familiarity with the Create and edit view in Form Builder
* Knowledge of form sections and side panel components
* Awareness of record permissions for viewing or creating child records

## Not covered

* How to build or modify the relational model itself
* Detailed permission setup
* General form-building concepts beyond this component
* Behavior for indirect descendants; the page only states direct children are selectable
* Advanced rules or validation beyond parent:child ratio limits

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.2/click-to-call-on-autologyx/index.agent.md
---
# Agent guide: Click-to-Call on Autologyx

* **Page path:** `release-notes/release-notes-1.2/click-to-call-on-autologyx/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces the Click to Call feature in Autologyx. It explains that users can click phone numbers stored on records to initiate calls directly from their browser across supported devices.

## User intent

* Understand what Click to Call does in Autologyx
* Learn how to place a call from a phone number on a record
* Check browser and device support for the feature
* Know what happens when clicking a number, such as opening FaceTime, a phone app, or a confirmation dialog

## Key terms

* Click to Call
* Autologyx record
* phone numbers saved on records
* browser-handled call initiation
* browser and device support
* FaceTime
* phone call app
* confirmation dialog

## Terminology links

* [Click to Call](/knowledgebase/terminology/#click-to-call)
* [Autologyx Record](/knowledgebase/terminology/#autologyx-record)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx records
* Access to a browser on desktop, laptop, or mobile device

## Not covered

* Configuration, setup, or admin enablement steps
* Troubleshooting browser or device-specific calling behavior
* Details on telephony integrations or supported calling apps
* Permissions, security controls, or compliance specifics beyond public classification

---

---
url: >-
  /knowledgebase-agent-guides/finding-your-way-around/ui-and-navigation/column-configuration-on-list-pages/index.agent.md
---
# Agent guide: Column Configuration on List Pages

* **Page path:** `finding-your-way-around/ui-and-navigation/column-configuration-on-list-pages/index.md`
* **Page type:** explanation

## What this page is about

This page explains how to use Column configuration on list pages to choose which columns are shown and arrange their order. It also describes save, cancel, and reset behaviors, plus restrictions on the Actions column.

## User intent

* Customize which columns appear on a list page
* Change the order of columns on a list page
* Add hidden columns back into a table
* Remove visible columns from a list page
* Save or cancel column layout changes
* Reset a list page back to its default column setup
* Understand what can and cannot be changed in column configuration mode

## Key terms

* Column configuration
* list page
* default column setup
* Save changes
* Reset to default
* Cancel
* * insertion icon
* column selection list
* Add columns
* drag and drop
* Actions column
* warning modal
* unsaved changes

## Terminology links

* [Column configuration](/knowledgebase/terminology/#column-configuration)
* [list pages](/knowledgebase/terminology/#list-pages) (matched from `list page`)
* [Save changes](/knowledgebase/terminology/#save-changes)
* [Reset to default](/knowledgebase/terminology/#reset-to-default)
* [Cancel](/knowledgebase/terminology/#cancel)
* [column selection list](/knowledgebase/terminology/#column-selection-list)
* [+ Add columns](/knowledgebase/terminology/#add-columns) (matched from `Add columns`)
* [drag and drop tool](/knowledgebase/terminology/#drag-and-drop-tool) (matched from `drag and drop`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with navigating a list page
* Understanding that list pages display data in table columns

## Not covered

* Configuration beyond the current list page
* Any global or shared column settings across pages
* How list page data itself is created or edited
* Permissions or role-based limits on column configuration
* Details of any specific list page beyond the generic behavior

---

---
url: /knowledgebase-agent-guides/administration/communication/index.agent.md
---
# Agent guide: Communication

* **Page path:** `administration/communication/index.md`
* **Page type:** explanation

## What this page is about

This page is a navigation overview for Communication-related administration topics. It lists links to setup and configuration guides such as company details, outbound mail, single sign-on, user activation rules, and Okta SSO.

## User intent

* Find where to configure company details
* Locate outbound mail setup instructions
* Access Microsoft client credentials setup for outbound mail
* Find how to edit a single sign-on setting
* Find how to configure single sign-on for users
* Locate user activation rules configuration
* Access Okta SSO setup information in Catalyst

## Key terms

* Communication
* Company Details
* Configuring Outbound Mail Setup With Microsoft Client Credentials
* Editing A Single Sign On Setting
* How Do I Configure Single Sign On For Users
* How Do I Configure User Activation Rules
* Okta Sso In Catalyst
* Outbound Mail Setup Autologyx

## Terminology links

* [Communication](/knowledgebase/terminology/#communication)
* [Company details](/knowledgebase/terminology/#company-details)
* [Configuring Outbound mail setup with Microsoft client credentials](/knowledgebase/terminology/#configuring-outbound-mail-setup-with-microsoft-client-credentials)
* [Okta Sso In Catalyst](/knowledgebase/terminology/#okta-sso-in-catalyst)

## Related topics

* Not provided.

## Prerequisites

* General familiarity with administration/configuration tasks

## Not covered

* Detailed procedures for any listed setup task
* Step-by-step configuration instructions
* Conceptual explanation of communication architecture
* Troubleshooting guidance

---

---
url: /api-agent-guides/catalyst/resources/company-details/index.agent.md
---
# Agent guide: Company details

* **Page path:** `catalyst/resources/company-details.md`
* **Page type:** reference

## What this page is about

This page documents the Company Details single-instance endpoint used to store a nominated system administrator or generic contact. It explains how to retrieve and update those details, the required permissions, field constraints, and possible errors.

## User intent

* Find what Company Details are used for in the system
* Retrieve the current company/admin contact details via API
* Update the single Company Details record via API
* Understand which permissions are required to view or edit Company Details
* Check validation rules and max lengths for Company Details fields
* See error responses for invalid input or insufficient permissions

## Key terms

* Company Details
* single instance endpoint
* merge fields
* standard message templates
* admin first name
* admin last name
* admin email address
* admin phone number
* admin job title
* admin email signature
* meta.permissions
* GET /api/administration/company details/
* PATCH /api/administration/company details/
* OPTIONS /api/administration/company details/
* view permission
* edit permission
* 403 Forbidden
* 400 Bad Request

## Terminology links

* [Company details](/api/terminology/#company-details)
* [single instance endpoint](/api/terminology/#single-instance-endpoint)
* [Merge fields](/api/terminology/#merge-fields)
* [standard message templates](/api/terminology/#standard-message-templates)
* [permissions](/api/terminology/#permissions) (matched from `meta.permissions`)
* [GET /api/administration/company details/](/api/terminology/#get-apiadministrationcompany-details)
* [PATCH /api/administration/company details/](/api/terminology/#patch-apiadministrationcompany-details)
* [OPTIONS /api/administration/company details/](/api/terminology/#options-apiadministrationcompany-details)

## Related topics

* Roles

## Prerequisites

* Basic understanding of making API requests
* Awareness of role-based permissions in the system

## Not covered

* How merge fields are referenced or rendered in templates
* How standard message templates are configured
* Any multi-record/company model beyond the single Company Details record
* Authentication setup or header specifics
* Broader security or authorization design beyond listed permissions

---

---
url: >-
  /knowledgebase-agent-guides/administration/communication/company-details/index.agent.md
---
# Agent guide: Company details

* **Page path:** `administration/communication/company-details/index.md`
* **Page type:** explanation

## What this page is about

This page explains the Company details page under Administration, including who can access it and what information it is used for. It describes how entered contact details can be reused as merge fields in standard system message templates.

## User intent

* Find where the Company details page is located
* Check which users or roles can access the Company details page
* Enter details for a nominated user or generic contact
* Understand how Company details are used in merge fields
* Use Company details in standard outgoing message templates
* Confirm whether any Company details fields are mandatory

## Key terms

* Company details
* Administration
* Super admin
* Role
* Edit Permission for Company Details
* Administration tab
* nominated user
* generic contact
* merge fields
* standard message templates
* Task notification
* Admin email signature

## Terminology links

* [Company details](/knowledgebase/terminology/#company-details)
* [Administration Sections](/knowledgebase/terminology/#administration-sections) (matched from `Administration`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Roles](/knowledgebase/terminology/#roles) (matched from `Role`)
* [Edit Permission for Company Details](/knowledgebase/terminology/#edit-permission-for-company-details)
* [Administration tab of System permissions](/knowledgebase/terminology/#administration-tab-of-system-permissions) (matched from `Administration tab`)
* [merge fields](/knowledgebase/terminology/#merge-fields)
* [standard message templates](/knowledgebase/terminology/#standard-message-templates)

## Related topics

* Not provided.

## Prerequisites

* Access to the Administration area
* A Super admin account type or a role with Edit Permission for Company Details enabled on the Administration tab
* Basic understanding of roles, permissions, and message templates

## Not covered

* Step-by-step instructions for editing or saving Company details
* Definitions of all individual fields on the page
* How to configure message templates beyond noting that merge fields can be used
* How roles and permissions are created or managed generally
* Any mandatory validation rules, since the page states none of these fields are mandatory

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/merge-fields/conditional-logic/index.agent.md
---
# Agent guide: Conditional Logic

* **Page path:** `system-configuration/merge-fields/conditional-logic/index.md`
* **Page type:** explanation

## What this page is about

This page briefly explains that conditional logic can be used in Word Add-In document templates or email bodies to show or hide content based on field values. It mentions supported logic patterns such as basic if/else, nested conditions, and operators like in, not in, and/or.

## User intent

* Understand whether conditional logic is supported in document templates and email bodies
* Learn how to show or hide template content based on field values
* See what kinds of conditional statements are available, such as if/else and nested conditions
* Identify supported logical operators like in, not in, and/or
* Find guidance related to configuring the Word Add-In for template building

## Key terms

* Conditional Logic
* Word Add In
* document templates
* Templates tab
* Record
* email body
* field values
* If / Else
* Nested conditions
* in
* not in
* and
* or

## Terminology links

* [conditional logic](/knowledgebase/terminology/#conditional-logic)
* [Catalyst Word Add in](/knowledgebase/terminology/#catalyst-word-add-in) (matched from `Word Add In`)
* [Document Templates](/knowledgebase/terminology/#document-templates)
* [Templates tab](/knowledgebase/terminology/#templates-tab)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `Record`)
* [email body](/knowledgebase/terminology/#email-body)
* [field values](/knowledgebase/terminology/#field-values)
* [If / Else](/knowledgebase/terminology/#if-else)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the Word Add-In
* Understanding of document templates and email bodies
* Awareness of record-based template generation

## Not covered

* Step-by-step configuration instructions for the Word Add-In
* Detailed syntax or examples for conditional statements
* How template generation works in sequence versus manual generation
* Full operator reference or advanced logic behavior
* Troubleshooting or validation guidance

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/merge-fields/configuration-and-use-of-the-image-merge-field/index.agent.md
---
# Agent guide: Configuration and use of the Image Merge Field

* **Page path:** `system-configuration/merge-fields/configuration-and-use-of-the-image-merge-field/index.md`
* **Page type:** explanation

## What this page is about

Explains how to configure and use an Image Merge Field to insert personalised images from object class document fields into generated .docx documents. It also covers sizing and layout controls using merge field filters and text boxes.

## User intent

* Configure an object class to store an image for document generation
* Add an image merge field to a Word .docx template
* Insert customer-specific logos, photos, charts, QR codes, or similar images into generated documents
* Ensure image fields are populated before document generation
* Control merged image width and height in a template
* Improve image placement and avoid layout issues such as page breaks

## Key terms

* Image Merge Field
* object class
* document type field
* Customer
* Customer Logo
* .docx document template
* merge field
* record.field
* embedded
* img width
* img height
* aspect ratio
* text box
* document generation
* sequencer
* manual document generation

## Terminology links

* [Image merge fields](/knowledgebase/terminology/#image-merge-fields) (matched from `Image Merge Field`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [document type fields](/knowledgebase/terminology/#document-type-fields) (matched from `document type field`)
* [merge fields](/knowledgebase/terminology/#merge-fields) (matched from `merge field`)
* [record.field](/knowledgebase/terminology/#recordfield)
* [embedded](/knowledgebase/terminology/#embedded)
* [img width](/knowledgebase/terminology/#img-width)
* [img height](/knowledgebase/terminology/#img-height)

## Related topics

* automatic document generation using the sequencer
* manual document generation from the side panel

## Prerequisites

* Basic understanding of object classes and fields
* Ability to edit Forms tab or create/edit display views
* Ability to edit Word .docx document templates
* Knowledge of the document generation process for the relevant object class

## Not covered

* Detailed syntax reference for all merge field formats beyond the image example shown
* Step-by-step setup of sequencer-based automatic document generation
* Step-by-step instructions for manual document generation from the side panel
* General Word text box formatting guidance beyond removing the border
* Image editing or validation outside the described width/height filters

---

---
url: >-
  /knowledgebase-agent-guides/administration/elements/configuring-an-element-and-how-it-works-on-a-form/index.agent.md
---
# Agent guide: Configuring an Element, and how it works on a form

* **Page path:** `administration/elements/configuring-an-element-and-how-it-works-on-a-form/index.md`
* **Page type:** how-to

## What this page is about

This page explains how to configure a custom Element after it has been imported, where it can be used in the product, and how its configuration values are passed into the Element iframe as message data. It also outlines how the Element receives that data in code and how context differs between landing pages and object class forms.

## User intent

* Understand where custom Elements can be used
* Configure an Element on a landing page, form, or view
* Set Element properties generated from parameter objects
* Set the Element height and verify its size/position
* Understand what message data is passed to an Element iframe
* Know why class id and record id may be undefined on a landing page
* Understand how object record metadata is passed on object class forms
* Implement code to receive message data via an event listener

## Key terms

* Element
* Landing page
* Object class create/edit view display form
* summary view display form
* standalone form
* Element Details
* parameter objects
* parameter name
* parameter description
* parameter type
* message data
* iframe
* endpoint
* class id
* record id
* object record meta
* event listener
* React hook
* access token
* height in pixels

## Terminology links

* [Elements](/knowledgebase/terminology/#elements) (matched from `Element`)
* [Landing page](/knowledgebase/terminology/#landing-page)
* [Object class create/edit view display form](/knowledgebase/terminology/#object-class-createedit-view-display-form)
* [summary view display form](/knowledgebase/terminology/#summary-view-display-form)
* [standalone forms](/knowledgebase/terminology/#standalone-forms) (matched from `standalone form`)
* [Element Details](/knowledgebase/terminology/#element-details)
* [parameter objects](/knowledgebase/terminology/#parameter-objects)
* [parameter\ type](/knowledgebase/terminology/#parameter-type) (matched from `parameter type`)

## Related topics

* Everything you need to create an Element

## Prerequisites

* JavaScript for the Element has been written
* Required files have been created in a Git repository
* The package has been successfully imported
* The Element is already available for use in the system

## Not covered

* How to write the Element JavaScript itself
* Full Git repository/package structure details
* Detailed boilerplate implementation beyond mentioning an event listener/hook
* Advanced layout or styling guidance beyond setting height and checking size/position
* Broader API design or authentication details beyond noting the access token refreshes every 5 minutes

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-class-relationships/configuring-relationships-in-object-classes/index.agent.md
---
# Agent guide: Configuring relationships in Object classes

* **Page path:** `system-configuration/object-class-relationships/configuring-relationships-in-object-classes/index.md`
* **Page type:** how-to

## What this page is about

Explains how to configure parent object class create/edit forms so users can create relational child records after relationships have been defined in the Relational modeller. It covers adding child object classes to the Display tab form layout and choosing which child fields are shown.

## User intent

* Add available child object classes to a parent object class create/edit view
* Enable the interface for creating relational records from a parent form
* Drag and drop child object classes from the CHILD OBJECT CLASSES sidebar section into the form
* Configure which columns/fields are displayed for each child object class
* Understand how multi-level relationships appear in the sidebar during form configuration

## Key terms

* Relational modeller
* parent object class
* child object class
* create/edit view
* Display tab
* CHILD OBJECT CLASSES
* relational records
* Record properties
* Class fields
* display fields
* multi level relationships

## Terminology links

* [Relational modeller](/knowledgebase/terminology/#relational-modeller)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `parent object class`)
* [create/edit view](/knowledgebase/terminology/#createedit-view)
* [Display tab](/knowledgebase/terminology/#display-tab)
* [Child Object Classes](/knowledgebase/terminology/#child-object-classes)
* [relational records](/knowledgebase/terminology/#relational-records)
* [Object Record properties](/knowledgebase/terminology/#object-record-properties) (matched from `Record properties`)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `Class fields`)

## Related topics

* Not provided.

## Prerequisites

* Relationships between object classes have already been created in the Relational modeller
* Basic familiarity with editing an object class create/edit view and form layout

## Not covered

* How to create the relationships themselves in the Relational modeller
* Anything beyond configuring direct child object classes on the parent form
* Detailed behavior of records list column configuration beyond noting the same add-field panel is used
* General object class design outside the Display tab form setup

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/merge-fields/controlling-whitespace-in-jinja-and-why-it-matters/index.agent.md
---
# Agent guide: Controlling Whitespace in Jinja (and Why It Matters)

* **Page path:** `system-configuration/merge-fields/controlling-whitespace-in-jinja-and-why-it-matters/index.md`
* **Page type:** explanation

## What this page is about

Explains that Jinja preserves whitespace by default and why that can break or visibly affect generated output in Autologyx. It shows using Jinja whitespace control with hyphens on block tags to remove unwanted spaces and line breaks when exact formatting matters.

## User intent

* Understand why Jinja output may contain unexpected spaces or line breaks
* Prevent invalid output for exact-value fields such as Booleans
* Avoid formatting/validation issues in JSON or API payloads caused by extra whitespace
* Use Jinja whitespace control modifiers to trim whitespace around control blocks
* Reduce unintended blank lines or blank pages in document generation, especially around loops

## Key terms

* Jinja2
* templating engine
* whitespace
* whitespace control
* hyphen modifier
* block tags
* Boolean output
* JSON generation
* API request bodies
* document automation
* for loops
* blank lines
* page breaks

## Terminology links

* [Jinja2](/knowledgebase/terminology/#jinja2)
* [whitespace control](/knowledgebase/terminology/#whitespace-control)
* [Document Automation](/knowledgebase/terminology/#document-automation)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Jinja templates and control structures
* Awareness of generating dynamic content in Autologyx

## Not covered

* General Jinja syntax beyond whitespace handling
* Detailed examples of all whitespace control combinations
* Configuration-level whitespace settings
* Broader document layout or pagination techniques outside Jinja whitespace control

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/working-with-document-templates/create-a-document-template/index.agent.md
---
# Agent guide: Create a Document Template

* **Page path:** `system-configuration/working-with-document-templates/create-a-document-template/index.md`
* **Page type:** how-to

## What this page is about

Explains how to create a document template for a specific object class, including required permissions, required fields, upload behavior, and save outcomes. It also notes how templates can later use merge fields and points to separate guidance for setting those up.

## User intent

* Find out who is allowed to create or edit a document template
* Create a new document template for an object class
* Understand which fields are required on the create page
* Upload a Word document as a template
* Make a template available for manual generation from a record
* Understand what happens after saving or when template names are not unique
* Learn basic limits and file format requirements for document templates
* Find where to go next to add merge fields

## Key terms

* Document Template
* Object class
* System configuration
* Document templates tab
* Template file name
* Description
* Upload template file
* Manual generation
* Templates tab
* Merge fields
* Related object classes
* Word Add in
* .docx format
* Permission set
* Role with permission to edit object classes
* Super Admin

## Terminology links

* [Document Templates](/knowledgebase/terminology/#document-templates) (matched from `Document Template`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [System configuration](/knowledgebase/terminology/#system-configuration)
* [Document templates list](/knowledgebase/terminology/#document-templates-list) (matched from `Document templates tab`)
* [Template File Name](/knowledgebase/terminology/#template-file-name)
* [Description](/knowledgebase/terminology/#description)
* [manual generation](/knowledgebase/terminology/#manual-generation)
* [Templates tab](/knowledgebase/terminology/#templates-tab)

## Related topics

* Manual generation of a document from a template
* MS Word add in article
* article which explains the correct syntax for merging field data into your document template

## Prerequisites

* One of the required permissions: Super Admin, a role with permission to edit object classes, or membership in a permission set allowing edit access to a specific object class
* An existing object class to attach the template to
* A saved Word document in .docx format if uploading a template file

## Not covered

* Detailed steps for editing an existing document template
* How manual generation works in practice beyond linking to another article
* How to configure the Catalyst Word Add in
* Detailed merge field syntax or insertion instructions
* Sequence-based document generation setup

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/create-a-standalone-form/index.agent.md
---
# Agent guide: Create a Standalone Form

* **Page path:** `system-configuration/object-classes/create-a-standalone-form/index.md`
* **Page type:** how-to

## What this page is about

This page explains how to create and test a standalone form for creating records in an object class. It covers who can create one, the main configuration options, and form limits.

## User intent

* Create a standalone form for an object class
* Understand who has permission to create a standalone form
* Configure sections, fields, required/read-only settings, and input types
* Enable redirect or submit behavior on a standalone form
* Preview, revert, cancel, save, and enable a form
* Copy the standalone form URL and test record creation
* Verify that submitted records appear in Workspace /Records

## Key terms

* standalone form
* object class
* object class fields
* Forms tab
* section
* Label
* Alias
* Field Options
* Required
* Read only
* Input type
* conditional logic
* Preview
* Revert
* Cancel
* Enable
* Redirect
* Submit
* URL
* Workspace /Records
* landing page

## Terminology links

* [standalone forms](/knowledgebase/terminology/#standalone-forms) (matched from `standalone form`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [Object class fields](/knowledgebase/terminology/#object-class-fields)
* [Forms tab](/knowledgebase/terminology/#forms-tab)
* [Workspace Sections](/knowledgebase/terminology/#workspace-sections) (matched from `section`)
* [Label](/knowledgebase/terminology/#label)
* [Alias](/knowledgebase/terminology/#alias)
* [Field Options](/knowledgebase/terminology/#field-options)

## Related topics

* CONDITIONAL LOGIC
* OBJECT CLASS FIELDS

## Prerequisites

* Access to the required object class
* Permission to edit the object class or appropriate admin/owner rights
* Basic familiarity with object classes and fields
* User permission to create records for the object class when using the form

## Not covered

* Detailed instructions for configuring conditional logic
* Detailed explanation of object class fields
* How to configure landing page links or third-party hosting/iframe integrations
* Broader authentication or permission setup beyond stated requirements
* Advanced styling or design customization of forms

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/create-and-manage-your-data-model/index.agent.md
---
# Agent guide: Create And Manage Your Data Model

* **Page path:** `system-configuration/create-and-manage-your-data-model/index.md`
* **Page type:** how-to

## What this page is about

This page is intended to cover creating and managing a data model, but it is currently empty or under construction.

## User intent

* Find instructions for creating a data model
* Learn how to manage an existing data model

## Key terms

* data model

## Terminology links

* [Catalyst data model](/knowledgebase/terminology/#catalyst-data-model) (matched from `data model`)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Any actual steps, procedures, or guidance for creating a data model
* Any actual steps, procedures, or guidance for managing a data model
* Definitions, examples, or configuration details related to data models

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.5/create-task-actor/index.agent.md
---
# Agent guide: Create task actor

* **Page path:** `release-notes/release-notes-1.5/create-task-actor/index.md`
* **Page type:** release-notes

## What this page is about

Release notes for version 1.5 introducing the Create task actor, which replaces the side-panel Task templates list and simplifies task configuration with autocomplete search. It also summarizes how the actor behaves during sequence execution and which task-related events it can trigger.

## User intent

* Understand what changed in release 1.5 for task creation in Sequence designer
* Learn how the Create task actor replaces the old Task templates section
* See how the Create task actor behaves when executed for a record
* Find out what happens if no task template is selected
* Identify which events task actors can trigger
* Understand that conditions can be defined for task event handling

## Key terms

* Create task actor
* Task templates
* autocomplete search
* Sequence designer
* Sequencer
* sequence execution engine
* task template
* Task created
* Task completed
* conditions
* workflow automation

## Terminology links

* [Create task actor](/knowledgebase/terminology/#create-task-actor)
* [Task templates](/knowledgebase/terminology/#task-templates)
* [Sequence designers](/knowledgebase/terminology/#sequence-designers) (matched from `Sequence designer`)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [sequence execution engine](/knowledgebase/terminology/#sequence-execution-engine)
* [Task created event](/knowledgebase/terminology/#task-created-event) (matched from `Task created`)
* [Task completed event](/knowledgebase/terminology/#task-completed-event) (matched from `Task completed`)
* [Filter conditions](/knowledgebase/terminology/#filter-conditions) (matched from `conditions`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with tasks and task templates
* Basic understanding of sequences or Sequence designer
* General understanding of workflow automation concepts

## Not covered

* Step-by-step configuration instructions
* A full list of available task templates
* Detailed definitions of events or condition types
* UI screenshots or navigation details beyond the removed side-panel section
* Troubleshooting or advanced implementation details

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequence-actors/create-task-actor/index.agent.md
---
# Agent guide: Create Task Actor

* **Page path:** `system-configuration/sequence-actors/create-task-actor/index.md`
* **Page type:** how-to

## What this page is about

Explains how to configure and use the Create Task actor in a sequence to create a task from an Automatic task template for a record at a specific workflow point. It also describes task template selection, trigger behavior, defaults, and important execution limits.

## User intent

* Understand what the Create Task actor does
* Add a Create Task actor to a sequence workspace
* Configure the actor to use a task template
* Find which task templates are available for selection
* Understand when a task will or will not be created
* Learn default trigger conditions for the actor
* Avoid issues caused by using the same task in multiple sequences
* Know when to use Create Task versus Set Task

## Key terms

* Create Task actor
* task template
* Automatic task creation mechanism
* Set Task actor
* Task Assignment actor
* default task assignees
* Configure
* autocomplete search
* Update object record type
* sequence object class
* Complete self contained form
* trigger conditions
* When Task Created
* When Task Completed
* sequence execution engine
* Sequencer

## Terminology links

* [Create task actor](/knowledgebase/terminology/#create-task-actor)
* [Task templates](/knowledgebase/terminology/#task-templates) (matched from `task template`)
* [Automatic Task creation mechanism](/knowledgebase/terminology/#automatic-task-creation-mechanism)
* [Set Task actor](/knowledgebase/terminology/#set-task-actor)
* [Task Assignment actor](/knowledgebase/terminology/#task-assignment-actor)
* [Default task assignees](/knowledgebase/terminology/#default-task-assignees)
* [Configure](/knowledgebase/terminology/#configure)
* [Update object record type](/knowledgebase/terminology/#update-object-record-type)

## Related topics

* Set Task actor
* Task Assignment actor

## Prerequisites

* Basic familiarity with sequences and sequence actors
* A task template already created
* Understanding of task assignment if assignees are needed
* Knowledge of the relevant sequence object class

## Not covered

* How to create or manage task templates themselves
* How to configure a Set Task actor in detail
* Broader sequence design beyond this actor
* Detailed configuration of default task assignees
* Any actor types other than brief references to Set Task and Task Assignment

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequences/creating-a-sequence/index.agent.md
---
# Agent guide: Creating a Sequence

* **Page path:** `system-configuration/sequences/creating-a-sequence/index.md`
* **Page type:** how-to

## What this page is about

This page explains how to create a Sequence from the Sequences list, including required permissions, mandatory fields, optional default task assignees, and what happens when you save. It also notes key limits and validation behaviors during creation.

## User intent

* Understand who can create a Sequence
* Learn the prerequisites for creating a Sequence
* Create a new Sequence from the Sequences list
* Fill in required Sequence fields correctly
* Add or remove default task assignees
* Understand validation errors and save behavior
* Know what state a newly created Sequence starts in
* Check limits for assignees and total Sequences

## Key terms

* Sequence
* Sequences list
* Super admin account
* Role permissions
* Sequencer tab
* Create permission
* Object class
* Owner of the Object class
* Sequence Name
* Description
* Default task assignees
* Manage default task assignees
* Save
* Paused state
* Unsaved changes will be lost warning
* Actions menu

## Terminology links

* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequence`)
* [sequences](/knowledgebase/terminology/#sequences) (matched from `Sequences list`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin account`)
* [Roles and Permissions](/knowledgebase/terminology/#roles-and-permissions) (matched from `Role permissions`)
* [Sequencer tab](/knowledgebase/terminology/#sequencer-tab)
* [Create permission under User Groups](/knowledgebase/terminology/#create-permission-under-user-groups) (matched from `Create permission`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Owner of the Object class](/knowledgebase/terminology/#owner-of-the-object-class)

## Related topics

* Edit properties
* Edit design

## Prerequisites

* A Super admin account, or a Role with Create enabled under the Sequencer tab and ownership of the Object class
* The Object class must already be configured
* It is useful, though not required, to have Users already set up for default task assignment

## Not covered

* How to configure an Object class
* How to create Users
* How to edit Sequence properties in detail
* How to edit Sequence design
* How to start or run a Sequence after creation
* How sequence starting conditions are configured

---

---
url: >-
  /knowledgebase-agent-guides/using-help-and-support/we're-here-to-help/creating-a-support-ticket/index.agent.md
---
# Agent guide: Creating a support ticket

* **Page path:** `using-help-and-support/we're-here-to-help/creating-a-support-ticket/index.md`
* **Page type:** how-to

## What this page is about

This page appears intended to explain how to create a support ticket, but the provided content contains only the title and a classification label with no instructions.

## User intent

* Find out how to create a support ticket
* Look for support/help request submission guidance

## Key terms

* support ticket
* help and support
* Autologyx Classification
* Unrestricted, Public

## Terminology links

* [Support Ticket](/knowledgebase/terminology/#support-ticket)
* [Help and Support](/knowledgebase/terminology/#help-and-support)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Step-by-step instructions for creating a support ticket
* Where to submit a ticket
* Required information for a ticket
* Ticket categories, priorities, or routing
* How to track or update an existing ticket

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/creating-object-class-fields/index.agent.md
---
# Agent guide: Creating Object class fields

* **Page path:** `system-configuration/object-classes/creating-object-class-fields/index.md`
* **Page type:** how-to

## What this page is about

Explains how to create, configure, and manage fields within an Object class edit page. It covers adding fields, field properties, selection and validation options, field list behavior, unique values, and identifier field rules.

## User intent

* Add the first or additional fields to an Object class
* Understand which field settings are mandatory when creating a field
* Learn when Selection Options and Validation sections appear
* Use aliases correctly for merge fields, API requests/responses, and document templates
* Search, reorder, edit, view usage of, or remove Object class fields
* Configure a field as a unique value or identifier
* Understand limits and constraints for Object class fields

## Key terms

* Object class
* Object class edit page
* Add field panel
* Field Properties
* Label
* Alias
* Type
* Selection Options
* Validation
* Unique value
* Identifier
* Fields list
* View usage
* merge fields
* API requests and responses
* document templates
* card view

## Terminology links

* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Object class edit page](/knowledgebase/terminology/#object-class-edit-page)
* [Add field panel](/knowledgebase/terminology/#add-field-panel)
* [Record properties](/knowledgebase/terminology/#record-properties) (matched from `Field Properties`)
* [Label](/knowledgebase/terminology/#label)
* [Alias](/knowledgebase/terminology/#alias)
* [field types](/knowledgebase/terminology/#field-types) (matched from `Type`)
* [Select options](/knowledgebase/terminology/#select-options) (matched from `Selection Options`)

## Related topics

* Not provided.

## Prerequisites

* Appropriate role and/or permission to edit an Object class
* Basic familiarity with the Object class edit page

## Not covered

* Detailed definitions of each available field type and all their attributes
* How to create or edit Object classes themselves
* Detailed guidance on list pages or card view pages beyond where the identifier appears
* Workflow, Sequence, API, or document template configuration beyond mentioning alias usage

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/relational-modeller/creating-the-relational-model/index.agent.md
---
# Agent guide: Creating the Relational model

* **Page path:** `system-configuration/relational-modeller/creating-the-relational-model/index.md`
* **Page type:** how-to

## What this page is about

This page explains how to create and save a relational model in the Relational modeller by arranging existing object classes into parent/child trees. It also describes the canvas, ratio options, model limits, and what must be configured afterward for parent classes.

## User intent

* Open the Relational modeller and start a new relational model
* Add object classes to the canvas as root parents or children
* Set parent/child relationship ratios such as 1:N or 1:1
* Understand the page layout and controls in the modeller
* Know the limits on roots, children per parent, and tree depth
* Save the relational model and understand what happens next
* Remove, move, collapse, or reorganize object classes in the model

## Key terms

* Relational modeller
* relational model canvas
* object classes
* root parent class
* child object class
* parent/child relationships
* ratio selector
* 1:N
* 1:1
* collapse icon
* sidebar
* Save
* Cancel
* System configuration

## Terminology links

* [Relational modeller](/knowledgebase/terminology/#relational-modeller)
* [Relational model canvas](/knowledgebase/terminology/#relational-model-canvas)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [root parent class](/knowledgebase/terminology/#root-parent-class)
* [parent/child relationships](/knowledgebase/terminology/#parentchild-relationships)
* [ratio selector](/knowledgebase/terminology/#ratio-selector)
* [1:N](/knowledgebase/terminology/#1n)
* [1:1](/knowledgebase/terminology/#11)

## Related topics

* who can create/edit the relational model
* configuring relationships in object classes
* the Relational modeller
* create/edit view under the display tab

## Prerequisites

* Object classes must already be created
* Access to the System configuration section
* Later, each parent class needs a create/edit view enabled under the display tab so child object classes can be added to the parent view

## Not covered

* Detailed permission rules for who can create or edit the relational model
* Step-by-step configuration of create/edit views under the display tab
* Detailed instructions for configuring relationships inside each parent object class after saving
* General conceptual overview beyond creating and editing the model itself

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/theme/creating-the-theme/index.agent.md
---
# Agent guide: Creating the Theme

* **Page path:** `system-configuration/theme/creating-the-theme/index.md`
* **Page type:** how-to

## What this page is about

This page explains how a Super admin creates and configures a Theme in System configuration, including logo upload, login-page text overrides, and system colour settings. It also covers enabling, saving, editing, and cancelling theme changes.

## User intent

* Find who is allowed to create or edit a Theme
* Locate the Theme configuration page
* Upload or remove a custom logo
* Understand logo file requirements
* Change login-page text content
* Configure system colours using hex values
* Understand what each colour setting affects
* Enable and save a Theme so it applies across the application
* Cancel theme changes and understand how revert behavior works

## Key terms

* Theme
* Super admin
* System configuration
* Media tab
* Text overrides
* Colours tab
* SVG
* Hex numbers
* Primary colour
* Secondary colour
* Tertiary colour
* Navigation panel background colour
* Section content background
* Section header background
* Enable
* Save
* Cancel
* Unsaved changes will be lost modal

## Terminology links

* [Theme](/knowledgebase/terminology/#theme)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [System configuration](/knowledgebase/terminology/#system-configuration)
* [Media tab](/knowledgebase/terminology/#media-tab)
* [Text overrides](/knowledgebase/terminology/#text-overrides)
* [Colours tab](/knowledgebase/terminology/#colours-tab)
* [Primary colour](/knowledgebase/terminology/#primary-colour)
* [Secondary colour](/knowledgebase/terminology/#secondary-colour)

## Related topics

* Not provided.

## Prerequisites

* A user account with Super admin account type
* Access to the System configuration section
* A logo file in SVG format under 100KB if branding is being customised
* Hex colour values for required colour fields

## Not covered

* How to create a Super admin account
* Detailed branding or design guidance
* How themes interact with other configuration areas beyond the listed UI elements
* Any export, import, or versioning of themes
* Specific image converter recommendations or instructions

---

---
url: >-
  /knowledgebase-agent-guides/workspace/the-task-panel/creation-of-a-manual-task-for-an-object-record/index.agent.md
---
# Agent guide: Creation of a Manual Task for an Object Record

* **Page path:** `workspace/the-task-panel/creation-of-a-manual-task-for-an-object-record/index.md`
* **Page type:** explanation

## What this page is about

Explains how to create a manual task for an object record from the Workspace, rather than automatically via the Sequencer. It covers eligibility, required fields, assignment rules, visibility, and task creation/cancellation behavior.

## User intent

* Understand how to create a manual task for an object record in the Workspace
* Learn who is allowed to create manual tasks for object records
* See which task templates are available for manual task creation
* Find out which fields are mandatory when creating a manual task
* Understand how task assignees can be selected and edited
* Learn the rules for assigning Super Admin, Standard, and one time completion users
* Set due dates and instructions for a manual task
* Know when the Add button becomes enabled
* Understand who can view a created manual task
* Learn limits and behaviors such as maximum assignees and instruction length

## Key terms

* Manual Task
* Object record
* Workspace
* Sequencer
* Task template
* Task creation mechanism set to Manual
* Update object records type
* Object class
* Mortgage Application class
* Super Admin
* Object class Owner
* Permission set
* Create Tasks
* Tasks tab
* * Create task button
* Task details
* Assignment of stages
* Instructions
* Task name
* Task template
* Complete field
* Due date
* No due date
* Date
* one time completion user
* Standard user
* Task completion screen
* Task properties
* * Add button
* Outstanding status
* Tasks/View all permission

## Terminology links

* [Manual Tasks](/knowledgebase/terminology/#manual-tasks) (matched from `Manual Task`)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `Object record`)
* [Workspace](/knowledgebase/terminology/#workspace)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Task templates](/knowledgebase/terminology/#task-templates) (matched from `Task template`)
* [Update object records type](/knowledgebase/terminology/#update-object-records-type)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Mortgage Application class](/knowledgebase/terminology/#mortgage-application-class)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with object records and object classes
* Access to the Workspace and an object's Tasks tab
* A task template configured for Manual creation and available for the relevant object class
* Appropriate permissions: Super Admin, Object class Owner, or a permission set allowing Create Tasks

## Not covered

* Automatic task creation from the Sequencer
* How to configure task templates
* How to configure object classes or identifiers
* How to complete the task after creation beyond where instructions appear
* Broader workflow design or sequencing behavior

---

---
url: /api-agent-guides/catalyst/resources/custom-components/index.agent.md
---
# Agent guide: Custom Components

* **Page path:** `catalyst/resources/custom-components.md`
* **Page type:** reference

## What this page is about

Reference documentation for Custom Components implementation and API, including repository import, component CRUD, permissions, validations, statuses, and usage lookup endpoints. It also notes that deeper implementation details live in an external technical design document.

## User intent

* Understand what permissions are required to manage custom components
* Create or inspect a custom component repository
* Create a custom component from an imported repository
* List custom components or retrieve details for one component
* Update or delete a custom component
* Check where a custom component is being used before deletion
* Understand request/response fields, validation rules, and common error responses

## Key terms

* Custom Components
* Custom Components Repository
* custom component permission resource
* super admin
* repository status
* component status
* available use
* landing page
* object class create form
* object class summary form
* object class standalone form
* task template form
* parameters
* meta.permissions
* usage endpoint

## Terminology links

* [custom components](/api/terminology/#custom-components)
* [Custom Components Repository](/api/terminology/#custom-components-repository)
* [super admin](/api/terminology/#super-admin)
* [repository status](/api/terminology/#repository-status)
* [component status](/api/terminology/#component-status)
* [available use](/api/terminology/#available-use)
* [landing page](/api/terminology/#landing-page)
* [object class create form](/api/terminology/#object-class-create-form)

## Related topics

* Limits
* Roles
* Security Rules

## Prerequisites

* Familiarity with REST API requests and responses
* Understanding of user permissions and super admin access
* Basic knowledge of repository-based component import flow
* Awareness of account type restrictions

## Not covered

* Detailed implementation internals beyond the API/reference surface
* The external "Custom Components Technical Design" contents
* How related resources such as object classes or landing pages are configured elsewhere
* General role or security model details beyond the stated permission requirements

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.8/database-views/index.agent.md
---
# Agent guide: Database views

* **Page path:** `release-notes/release-notes-1.8/database-views/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces Catalyst database views via ClickHouse integration. It explains how users can connect to a ClickHouse database for a selected domain, browse read-only Autologyx data, and create views of records from Object classes for analysis.

## User intent

* Understand what the new database views feature in Catalyst does
* Learn how users connect to a ClickHouse database within a domain
* Find out what data can be explored, such as Event History and Resource tables
* Confirm whether the exposed database views are read-only
* See what record-based views can be created from Object classes
* Identify analysis use cases for compliance, legal, M\&A, and litigation teams

## Key terms

* Catalyst
* ClickHouse integration
* database views
* selected domain
* connection credentials
* Event History tables
* Resource tables (replica)
* Autologyx Cross Platform views
* read-only access
* Object class
* Record ID
* Record Identifier
* Record Creation Datetime

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst)
* [ClickHouse integration](/knowledgebase/terminology/#clickhouse-integration)
* [Database views](/knowledgebase/terminology/#database-views)
* [selected domain](/knowledgebase/terminology/#selected-domain)
* [Event History tables](/knowledgebase/terminology/#event-history-tables)
* [Resource tables](/knowledgebase/terminology/#resource-tables) (matched from `Resource tables (replica)`)
* [Autologyx Cross Platform views](/knowledgebase/terminology/#autologyx-cross-platform-views)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)

## Related topics

* Not provided.

## Prerequisites

* Access to a selected domain
* Valid ClickHouse connection credentials
* Basic familiarity with database management tools and tables
* Understanding of Autologyx Object classes and records

## Not covered

* Detailed setup or configuration steps for ClickHouse connections
* Security, permission, or credential management details beyond requiring credentials
* How to modify schemas or data, since access is read-only
* Technical implementation details of replicas or view generation
* Performance benchmarks or architecture details

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.11/delayed-account-activation/index.agent.md
---
# Agent guide: Delayed account activation

* **Page path:** `release-notes/release-notes-1.11/delayed-account-activation/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces delayed account activation for new users. It explains how admins can postpone sending activation emails and track user activation states in the User details page and User List.

## User intent

* Understand what delayed account activation does
* Learn how user creation works when the activation email is not sent immediately
* Identify the meaning of the Created, Pending, and Active user statuses
* Find where to manually send or resend activation emails
* See how to filter users by activation status in the User List

## Key terms

* delayed account activation
* activation email
* User details page
* Status section
* Created
* Pending
* Active
* User List
* status column

## Terminology links

* [delayed account activation](/knowledgebase/terminology/#delayed-account-activation)
* [activation email](/knowledgebase/terminology/#activation-email)
* [User details page](/knowledgebase/terminology/#user-details-page)
* [Status section](/knowledgebase/terminology/#status-section)
* [Created status](/knowledgebase/terminology/#created-status) (matched from `Created`)
* [Pending status](/knowledgebase/terminology/#pending-status) (matched from `Pending`)
* [Active status](/knowledgebase/terminology/#active-status) (matched from `Active`)
* [Users list](/knowledgebase/terminology/#users-list) (matched from `User List`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with creating and managing users in the platform
* Understanding of account activation via email

## Not covered

* Detailed step-by-step UI instructions for creating users
* Configuration options beyond delaying the activation email
* Permission or role setup procedures
* Compliance workflow details
* Any technical implementation or API behavior

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.13/delete-option-in-set-task-actor/index.agent.md
---
# Agent guide: Delete option in Set Task actor

* **Page path:** `release-notes/release-notes-1.13/delete-option-in-set-task-actor/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces a new Delete action in the Set Task actor, allowing workflows to remove tasks programmatically as well as create/re-create them. It explains the available delete targets, how deletion behaves, and example workflow use cases.

## User intent

* Understand what the new Delete option in Set Task actor does
* Learn which task deletion targets are available
* Determine how task deletion behaves when no matching tasks exist
* See examples of when to use task deletion in workflows
* Understand how this improves workflow-based task lifecycle management

## Key terms

* Set Task actor
* Delete action
* Re create option
* Task Template
* Delete Target
* All tasks
* All outstanding tasks
* All complete tasks
* Most recent task
* Most recent outstanding task
* Most recent complete task
* workflow
* record

## Terminology links

* [Set Task actor](/knowledgebase/terminology/#set-task-actor)
* [Delete action](/knowledgebase/terminology/#delete-action)
* [Re create option](/knowledgebase/terminology/#re-create-option)
* [Task templates](/knowledgebase/terminology/#task-templates) (matched from `Task Template`)
* [Delete Target](/knowledgebase/terminology/#delete-target)
* [All tasks](/knowledgebase/terminology/#all-tasks)
* [All outstanding tasks](/knowledgebase/terminology/#all-outstanding-tasks)
* [All complete tasks](/knowledgebase/terminology/#all-complete-tasks)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of workflows
* Familiarity with tasks and task templates in Catalyst
* Awareness of the Set Task actor and its existing create/re-create behavior

## Not covered

* Step-by-step configuration instructions beyond selecting the action and delete target
* Any permissions, audit, or recovery/restore behavior for deleted tasks
* Broader workflow design guidance outside this specific feature
* Details of other actors or unrelated release note changes

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequence-actors/docauto-actor/index.agent.md
---
# Agent guide: DocAuto Actor

* **Page path:** `system-configuration/sequence-actors/docauto-actor/index.md`
* **Page type:** explanation

## What this page is about

This page explains what the DocAuto actor does in a sequence and how to configure it to generate documents from templates in a workflow. It also describes how it is commonly used with Document Picker and other sequence actors to move generated documents through later steps.

## User intent

* Understand the purpose of the DocAuto actor
* Learn when to use DocAuto in a workflow sequence
* Configure a DocAuto actor to generate a document from a template
* Connect DocAuto correctly in a sequence
* Use DocAuto with Document Picker to pass generated documents to later actors
* Generate documents that use merge fields, IF statements, or other Jinja template features
* Set conditions so document generation only runs after specific record updates

## Key terms

* DocAuto actor
* Document Picker actor
* document template
* Object class
* sequence actors
* Jinja
* merge fields
* IF statements
* When Record Updated
* Update Record actor
* Send Message actor
* source field
* template field
* properties
* additional conditions
* Combine Results

## Terminology links

* [DocAuto actor](/knowledgebase/terminology/#docauto-actor)
* [Document Picker actor](/knowledgebase/terminology/#document-picker-actor)
* [Document Templates](/knowledgebase/terminology/#document-templates) (matched from `document template`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Sequence Actors](/knowledgebase/terminology/#sequence-actors)
* [Jinja merge fields](/knowledgebase/terminology/#jinja-merge-fields) (matched from `Jinja`)
* [merge fields](/knowledgebase/terminology/#merge-fields)
* [IF Statements](/knowledgebase/terminology/#if-statements)

## Related topics

* Document Picker actor
* Automatic Document Generation
* Send Message actor
* Update Record actor

## Prerequisites

* Basic understanding of sequence actors and the sequence workspace
* Familiarity with Object class records
* Access to document templates saved against the Object class
* Basic understanding of Jinja-based template fields such as merge fields and IF statements

## Not covered

* Detailed explanation of Automatic Document Generation beyond the linked further reading
* Full instructions for configuring Document Picker, Update Record, or Send Message actors
* Detailed explanation of the Combine Results feature beyond pointing to another article
* Template authoring guidance for Jinja syntax
* API setup details for GET request document retrieval

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.14/document-records-enhancements/index.agent.md
---
# Agent guide: Document & Records Enhancements

* **Page path:** `release-notes/release-notes-1.14/document-records-enhancements/index.md`
* **Page type:** release-notes

## What this page is about

This release note describes enhancements to document and records handling in version 1.14, including clearer file name display in tables/records, new filtering for document-type fields, and a new API endpoint for retrieving file metadata in bulk.

## User intent

* Understand how document fields are now displayed in tables and records
* Learn when a file name is shown instead of a generic document count
* Find out how to filter object records by document-type fields
* See what filter options are available for document fields
* Understand the purpose of the new file metadata API endpoint
* Learn how the API change reduces the number of calls needed for file metadata retrieval

## Key terms

* File name display
* tables and records
* document field
* single file
* multiple documents
* document count
* object records
* document type fields
* Is empty
* Is not empty
* file metadata
* API endpoint
* bulk request
* record details endpoint

## Terminology links

* [document type fields](/knowledgebase/terminology/#document-type-fields) (matched from `document field`)
* [Object records](/knowledgebase/terminology/#object-records)
* [Is Empty](/knowledgebase/terminology/#is-empty)
* [Is Not Empty](/knowledgebase/terminology/#is-not-empty)
* [file metadata](/knowledgebase/terminology/#file-metadata)
* [API endpoints](/knowledgebase/terminology/#api-endpoints) (matched from `API endpoint`)
* [record details endpoint](/knowledgebase/terminology/#record-details-endpoint)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with documents and records in the platform
* Basic understanding of record lists and filtering
* Basic understanding of API endpoints and file metadata for integration use cases

## Not covered

* The exact API endpoint path
* Detailed request/response payload definitions beyond noting an example response structure
* Configuration or setup steps for using the new filters or API
* Any changes outside document display, record filtering, and file metadata retrieval
* Implementation details for integrations

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/merge-fields/document-assembly-using-the-.docx-merge-field/index.agent.md
---
# Agent guide: Document Assembly Using the .docx Merge Field

* **Page path:** `system-configuration/merge-fields/document-assembly-using-the-.docx-merge-field/index.md`
* **Page type:** explanation

## What this page is about

Explains how to use the .docx merge field to insert one or more complete documents into a master document template. It covers when to use it, required syntax/conditions, optional-field handling, and example sequence-based workflows.

## User intent

* Understand when to use the .docx merge field versus image merge fields or Jinja2 conditionals
* Configure a master document to merge documents stored on the record or a related record
* Choose between inline merge and paragraph replacement
* Ensure required setup is in place before generating a merged document
* Handle optional or empty document fields safely with IF statements
* Build document packs by combining previously generated documents
* Pull a centrally maintained document into an agreement before generation

## Key terms

* .docx merge field
* master document
* inserted document
* document field
* related record
* inline merge
* paragraph replacement
* index
* IF statement
* Jinja2
* DocAuto actor
* Document picker actor
* Update record actor
* Sequence runner actor
* API Call
* Local Variable
* image merge field

## Terminology links

* [.docx merge fields](/knowledgebase/terminology/#docx-merge-fields) (matched from `.docx merge field`)
* [document type fields](/knowledgebase/terminology/#document-type-fields) (matched from `document field`)
* [Records](/knowledgebase/terminology/#records) (matched from `related record`)
* [inline merge](/knowledgebase/terminology/#inline-merge)
* [paragraph replacement](/knowledgebase/terminology/#paragraph-replacement)
* [index](/knowledgebase/terminology/#index)
* [IF Statements](/knowledgebase/terminology/#if-statements) (matched from `IF statement`)
* [Jinja2](/knowledgebase/terminology/#jinja2)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of document templates
* Documents must be stored in document fields on the record or a related record
* Familiarity with sequence generation methods such as Sequencer or manual generation from the record side panel
* Awareness of IF statements/Jinja2 if handling optional content

## Not covered

* Exact merge field syntax examples are not shown in the supplied text
* Detailed Jinja2 syntax beyond recommending it for smaller conditional clauses
* Image merging configuration details
* General document templating outside document templates
* Full setup details for external repositories like iManage or DocuSign integrations

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/document-automation/index.agent.md
---
# Agent guide: Document Automation

* **Page path:** `system-configuration/document-automation/index.md`
* **Page type:** explanation

## What this page is about

This page is a placeholder for the Document Automation section and does not yet provide substantive content. It indicates the section is empty or under construction.

## User intent

* Check whether documentation for Document Automation is available
* Determine if this section contains guidance or configuration details yet

## Key terms

* Document Automation
* under construction
* Autologyx Classification: Unrestricted, Public

## Terminology links

* [Document Automation](/knowledgebase/terminology/#document-automation)

## Related topics

* Not provided.

## Prerequisites

* No specific prior knowledge is stated

## Not covered

* Any explanation of what Document Automation does
* Setup or configuration steps
* Usage instructions
* Examples, workflows, or troubleshooting

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequence-actors/document-picker-actor/index.agent.md
---
# Agent guide: Document Picker Actor

* **Page path:** `system-configuration/sequence-actors/document-picker-actor/index.md`
* **Page type:** explanation

## What this page is about

This page explains what the Document Picker actor does in a sequence and how it is used to move documents from document fields, API calls, or DocAuto into later steps such as Send Message, Update Record, or API Call actors. It also explains the Combine results option for collecting documents from across a sequence path.

## User intent

* Understand the purpose of the Document Picker actor
* Configure a Document Picker in a sequence
* Choose the correct document source based on the preceding actor
* Use documents as email attachments or file them into record fields
* Pass documents into Post or Patch API Call actors using file parameters
* Process a picked Word document with DocAuto and Jinja merge fields
* Understand when and how to use the Combine results option
* Avoid performance issues when handling many documents in a field

## Key terms

* Document Picker actor
* DocAuto actor
* API Call actor
* Get request
* Post API Call
* Patch API Call
* Form Data
* Multipart Data
* Binary Data
* Files section
* Document Field
* API Call Document
* DocAuto Actor
* Combine results
* Send Message actor
* Update Record actor
* Create Task actor
* Record field
* Jinja merge fields
* .docx

## Terminology links

* [Document Picker actor](/knowledgebase/terminology/#document-picker-actor)
* [DocAuto actor](/knowledgebase/terminology/#docauto-actor)
* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [Post API call](/knowledgebase/terminology/#post-api-call)
* [PATCH API calls](/knowledgebase/terminology/#patch-api-calls) (matched from `Patch API Call`)
* [Form Data](/knowledgebase/terminology/#form-data)
* [Multipart Data](/knowledgebase/terminology/#multipart-data)
* [Binary Data mode](/knowledgebase/terminology/#binary-data-mode) (matched from `Binary Data`)

## Related topics

* Create Document Template
* Automatic Document Generation

## Prerequisites

* Basic understanding of sequence actors and connecting actors in a workflow
* Familiarity with document fields and record fields
* Basic knowledge of API Call and DocAuto actors
* For DocAuto processing, awareness of Jinja merge fields in Word documents

## Not covered

* Detailed Jinja syntax rules
* Full configuration details for Send Message, Update Record, Create Task, or API Call actors
* Broader performance tuning beyond the warning about many documents
* General sequence design outside Document Picker behavior

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/working-with-document-templates/document-templates-list/index.agent.md
---
# Agent guide: Document templates list

* **Page path:** `system-configuration/working-with-document-templates/document-templates-list/index.md`
* **Page type:** explanation

## What this page is about

This page explains where to find the Document templates list within an Object class, what permissions are required to access it, and what information and actions are available in the list. It also describes the default and optional columns, editing from the list, empty state, and key usage limits.

## User intent

* Find the Document templates list in an Object class
* Understand what access or permissions are needed to view the list
* See what controls appear at the top of the list
* Understand the default columns and available actions for each template
* View which additional columns can be added
* Learn how to edit a template directly from the list
* Check when a template can be deleted
* Understand how to see where a template is used in sequences
* Know what happens when no templates exist
* Understand list limits and sorting options

## Key terms

* Document templates list
* Object class
* Document templates tab
* Super Admin
* Role with permission to edit object classes
* Permission set
* Create button
* pagination
* column configuration
* ID
* Name
* Template File Name
* Actions
* Edit
* Download
* Delete
* View usage
* sequences
* DocAuto actor
* Created
* Created by
* Description
* Last edited
* Last edited by
* Manual generation
* empty state

## Terminology links

* [Document templates list](/knowledgebase/terminology/#document-templates-list)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super Admin`)
* [Role with permission to edit object classes](/knowledgebase/terminology/#role-with-permission-to-edit-object-classes)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `Permission set`)
* [+Create button](/knowledgebase/terminology/#create-button) (matched from `Create button`)
* [Column configuration](/knowledgebase/terminology/#column-configuration)
* [Identifier](/knowledgebase/terminology/#identifier) (matched from `ID`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Object classes
* Appropriate access: Super Admin, a Role with permission to edit object classes, or membership in a Permission set allowing editing of a specific Object class

## Not covered

* Detailed steps for creating a document template
* Detailed steps for editing a document template
* Detailed explanation of document manual generation
* General filtering features, since this list does not have a filter
* Configuration of sequences or DocAuto actors beyond usage visibility

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.5/documents-in-sequencer/index.agent.md
---
# Agent guide: Documents in Sequencer

* **Page path:** `release-notes/release-notes-1.5/documents-in-sequencer/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces support for binary and multipart documents in Sequencer via the API Call actor. It explains how to send multiple files using Form Data and a single file using Binary Data mode, including basic file-name validation.

## User intent

* Understand what document support was added to Sequencer in release 1.5
* Learn how to send multiple documents through an API Call actor using Form Data
* Learn how to send a single document through an API Call actor using Binary Data mode
* Understand how Document Picker actors can supply files to an API Call actor
* Check whether file validation is included when attaching documents

## Key terms

* Sequencer
* API Call actor
* Form Data
* Binary Data mode
* Files section
* Parameters
* Document Picker actor
* multipart documents
* binary documents
* validation

## Terminology links

* [Sequencer](/knowledgebase/terminology/#sequencer)
* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [Form Data](/knowledgebase/terminology/#form-data)
* [Binary Data mode](/knowledgebase/terminology/#binary-data-mode)
* [Files section](/knowledgebase/terminology/#files-section)
* [Element parameters](/knowledgebase/terminology/#element-parameters) (matched from `Parameters`)
* [Document Picker actor](/knowledgebase/terminology/#document-picker-actor)
* [Validation section](/knowledgebase/terminology/#validation-section) (matched from `validation`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Sequencer workflows
* Understanding of API Call actors
* Awareness of Document Picker actors

## Not covered

* Detailed setup steps or screenshots for configuring the API Call actor
* Technical API specifications for multipart or binary payloads
* Limits, supported file types, or size constraints
* Advanced validation rules beyond checking that a file is named
* Examples of downstream integrations beyond brief use cases

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.13/dynamic-document-assembly-with-.docx-merge-fields/index.agent.md
---
# Agent guide: Dynamic document assembly with .docx merge fields

* **Page path:** `release-notes/release-notes-1.13/dynamic-document-assembly-with-.docx-merge-fields/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces a new Document Templates merge field syntax that inserts the full content of a .docx file stored on a record directly into a generated document. It explains the two merge modes, expected behavior, and validation rules such as required file indexes and empty results for unsupported cases.

## User intent

* Learn how to merge the contents of record-stored .docx files into Document Templates
* Understand the difference between inline merge and paragraph replacement merge
* Find when to use paragraph replacement for long or formatted inserted content
* Check validation rules for file type, index requirements, and out-of-range behavior
* Confirm what happens if the merge field is used outside Document Templates

## Key terms

* Document Templates
* merge field syntax
* dynamic document assembly
* .docx
* inline merge
* paragraph replacement
* {{p ... }} syntax
* record document field
* embedded file content
* empty string result

## Terminology links

* [Document Templates](/knowledgebase/terminology/#document-templates)
* [merge field syntax](/knowledgebase/terminology/#merge-field-syntax)
* [Dynamic document assembly](/knowledgebase/terminology/#dynamic-document-assembly)
* [inline merge](/knowledgebase/terminology/#inline-merge)
* [paragraph replacement](/knowledgebase/terminology/#paragraph-replacement)
* [{{p ... }} syntax](/knowledgebase/terminology/#p-syntax)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Document Templates
* Understanding that files are stored on record fields
* Knowledge of .docx-based template generation and merge fields

## Not covered

* Exact full syntax reference beyond the examples and {{p ... }} mention
* How to configure record fields or upload files
* Support for non-.docx files beyond stating they return an empty string
* Detailed behavior in Sequencer or other products beyond empty result
* Advanced template logic or conditional record logic setup

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/working-with-document-templates/edit-a-document-template/index.agent.md
---
# Agent guide: Edit a Document Template

* **Page path:** `system-configuration/working-with-document-templates/edit-a-document-template/index.md`
* **Page type:** how-to

## What this page is about

Explains how to edit an existing Document Template for an Object class in System configuration. It covers required permissions, where to find the template, what properties can be changed, and that the updated file must be re-uploaded before saving.

## User intent

* Find and open a document template for editing
* Understand what permissions are required to edit a document template
* Change a template's name, description, or manual generation setting
* Download an existing template and modify merge fields, IF statements, other function statements, text, layout, or formatting
* Replace the existing template file with an amended version

## Key terms

* Document Template
* System configuration
* Object classes
* Document templates tab
* Super Admin
* Role
* Permission set
* manual generation
* merge fields
* IF Statements
* function Statements
* Name
* Description

## Terminology links

* [Document Templates](/knowledgebase/terminology/#document-templates) (matched from `Document Template`)
* [System configuration](/knowledgebase/terminology/#system-configuration)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [Document templates list](/knowledgebase/terminology/#document-templates-list) (matched from `Document templates tab`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super Admin`)
* [Roles](/knowledgebase/terminology/#roles) (matched from `Role`)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `Permission set`)
* [manual generation](/knowledgebase/terminology/#manual-generation)

## Related topics

* Not provided.

## Prerequisites

* Access to System configuration
* One of the required permissions: Super Admin account, a Role with permission to edit object classes, or membership of a Permission set allowing edit access to a specific Object class
* An existing Object class and document template to edit

## Not covered

* How to create a new document template
* How to delete a document template
* Detailed syntax or usage of merge fields, IF statements, or other function statements
* How permission roles or permission sets are configured
* How document generation works beyond enabling or disabling manual generation

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/edit-object-class---configure-displays/index.agent.md
---
# Agent guide: Edit Object class - configure displays

* **Page path:** `system-configuration/object-classes/edit-object-class---configure-displays/index.md`
* **Page type:** how-to

## What this page is about

Explains how to configure the three Object class display views under the Display tab: Card view, Create and edit view, and Summary view. It describes where each view is used, how to build them with the form builder, and key limits and defaults.

## User intent

* Understand the purpose of the Card, Create and edit, and Summary views
* Configure display layouts for an existing Object class
* Know which fields must exist before configuring displays
* Learn where each display view appears in the system
* Enable Create and edit or Summary views for use
* Use the form builder to add sections, fields, and properties
* Preview or revert changes to a display
* Understand field and section limits for each view
* See how Object class field changes affect existing displays

## Key terms

* Object class
* Display tab
* Fields
* Card view
* Create and edit view
* Summary view
* Identifier
* ALX ID
* form builder
* canvas
* Components
* Layout
* Fields
* Properties
* section
* columns
* column ratio
* Conditional Visibility
* Preview
* Revert
* system fields
* Owners
* Created date/time
* Updated date/time

## Terminology links

* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Display tab](/knowledgebase/terminology/#display-tab)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `Fields`)
* [Card view](/knowledgebase/terminology/#card-view)
* [Create and edit view](/knowledgebase/terminology/#create-and-edit-view)
* [summary view](/knowledgebase/terminology/#summary-view)
* [Identifier](/knowledgebase/terminology/#identifier)
* [ALX ID](/knowledgebase/terminology/#alx-id)

## Related topics

* Not provided.

## Prerequisites

* An Object class has already been created
* Fields should be created before configuring displays
* Basic understanding of Object records and Object class configuration

## Not covered

* How to create the Object class itself
* Detailed instructions for creating fields
* Configuration of Forms, Document Templates, or Permissions beyond noting field dependencies
* The separate section describing form builder, components, and fields

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/edit-object-class---creating-class-permissions-and-addremove-assignees/index.agent.md
---
# Agent guide: Edit Object class - creating Class permissions and add/remove Assignees

* **Page path:** `system-configuration/object-classes/edit-object-class---creating-class-permissions-and-addremove-assignees/index.md`
* **Page type:** how-to

## What this page is about

How to manage an Object class’s Class permissions in Edit mode: create new permission sets and add or remove user and user-group assignees. It also clarifies who is allowed to do this and the limits on permission sets and assignees.

## User intent

* Find who can create or manage Class permission sets on an Object class
* Create a new Class permission set from the Permissions tab
* Enable specific permissions within a new permission set
* Add individual users as assignees to a permission set
* Add user groups as assignees to a permission set
* Remove users or user groups from a permission set
* Understand what happens to permissions when assignees are added or removed
* Check limits for number of permission sets, assignees, and user groups

## Key terms

* Edit mode
* Object class
* Permissions tab
* Class permissions
* Permission set
* Owner
* Super admin account type
* Assignees
* Users tab
* User groups tab
* Manage assignees side panel
* kebab menu
* Success toast
* Record Permission sets

## Terminology links

* [Edit mode](/knowledgebase/terminology/#edit-mode)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Permissions tab](/knowledgebase/terminology/#permissions-tab)
* [Class permissions](/knowledgebase/terminology/#class-permissions)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `Permission set`)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Owner`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type)
* [Assignees](/knowledgebase/terminology/#assignees)

## Related topics

* Explanation of Class Permissions
* Explanation of Record Permissions
* Editing Permission sets

## Prerequisites

* Access to an Object class in Edit mode
* Be a Super admin or an Owner of the Object class to create permission sets
* Basic understanding of users, user groups, and assignees

## Not covered

* Detailed explanation of what each individual permission means
* How to manage Owners beyond noting that Owners can add further Owners
* Managing Record Permission sets on individual records beyond a brief comparison
* General Object class creation or broader system configuration steps

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/edit-object-class---editing-permission-sets/index.agent.md
---
# Agent guide: Edit Object class - editing Permission sets

* **Page path:** `system-configuration/object-classes/edit-object-class---editing-permission-sets/index.md`
* **Page type:** how-to

## What this page is about

How to edit Permission sets for an Object class, including who can edit, how to manage Owners and Assignees, and how to edit or delete class and record permission sets. It also explains immediate effects of changes and key limits on Permission sets and assignees.

## User intent

* Find out who is allowed to edit an Object class Permission set
* Open the Permissions tab for an Object class
* Switch between Class permissions and Record permissions
* Manage Owners for the Object class
* Add or remove assignees from a Permission set
* Edit the permissions inside an existing Permission set
* Delete a Permission set
* Understand what happens when an Owner removes themself
* Learn limits such as maximum Permission sets and assignees

## Key terms

* Object class
* Permission set
* Permissions tab
* Class permissions
* Record permissions
* Owner
* Assignee
* Super admin
* Edit Object class permission
* Manage owners
* Manage assignees
* kebab menu
* Permission set modal
* Data Model tab

## Terminology links

* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `Permission set`)
* [Permissions tab](/knowledgebase/terminology/#permissions-tab)
* [Class permissions](/knowledgebase/terminology/#class-permissions)
* [Record Permission Sets](/knowledgebase/terminology/#record-permission-sets) (matched from `Record permissions`)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Owner`)
* [Assignees](/knowledgebase/terminology/#assignees) (matched from `Assignee`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)

## Related topics

* Creating Permission sets

## Prerequisites

* Access to an Object class
* Being a Super admin or an Owner of the Object class to edit Permission sets
* Basic familiarity with the Actions menu and Permissions tab

## Not covered

* How to create Permission sets in detail
* How Owners and Assignees for Record permissions are managed on individual records
* General setup of Roles or Permission sets outside this Object class editing flow
* Detailed explanation of every individual permission option

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/edit-object-class---remove-fields/index.agent.md
---
# Agent guide: Edit Object class - Remove fields

* **Page path:** `system-configuration/object-classes/edit-object-class---remove-fields/index.md`
* **Page type:** how-to

## What this page is about

This page explains how to remove fields from an Object class and what permissions are required. It also describes what happens when a field is unused versus when it is still in use by Object records or task templates.

## User intent

* Check whether I have permission to remove a field from an Object class
* Remove a field from the Fields list
* Understand the warning and confirmation flow when removing a field
* Find out why a field cannot be removed
* See how to identify where a field is currently in use before removal

## Key terms

* Object class
* field
* Fields list
* Actions menu
* Remove
* permissions required
* Super admin
* Owner
* Role
* Data Model tab
* Permission set
* Object class Edit permission
* warning message
* success toast
* View usage panel
* Edit panel
* Object records
* task templates
* field associations

## Terminology links

* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `field`)
* [Fields list](/knowledgebase/terminology/#fields-list)
* [Actions menu](/knowledgebase/terminology/#actions-menu)
* [Remove](/knowledgebase/terminology/#remove)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Owner`)
* [Roles](/knowledgebase/terminology/#roles) (matched from `Role`)

## Related topics

* Not provided.

## Prerequisites

* Access to an Object class and its Fields list
* One of the required permissions: Super admin, Object class Owner, a Role with Object class Edit permission on the Data Model tab, or a Permission set for the specific Object class with Object class Edit permission

## Not covered

* How to create or edit fields
* How to remove the field associations from Object records or task templates
* Broader Object class configuration beyond field removal
* Detailed steps for using the View usage panel beyond showing where the field is in use

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequences/editing-a-sequence---design/index.agent.md
---
# Agent guide: Editing a Sequence - Design

* **Page path:** `system-configuration/sequences/editing-a-sequence---design/index.md`
* **Page type:** how-to

## What this page is about

This page explains how to open and edit a Sequence design and begin constructing its workflow from the Sequence list. It focuses on permissions, adding objects and connectors, and configuring starting trigger conditions for a Sequence.

## User intent

* Open a Sequence design for editing
* Understand who is allowed to edit a Sequence design
* Start building a Sequence workflow in the workflow area
* Connect the Object class to workflow objects such as Task templates
* Configure Sequence starting conditions and trigger timing
* Understand the differences between Record created, Record updated, Record created or updated, and Sequence Activated triggers
* Know which kinds of record changes do or do not count as updates for starting a Sequence

## Key terms

* Sequence
* Sequence design
* Workflow area
* Object class
* Edit design
* Super admin
* Role
* Edit permission
* Sequencer tab
* Owner
* Task template
* connector
* trigger configuration
* starting condition
* When
* After
* timed trigger
* Record created
* Record updated
* Record created or updated
* Sequence Activated
* API Call
* Update object record Task type
* Update Record Actor
* Automatic task creation mechanism

## Terminology links

* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequence`)
* [Sequence design](/knowledgebase/terminology/#sequence-design)
* [Workflow area](/knowledgebase/terminology/#workflow-area)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Roles](/knowledgebase/terminology/#roles) (matched from `Role`)
* [Edit permission for Single sign on](/knowledgebase/terminology/#edit-permission-for-single-sign-on) (matched from `Edit permission`)
* [Sequencer tab](/knowledgebase/terminology/#sequencer-tab)

## Related topics

* Not provided.

## Prerequisites

* A Sequence has already been created
* The user has the required permissions: Super admin or a Role with Edit permission under the Sequencer tab
* The user is an Owner of the relevant Object class
* Basic familiarity with Object classes, Task templates, and workflow editing

## Not covered

* Detailed Sequence navigation and menus (the page refers elsewhere for this)
* How to create a Sequence initially
* Full details of adding further conditions beyond the examples shown
* Broader workflow design patterns outside initial trigger setup
* Configuration of task templates beyond the note that only Automatic ones are available

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequences/editing-a-sequence---properties/index.agent.md
---
# Agent guide: Editing a Sequence - Properties

* **Page path:** `system-configuration/sequences/editing-a-sequence---properties/index.md`
* **Page type:** how-to

## What this page is about

This page explains how to edit the properties of an existing Sequence, including which fields can be changed, how to manage default task assignees, and how saving/cancel behavior works. It also clarifies access requirements for editing any part of a Sequence.

## User intent

* Find how to open the Edit properties page for a Sequence
* Understand who is allowed to edit Sequence properties
* Learn which Sequence properties are editable versus non-editable
* Change a Sequence name or description within allowed restrictions
* Add or remove default task assignees for a Sequence
* Understand whether changes are saved automatically or require manual saving
* Know what happens when leaving the page with unsaved changes

## Key terms

* Sequence
* Edit properties
* Properties
* Design
* Super admin
* Role
* Edit permission
* Sequencer tab
* Sequence Name
* Description
* Object class
* Default task assignees
* Manage default task assignees
* in place editing
* Unsaved changes will be lost warning modal

## Terminology links

* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequence`)
* [Edit properties](/knowledgebase/terminology/#edit-properties)
* [Properties](/knowledgebase/terminology/#properties)
* [Sequence design](/knowledgebase/terminology/#sequence-design) (matched from `Design`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Roles](/knowledgebase/terminology/#roles) (matched from `Role`)
* [Edit permission for Single sign on](/knowledgebase/terminology/#edit-permission-for-single-sign-on) (matched from `Edit permission`)
* [Sequencer tab](/knowledgebase/terminology/#sequencer-tab)

## Related topics

* Editing a Sequence - Design

## Prerequisites

* Access to the Sequences list
* A Super admin account type or a Role with Edit permission enabled under the Sequencer tab
* An existing Sequence to edit

## Not covered

* How to create a Sequence
* How to edit Sequence design in detail
* How Roles or Sequencer permissions are configured
* Rules for task completion beyond the statement that removed default task assignees can no longer complete tasks created from the Sequence

---

---
url: >-
  /knowledgebase-agent-guides/administration/communication/editing-a-single-sign-on-setting/index.agent.md
---
# Agent guide: Editing a Single sign-on setting

* **Page path:** `administration/communication/editing-a-single-sign-on-setting/index.md`
* **Page type:** how-to

## What this page is about

This page explains how to edit an existing Single sign on setting, including who has permission and which fields can or cannot be changed. It also describes validation rules, save/cancel behavior, and role assignment for automatically created users.

## User intent

* Check who can edit a Single sign on setting
* Open the edit screen for an existing Single sign on setting
* Understand which SSO fields are editable, mandatory, or read-only
* Learn what happens when mandatory fields are empty or duplicate names are used
* Edit the Automatically create user option and assign roles to created users
* Understand cancel behavior and the unsaved changes warning

## Key terms

* Single sign on setting
* Super admin
* Create/Edit permission
* Edit permission
* Administration tab
* Name
* Enabled
* Single sign on provider
* Tenant ID
* Client ID
* Client secret
* Redirect URI
* Automatically create user
* Role to assign to created user
* mandatory field
* Save
* Cancel
* Unsaved changes will be lost

## Terminology links

* [Single sign on settings](/knowledgebase/terminology/#single-sign-on-settings) (matched from `Single sign on setting`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Create/Edit permission for Single sign on](/knowledgebase/terminology/#createedit-permission-for-single-sign-on) (matched from `Create/Edit permission`)
* [Edit permission for Single sign on](/knowledgebase/terminology/#edit-permission-for-single-sign-on) (matched from `Edit permission`)
* [Administration tab of System permissions](/knowledgebase/terminology/#administration-tab-of-system-permissions) (matched from `Administration tab`)
* [Enabled switch](/knowledgebase/terminology/#enabled-switch) (matched from `Enabled`)
* [Single sign on provider](/knowledgebase/terminology/#single-sign-on-provider)
* [Tenant ID](/knowledgebase/terminology/#tenant-id)

## Related topics

* Not provided.

## Prerequisites

* Access to an existing Single sign on setting
* A Super admin account type or a Role with Create/Edit or Edit permission for Single sign on under the Administration tab

## Not covered

* Creating a new Single sign on setting
* Deleting a Single sign on setting
* Changing the Single sign on provider
* Editing the Redirect URI
* Detailed steps for establishing the provider connection
* How Object class Permission sets or Task assignee setup works beyond the brief effect on new users

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/editing-a-standalone-form/index.agent.md
---
# Agent guide: Editing a Standalone Form

* **Page path:** `system-configuration/object-classes/editing-a-standalone-form/index.md`
* **Page type:** how-to

## What this page is about

This page explains who can edit a standalone form and how to edit it from an object class’s Forms tab. It also outlines what can be changed, how preview/revert/cancel behave, and the effect of saved changes on active versus newly opened forms.

## User intent

* Find out which users are permitted to edit a standalone form
* Open an existing standalone form for editing
* Disable a form or disable its submit button
* Rename a form and understand naming constraints
* Change or remove the post-submission redirect
* Modify form layout, sections, fields, instructions, and conditional logic
* Preview changes before saving
* Revert unsaved changes or cancel editing
* Understand when saved changes take effect

## Key terms

* standalone form
* object class
* Forms tab
* Super admin
* Config admin
* Role
* permission set
* owner of the object class
* Disabled status
* Redirect
* default confirmation
* Disable Submit
* conditional logic
* Required option
* Read only option
* Preview
* Revert
* Cancel

## Terminology links

* [standalone forms](/knowledgebase/terminology/#standalone-forms) (matched from `standalone form`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [Forms tab](/knowledgebase/terminology/#forms-tab)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Config admin account type](/knowledgebase/terminology/#config-admin-account-type) (matched from `Config admin`)
* [Roles](/knowledgebase/terminology/#roles) (matched from `Role`)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `permission set`)
* [Owner of the Object class](/knowledgebase/terminology/#owner-of-the-object-class)

## Related topics

* Not provided.

## Prerequisites

* Access to the relevant object class
* Permissions to edit the object class or form
* Basic familiarity with the Forms tab and object classes

## Not covered

* How to create a standalone form from scratch
* How to host or embed the form outside the application beyond a warning to remove links when disabling
* Detailed behavior of landing page Elements or third-party iframe integrations
* General object class administration beyond form editing

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/task-group-templates/editing-a-task-group-template/index.agent.md
---
# Agent guide: Editing a Task group template

* **Page path:** `system-configuration/task-group-templates/editing-a-task-group-template/index.md`
* **Page type:** how-to

## What this page is about

Explains who can edit a Task group template and what changes are allowed in the edit screen. It also describes different editing rules depending on whether the template contains only Self contained form type Task templates or includes Update object record type Task templates.

## User intent

* Find out whether I have permission to edit a Task group template
* Open a Task group template in the edit screen
* Change the name or description of a Task group template
* Understand when Object classes can be added or removed
* Understand how editing affects existing Tasks already created for Records
* Learn the restrictions for templates containing Update object record type Task templates
* Know the system limit for total Task group templates

## Key terms

* Task group template
* Super admin
* Edit Task group templates permission
* Task configuration tab
* Edit screen
* Name
* Description
* Object classes
* Task templates
* Self contained form type
* Update object record type
* Records
* Actions menu

## Terminology links

* [Task Group Templates](/knowledgebase/terminology/#task-group-templates) (matched from `Task group template`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Edit Task group templates permission](/knowledgebase/terminology/#edit-task-group-templates-permission)
* [Task configuration tab](/knowledgebase/terminology/#task-configuration-tab)
* [Edit screen](/knowledgebase/terminology/#edit-screen)
* [Description](/knowledgebase/terminology/#description)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [Task templates](/knowledgebase/terminology/#task-templates)

## Related topics

* Not provided.

## Prerequisites

* Access to the system with either a Super admin account type or a Role that has the Edit Task group templates permission enabled under Task configuration
* Basic understanding of Task group templates, Task templates, Object classes, and Records

## Not covered

* How to create a Task group template
* How to delete a Task group template
* How to configure Task templates in detail
* How permissions or Roles are set up
* Any workflow beyond editing name, description, Object classes, and included Task templates

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/task-templates/editing-a-task-template/index.agent.md
---
# Agent guide: Editing a Task template

* **Page path:** `system-configuration/task-templates/editing-a-task-template/index.md`
* **Page type:** how-to

## What this page is about

This page explains who can edit a Task template, how to open the edit screen, which fields can and cannot be changed, and the effect of saving changes. It also warns that edits only affect future Tasks created from the template.

## User intent

* Find out whether I have permission to edit a Task template
* Open the edit screen for a Task template
* Understand which Task template fields are editable
* Learn which fields are locked and cannot be changed
* Understand how Response form elements can be amended
* Avoid breaking workflows when changing fields used in Sequence triggers
* Know whether edits affect existing Tasks or only newly created Tasks

## Key terms

* Task template
* Super admin
* Edit Task templates permission
* Task configuration tab
* Edit screen
* Actions menu
* Task template Name
* Description
* Response form
* Sequence trigger
* Input type
* Single select
* Text field
* Numeric field
* Required value
* File upload field
* Lifecycle and expiry
* Task type
* Task creation mechanism
* Object class
* Update objects records
* Field type

## Terminology links

* [Task templates](/knowledgebase/terminology/#task-templates) (matched from `Task template`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Edit Task templates permission](/knowledgebase/terminology/#edit-task-templates-permission)
* [Task configuration tab](/knowledgebase/terminology/#task-configuration-tab)
* [Edit screen](/knowledgebase/terminology/#edit-screen)
* [Actions menu](/knowledgebase/terminology/#actions-menu)
* [task template names](/knowledgebase/terminology/#task-template-names) (matched from `Task template Name`)
* [Description](/knowledgebase/terminology/#description)

## Related topics

* Not provided.

## Prerequisites

* Access as a Super admin or a Role with the Edit Task templates permission enabled under the Task configuration tab
* Basic familiarity with Task templates and Response forms

## Not covered

* How to create a new Task template
* How to delete a Task template
* How to change disabled properties such as Task type, Task creation mechanism, Object class, or Response form Field type
* Detailed setup of Sequence triggers
* How to amend existing Tasks already created from a template

---

---
url: >-
  /knowledgebase-agent-guides/administration/user-groups/editing-a-user-group/index.agent.md
---
# Agent guide: Editing a User group

* **Page path:** `administration/user-groups/editing-a-user-group/index.md`
* **Page type:** how-to

## What this page is about

This page explains who can edit a User group, how they access it, and what changes they can make to group details, members, and owners. It also describes list filters, available actions, and account-type-based limitations.

## User intent

* Find out who is allowed to edit a User group
* Understand what Super admins, Config Admin owners, and Internal owners can do
* Learn how to open a User group page
* Edit a group name or description
* Manage User group members and owners
* Promote members to owners or demote owners to members
* Add or remove users from a group, including bulk member actions
* Understand filter options such as Members, Non members, Owners, and all Users
* Know what non-owners can view but not edit
* Troubleshoot why a user is not visible in the member lists

## Key terms

* User group
* Super admin
* Config Admin account
* Internal account type
* User group owner
* Member
* Owners filter
* Members filter
* Non members filter
* Actions menu
* bulk actions
* filter editor
* group description
* toast confirmation message
* User group permissions

## Terminology links

* [User Groups](/knowledgebase/terminology/#user-groups) (matched from `User group`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Config Admin account](/knowledgebase/terminology/#config-admin-account)
* [Internal account type](/knowledgebase/terminology/#internal-account-type)
* [User group Owner](/knowledgebase/terminology/#user-group-owner)
* [Members](/knowledgebase/terminology/#members) (matched from `Member`)
* [Owners](/knowledgebase/terminology/#owners) (matched from `Owners filter`)
* [Members filter](/knowledgebase/terminology/#members-filter)

## Related topics

* User Group Permissions
* using the list page filter editor

## Prerequisites

* Access to the administration area and a User group
* An account type with sufficient rights to edit or manage the group
* Basic understanding of User groups, members, and owners

## Not covered

* Detailed instructions for User Group Permissions; the page refers to another article
* General creation of User groups
* Detailed behavior of the list page filter editor beyond a reference link
* Other administration features outside User group editing

---

---
url: >-
  /knowledgebase-agent-guides/administration/elements/editing-an-element/index.agent.md
---
# Agent guide: Editing an Element

* **Page path:** `administration/elements/editing-an-element/index.md`
* **Page type:** how-to

## What this page is about

Explains how Super admin users can edit an existing Element in Catalyst and which Element properties are editable versus fixed. It also clarifies that Package Management fields cannot be changed and that functional or visual changes require creating a new Element from updated files.

## User intent

* Find out who can edit an Element
* Open the edit page for an Element from the Actions menu
* Understand which Element fields can be changed
* Change an Element's name, description, or availability
* Disable or enable an Element
* Learn what cannot be edited on an Element
* Understand when a new Element must be created instead of editing the existing one

## Key terms

* Element
* Super admin
* Actions menu
* Package Management
* Element name
* Description
* Available Use
* Disable/Enable
* Git repository
* Catalyst system
* system forms

## Terminology links

* [Elements](/knowledgebase/terminology/#elements) (matched from `Element`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Actions menu](/knowledgebase/terminology/#actions-menu)
* [Package Management section](/knowledgebase/terminology/#package-management-section) (matched from `Package Management`)
* [Description](/knowledgebase/terminology/#description)
* [Available Use](/knowledgebase/terminology/#available-use)
* [Disable/Enable](/knowledgebase/terminology/#disableenable)
* [Git repository](/knowledgebase/terminology/#git-repository)

## Related topics

* Not provided.

## Prerequisites

* Super admin account type
* Access to the Elements list
* Basic understanding of Elements and system forms

## Not covered

* How to create a new Element
* How to delete an Element
* How to modify an Element's underlying files or Git repository contents
* Detailed steps for package development or versioning
* Using the future Disable option from the Actions menu

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/editing-object-class-fields/index.agent.md
---
# Agent guide: Editing Object class fields

* **Page path:** `system-configuration/object-classes/editing-object-class-fields/index.md`
* **Page type:** how-to

## What this page is about

This page explains how to edit fields within an Object class, including who has permission and how different field changes affect existing records and system behavior. It focuses on editing field properties such as labels, defaults, identifiers, uniqueness, select options, and validation rules.

## User intent

* Find out who can edit Object class fields
* Edit an existing Object class field from the fields list
* Understand which field properties can and cannot be changed
* Learn how label changes propagate across the system
* Understand the effect of changing default values on existing versus new records
* Change which field is used as the identifier
* Determine when the Unique value flag can be added or removed
* Add, delete, or rename select options safely
* Understand how validation changes affect existing records
* Learn the impact of editing constraints for text, numeric, multi select, document, and user fields

## Key terms

* Object class
* fields list
* Edit field panel
* Label
* Alias
* Type
* Default value
* Use as identifier
* Autologyx ID
* Unique value
* select options
* Validation
* Max length
* Min value
* Max value
* Min selections
* Max selections
* Document field
* User field
* Permission set
* Role
* Config admin
* Super admin
* Owner

## Terminology links

* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Fields list](/knowledgebase/terminology/#fields-list)
* [Edit field panel](/knowledgebase/terminology/#edit-field-panel)
* [Label](/knowledgebase/terminology/#label)
* [Alias](/knowledgebase/terminology/#alias)
* [field types](/knowledgebase/terminology/#field-types) (matched from `Type`)
* [Default value](/knowledgebase/terminology/#default-value)
* [Use as identifier](/knowledgebase/terminology/#use-as-identifier)

## Related topics

* Not provided.

## Prerequisites

* Access to an existing Object class
* Appropriate permissions to edit Object class fields
* Basic familiarity with Object class field types and configuration

## Not covered

* Creating a new Object class
* Adding a new field in detail
* Detailed reference for all field types and attributes beyond a linked further-information page
* Broader data model or sequencer configuration outside field-edit impacts
* How to resolve broken sequence triggers beyond noting that deleted select options can break them

---

---
url: >-
  /knowledgebase-agent-guides/workspace/records/editing-object-records/index.agent.md
---
# Agent guide: Editing Object records

* **Page path:** `workspace/records/editing-object-records/index.md`
* **Page type:** how-to

## What this page is about

This page explains how to open and edit Object records from the Records list in Workspace. It also outlines inline editing behavior, validation warnings for Unique and Required fields, and the available side panel tabs in edit view.

## User intent

* Open an Object record for editing from the Records list
* Edit a record in the Create and edit view
* Understand how inline editing works
* Recognize and fix validation warnings for Unique fields
* Recognize and fix validation warnings for Required fields
* Use the side panel tabs while viewing or editing a record
* Understand who can manage record access and owners
* View activity history for a record

## Key terms

* Object record
* Workspace
* Records
* Tasks
* Records List
* Actions menu
* Open
* Create and edit view
* Object class Display tab
* Card view
* inline editing
* Unique field
* Required field
* side panel
* Summary Information
* Record access
* Object Record Owner
* Super admin
* Object class Owners
* Activity log

## Terminology links

* [Object records](/knowledgebase/terminology/#object-records) (matched from `Object record`)
* [Workspace](/knowledgebase/terminology/#workspace)
* [Tasks](/knowledgebase/terminology/#tasks)
* [Records list](/knowledgebase/terminology/#records-list)
* [Actions menu](/knowledgebase/terminology/#actions-menu)
* [Open](/knowledgebase/terminology/#open)
* [Create and edit view](/knowledgebase/terminology/#create-and-edit-view)
* [Object class Display tab](/knowledgebase/terminology/#object-class-display-tab)

## Related topics

* Not provided.

## Prerequisites

* Access to Workspace
* Permissions to view Records and possibly Tasks
* An existing Object record to edit
* Basic familiarity with the Records list and Object class display configuration

## Not covered

* How to create a new Object record
* How to configure the Create and edit view or Object class Display tab
* How to configure Unique or Required field rules
* Detailed task workflow instructions
* How permissions are assigned or managed generally
* How to disable or configure side panel options

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/relational-modeller/editing-the-relational-model/index.agent.md
---
# Agent guide: Editing the Relational model

* **Page path:** `system-configuration/relational-modeller/editing-the-relational-model/index.md`
* **Page type:** how-to

## What this page is about

This page explains how to edit the relational model in System configuration using the Relational modeller. It focuses on what can be moved or deleted, why some object classes are locked, and the model size limits that affect editing.

## User intent

* Open the Relational modeller and view existing relationships
* Understand which object classes can be moved or deleted
* Interpret padlock and bin icons on the model canvas
* Move an object class to a new parent or make it a root parent
* Remove a root parent object class by first moving its children
* Understand why some relationships cannot be changed when records already exist
* Check model limits for root parents, children per parent, and depth
* Understand the effect of deleting a child object class on the parent create/edit view

## Key terms

* Relational modeller
* relational model
* object class
* root parent
* parent
* child object class
* descendent object classes
* canvas
* padlock icon
* bin icon
* relationship
* create/edit view
* sidebar
* model limits

## Terminology links

* [Relational modeller](/knowledgebase/terminology/#relational-modeller)
* [relational model](/knowledgebase/terminology/#relational-model)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [root parent object class](/knowledgebase/terminology/#root-parent-object-class) (matched from `root parent`)
* [parent object class](/knowledgebase/terminology/#parent-object-class) (matched from `parent`)
* [descendent object classes](/knowledgebase/terminology/#descendent-object-classes)
* [Sequence canvas](/knowledgebase/terminology/#sequence-canvas) (matched from `canvas`)
* [padlock icon](/knowledgebase/terminology/#padlock-icon)

## Related topics

* Not provided.

## Prerequisites

* Access to the System configuration section
* Basic understanding of object classes and parent-child relationships in the relational model
* Awareness that permissions on who can create or edit the relational model are explained in a separate article

## Not covered

* Who is allowed to create or edit the relational model, beyond pointing to another article
* How to create a new relational model from scratch
* Detailed steps for adding new object classes beyond stated limits
* Any configuration outside the Relational modeller
* Error message wording in full

---

---
url: >-
  /knowledgebase-agent-guides/administration/user-groups/editing-user-group-permissions/index.agent.md
---
# Agent guide: Editing User group Permissions

* **Page path:** `administration/user-groups/editing-user-group-permissions/index.md`
* **Page type:** how-to

## What this page is about

This page explains who can edit User group permissions and how to edit permission sets or manage assignees within a User group. It also notes limits and what changes take effect immediately.

## User intent

* Find out who is allowed to edit User group permissions
* Edit an existing User group permission set
* Understand what View, Edit, and Delete permissions do
* Remove users or user groups from a permission set
* Learn what happens after assignees are removed
* Check limits on permission sets, users, and user groups

## Key terms

* User group
* permission sets
* Owners
* Everyone
* Members
* custom permission sets
* Super admin
* Config Admin account
* Internal account type
* User group Owner
* Manage assignees
* View
* Edit
* Delete
* View Users permission

## Terminology links

* [User Groups](/knowledgebase/terminology/#user-groups) (matched from `User group`)
* [Permission Sets](/knowledgebase/terminology/#permission-sets)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Owners`)
* [Everyone](/knowledgebase/terminology/#everyone)
* [Members](/knowledgebase/terminology/#members)
* [custom permission sets](/knowledgebase/terminology/#custom-permission-sets)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Config Admin account](/knowledgebase/terminology/#config-admin-account)

## Related topics

* User Group Permissions

## Prerequisites

* Basic understanding of User groups and permission sets
* Access to a User group as a permitted editor
* Knowledge of the User group URL if using an Internal account type owner

## Not covered

* How to add users or user groups to a permission set
* A full overview of User group permissions beyond the referenced overview page
* Editing the Owners permission set, which is not modifiable
* General user or role administration outside User groups

---

---
url: /knowledgebase-agent-guides/administration/elements/index.agent.md
---
# Agent guide: Elements

* **Page path:** `administration/elements/index.md`
* **Page type:** explanation

## What this page is about

This page is an overview for the Elements section. It points readers to subtopics covering what elements are, how to create and edit them, and how they work on forms.

## User intent

* Understand what elements are and what they can be used for
* Learn how to create an element
* Learn how to edit an existing element
* Understand how to configure an element
* See how an element works on a form

## Key terms

* Elements
* Configuring an Element
* Editing an Element
* Create an Element
* Form

## Terminology links

* [Elements](/knowledgebase/terminology/#elements)
* [Configuring An Element](/knowledgebase/terminology/#configuring-an-element)
* [Editing An Element](/knowledgebase/terminology/#editing-an-element)
* [Create An Element](/knowledgebase/terminology/#create-an-element)
* [Forms tab](/knowledgebase/terminology/#forms-tab) (matched from `Form`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with forms in the platform

## Not covered

* Detailed instructions for configuration, editing, or creation
* Specific element types or examples
* Advanced form behavior beyond the linked subtopics

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/formbuilder-components/elements/index.agent.md
---
# Agent guide: Elements

* **Page path:** `record-and-task-forms/formbuilder-components/elements/index.md`
* **Page type:** explanation

## What this page is about

This page explains what Elements are in Catalyst forms, who can create or edit them, where they can be used, and how to add and configure them in forms. It also points users to separate knowledgebase documentation for broader explanations, use cases, and code samples.

## User intent

* Understand what Elements are in the context of Catalyst forms
* Find out which account types and permissions are required to create or edit Elements
* Learn where Elements can be enabled and used across forms and views
* Add an Element to a form in Formbuilder
* Configure an Element's display properties such as height and colours
* Understand permission differences between Super admin and Config Admin users when using Elements

## Key terms

* Elements
* Super admin
* Config Admin
* Permission set
* Object classes
* Landing page
* Create/edit view
* Summary view
* Standalone forms
* Element component
* Canvas
* Zuva Document Viewer Element

## Terminology links

* [Elements](/knowledgebase/terminology/#elements)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Config admin account type](/knowledgebase/terminology/#config-admin-account-type) (matched from `Config Admin`)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `Permission set`)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [Landing page](/knowledgebase/terminology/#landing-page)
* [create/edit view](/knowledgebase/terminology/#createedit-view)
* [summary view](/knowledgebase/terminology/#summary-view)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst record and task forms
* Understanding of account types, roles, and permission sets
* Knowledge of Object classes and Formbuilder basics

## Not covered

* Detailed Element use cases and code samples
* Full conceptual documentation for each Element type
* Step-by-step landing page editing instructions
* Detailed configuration options for specific Element types beyond general display properties

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.5/elements/index.agent.md
---
# Agent guide: Elements

* **Page path:** `release-notes/release-notes-1.5/elements/index.md`
* **Page type:** release-notes

## What this page is about

An overview of Elements in Autologyx Catalyst, a feature for securely installing and displaying selected third-party content on summary panels or landing pages. It explains basic installation inputs, placement, and example use cases for embedded content.

## User intent

* Understand what Elements are and what they enable in the platform
* Learn the high-level installation flow for an Element from a repository
* Identify what files are required to supply an Element
* See where Elements can be placed in the UI
* Explore example use cases such as widgets, charts, maps, diagrams, web pages, and third-party resources

## Key terms

* Elements
* Autologyx Catalyst
* third-party content
* repository credentials
* secure validation
* download and installation
* summary panel
* landing page
* customizable parameters
* interactive widgets
* dynamic charts
* maps
* web pages

## Terminology links

* [Elements](/knowledgebase/terminology/#elements)
* [Catalyst](/knowledgebase/terminology/#catalyst) (matched from `Autologyx Catalyst`)
* [summary panel](/knowledgebase/terminology/#summary-panel)
* [Landing page](/knowledgebase/terminology/#landing-page)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the Autologyx Catalyst platform
* Access credentials to the repository where the Element is stored
* Awareness of summary panels or landing pages in the platform

## Not covered

* Detailed step-by-step installation instructions
* Exact names or formats of the two required files
* Technical configuration, security model, or validation details
* Development guidance for creating Elements
* Troubleshooting, limitations, or compatibility information

---

---
url: >-
  /knowledgebase-agent-guides/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/index.agent.md
---
# Agent guide: Embedding Model Actors

* **Page path:** `applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/index.md`
* **Page type:** explanation

## What this page is about

This page is a placeholder for documentation about Embedding Model Actors. It indicates the content is still being prepared and provides no substantive guidance yet.

## User intent

* Check whether documentation for Embedding Model Actors is available
* Determine the current status of the Embedding Model Actors page

## Key terms

* Embedding Model Actors
* Status
* being prepared
* Autologyx Classification
* Unrestricted
* Public

## Terminology links

* [Embedding Model Actors](/knowledgebase/terminology/#embedding-model-actors)
* [Autologyx Classification](/knowledgebase/terminology/#autologyx-classification)
* [Unrestricted, Public](/knowledgebase/terminology/#unrestricted-public) (matched from `Unrestricted`)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Definition or purpose of Embedding Model Actors
* Usage instructions
* Configuration details
* API examples
* Operational behavior
* Integration guidance

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.14/error-handling-reliability/index.agent.md
---
# Agent guide: Error Handling & Reliability

* **Page path:** `release-notes/release-notes-1.14/error-handling-reliability/index.md`
* **Page type:** release-notes

## What this page is about

This release note summarizes improvements to error handling, validation, and reliability across the platform. It highlights clearer permission errors, real-time Loop actor validation, and more detailed API error reporting for Object Class relation removal.

## User intent

* Understand what changed in error messaging in release 1.14
* Learn why sequence creation may fail for Config Admin users without sufficient permissions
* See how Loop actor configuration is now validated
* Find out when a Loop actor cannot be saved due to JSON Path issues
* Understand new warnings shown for misconfigured actors on the Sequence canvas
* Learn what API error details are returned when removing Object Class relations fails
* Identify dependency types blocking Object Class relation removal

## Key terms

* error handling
* reliability
* permissions feedback
* Config Admin
* sequence creation
* Object Class owner
* Loop actor
* JSON Path
* iterable array
* real-time validation
* Sequence canvas
* warning icon
* Object Class relations
* 400 Bad Request
* Sequences
* Document Templates
* Records
* dependency validation

## Terminology links

* [Error Handling Reliability](/knowledgebase/terminology/#error-handling-reliability) (matched from `error handling`)
* [Config admin account type](/knowledgebase/terminology/#config-admin-account-type) (matched from `Config Admin`)
* [Object class Owners](/knowledgebase/terminology/#object-class-owners) (matched from `Object Class owner`)
* [Loop actors](/knowledgebase/terminology/#loop-actors) (matched from `Loop actor`)
* [JSON Path field](/knowledgebase/terminology/#json-path-field) (matched from `JSON Path`)
* [Sequence canvas](/knowledgebase/terminology/#sequence-canvas)
* [warning icon](/knowledgebase/terminology/#warning-icon)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object Class relations`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with sequences and actors
* Understanding of Config Admin permissions and Object Classes
* Awareness of JSON Path usage in workflow configuration
* Basic knowledge of API error responses such as 400 Bad Request

## Not covered

* Exact text of the new permission error message
* Step-by-step instructions for fixing permission issues
* General Loop actor behavior beyond the new validation
* Validation rules for Loop actors configured after a Document Picker actor
* Detailed API endpoints or request examples for removing Object Class relations
* Broader reliability changes outside the listed improvements

---

---
url: /api-agent-guides/event-history/index.agent.md
---
# Agent guide: Event History API Reference

* **Page path:** `event-history/index.md`
* **Page type:** explanation

## What this page is about

Overview of the Event History API reference for the Event History microservice. It explains the main technical areas covered: tenant setup, file upload/handling, event creation/querying, and operational endpoints like healthcheck and version.

## User intent

* Understand what the Event History microservice is used for
* Find where to initialise or delete tenant-specific Event History storage
* Find APIs for generating presigned upload URLs and handling files tied to events
* Find APIs to create, ingest, retrieve, or query historical event records
* Learn the typical workflow for storing events with optional file content
* Identify the intended audience and support boundaries for this API section
* Locate operational reference endpoints for service health or deployed version

## Key terms

* Event History microservice
* historical event data
* tenant management
* tenant initialisation
* tenant deletion
* tenant-specific storage
* file handling
* presigned upload URLs
* event storage
* event retrieval
* event records
* event ingestion
* associated file content
* history endpoints
* Healthcheck
* Version

## Terminology links

* No matched terminology links found.

## Related topics

* Not provided.

## Prerequisites

* Internal platform or engineering context for Autologyx/Catalyst services
* Basic understanding of tenants, APIs, and file upload workflows
* Need to work on event ingestion, storage, retrieval, or service operations

## Not covered

* General-purpose external Catalyst integration surface
* General support coverage for external users
* Detailed endpoint definitions on this overview page
* Non-technical business-facing usage guidance

---

---
url: /api-agent-guides/event-history/resources/events/index.agent.md
---
# Agent guide: Events

* **Page path:** `event-history/resources/events.md`
* **Page type:** reference

## What this page is about

Reference documentation for the Event History API "Events" endpoints used to store and retrieve historical activity for a client environment. It describes internal/platform-focused endpoints for creating events, listing/filtering paginated history events, and generating presigned file download URLs.

## User intent

* Understand which Events endpoints exist in the Event History API
* Create a history event through the EventBridge/Lambda/Event History API flow
* Retrieve paginated history events for a client
* Learn supported response fields for event records
* Filter history events by datetime, source type, source ID, and field ID
* Understand default sorting behavior for event results
* Generate a presigned S3 download URL for an event file
* Check required headers/permissions and possible error cases

## Key terms

* Event History API
* History Event
* ClickHouse
* tenant entry
* client-specific database
* AWS EventBridge
* Lambda
* /api/event-bridge/create-event
* /api/history/events
* /api/history/events/{event\_id}/file
* paginated list
* event id
* event datetime
* event type
* event data
* source type
* source id
* presigned URL
* S3
* filtering
* sorting
* UUID v4

## Terminology links

* [Event History API](/api/terminology/#event-history-api)
* [History Events](/api/terminology/#history-events) (matched from `History Event`)
* [clickhouse default database](/api/terminology/#clickhouse-default-database) (matched from `ClickHouse`)
* [event type](/api/terminology/#event-type)
* [event data](/api/terminology/#event-data)
* [source type](/api/terminology/#source-type)
* [source id](/api/terminology/#source-id)
* [presigned url](/api/terminology/#presigned-url)

## Related topics

* Files
* Tenants

## Prerequisites

* Familiarity with internal Autologyx platform architecture
* Understanding of client/tenant resolution in Event History
* Knowledge of API headers, authentication, and permissions
* Basic understanding of pagination and standard API filtering predicates
* Awareness that this is an internal service-level API, not the main external Catalyst integration surface

## Not covered

* General-purpose external Catalyst integration usage
* Detailed support guidance beyond contacting Customer Success
* Complete definitions of standard predicates beyond referencing the ALX API standards Developers guide
* Full event-data schemas for every event type
* Controllable/custom sorting options beyond the fixed descending event datetime order

---

---
url: >-
  /knowledgebase-agent-guides/administration/elements/everything-you-need-to-create-an-element/index.agent.md
---
# Agent guide: Everything you need to create an Element

* **Page path:** `administration/elements/everything-you-need-to-create-an-element/index.md`
* **Page type:** explanation

## What this page is about

This page explains the prerequisites, required repository files, key configuration fields, and Catalyst import steps needed to create an Element. It also highlights repository access token requirements and file structure expectations that must be met for installation to succeed.

## User intent

* Understand what must be in place before creating an Element
* Learn the required Git repository setup and access needed for Elements
* Know which files are mandatory for an Element project
* Understand important JSON config fields and parameter requirements
* Import a new Element into Catalyst from a Git repository
* Avoid common installation failures caused by missing files, bad structure, or expired tokens

## Key terms

* Element
* Super admin account
* Git repository URL
* JSON configuration
* use cases
* development source code repository
* finalised code repository
* required files
* file structure
* Version
* Logo
* Publisher
* Publisher URL
* Parameters
* enum
* React
* assets folder
* Administration / Elements
* +Create
* Package Management
* Clone with HTTPS
* Access Tokens
* required scopes
* Git repository username
* Git repository token
* Import

## Terminology links

* [Elements](/knowledgebase/terminology/#elements) (matched from `Element`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin account`)
* [Git repository URL](/knowledgebase/terminology/#git-repository-url)
* [Publisher](/knowledgebase/terminology/#publisher)
* [Element parameters](/knowledgebase/terminology/#element-parameters) (matched from `Parameters`)
* [Enum](/knowledgebase/terminology/#enum)
* [+Create button](/knowledgebase/terminology/#create-button) (matched from `+Create`)
* [Package Management section](/knowledgebase/terminology/#package-management-section) (matched from `Package Management`)

## Related topics

* Not provided.

## Prerequisites

* Super admin account type
* Access to a Git repository and permissions to download/manage files
* Familiarity with JSON configuration syntax and structure
* Understanding of the intended use cases, forms, pages, and required functionality for the Element

## Not covered

* Detailed JSON schema or full config file reference
* Complete code examples for the required files
* How to develop the Element’s React source code
* Detailed explanation of all repository provider token settings beyond linked external docs
* General Catalyst administration beyond creating/importing Elements

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/explanation-of-class-permissions/index.agent.md
---
# Agent guide: Explanation of Class Permissions

* **Page path:** `system-configuration/object-classes/explanation-of-class-permissions/index.md`
* **Page type:** explanation

## What this page is about

This page explains the meaning and effects of each option in an Object class's Class permissions set. It covers permissions for the object class itself, all records in the class, and all tasks assigned to those records, including default owner behavior and auto-enabled dependencies.

## User intent

* Understand what each Class permission allows a user to do
* Determine how Object class, Object records, and Tasks permissions differ
* Learn which permissions are automatically enabled by others
* Work out what access a user will have in the Workspace or System Configuration
* Understand how default Owner permissions behave
* Check how Class permissions interact with Record permissions
* Know platform limits for permission sets, owners, and assignees

## Key terms

* Class permissions
* Record permissions
* Object class
* Object records
* Tasks
* Permissions tab
* Owner
* Assignee
* Permission set
* Super admin
* View
* Edit
* Delete
* List
* Create
* View all
* Edit all
* Delete all
* Complete all
* Assign all

## Terminology links

* [Class permissions](/knowledgebase/terminology/#class-permissions)
* [Record Permission Sets](/knowledgebase/terminology/#record-permission-sets) (matched from `Record permissions`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Object records](/knowledgebase/terminology/#object-records)
* [Tasks](/knowledgebase/terminology/#tasks)
* [Permissions tab](/knowledgebase/terminology/#permissions-tab)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Owner`)
* [Assignees](/knowledgebase/terminology/#assignees) (matched from `Assignee`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Object classes and records
* Familiarity with Edit mode and the Permissions tab
* Awareness of Owners, Assignees, and permission sets
* General knowledge of Workspace and System Configuration areas

## Not covered

* Detailed explanation of Record permissions options beyond how Class permissions may override them
* Step-by-step instructions for configuring permission sets
* General account type or role management except brief mentions of Owner and Super admin capabilities
* Detailed task template, sequence, form, or document template configuration

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/explanation-of-record-permissions/index.agent.md
---
# Agent guide: Explanation of Record Permissions

* **Page path:** `system-configuration/object-classes/explanation-of-record-permissions/index.md`
* **Page type:** explanation

## What this page is about

Explains the meaning of each option in an Object class Record permissions set, covering both object-record permissions and task permissions tied to records. It also clarifies defaults for record owners and dependencies on Class permission/Object class/List.

## User intent

* Understand what each Record permission allows a user to do
* Determine how record-level permissions affect access to records and associated tasks
* Learn which permissions are automatically enabled when others are selected
* Understand default Record Owner permissions and their limitations
* Check what additional Class permission is needed for Record permissions to be useful
* Decide what permission set to grant roles such as a reviewer

## Key terms

* Permissions tab
* Class permissions
* Record permissions
* Record permission set
* Default owner permissions
* Record Owner
* Object class owner
* Super Admin account type
* Class permission/Object class/List
* Object record/View
* Object record/Edit
* Object record/Delete
* Tasks/Create
* Tasks/View all
* Tasks/Edit all
* Tasks/Complete all
* Tasks/Assign all
* Record access tab
* Task template
* Manual task creation mechanism
* PATCH API calls

## Terminology links

* [Permissions tab](/knowledgebase/terminology/#permissions-tab)
* [Class permissions](/knowledgebase/terminology/#class-permissions)
* [Record Permission Sets](/knowledgebase/terminology/#record-permission-sets) (matched from `Record permissions`)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `Record permission set`)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Record Owner`)
* [Object class Owners](/knowledgebase/terminology/#object-class-owners) (matched from `Object class owner`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type)
* [Record access tab](/knowledgebase/terminology/#record-access-tab)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Object classes and Edit mode
* Familiarity with users, roles, and account types such as Super Admin
* Awareness of records and tasks within an Object class
* For task visibility/usefulness, knowledge that Class permission/Object class/List is required

## Not covered

* How to grant ownership or assign a Record permission set from individual records
* Detailed explanation of Class permissions beyond the needed List permission
* General task template or sequence configuration steps
* Broader API usage beyond noting that Edit all permits PATCH updates to task due dates
* User-avatar display for Record permissions, which the page notes does not exist because access is granted from individual records

---

---
url: /knowledgebase-agent-guides/using-help-and-support/faqs/index.agent.md
---
# Agent guide: FAQs

* **Page path:** `using-help-and-support/faqs/index.md`
* **Page type:** faq

## What this page is about

A brief FAQs landing page that directs users to browse sections below. The visible FAQ listed is about granting View Users permission to Config Admins.

## User intent

* Find FAQ entries to answer common support questions
* Learn how to grant View Users permission to Config Admins

## Key terms

* FAQs
* View Users
* Permission
* Config Admins

## Terminology links

* [FAQs](/knowledgebase/terminology/#faqs)
* [View Users permission](/knowledgebase/terminology/#view-users-permission) (matched from `View Users`)
* [Class permissions](/knowledgebase/terminology/#class-permissions) (matched from `Permission`)
* [Config Admins](/knowledgebase/terminology/#config-admins)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with user roles and permissions in the product

## Not covered

* Detailed steps or answers to the FAQ topic are not provided in the visible text
* Other FAQ sections or support topics are not shown on this page

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/merge-fields/field-types-and-formatting/index.agent.md
---
# Agent guide: Field Types and Formatting

* **Page path:** `system-configuration/merge-fields/field-types-and-formatting/index.md`
* **Page type:** explanation

## What this page is about

This page lists supported merge field data types and shows the basic merge syntax for each. It also explains how to format merge field output by applying filters with pipe syntax.

## User intent

* Identify the correct merge field suffix for a specific field type
* Format date or datetime output in a merge field
* Provide fallback values when a field is empty
* Join or count values in a set field
* Transform text output with filters like upper, capitalize, or replace
* Understand what document, user, and group field outputs return

## Key terms

* merge field
* field type
* string
* integer
* float
* boolean
* enum
* set
* email
* phone
* date
* datetime
* time
* URL
* JSON
* document
* user field
* group field
* filter
* pipe syntax
* default
* join
* length
* upper
* capitalize
* replace

## Terminology links

* [merge fields](/knowledgebase/terminology/#merge-fields) (matched from `merge field`)
* [field types](/knowledgebase/terminology/#field-types) (matched from `field type`)
* [Integer](/knowledgebase/terminology/#integer)
* [Enum](/knowledgebase/terminology/#enum)
* [Set](/knowledgebase/terminology/#set)
* [Email](/knowledgebase/terminology/#email)
* [phone and e mail](/knowledgebase/terminology/#phone-and-e-mail) (matched from `phone`)
* [DateTime](/knowledgebase/terminology/#datetime)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with merge field syntax using {{ ... }}
* Knowing the record field names you want to reference

## Not covered

* How merge fields are created or configured
* Detailed behavior or formatting rules for every output example
* Comprehensive filter reference beyond the listed examples
* How aliases for user or group fields are defined
* Any broader templating language concepts outside the shown syntax

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.13/file-upload-component/index.agent.md
---
# Agent guide: File upload component

* **Page path:** `release-notes/release-notes-1.13/file-upload-component/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces the File upload component, a drag-and-drop module for Landing pages that lets users upload a ZIP of documents and automatically create records with files attached. It explains configuration options, user flow, processing behavior, limits, and integration with Catalyst automation.

## User intent

* Understand what the File upload component does
* Learn how administrators configure the component on a Landing page
* See how end users upload and process batches of documents
* Check ZIP file requirements and size limits
* Understand what happens during upload, scanning, validation, and record creation
* Learn how failed files and upload history are handled
* See how uploaded records integrate with Sequencer workflows and broader automation
* Assess whether the component fits high-volume document ingestion use cases

## Key terms

* File upload component
* Landing page
* drag and drop module
* Object class
* document type field
* ZIP archive
* record creation
* antivirus scan
* extraction and validation
* Failed files
* upload history
* background processing
* Sequencer workflow
* Catalyst automation

## Terminology links

* [File upload component](/knowledgebase/terminology/#file-upload-component)
* [Landing page](/knowledgebase/terminology/#landing-page)
* [drag and drop module](/knowledgebase/terminology/#drag-and-drop-module)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [document type fields](/knowledgebase/terminology/#document-type-fields) (matched from `document type field`)
* [record creation](/knowledgebase/terminology/#record-creation)
* [Failed files tab](/knowledgebase/terminology/#failed-files-tab) (matched from `Failed files`)
* [upload history](/knowledgebase/terminology/#upload-history)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Landing pages
* Familiarity with Object classes and document fields
* General awareness of Catalyst records and workflows

## Not covered

* Step-by-step UI instructions for administrators adding the component
* Detailed configuration fields or advanced settings beyond object class, document field, and header/description
* Supported file formats beyond documents in a ZIP
* Nested folder handling beyond stating subfolders are not allowed
* Troubleshooting procedures or error resolution steps
* Technical implementation details of security, indexing, or background job architecture

---

---
url: /api-agent-guides/websockets/resources/files/index.agent.md
---
# Agent guide: File Upload Events

* **Page path:** `websockets/resources/files.md`
* **Page type:** reference

## What this page is about

Reference documentation for the Catalyst WebSocket endpoint that manages Object Record file upload workflows. It explains how clients connect, request presigned upload URLs, report upload completion, and receive progress, monitoring, and error messages as backend processing continues.

## User intent

* Understand the WebSocket endpoint for Object Record file uploads
* Implement a client that connects to the upload workflow over WebSocket
* Request presigned upload URLs for single-part or multipart uploads
* Notify the backend when an upload or multipart upload has completed
* Handle server responses for presigned URLs, progress updates, and monitoring updates
* Interpret validation and processing errors returned by the endpoint

## Key terms

* WebSocket endpoint
* Object Records
* bidirectional communication
* presigned upload URL
* single-part upload
* multipart upload
* upload id
* temp upload id
* s3 key
* s3 upload id
* part urls
* chunk size
* total parts
* progress updates
* monitoring updates
* step name
* attempt
* ISO 8601 timestamp
* permissions
* authentication via query string parameter

## Terminology links

* [Object Records](/api/terminology/#object-records)
* [upload id](/api/terminology/#upload-id)
* [temp upload id](/api/terminology/#temp-upload-id)
* [s3 key](/api/terminology/#s3-key)
* [s3 upload id](/api/terminology/#s3-upload-id)
* [multipart presigned URLs](/api/terminology/#multipart-presigned-urls) (matched from `part urls`)
* [progress update](/api/terminology/#progress-update) (matched from `progress updates`)
* [monitoring update](/api/terminology/#monitoring-update) (matched from `monitoring updates`)

## Related topics

* Object Record Events
* Task Events

## Prerequisites

* Familiarity with WebSocket connections and message exchange
* Understanding of Object Records in Catalyst
* Knowledge of S3-style uploads, including presigned URLs and multipart uploads
* Ability to send and parse JSON messages
* Awareness of endpoint permissions and query-parameter-based authentication

## Not covered

* End-user workflow guidance; this is implementation reference material only
* General WebSocket concepts beyond the documented endpoint behavior
* Detailed schema for every possible monitoring update variant
* Business context for Object Record processing beyond upload, scanning, unpacking, and record creation
* Other Catalyst event endpoints except nearby related topics

---

---
url: /api-agent-guides/catalyst/resources/files/index.agent.md
---
# Agent guide: Files

* **Page path:** `catalyst/resources/files.md`
* **Page type:** reference

## What this page is about

This page documents the ALX file APIs for uploading temporary files, storing them in public storage, listing and deleting stored files, and downloading files from several sources. It also summarizes the relevant permissions, validation rules, limits, and common error responses.

## User intent

* Upload a file and get a temporary token
* Store an uploaded file permanently in public storage
* List files in public storage with pagination, sorting, and filtering
* Delete a file from public storage
* Understand which permissions are required for file actions
* Download a public file
* Download files attached to task responses or object record document fields
* Check validation rules such as filename requirement, allowed extensions, and max file size
* See typical API error responses for file operations

## Key terms

* temporary file
* token
* public storage
* store permission
* list permission
* delete permission
* Content Disposition header
* allowed file extensions
* max size 50 MB
* uuid
* meta.permissions
* pagination
* ordering
* filtering

## Terminology links

* [temporary file](/api/terminology/#temporary-file)
* [file token](/api/terminology/#file-token) (matched from `token`)
* [public storage](/api/terminology/#public-storage)
* [store permission](/api/terminology/#store-permission)
* [list permission](/api/terminology/#list-permission)
* [delete permission](/api/terminology/#delete-permission)
* [permissions](/api/terminology/#permissions) (matched from `meta.permissions`)
* [ordering](/api/terminology/#ordering)

## Related topics

* Limits
* Roles
* Security Rules

## Prerequisites

* Basic understanding of ALX API endpoints and authenticated requests
* Familiarity with role-based permissions
* Knowledge of sending binary request bodies and HTTP headers
* Awareness that uploaded temporary files are later referenced by token in compatible endpoints

## Not covered

* The detailed file upload technical design; it is only referenced externally
* How compatible endpoints consume uploaded file tokens beyond noting that they can
* Configuration details for allowed file extensions or build-specific public file limits
* Detailed permission-check endpoints, which are only referenced in outline form
* General ALX API filtering predicate rules, which are delegated to ALX API standards

---

---
url: /api-agent-guides/event-history/resources/files/index.agent.md
---
# Agent guide: Files

* **Page path:** `event-history/resources/files.md`
* **Page type:** reference

## What this page is about

This page documents the Event History API file-handling endpoint used to generate a presigned S3 upload URL before a history event references a file. It describes an internal platform workflow where files are uploaded through Event History service flow and then linked from related event records.

## User intent

* Understand how file uploads work for Event History events
* Generate a presigned S3 upload URL using the Files API
* Learn the required sequence before recording an event with an associated file
* Identify what the GET /api/files/upload endpoint returns
* Understand how tenant/client identification affects file key generation
* Check likely error cases for the file upload URL endpoint

## Key terms

* Files API
* Event History API
* presigned URL
* S3
* history event
* file id
* upload url
* client instance
* client ID header
* tenant
* UUID v4
* AWS credentials
* file key prefix

## Terminology links

* [Event History API](/api/terminology/#event-history-api)
* [presigned url](/api/terminology/#presigned-url)
* [History Events](/api/terminology/#history-events) (matched from `history event`)
* [file id](/api/terminology/#file-id)
* [client instance](/api/terminology/#client-instance)
* [Tenants](/api/terminology/#tenants) (matched from `tenant`)
* [file key prefix](/api/terminology/#file-key-prefix)

## Related topics

* Events
* Tenants

## Prerequisites

* Basic understanding of Event History event workflows
* Knowledge of S3 presigned URL uploads
* Access to required authorization and API key headers
* Awareness of the tenant/client instance model

## Not covered

* Detailed request header names or exact permission value
* Complete response example payload
* Specific error response codes and messages for each listed error
* How to create or manage history events themselves
* External/general-purpose Catalyst integration usage
* General S3 or AWS setup beyond presigned URL generation

---

---
url: /knowledgebase-agent-guides/finding-your-way-around/index.agent.md
---
# Agent guide: Finding your way around

* **Page path:** `finding-your-way-around/index.md`
* **Page type:** explanation

## What this page is about

This page introduces a section that helps users get comfortable navigating the Autologyx Catalyst interface and understanding where commonly used features are located. It outlines guidance on interface patterns, personal account settings, and other orientation resources for day-to-day use.

## User intent

* Understand how to move around the Catalyst platform
* Find where common interface elements and tools are located
* Learn what My Account covers and what personal settings can be edited
* Understand list pages, filters, layouts, and navigation patterns
* Identify recommended next sections for getting oriented in the platform
* Distinguish interface orientation from platform configuration

## Key terms

* Autologyx platform
* Catalyst
* My Account
* UI and Navigation
* list pages
* filters
* layouts
* navigation patterns
* Workspace
* Help and Support
* Welcome / Introduction to Catalyst
* Getting Started

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst)
* [My account](/knowledgebase/terminology/#my-account)
* [UI and Navigation](/knowledgebase/terminology/#ui-and-navigation)
* [list pages](/knowledgebase/terminology/#list-pages)
* [filters](/knowledgebase/terminology/#filters)
* [Layout](/knowledgebase/terminology/#layout) (matched from `layouts`)
* [Workspace](/knowledgebase/terminology/#workspace)
* [Help and Support](/knowledgebase/terminology/#help-and-support)

## Related topics

* Welcome / Introduction to Catalyst
* Getting Started
* Workspace
* Using Help and Support

## Prerequisites

* No specific prior knowledge is stated
* Basic familiarity with using a software platform interface may be helpful

## Not covered

* Platform configuration
* Detailed workspace usage beyond orientation
* Advanced task-specific workflows
* Administrative setup or system configuration instructions

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/formbuilder-components/index.agent.md
---
# Agent guide: Formbuilder Components

* **Page path:** `record-and-task-forms/formbuilder-components/index.md`
* **Page type:** explanation

## What this page is about

This page introduces the main components of the Autologyx Catalyst formbuilder and explains that they are used to design clear, structured, effective forms. It frames the section as a guide to the building blocks, layout, field behavior, and configuration options used for Object Records and Tasks.

## User intent

* Understand the main components available in the formbuilder
* Learn how form layout, fields, and interactions are controlled
* Find where to learn about layout sections, instructions, properties, elements, and task form fields
* Understand how formbuilder components support process, data model, and user experience
* Know where to start if new to the formbuilder

## Key terms

* Formbuilder Components
* Catalyst formbuilder
* Overview of Formbuilder
* Layout Sections
* Instructions
* Properties
* Elements
* Task Form Fields
* Object Records
* Tasks
* configuration

## Terminology links

* [Formbuilder Components](/knowledgebase/terminology/#formbuilder-components)
* [Catalyst formbuilder](/knowledgebase/terminology/#catalyst-formbuilder)
* [Layout Sections And Instructions](/knowledgebase/terminology/#layout-sections-and-instructions) (matched from `Layout Sections`)
* [Instructions component](/knowledgebase/terminology/#instructions-component) (matched from `Instructions`)
* [Properties](/knowledgebase/terminology/#properties)
* [Elements](/knowledgebase/terminology/#elements)
* [Task Form Fields](/knowledgebase/terminology/#task-form-fields)
* [Object records](/knowledgebase/terminology/#object-records)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx forms, Object Records, and Tasks is helpful

## Not covered

* Detailed instructions for each component are not provided on this page
* Broader process or data model design is only referenced, not explained here
* This page does not cover topics outside individual formbuilder components and configuration areas

---

---
url: /knowledgebase-agent-guides/getting-started/index.agent.md
---
# Agent guide: Getting Started

* **Page path:** `getting-started/index.md`
* **Page type:** getting-started

## What this page is about

This page is a role-based entry point to the Autologyx documentation. It helps new and existing users choose the most relevant starting path based on whether they perform work, administer the platform, support delivery, or build applications.

## User intent

* Find the right documentation path based on my role
* Understand which getting-started guide applies to business users, administrators, analysts, or delivery teams
* Identify where to begin if I am new to the Autologyx platform
* Decide whether to start with performing work, platform administration, delivery support, or application building guidance

## Key terms

* Autologyx
* Performing Work
* Platform admin (Administrators)
* Building applications (Analysts)
* Performing work (Delivery)
* object records
* tasks
* documents
* personal preferences
* users
* roles
* permissions
* authentication
* outbound communications
* required outcomes
* data collection
* integrations
* communications

## Terminology links

* [Performing Work](/knowledgebase/terminology/#performing-work)
* [Platform admin](/knowledgebase/terminology/#platform-admin) (matched from `Platform admin (Administrators)`)
* [Building applications](/knowledgebase/terminology/#building-applications) (matched from `Building applications (Analysts)`)
* [Delivery](/knowledgebase/terminology/#delivery) (matched from `Performing work (Delivery)`)
* [Object records](/knowledgebase/terminology/#object-records)
* [Tasks](/knowledgebase/terminology/#tasks)
* [Document Fields](/knowledgebase/terminology/#document-fields) (matched from `documents`)
* [Users list](/knowledgebase/terminology/#users-list) (matched from `users`)

## Related topics

* Not provided.

## Prerequisites

* No specific prior knowledge is stated
* A basic understanding of your role and responsibilities in Autologyx is assumed

## Not covered

* Detailed feature instructions for performing work, administration, or application building
* Technical deep dives by feature area
* Step-by-step setup or configuration procedures
* Detailed delivery or rollout guidance beyond pointing users to the relevant path

---

---
url: >-
  /knowledgebase-agent-guides/applied-ai/mcp-services/getting-started-with-mcp/index.agent.md
---
# Agent guide: Getting started with MCP

* **Page path:** `applied-ai/mcp-services/getting-started-with-mcp/index.md`
* **Page type:** getting-started

## What this page is about

Introduces how MCP services let approved AI agents connect to Autologyx through governed tools, and explains how to begin using MCP safely. It outlines the two Autologyx MCP service types, setup checks, connection patterns for Claude CoWorker and OpenAI Web, and governance considerations.

## User intent

* Understand what MCP is used for in Autologyx
* Decide whether to use MCP Work or MCP Customer Success
* Check prerequisites before enabling an MCP-enabled agent
* Connect Claude CoWorker to an Autologyx MCP endpoint
* Connect OpenAI Web/ChatGPT to an Autologyx MCP endpoint
* Connect another MCP-compatible client to Autologyx
* Test a new MCP connection safely
* Understand permissions, audit, and governance expectations for agent use
* Learn the difference between co-pilot and autonomous agent patterns
* Know when to review the detailed MCP tool reference

## Key terms

* MCP services
* MCP enabled agent
* Autologyx MCP Work
* Autologyx MCP Customer Success
* MCP endpoint URL
* custom connector
* OAuth
* client ID
* permissions
* MCP mappings
* governance gateway
* audit logging
* co pilot pattern
* autonomous pattern
* Object Class
* Object Record
* Manual Task
* user group
* tool catalogue

## Terminology links

* [MCP services](/knowledgebase/terminology/#mcp-services)
* [MCP enabled agent](/knowledgebase/terminology/#mcp-enabled-agent)
* [Autologyx MCP Work](/knowledgebase/terminology/#autologyx-mcp-work)
* [Autologyx MCP Customer Success](/knowledgebase/terminology/#autologyx-mcp-customer-success)
* [MCP mappings](/knowledgebase/terminology/#mcp-mappings)
* [governance gateway](/knowledgebase/terminology/#governance-gateway)
* [co pilot pattern](/knowledgebase/terminology/#co-pilot-pattern)
* [autonomous pattern](/knowledgebase/terminology/#autonomous-pattern)

## Related topics

* Available MCP Work tools

## Prerequisites

* Access to an Autologyx environment with MCP services enabled
* An approved AI assistant or agent
* The correct MCP service connected
* A user or service account with appropriate permissions
* Agreed human review steps where required
* Understanding of audit and monitoring expectations
* Basic ability to configure connectors/apps and authenticate with OAuth

## Not covered

* Detailed reference for every MCP tool
* Exact endpoint URL, client ID, or authentication values for a specific implementation
* Client-specific UI details beyond general connection patterns
* How to design or configure Autologyx itself in depth
* A complete governance framework beyond high-level guidance
* Guarantees of agent correctness or risk-free autonomous operation

---

---
url: >-
  /knowledgebase-agent-guides/finding-your-way-around/some-things-you-might-find-useful/glossary/index.agent.md
---
# Agent guide: Glossary

* **Page path:** `finding-your-way-around/some-things-you-might-find-useful/glossary/index.md`
* **Page type:** explanation

## What this page is about

A glossary page for Autologyx. The supplied text only identifies the page and its classification as unrestricted and public, with no glossary terms shown.

## User intent

* Find definitions of Autologyx terms
* Check whether the glossary content is publicly accessible

## Key terms

* Glossary
* Autologyx
* Classification
* Unrestricted
* Public

## Terminology links

* [Glossary](/knowledgebase/terminology/#glossary)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* No actual glossary entries or definitions are provided in the supplied text
* No explanations of Autologyx concepts, features, or workflows
* No related pages or cross-references are included

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.10/groups-as-task-assignees/index.agent.md
---
# Agent guide: Groups as Task assignees

* **Page path:** `release-notes/release-notes-1.10/groups-as-task-assignees/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces assigning User Groups as task assignees in Tasks. It explains how group-based assignment works, how membership changes automatically update task assignees, and the related permissions, limits, and filtering support.

## User intent

* Understand how to assign User Groups to tasks
* Learn whether tasks can be assigned to both individual users and groups
* Find out what happens when users are added to or removed from a group
* Check permissions for selecting users and groups as assignees
* Learn the default limit for how many User Groups can be assigned to a task
* Understand how to filter tasks by User Groups

## Key terms

* User Groups
* task assignees
* Create Task panel
* group-based automation
* automatic assignment updates
* permissions to list users and groups
* 10 User Groups per task
* task filtering
* Tasks I'm Only an Assignee Of

## Terminology links

* [User Groups](/knowledgebase/terminology/#user-groups)
* [task assignees](/knowledgebase/terminology/#task-assignees)
* [Create Task panel](/knowledgebase/terminology/#create-task-panel)
* [Tasks I'm Only an Assignee Of](/knowledgebase/terminology/#tasks-im-only-an-assignee-of)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Tasks
* Understanding of task assignees and the Create Task panel
* Awareness of User Groups in the system

## Not covered

* How to create or manage User Groups
* How permissions are configured
* Whether the 10-group limit is configurable
* Technical implementation details of group sync
* Any workflow behavior beyond task assignment and filtering

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.10/groups-in-class-permission-sets/index.agent.md
---
# Agent guide: Groups in Class Permission sets

* **Page path:** `release-notes/release-notes-1.10/groups-in-class-permission-sets/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces support for assigning User Groups to Class Permission Sets, in addition to assigning individual users. It explains the updated Manage Assignees UI, how to add or remove groups, and the effect on group members’ permissions.

## User intent

* Understand the new ability to assign User Groups to a Class Permission Set
* Learn how to add a User Group from the Manage Assignees panel
* Learn how to remove an assigned User Group
* Understand what happens to users’ permissions when a group is unassigned
* Know the default limit on how many groups can be assigned to a permission set
* Understand which User Groups are visible for selection based on view permissions

## Key terms

* Class Permission Sets
* User Groups
* Manage Assignees panel
* Users tab
* User Groups tab
* Add Assignees panel
* view permissions
* assigned User Groups
* unassign
* permissions revoked

## Terminology links

* [Class permissions](/knowledgebase/terminology/#class-permissions) (matched from `Class Permission Sets`)
* [User Groups](/knowledgebase/terminology/#user-groups)
* [Manage assignees](/knowledgebase/terminology/#manage-assignees) (matched from `Manage Assignees panel`)
* [Users tab](/knowledgebase/terminology/#users-tab)
* [User groups tab](/knowledgebase/terminology/#user-groups-tab)
* [Add Assignees panel](/knowledgebase/terminology/#add-assignees-panel)
* [view permissions](/knowledgebase/terminology/#view-permissions)
* [assigned User Groups](/knowledgebase/terminology/#assigned-user-groups)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Class Permission Sets
* Basic understanding of users vs. User Groups
* Permission to view relevant User Groups

## Not covered

* How to create or manage User Groups themselves
* How to change the default limit of 10 groups per permission set
* Detailed rules for permission inheritance or conflict handling
* Any changes outside Class Permission Sets
* Broader administration or security configuration steps

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.10/groups-in-user-type-class-fields/index.agent.md
---
# Agent guide: Groups in User type Class fields

* **Page path:** `release-notes/release-notes-1.10/groups-in-user-type-class-fields/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces support for User Groups in User type Class fields. It explains how admins can configure selectable users/groups, interaction modes, selection limits, where the field can be used, and related behavior options like Required and Read only.

## User intent

* Understand what changed in User type Class fields
* Configure a User type Class field to allow selecting User Groups as well as individual users
* Decide whether end users can select whole groups, individual group members, or both
* Set minimum and maximum limits for users and groups in the field
* Learn where User type Class fields can be applied in the system
* Understand how list permissions affect which users and groups can be configured
* Use Required or Read only options when adding the field to a form builder

## Key terms

* User type Class field
* User Groups
* list permissions
* Allow Syncing Group Members
* Allow Selecting Individual Members
* Min Users selection
* Max Users selection
* Min/Max Groups selection
* Object classes display forms
* Card view
* Create and edit view
* Summary view
* Standalone forms
* Task templates
* record update task types
* form builder
* Required
* Read only
* Sequencer

## Terminology links

* [User Type Class fields](/knowledgebase/terminology/#user-type-class-fields) (matched from `User type Class field`)
* [User Groups](/knowledgebase/terminology/#user-groups)
* [List permissions](/knowledgebase/terminology/#list-permissions)
* [Allow Syncing Group Members](/knowledgebase/terminology/#allow-syncing-group-members)
* [Allow Selecting Individual Members](/knowledgebase/terminology/#allow-selecting-individual-members)
* [Min/Max Groups selection](/knowledgebase/terminology/#minmax-groups-selection)
* [Card view](/knowledgebase/terminology/#card-view)
* [Create and edit view](/knowledgebase/terminology/#create-and-edit-view)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Class Fields and User type fields
* Familiarity with User Groups and users in the system
* Awareness of list permissions
* Basic knowledge of forms, task templates, and form builder configuration

## Not covered

* Detailed end-user behavior when creating/editing records or managing tasks
* Step-by-step setup instructions beyond the described options
* General permission model beyond list permissions for selecting users/groups
* Automation logic details for Sequencer
* Any topics outside User type Class fields with groups

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.10/groups-in-user-type-fields/index.agent.md
---
# Agent guide: Groups in User type fields

* **Page path:** `release-notes/release-notes-1.10/groups-in-user-type-fields/index.md`
* **Page type:** release-notes

## What this page is about

This release note explains how end users interact with User Type Class fields when those fields are configured to include User Groups, individual group members, or individual users. It covers the available selection modes, required/min-max constraints, and how the same behavior applies in records and record update tasks.

## User intent

* Understand how grouped user selections appear and behave in User Type Class fields
* Learn the difference between syncing an entire group and selecting individual group members
* See what happens when both group sync and individual member selection are enabled
* Understand how individual users can be combined with groups in one field
* Check how required, minimum, and maximum selection rules affect end users
* Confirm that the same interaction model applies when the field is used in task templates and record update tasks

## Key terms

* User Type Class field
* User Groups
* Allow syncing group members
* Allow selecting individual members
* sync icon
* Search for users
* individual users
* required field
* Minimum user/group selections
* Maximum user/group selections
* record update tasks
* task template

## Terminology links

* [User Type Class fields](/knowledgebase/terminology/#user-type-class-fields) (matched from `User Type Class field`)
* [User Groups](/knowledgebase/terminology/#user-groups)
* [Allow Syncing Group Members](/knowledgebase/terminology/#allow-syncing-group-members)
* [Allow Selecting Individual Members](/knowledgebase/terminology/#allow-selecting-individual-members)
* [sync icon](/knowledgebase/terminology/#sync-icon)
* [Search for users](/knowledgebase/terminology/#search-for-users)
* [Required](/knowledgebase/terminology/#required) (matched from `required field`)
* [Minimum or Maximum user/group selections](/knowledgebase/terminology/#minimum-or-maximum-usergroup-selections) (matched from `Minimum user/group selections`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of what a User Type Class field is
* The field has already been configured with group/user options
* Familiarity with records, tasks, and task templates

## Not covered

* How to configure the User Type Class field itself
* Administrative setup steps for creating User Groups
* Permissions or backend rules beyond the described selection behavior
* Broader product context outside records and record update tasks

---

---
url: >-
  /api-agent-guides/catalyst/resources/platform-information/healthcheck/index.agent.md
---
# Agent guide: Health Check

* **Page path:** `catalyst/resources/platform-information/healthcheck.md`
* **Page type:** reference

## What this page is about

Reference documentation for the healthcheck technical design and its API endpoint. It describes the GET /api/health/ endpoint, request parameters, permissions note, response fields for backend/service status, and possible error responses.

## User intent

* Find the healthcheck endpoint path and method
* Understand what query parameter(s) the healthcheck API accepts
* See which backend/service statuses are returned by the healthcheck response
* Check what permission-related requirement applies to the endpoint
* Identify expected error codes for invalid parameters or methods

## Key terms

* healthcheck
* GET /api/health/
* format
* json
* permissions
* namespace
* vault
* cache
* celery
* cloud front
* history
* postgres
* s3
* rabbit
* redis2
* redis
* vault
* websocket
* 404 Not Found
* 405 Method Not Allowed

## Terminology links

* [permissions](/api/terminology/#permissions)

## Related topics

* Version

## Prerequisites

* Basic understanding of HTTP APIs and request methods
* Familiarity with query string parameters
* Awareness of backend services used by the platform
* Some context on namespace-based configuration and vault if permissions are configured there

## Not covered

* Detailed authentication or authorization flow
* Exact meaning of the missing permission/url placeholder text
* Concrete response examples
* Full response body schema details beyond listed status fields
* Operational interpretation of healthy vs unhealthy backend values
* Implementation details beyond the brief technical design statement

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.11/hierarchical-records-creation-endpoints/index.agent.md
---
# Agent guide: Hierarchical records creation endpoints

* **Page path:** `release-notes/release-notes-1.11/hierarchical-records-creation-endpoints/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces a new hierarchical record creation endpoint that lets you create entire parent-child record structures in a single API request. It highlights the request shape, asynchronous processing model, validation behavior, ownership, and history logging.

## User intent

* Understand what the hierarchical record creation endpoint does
* Learn how to submit parent-child hierarchies in one request
* Know that requests are processed asynchronously and how status is tracked
* Understand possible processing statuses and failure behavior
* Learn what validation issues can cause the transaction to fail
* Confirm ownership and history events for created records

## Key terms

* hierarchical record creation endpoint
* parent-child structures
* single request
* asynchronous processing
* transaction identifier
* transaction status
* status URL/link
* pending status
* processing status
* completed status
* failed status
* validation errors
* relationship validation
* object class configuration
* fields
* children
* ownership
* history events

## Terminology links

* [hierarchical record creation endpoint](/knowledgebase/terminology/#hierarchical-record-creation-endpoint)
* [asynchronous processing status](/knowledgebase/terminology/#asynchronous-processing-status) (matched from `transaction status`)
* [Pending status](/knowledgebase/terminology/#pending-status)
* [Object class configuration](/knowledgebase/terminology/#object-class-configuration)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `fields`)
* [children records](/knowledgebase/terminology/#children-records) (matched from `children`)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `ownership`)
* [standard history events](/knowledgebase/terminology/#standard-history-events) (matched from `history events`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of API requests and responses
* Familiarity with object records and object class fields/configuration
* Understanding of parent-child data relationships

## Not covered

* Exact endpoint URLs or full API path details
* Complete request/response schemas or field-by-field reference
* Authentication or authorization details
* Detailed examples of request payloads
* Retry behavior, rate limits, or performance limits
* How to resolve specific validation errors beyond general causes

---

---
url: >-
  /knowledgebase-agent-guides/administration/communication/how-do-i-configure-single-sign-on-for-users/index.agent.md
---
# Agent guide: How do I configure single sign-on for users?

* **Page path:** `administration/communication/how-do-i-configure-single-sign-on-for-users/index.md`
* **Page type:** faq

## What this page is about

This page explains how to configure user single sign-on in Catalyst using Microsoft Azure and OpenID Connect. It covers both the Catalyst-side setup and the required Azure application registration, authentication, and API permission steps.

## User intent

* Set up single sign-on for users in Catalyst
* Find where SSO settings are located in Catalyst
* Understand who can access and configure SSO settings
* Create an Azure application registration for Catalyst SSO
* Obtain and enter the Tenant ID, Client ID, and Client secret
* Configure Redirect URI and Logout URL in Azure
* Set Azure API permissions needed for user authentication
* Enable automatic user creation for SSO users
* Understand optional support for Catalyst login and the Catalyst Word add-in

## Key terms

* single sign on
* SSO
* Catalyst
* Microsoft Azure
* OpenID Connect
* Administration/Single sign on settings
* Super admin
* role permissions
* Tenant ID
* Client ID
* Client secret
* Redirect URI
* Logout URL
* Enterprise applications
* application registration
* Authentication
* API permissions
* Microsoft Graph
* Delegated permissions
* email
* profile
* User.Read
* User.Read.All
* admin consent
* Automatically create user
* Internal user account type
* Catalyst login support
* Catalyst Word add in support

## Terminology links

* [Single sign on](/knowledgebase/terminology/#single-sign-on)
* [Catalyst](/knowledgebase/terminology/#catalyst)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Roles and Permissions](/knowledgebase/terminology/#roles-and-permissions) (matched from `role permissions`)
* [Tenant ID](/knowledgebase/terminology/#tenant-id)
* [Client ID](/knowledgebase/terminology/#client-id)
* [Client Secret](/knowledgebase/terminology/#client-secret)
* [Redirect / Callback URI](/knowledgebase/terminology/#redirect-callback-uri) (matched from `Redirect URI`)

## Related topics

* Not provided.

## Prerequisites

* Access to Administration in Catalyst
* Either a Super admin account type or a role with create/edit permissions for single sign on enabled
* Access to the Microsoft Azure domain administration area
* Ability to manage Azure enterprise applications, authentication settings, secrets, and API permissions

## Not covered

* Detailed behavior after a user signs in with single sign on
* Configuration for SSO providers other than Microsoft Azure OpenID Connect
* Detailed setup of Catalyst Word add-in support
* General Azure administration concepts beyond the exact steps listed
* Username/password login troubleshooting beyond noting that it is used when SSO is not configured and enabled

---

---
url: >-
  /knowledgebase-agent-guides/administration/communication/how-do-i-configure-user-activation-rules/index.agent.md
---
# Agent guide: How do I configure user activation rules?

* **Page path:** `administration/communication/how-do-i-configure-user-activation-rules/index.md`
* **Page type:** faq

## What this page is about

Explains the end-user account activation experience and how administrators configure global user activation and password rules on the Standard authentication page. It also clarifies which rule changes apply only to new activations/password changes versus immediately to all users.

## User intent

* Understand what a new user sees when activating a full account
* Configure how long activation links remain valid
* Set password requirements for user login passwords
* Set password rotation timing
* Enable prevention of password reuse
* Understand the scope and effect timing of activation and password rule changes

## Key terms

* user activation rules
* activation email
* activation link
* Activate your user account page
* Standard authentication page
* Administration
* password rules
* minimum characters
* password rotation interval
* prevent password re use
* global settings
* new activations
* password changes
* active passwords

## Terminology links

* [user activation rules](/knowledgebase/terminology/#user-activation-rules)
* [activation email](/knowledgebase/terminology/#activation-email)
* [activation link](/knowledgebase/terminology/#activation-link)
* [Activate your user account page](/knowledgebase/terminology/#activate-your-user-account-page)
* [Standard authentication page](/knowledgebase/terminology/#standard-authentication-page)
* [Administration Sections](/knowledgebase/terminology/#administration-sections) (matched from `Administration`)
* [Password Rules](/knowledgebase/terminology/#password-rules)
* [Prevent password re use](/knowledgebase/terminology/#prevent-password-re-use)

## Related topics

* Not provided.

## Prerequisites

* Access to the Administration area
* Basic understanding of user accounts and authentication settings

## Not covered

* How to create a user account
* How to configure authentication methods beyond the Standard authentication page
* Detailed password complexity options beyond minimum characters, rotation, and reuse prevention
* Troubleshooting activation email delivery or failed activations
* Any per-user or per-group exceptions, since rules are global

---

---
url: >-
  /knowledgebase-agent-guides/administration/roles-and-permissions/how-do-i-create-a-role/index.agent.md
---
# Agent guide: How do I create a role?

* **Page path:** `administration/roles-and-permissions/how-do-i-create-a-role/index.md`
* **Page type:** faq

## What this page is about

Explains how to create a new role in Administration > Roles for users with the Standard account type, and how the available role permissions work. It also outlines how Create, Edit, and Delete permissions affect user access to system areas.

## User intent

* Create a new role for Standard account users
* Understand which role fields are required or optional
* Set system permissions for a role
* Learn how Create, Edit, and Delete permissions affect menu visibility and access
* Understand special permission behavior in Administration areas
* Check limits and default behavior for roles and permissions

## Key terms

* role
* Standard account type
* Administration
* Roles
* Role name
* Description
* System permissions
* Sequencer
* Task configuration
* Task Templates
* Task Group Templates
* Data model
* Object Classes
* Company Details
* Standard Authentication
* User groups
* Create
* Edit
* Delete
* Super admin

## Terminology links

* [Roles](/knowledgebase/terminology/#roles) (matched from `role`)
* [Standard account type](/knowledgebase/terminology/#standard-account-type)
* [Administration Sections](/knowledgebase/terminology/#administration-sections) (matched from `Administration`)
* [Description](/knowledgebase/terminology/#description)
* [System permissions](/knowledgebase/terminology/#system-permissions)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Task configuration](/knowledgebase/terminology/#task-configuration)
* [Task templates](/knowledgebase/terminology/#task-templates)

## Related topics

* Not provided.

## Prerequisites

* Access to the main left-hand menu and Administration > Roles
* Understanding that roles apply to users with the Standard account type
* Basic familiarity with system areas such as Sequencer, Task configuration, Data model, and Administration

## Not covered

* How to assign a role to a user
* How to edit or delete an existing role
* Detailed object-level permissions for Object Classes or Object Records
* How ownership and management of User groups works beyond the noted permission behavior
* General setup of account types beyond the mention of Standard and Super admin

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/task-group-templates/how-do-i-create-a-task-group-template/index.agent.md
---
# Agent guide: How do I create a task group template?

* **Page path:** `system-configuration/task-group-templates/how-do-i-create-a-task-group-template/index.md`
* **Page type:** faq

## What this page is about

Explains how to create a task group template from the task group template list, including required permissions, required fields, object class selection rules, task template constraints, and save/cancel behavior.

## User intent

* Find the prerequisites and permissions needed to create a task group template
* Create a new task group template from the list page
* Understand which object classes can be assigned to a template
* Understand which task templates can be added
* Learn the restrictions around Update object records task templates
* Know when Save is enabled and what happens on save or cancel
* Check the system limit for task group templates

## Key terms

* Task group template
* Task group template list
* * Create
* Name
* Description
* Object class
* Applicable to object classes
* Task template
* Task creation mechanism: Automatic
* Update object records type
* Save
* Cancel
* Unsaved changes will be lost warning
* Super admin
* Owner of an Object class
* Role permissions under Task configuration
* Permission set
* View the Object class

## Terminology links

* [Task Group Templates](/knowledgebase/terminology/#task-group-templates) (matched from `Task group template`)
* [Task group template list](/knowledgebase/terminology/#task-group-template-list)
* [Description](/knowledgebase/terminology/#description)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Applicable to object classes](/knowledgebase/terminology/#applicable-to-object-classes)
* [Task templates](/knowledgebase/terminology/#task-templates) (matched from `Task template`)
* [Automatic](/knowledgebase/terminology/#automatic) (matched from `Task creation mechanism: Automatic`)
* [Update object records type](/knowledgebase/terminology/#update-object-records-type)

## Related topics

* Not provided.

## Prerequisites

* One of: Super admin account, Owner of an Object class, or a role with Task Group Template create permissions plus a permission set allowing View the Object class
* The relevant Object class(es) must already be configured
* The Tasks to be added to the template must already be configured

## Not covered

* How to configure object classes
* How to configure task templates/tasks before creating the group template
* Editing, deleting, or managing existing task group templates beyond creation
* Detailed behavior of task types other than the noted Automatic and Update object records constraints

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/task-templates/how-do-i-create-a-task-template/index.agent.md
---
# Agent guide: How do I create a task template?

* **Page path:** `system-configuration/task-templates/how-do-i-create-a-task-template/index.md`
* **Page type:** faq

## What this page is about

This page explains how to create a Task template in System configuration, including required permissions, setup steps, and the main configuration areas: Response configuration, Lifecycle, and Stages. It also outlines due date and expiry options, task creation mechanisms, and who can complete tasks.

## User intent

* Understand who is allowed to create a Task template
* Create a new Task template from the Task templates list
* Enter required basic details such as a unique template name
* Choose a Task type and task creation mechanism
* Configure lifecycle settings such as due dates, SLA, and expiry behavior
* Understand how automatic and manual tasks differ
* See how task completion responsibility is determined
* Check who can complete a Task
* Know system limits for the number of Task templates

## Key terms

* Task template
* System configuration
* Super admin
* Role
* Task Templates Create permission
* Task configuration tab
* Complete self contained form
* Update object record
* Owner of the Object class
* Task type
* Task creation mechanism
* Automatic
* Manual
* Sequence
* Response configuration
* Lifecycle
* Stages
* Due Date
* Outstanding
* Overdue
* Expiry rules
* Task Expiry
* SLA
* Assignee
* Object Class Permission set

## Terminology links

* [Task templates](/knowledgebase/terminology/#task-templates) (matched from `Task template`)
* [System configuration](/knowledgebase/terminology/#system-configuration)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Roles](/knowledgebase/terminology/#roles) (matched from `Role`)
* [Task configuration tab](/knowledgebase/terminology/#task-configuration-tab)
* [Complete self contained form](/knowledgebase/terminology/#complete-self-contained-form)
* [Update object records](/knowledgebase/terminology/#update-object-records) (matched from `Update object record`)
* [Owner of the Object class](/knowledgebase/terminology/#owner-of-the-object-class)

## Related topics

* Task type
* Update object record

## Prerequisites

* Access to System configuration
* Appropriate permissions or Super admin account
* For Update object record templates, ownership of the Object class
* Basic understanding of Tasks, Object classes, and Sequences

## Not covered

* Detailed configuration of each Task type beyond referencing dedicated articles
* How to configure Sequences
* How to create manual tasks from the Tasks panel
* Detailed approval-stage setup, which is described as future functionality
* Task maintenance, editing, or deletion after creation

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.13/how-do-i-create-a-test-user-account/index.agent.md
---
# Agent guide: How do I create a test user account?

* **Page path:** `release-notes/release-notes-1.13/how-do-i-create-a-test-user-account/index.md`
* **Page type:** release-notes

## What this page is about

Explains how to create test user accounts in Catalyst using email plus addressing, mainly with Microsoft 365 but noting many other providers also support it. It also suggests MailSlurp as an alternative and advises contacting Autologyx if this method does not work for a testing scenario.

## User intent

* Create a test user account in Catalyst
* Use plus addressing to generate multiple test email addresses that deliver to one inbox
* Understand the email format to use for test accounts
* Find alternatives if plus addressing is not suitable for testing

## Key terms

* Catalyst
* test user account
* Microsite 365
* Microsoft 365
* plus addressing
* test email addresses
* inbox
* MailSlurp
* Autologyx contact

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst)
* [test user account](/knowledgebase/terminology/#test-user-account)

## Related topics

* General information on how to create a user account

## Prerequisites

* Access to an email mailbox
* Basic understanding of email address formatting
* A mailbox provider that supports plus addressing, or an alternative testing mailbox solution

## Not covered

* Detailed Catalyst account creation steps beyond the email-address approach
* Configuration or administration of Microsoft 365
* How to set up MailSlurp
* Alternative testing methods beyond brief recommendations
* Troubleshooting details for failed test account creation

---

---
url: >-
  /knowledgebase-agent-guides/administration/all-about-users/how-do-i-create-a-user-account/index.agent.md
---
# Agent guide: How do I create a user account?

* **Page path:** `administration/all-about-users/how-do-i-create-a-user-account/index.md`
* **Page type:** faq

## What this page is about

Explains how a Super admin manually creates a user account from Administration > Users, including choosing the account type, entering required details, saving, and optionally sending an activation email. It also summarizes user account types, activation flow, and resulting account statuses.

## User intent

* Create a new user account manually
* Understand which account type to assign to a user
* Know what information is required when creating a user
* Understand how activation emails work
* Interpret Created, Pending, and Active account statuses
* Know who is allowed to create, edit, or delete users

## Key terms

* Super admin
* Administration / Users
* Create user
* * Create
* User account type
* 1 time completion
* Internal
* External
* Config admin
* Roles
* Super admin account type
* Username
* email address
* activation email
* Personal Information
* Status
* Created
* Pending
* Active
* User ID
* record permissions
* user groups
* object class permissions
* Single sign on

## Terminology links

* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Create user page](/knowledgebase/terminology/#create-user-page) (matched from `Create user`)
* [User Account Types](/knowledgebase/terminology/#user-account-types) (matched from `User account type`)
* [1 time completion account type](/knowledgebase/terminology/#1-time-completion-account-type) (matched from `1 time completion`)
* [Internal account type](/knowledgebase/terminology/#internal-account-type) (matched from `Internal`)
* [External account type](/knowledgebase/terminology/#external-account-type) (matched from `External`)
* [Config admin account type](/knowledgebase/terminology/#config-admin-account-type) (matched from `Config admin`)
* [Roles](/knowledgebase/terminology/#roles)

## Related topics

* Not provided.

## Prerequisites

* You must have a Super admin account type
* Know the intended user's role in the organisation or whether they are internal/external
* Have a unique valid email address for the user

## Not covered

* Detailed setup of roles beyond selecting them for Config admin users
* How to configure permissions, object classes, record permissions, or user groups
* How users activate accounts beyond receiving the activation email and setting a password
* How to change a password in detail
* How to configure Single sign on, Landing page, Outbound mail setup, or Theme

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/how-do-i-create-an-object-class/index.agent.md
---
# Agent guide: How do I create an Object Class?

* **Page path:** `system-configuration/object-classes/how-do-i-create-an-object-class/index.md`
* **Page type:** faq

## What this page is about

Explains how to create a new Object class, including required permissions, the fields on the create form, what happens after saving, and system limits for Object classes and Object fields.

## User intent

* Create a new Object class from the Object classes list
* Understand what permissions are needed to create an Object class
* Know which form fields are required or optional when creating an Object class
* Decide whether to add fields immediately after saving
* See what configuration areas are available after creation
* Check system limits for the number of Object classes and fields

## Key terms

* Object class
* Object classes list
* * Create button
* Role permissions
* Super admin account type
* Name field
* Description field
* Save button
* success toast message
* Add fields
* Edit Object class page
* required fields
* Display
* card view
* create/edit view
* summary view
* Forms
* Document templates
* Permissions
* Object fields

## Terminology links

* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [+ Create button](/knowledgebase/terminology/#create-button)
* [Roles and Permissions](/knowledgebase/terminology/#roles-and-permissions) (matched from `Role permissions`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type)
* [Name field](/knowledgebase/terminology/#name-field)
* [Description field](/knowledgebase/terminology/#description-field)
* [green success toast message](/knowledgebase/terminology/#green-success-toast-message) (matched from `success toast message`)
* [Add fields](/knowledgebase/terminology/#add-fields)

## Related topics

* Not provided.

## Prerequisites

* Access to the Object classes list
* Permission to create an Object class via Role or Super admin account type

## Not covered

* Detailed steps for configuring fields after creation
* How to create and use document templates in detail
* Detailed setup of display views, forms, or permissions tabs
* How to edit or delete an existing Object class

---

---
url: >-
  /knowledgebase-agent-guides/using-help-and-support/faqs/how-do-i-grant-view-users-permission-to-config-admins/index.agent.md
---
# Agent guide: How do I grant "view users" permission to Config admins

* **Page path:** `using-help-and-support/faqs/how-do-i-grant-view-users-permission-to-config-admins/index.md`
* **Page type:** faq

## What this page is about

This FAQ explains what the "view users" permission lets Config admins do. It describes the user-related actions enabled when a Config admin has this permission alongside the appropriate role permissions.

## User intent

* Understand what the "view users" permission allows for Config admins
* Determine whether Config admins can view user details from avatars and lists
* Check whether Config admins can add users to fields or user groups
* Confirm whether Config admins can assign or reassign manual tasks to available users

## Key terms

* view users permission
* Config admin
* role permissions
* user details
* user avatars
* lists
* drop downs
* fields
* User group
* manual task
* available user

## Terminology links

* [View Users permission](/knowledgebase/terminology/#view-users-permission)
* [Config admin account type](/knowledgebase/terminology/#config-admin-account-type) (matched from `Config admin`)
* [Roles and Permissions](/knowledgebase/terminology/#roles-and-permissions) (matched from `role permissions`)
* [User details page](/knowledgebase/terminology/#user-details-page) (matched from `user details`)
* [user avatars](/knowledgebase/terminology/#user-avatars)
* [List permissions](/knowledgebase/terminology/#list-permissions) (matched from `lists`)
* [drop down list](/knowledgebase/terminology/#drop-down-list) (matched from `drop downs`)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `fields`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Config admin roles
* Awareness that role permissions may also be required

## Not covered

* How to actually grant or configure the permission
* Where in the product settings this permission is managed
* Any step-by-step instructions
* Details of related permissions or role setup

---

---
url: >-
  /knowledgebase-agent-guides/administration/all-about-users/how-does-a-1-time-completion-user-interact-with-catalyst/index.agent.md
---
# Agent guide: How does a 1-time completion user interact with Catalyst?

* **Page path:** `administration/all-about-users/how-does-a-1-time-completion-user-interact-with-catalyst/index.md`
* **Page type:** faq

## What this page is about

Explains who 1-time completion users are and how they complete assigned tasks in Catalyst without logging in. It covers task email links, saving progress, completion behavior, and when task links become invalid.

## User intent

* Understand what a 1-time completion user is
* Learn how 1-time completion users access and complete tasks
* Find out whether these users need a login
* Understand how their accounts are created and communicated
* See how saving progress and completing a task works
* Check when a task link remains active or becomes invalid

## Key terms

* 1-time completion user
* account type
* task assignment email
* no login required
* Save progress
* Complete button
* mandatory fields
* due date
* Overdue status
* task link

## Terminology links

* [1 time completion user](/knowledgebase/terminology/#1-time-completion-user) (matched from `1-time completion user`)
* [account type](/knowledgebase/terminology/#account-type)
* [Save progress](/knowledgebase/terminology/#save-progress)
* [Complete button](/knowledgebase/terminology/#complete-button)
* [mandatory fields](/knowledgebase/terminology/#mandatory-fields)
* [Due Date](/knowledgebase/terminology/#due-date)
* [task link](/knowledgebase/terminology/#task-link)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Catalyst user accounts
* Basic understanding of task assignment in Catalyst

## Not covered

* How to create the user account step by step
* How admins assign tasks in detail
* How other user account types interact with Catalyst
* Configuration or customization of email notifications
* Troubleshooting beyond the listed invalid-link scenarios

---

---
url: >-
  /knowledgebase-agent-guides/workspace/working-with-relational-records/how-to-associate-child-records-with-existing-parent-records/index.agent.md
---
# Agent guide: How to associate child records with existing parent records

* **Page path:** `workspace/working-with-relational-records/how-to-associate-child-records-with-existing-parent-records/index.md`
* **Page type:** faq

## What this page is about

Explains how users can associate child records with an existing parent record from the Workspace after relational modeling and parent form configuration are already set up. It covers behavior for 1:1 and 1:N relationships, UI behavior, permissions, and record limits.

## User intent

* Add existing child records to an existing parent record
* Understand how child selectors behave for 1:1 versus 1:N parent-child ratios
* Find where in the Workspace to open a parent record and associate children
* Remove associated child records from a parent
* Understand how search, filtering, pagination, and child summaries work in child record components
* Know when users can create child records directly from the parent record
* Check what permissions affect visibility or availability of child association controls
* Understand limits on the number of associated or newly created child records

## Key terms

* parent record
* child record
* parent:child ratio
* 1:1
* 1:N
* Relational modeller
* Workspace
* create/edit view
* child record selector
* identifier
* ALX ID
* child record summary
* Actions menu
* +Create button
* view record permission
* view class permission
* list records permission
* create records permission

## Terminology links

* [Records](/knowledgebase/terminology/#records) (matched from `parent record`)
* [parent:child ratio](/knowledgebase/terminology/#parentchild-ratio)
* [1:1](/knowledgebase/terminology/#11)
* [1:N](/knowledgebase/terminology/#1n)
* [Relational modeller](/knowledgebase/terminology/#relational-modeller)
* [Workspace](/knowledgebase/terminology/#workspace)
* [create/edit view](/knowledgebase/terminology/#createedit-view)
* [child record selector](/knowledgebase/terminology/#child-record-selector)

## Related topics

* Not provided.

## Prerequisites

* Parent/child relationships must already be created in the Relational modeller
* The parent object class must already be configured to include the child object classes in its create/edit view
* The user needs appropriate permissions to view, edit, list, or create records as applicable
* Basic familiarity with opening and editing records in the Workspace

## Not covered

* How to create parent/child relationships in the Relational modeller
* How to configure the parent object class create/edit view to include child classes
* Detailed steps for creating child records via the +Create flow
* General user preference configuration beyond noting row height behavior

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/landing-page/how-to-configure-the-landing-page/index.agent.md
---
# Agent guide: How to configure the Landing page

* **Page path:** `system-configuration/landing-page/how-to-configure-the-landing-page/index.md`
* **Page type:** faq

## What this page is about

Explains how a Super admin configures the application Landing page in System configuration, including adding sections, using the HTML component/editor, previewing, saving, and enabling the page. It also notes current limitations and behavior of navigation actions like Cancel and Revert.

## User intent

* Configure the Landing page in System configuration
* Set up the first section with labels, columns, ratios, and spacing
* Add and edit HTML content on the Landing page
* Insert text, tables, images, media, iframes, or raw HTML/source code
* Preview how the Landing page appears to users
* Understand what Cancel, Revert, Preview, and Save do
* Enable the Landing page and make it live
* Hide section headers if needed

## Key terms

* Landing page
* Super admin
* System configuration
* Layout panel
* Section
* HTML component
* HTML editor
* Source
* iframe
* Power BI
* Preview
* Save
* Revert
* Cancel
* Enable
* section header
* columns
* ratio
* spacing

## Terminology links

* [Landing page](/knowledgebase/terminology/#landing-page)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [System configuration](/knowledgebase/terminology/#system-configuration)
* [Layout panel](/knowledgebase/terminology/#layout-panel)
* [Workspace Sections](/knowledgebase/terminology/#workspace-sections) (matched from `Section`)
* [HTML component](/knowledgebase/terminology/#html-component)
* [HTML editor](/knowledgebase/terminology/#html-editor)
* [Source field](/knowledgebase/terminology/#source-field) (matched from `Source`)

## Related topics

* Not provided.

## Prerequisites

* Super admin user account is required
* Access to the application System configuration > Landing page area
* Basic understanding of Catalyst form sections and drag-and-drop layout
* Hosted URLs for images/media or embed code if using external content like iframes

## Not covered

* Detailed behavior of Catalyst forms beyond stating sections work the same way
* Advanced HTML/CSS/JavaScript guidance
* Permissions setup beyond requiring Super admin access
* How to create multiple different landing pages for different users; this version supports only one for all users
* Troubleshooting embed/content rendering issues
* Broader System configuration options outside the Landing page

---

---
url: >-
  /knowledgebase-agent-guides/workspace/working-with-relational-records/how-to-create-a-child-record-from-the-parent-record/index.agent.md
---
# Agent guide: How to create a child record from the parent record

* **Page path:** `workspace/working-with-relational-records/how-to-create-a-child-record-from-the-parent-record/index.md`
* **Page type:** faq

## What this page is about

Explains how to create a child record from within a parent record, including while the parent itself is still being created or edited. It also walks through creating a parent, child, and grandchild record in sequence using modal flyouts.

## User intent

* Understand whether a child record can be created before the parent record is saved
* Learn the permissions needed to create child records from a parent record
* See the steps for creating parent, child, and grandchild records in one workflow
* Understand how modal flyouts behave when creating nested relational records
* Know what happens when saving, cancelling, or navigating away with unsaved changes

## Key terms

* parent record
* child record
* grandchild record
* object class
* relational model
* create/edit record display form
* child component
* fly out modal
* breadcrumbs
* Records list
* Save
* Cancel
* Revert
* unsaved changes
* Child record summary
* permissions

## Terminology links

* [Records](/knowledgebase/terminology/#records) (matched from `parent record`)
* [grand child](/knowledgebase/terminology/#grand-child) (matched from `grandchild record`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [relational model](/knowledgebase/terminology/#relational-model)
* [create/edit record display form](/knowledgebase/terminology/#createedit-record-display-form)
* [child component](/knowledgebase/terminology/#child-component)
* [fly out modal](/knowledgebase/terminology/#fly-out-modal)
* [breadcrumbs](/knowledgebase/terminology/#breadcrumbs)

## Related topics

* Not provided.

## Prerequisites

* A relational setup with parent and child object classes
* Permission to create records in the child object class
* Permission to create or edit records in the parent object class
* Basic familiarity with the Records list and create/edit forms

## Not covered

* How to configure relational models or object classes
* How permissions are set up
* How to edit existing child relationships beyond the creation flow
* Detailed guidance on interacting with child records beyond the brief pointer to a separate page
* Any URL-based navigation for child creation modals, since the modal does not have its own URL

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.8/image-merge-fields/index.agent.md
---
# Agent guide: Image merge fields

* **Page path:** `release-notes/release-notes-1.8/image-merge-fields/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces and explains a new image merge field in Catalyst that lets users inject attached images into generated documents. It also notes support for resizing images with merge-field filters and suggests using text boxes to control placement.

## User intent

* Understand what the new image merge field feature does
* Learn how to reference an attached image in a merge field
* Resize inserted images using width and height filters
* Control image placement in a generated document
* Use generated documents to include logos, charts, QR codes, or other visuals

## Key terms

* image merge field
* standard document type merge field
* attached file index
* .embedded.
* filters
* image width
* image height
* text box
* generated document
* document personalization

## Terminology links

* [Image merge fields](/knowledgebase/terminology/#image-merge-fields) (matched from `image merge field`)
* [document type merge field](/knowledgebase/terminology/#document-type-merge-field) (matched from `standard document type merge field`)
* [filters](/knowledgebase/terminology/#filters)
* [document generation](/knowledgebase/terminology/#document-generation) (matched from `generated document`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst document generation
* Understanding of merge fields
* Access to attached files or document fields containing images

## Not covered

* Exact merge field syntax examples in fully rendered form
* Detailed list of supported image file types
* Advanced formatting or alignment options beyond using a text box
* Troubleshooting failed image insertion
* Whether the feature has platform, template, or output-format limitations

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.6/imanage-authentication-objects/index.agent.md
---
# Agent guide: iManage Authentication objects

* **Page path:** `release-notes/release-notes-1.6/imanage-authentication-objects/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces iManage Authentication objects for the iManage-Catalyst integration. It explains the required credentials, the ability to test authentication during creation and editing, and how the object can be used in workflows and API-based document access.

## User intent

* Understand what an iManage Authentication object is used for
* Find the credentials required to create an iManage Authentication object
* Learn whether authentication can be tested during creation or editing
* See how to use the authentication object within sequences/workflows
* Understand how iManage documents can be accessed through API Actor and API Call actor

## Key terms

* iManage Authentication object
* iManage
* Catalyst integration
* single login access
* username
* password
* client ID
* host
* test during creation
* test during editing
* workflows
* sequences
* API Actor
* API Call actor
* document management
* security and compliance

## Terminology links

* [iManage Authentication Objects](/knowledgebase/terminology/#imanage-authentication-objects) (matched from `iManage Authentication object`)
* [iManage template](/knowledgebase/terminology/#imanage-template) (matched from `iManage`)
* [Username](/knowledgebase/terminology/#username)
* [Client ID](/knowledgebase/terminology/#client-id)
* [Host selection](/knowledgebase/terminology/#host-selection) (matched from `host`)
* [Catalyst workflows](/knowledgebase/terminology/#catalyst-workflows) (matched from `workflows`)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `sequences`)
* [API Call actor](/knowledgebase/terminology/#api-call-actor) (matched from `API Actor`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst
* Basic understanding of workflows or sequences
* Access to iManage credentials: username, password, client ID, and host
* Some awareness of API Actor and API Call actor configuration

## Not covered

* Step-by-step configuration instructions
* Detailed API Actor or API Call actor setup
* Troubleshooting authentication failures
* Specific security protocol or compliance standard details
* Examples of complete workflow implementations

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/integrations/imanage-cloud-integration/index.agent.md
---
# Agent guide: iManage Cloud integration

* **Page path:** `system-configuration/integrations/imanage-cloud-integration/index.md`
* **Page type:** explanation

## What this page is about

This page explains how the iManage Cloud integration works in Catalyst and how to add the iManage component to record display forms so users can access iManage documents inside records. It also covers associating an iManage folder with a record manually or via API and notes the availability of iManage API call templates in Sequencer.

## User intent

* Understand what the iManage Cloud integration enables in Catalyst
* Check prerequisites before configuring the integration
* Add the iManage Cloud component to a record display form
* Enable users to browse, preview, and manage iManage documents inside a Catalyst record
* Associate a default iManage folder with a record manually
* Understand that iManage folder association can also be done programmatically via API
* Learn what iManage API Call templates are available in Sequencer
* Know authentication behavior and default loading behavior for records without an associated iManage location

## Key terms

* iManage Cloud integration
* Catalyst records
* record display form
* form builder
* iManage Cloud component
* OAuth 2.0
* iManage credentials
* associated folder
* iManage location
* API based folder assignment
* Sequencer
* API Call templates
* feature enablement

## Terminology links

* [iManage Cloud integration](/knowledgebase/terminology/#imanage-cloud-integration)
* [Catalyst record](/knowledgebase/terminology/#catalyst-record) (matched from `Catalyst records`)
* [Form builder](/knowledgebase/terminology/#form-builder)
* [iManage Cloud component](/knowledgebase/terminology/#imanage-cloud-component)
* [iManage location](/knowledgebase/terminology/#imanage-location)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [API Call template](/knowledgebase/terminology/#api-call-template) (matched from `API Call templates`)
* [feature enabled](/knowledgebase/terminology/#feature-enabled) (matched from `feature enablement`)

## Related topics

* Not provided.

## Prerequisites

* The iManage integration must be enabled
* Users must have valid iManage credentials
* Permission to edit record display forms
* Basic familiarity with System Configuration, Object Classes, and record display forms

## Not covered

* Detailed steps for enabling the integration itself
* Specific API endpoint details or example payload content
* Configuration details for OAuth 2.0 or authentication troubleshooting
* Detailed explanation of Sequencer usage beyond noting available templates
* General iManage administration outside Catalyst

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.8/imanage-in-api-call-actor/index.agent.md
---
# Agent guide: iManage in API Call actor

* **Page path:** `release-notes/release-notes-1.8/imanage-in-api-call-actor/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces iManage support in the API Call actor for document exchange between Catalyst and iManage. It explains the basic setup, required fields, and supported GET/POST methods.

## User intent

* Understand what iManage support in the API Call actor does
* Set up the API Call actor to connect to iManage
* Know that an iManage Authentication object must be created first
* Choose the correct template and authentication object
* Use GET to retrieve files from iManage
* Use POST to upload documents from Catalyst to iManage
* Identify the required Customer ID, Library ID, and Folder ID fields
* Know that URL placeholders such as {Hostname} and {documentId} must be manually filled

## Key terms

* API Call actor
* iManage
* iManage Authentication object
* Template field
* Authentication object
* GET
* POST
* Customer ID
* Library ID
* Folder ID
* discovery request
* URL input
* {Hostname}
* {documentId}
* Catalyst

## Terminology links

* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [iManage template](/knowledgebase/terminology/#imanage-template) (matched from `iManage`)
* [iManage Authentication Objects](/knowledgebase/terminology/#imanage-authentication-objects) (matched from `iManage Authentication object`)
* [Template field](/knowledgebase/terminology/#template-field)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `Authentication object`)
* [discovery request](/knowledgebase/terminology/#discovery-request)
* [URL input](/knowledgebase/terminology/#url-input)
* [{Hostname}](/knowledgebase/terminology/#hostname)

## Related topics

* Not provided.

## Prerequisites

* Familiarity with configuring the API Call actor
* Access to or ability to create an iManage Authentication object
* Knowledge of iManage identifiers such as Customer ID, Library ID, and Folder ID
* Ability to obtain Customer ID through a discovery request

## Not covered

* Detailed steps for creating the iManage Authentication object
* How to perform the discovery request
* Complete URL format or endpoint reference
* Error handling or troubleshooting details
* Any methods beyond GET and POST
* Broader iManage integration features outside the API Call actor

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.13/imanage-integration/index.agent.md
---
# Agent guide: iManage integration

* **Page path:** `release-notes/release-notes-1.13/imanage-integration/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces the iManage integration in Catalyst, letting users access iManage documents directly from Catalyst record views. It explains how to add the iManage component, authenticate users, define default iManage folders per record, and use a built-in API template in Sequencer.

## User intent

* Understand what the iManage integration in this release enables
* Add the iManage Cloud component to a Catalyst record display form
* Learn how user authentication to iManage works in Catalyst
* Set which iManage folder or matter opens by default for a record
* Associate an iManage folder with a Catalyst record from the UI
* Understand that folder assignment can also be automated via API
* Use the built-in iManage API Call template in Sequencer
* See what document actions users can perform inside Catalyst with iManage

## Key terms

* iManage integration
* Catalyst record views
* Create/edit record display form builder
* Integrations
* iManage Cloud component
* OAuth 2.0
* Authorization Code Grant flow
* Associate with Catalyst record
* folder assignment
* API endpoint
* Sequencer
* API Call template
* documents
* matters

## Terminology links

* [iManage integration](/knowledgebase/terminology/#imanage-integration)
* [Catalyst record views](/knowledgebase/terminology/#catalyst-record-views)
* [Create/edit record display form builder](/knowledgebase/terminology/#createedit-record-display-form-builder)
* [Integrations](/knowledgebase/terminology/#integrations)
* [iManage Cloud component](/knowledgebase/terminology/#imanage-cloud-component)
* [OAuth 2.0 (Authorization Code Grant flow)](/knowledgebase/terminology/#oauth-20-authorization-code-grant-flow) (matched from `Authorization Code Grant flow`)
* [Associate with Catalyst record](/knowledgebase/terminology/#associate-with-catalyst-record)
* [API endpoints](/knowledgebase/terminology/#api-endpoints) (matched from `API endpoint`)

## Related topics

* Not provided.

## Prerequisites

* The iManage integration must be active and enabled
* Access to Catalyst form design/editing if adding the component
* An iManage account for user sign-in
* Basic familiarity with Catalyst records, forms, and integrations
* For automation use cases, familiarity with API-based record setup

## Not covered

* Detailed setup steps for activating or enabling the iManage integration
* Full API endpoint syntax or complete payload specification
* Comprehensive OAuth configuration details
* Troubleshooting authentication, token expiry, or session issues
* Permissions, security policy, or admin governance details beyond the brief auth description
* Detailed Sequencer workflow examples

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.2/improved-breadcrumbs/index.agent.md
---
# Agent guide: Improved breadcrumbs

* **Page path:** `release-notes/release-notes-1.2/improved-breadcrumbs/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces refreshed breadcrumbs in the record keeping system. The new breadcrumbs show the Object Class name plus the record Identifier or ID to make navigation clearer and more efficient.

## User intent

* Understand what changed in the breadcrumbs UI
* Learn what information each breadcrumb now displays
* See how the updated breadcrumbs improve record navigation
* Determine whether the breadcrumb update helps reduce confusion when moving through record hierarchies

## Key terms

* breadcrumbs
* refreshed breadcrumbs
* Object Class name
* Identifier
* ID
* record hierarchy
* navigation
* record keeping system

## Terminology links

* [breadcrumbs](/knowledgebase/terminology/#breadcrumbs)
* [Object Class name](/knowledgebase/terminology/#object-class-name)
* [Identifier](/knowledgebase/terminology/#identifier)
* [record hierarchy](/knowledgebase/terminology/#record-hierarchy)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with navigating records in the system
* Understanding of records, object classes, and record identifiers or IDs

## Not covered

* Step-by-step instructions for using breadcrumbs
* Configuration or customization options for breadcrumbs
* Technical implementation details
* Any other navigation changes outside the refreshed breadcrumbs

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.2/improved-instructions-editor/index.agent.md
---
# Agent guide: Improved instructions editor

* **Page path:** `release-notes/release-notes-1.2/improved-instructions-editor/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces an improved instructions text editor for forms in Autologyx. It highlights new rich-text formatting and media/link features that help System Administrators create clearer, more engaging form instructions.

## User intent

* Understand what changed in the instructions editor
* See which formatting features are now available for form instructions
* Learn whether images and clickable links can be added to instructions
* Determine how the update improves end-user experience on forms
* Know who can use the enhanced editor in form builders

## Key terms

* instructions editor
* rich text instructions
* form builder
* System Administrators
* font size
* font type
* font color
* text alignment
* bullet lists
* numbered lists
* images
* clickable links

## Terminology links

* [instructions editor](/knowledgebase/terminology/#instructions-editor)
* [rich text instructions](/knowledgebase/terminology/#rich-text-instructions)
* [Form builder](/knowledgebase/terminology/#form-builder)
* [System Administrators](/knowledgebase/terminology/#system-administrators)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with forms in the Autologyx platform
* Awareness of form builder usage
* Understanding that instructions are displayed on forms

## Not covered

* Step-by-step instructions for using the editor
* Technical configuration or enablement details
* Permissions model beyond mentioning System Administrators
* Limitations, supported file types, or formatting constraints
* Any changes outside instructions editing

---

---
url: >-
  /knowledgebase-agent-guides/welcome-introduction-to-catalyst/in-application-help/index.agent.md
---
# Agent guide: In Application Help

* **Page path:** `welcome-introduction-to-catalyst/in-application-help/index.md`
* **Page type:** explanation

## What this page is about

This page is a minimal entry point to in-application help. It invites users to browse the help sections below and labels the content as public.

## User intent

* Access the in-application help starting point
* Browse available help sections within the application
* Confirm the help content classification/status

## Key terms

* In Application Help
* Welcome To In Application Help
* Classification: Unrestricted, Public

## Terminology links

* [In Application Help](/knowledgebase/terminology/#in-application-help)

## Related topics

* Not provided.

## Prerequisites

* Access to the application's help area

## Not covered

* Specific help topics or feature instructions
* Navigation details beyond browsing sections below
* Any procedural guidance or troubleshooting steps

---

---
url: >-
  /api-agent-guides/catalyst/resources/outbound-mail-setup/integrations/index.agent.md
---
# Agent guide: Integrations

* **Page path:** `catalyst/resources/outbound-mail-setup/integrations.md`
* **Page type:** reference

## What this page is about

Reference for ALX integration configurations and related API endpoints, including permissions, CRUD operations, testing, type-specific schema behavior, and iManage-specific fields. It also briefly includes SMTP settings administration endpoints.

## User intent

* Create an integration configuration via POST /api/integrations/
* List integration configurations via GET /api/integrations/
* Retrieve a single integration configuration by UUID
* Update an integration configuration via PATCH
* Delete an integration configuration via DELETE
* Check what permissions are required for integration actions
* Understand common validation rules and error responses for integrations
* See additional request/response fields for the iManage integration type
* Test an integration configuration via POST /api/integrations/test/
* Inspect schema/type-specific details through OPTIONS /api/integrations/
* View available sorting and filtering for integration lists
* Retrieve SMTP settings via /api/administration/smtp settings/

## Key terms

* integration configuration
* permissions
* list
* view
* create
* edit
* delete
* UUID
* type
* name
* description
* is enabled
* authentication object
* object class
* meta.labels
* meta.permissions
* iManage
* folder
* object class field
* dedupe
* OPTIONS /api/integrations/
* POST /api/integrations/test/
* SMTP settings

## Terminology links

* [integration configuration](/api/terminology/#integration-configuration)
* [permissions](/api/terminology/#permissions)
* [list permission](/api/terminology/#list-permission) (matched from `list`)
* [delete permission](/api/terminology/#delete-permission) (matched from `delete`)
* [Permission Set type](/api/terminology/#permission-set-type) (matched from `type`)
* [authentication objects](/api/terminology/#authentication-objects) (matched from `authentication object`)
* [object classes](/api/terminology/#object-classes) (matched from `object class`)
* [meta.labels](/api/terminology/#metalabels)

## Related topics

* Integrations technical design
* ALX API standards for predicates

## Prerequisites

* Access to ALX APIs
* Understanding of role-based permissions
* Familiarity with UUIDs, pagination, filtering, and sorting in REST APIs
* Knowledge that schema depends on integration type and can be inspected via OPTIONS
* For iManage, awareness of related objects such as AuthenticationObjectData, ObjectClass, and ObjectClassField

## Not covered

* Detailed schemas for each integration type beyond the notes to inspect OPTIONS /api/integrations/
* Full technical design content; only a reference link/title is given
* Detailed SMTP PATCH behavior, which is cut off in the provided text
* Non-iManage integration-specific request/response examples
* General ALX API predicate definitions beyond referring to ALX API standards

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.13/integrations/index.agent.md
---
# Agent guide: Integrations

* **Page path:** `release-notes/release-notes-1.13/integrations/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces a new centralized Integrations area in Catalyst under System configuration → Integrations. It explains how Super Admins can view, request, enable, and manage third-party and AI integrations, and how those integrations are used in workflows.

## User intent

* Find where integrations are managed in Catalyst
* Understand what changed about integrations in release 1.13
* See which integration categories and providers are available
* Learn how to request an integration that is not yet active
* Understand how integrations are used in workflow automation
* Determine what Super Admins can enable or disable from the Integrations screen

## Key terms

* System configuration → Integrations
* centralised integrations management
* Super Admins
* Integrations
* Applied AI
* iManage Cloud
* DocuSign
* Adobe Sign
* Microsoft
* Salesforce
* Box
* OpenAI: GPT
* OpenAI: Embeddings
* Azure OpenAI
* AWS Bedrock
* Professional Services
* Authentication Objects
* Sequencer
* API Call actors
* provider specific actors
* workflow automation

## Terminology links

* [Centralised integrations management](/knowledgebase/terminology/#centralised-integrations-management)
* [Super Admins](/knowledgebase/terminology/#super-admins)
* [Integrations](/knowledgebase/terminology/#integrations)
* [Applied AI](/knowledgebase/terminology/#applied-ai)
* [OpenAI: Embeddings](/knowledgebase/terminology/#openai-embeddings)
* [AWS Bedrock integration](/knowledgebase/terminology/#aws-bedrock-integration) (matched from `AWS Bedrock`)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects)
* [Sequencer](/knowledgebase/terminology/#sequencer)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst administration
* Understanding of Super Admin permissions
* General knowledge of Catalyst workflows and Sequencer
* Awareness of external systems such as document management, eSignature, or AI providers

## Not covered

* Detailed setup steps for specific integrations
* Configuration details for Authentication Objects or API Call actors
* Technical requirements or credentials needed for each provider
* Pricing, licensing, or availability rules for integrations
* End-user workflow examples beyond the high-level use cases listed

---

---
url: /knowledgebase-agent-guides/system-configuration/integrations/index.agent.md
---
# Agent guide: Integrations

* **Page path:** `system-configuration/integrations/index.md`
* **Page type:** explanation

## What this page is about

This page explains the Catalyst Integrations area in System Configuration, where Super admins can view, enable, manage, request, and configure integrations. It also outlines the main integration categories, common use cases, and important usage considerations.

## User intent

* Find where to manage integrations in Catalyst
* See what integrations are available or enabled
* Understand the difference between operational integrations and Applied AI integrations
* Learn what business systems and AI providers Catalyst can connect to
* Understand how integrations are used in workflows and automation
* Request an integration that is not enabled
* Check requirements such as licensing, permissions, and Authentication Objects

## Key terms

* Integrations
* System Configuration
* Super admins
* Applied AI
* Authentication Objects
* Sequencer
* API Call actors
* DocuSign
* Adobe Sign
* Microsoft
* Salesforce
* Box
* iManage Cloud
* OpenAI: GPT
* OpenAI: Embeddings
* Azure OpenAI
* AWS Bedrock
* eSignature
* semantic search
* workflow automation

## Terminology links

* [Integrations](/knowledgebase/terminology/#integrations)
* [System configuration](/knowledgebase/terminology/#system-configuration)
* [Super Admins](/knowledgebase/terminology/#super-admins)
* [Applied AI](/knowledgebase/terminology/#applied-ai)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [API Call actor](/knowledgebase/terminology/#api-call-actor) (matched from `API Call actors`)
* [OpenAI: Embeddings](/knowledgebase/terminology/#openai-embeddings)

## Related topics

* Not provided.

## Prerequisites

* Access to Catalyst System Configuration
* Super admin role for managing integration settings
* Basic understanding of Catalyst workflows and automation
* Awareness that some integrations require Authentication Objects, licensing, or feature enablement

## Not covered

* Step-by-step setup instructions for specific integrations
* Detailed configuration procedures for Authentication Objects
* Technical implementation details for API Call actors or Sequencer
* Licensing terms or pricing for individual integrations
* Detailed onboarding and setup process handled by Autologyx Professional Services

---

---
url: >-
  /knowledgebase-agent-guides/workspace/working-with-relational-records/interacting-with-associated-child-records-via-the-parent/index.agent.md
---
# Agent guide: Interacting with associated child records via the parent

* **Page path:** `workspace/working-with-relational-records/interacting-with-associated-child-records-via-the-parent/index.md`
* **Page type:** explanation

## What this page is about

Explains how to work with associated child records from within a parent record in Workspace: viewing a selected child’s summary, opening child records in a flyout, and navigating recursively through child and grandchild records.

## User intent

* View summary details for a selected child record inside a parent record
* Open a child record from the parent record as a flyout
* Understand how sidebar tabs behave for parent vs child context
* Navigate through child, grandchild, and deeper related records via breadcrumbs
* Use pagination and child search when a parent has many child records
* Understand limits and behavior when recursing through related records

## Key terms

* parent record
* child record
* grandchild record
* Relational modeller
* parent/child relationships
* create/edit view
* summary view
* Child record summary
* sidebar tabs
* fly out
* breadcrumbs
* identifier field
* pagination controls
* child search control
* root parent object class

## Terminology links

* [Records](/knowledgebase/terminology/#records) (matched from `parent record`)
* [grand child](/knowledgebase/terminology/#grand-child) (matched from `grandchild record`)
* [Relational modeller](/knowledgebase/terminology/#relational-modeller)
* [parent/child relationships](/knowledgebase/terminology/#parentchild-relationships)
* [create/edit view](/knowledgebase/terminology/#createedit-view)
* [summary view](/knowledgebase/terminology/#summary-view)
* [child record summary](/knowledgebase/terminology/#child-record-summary)
* [sidebar tabs](/knowledgebase/terminology/#sidebar-tabs)

## Related topics

* Not provided.

## Prerequisites

* Parent/child relationships have been created using the Relational modeller
* Each parent object class has been edited to add available child object classes into the create/edit view
* The system contains records with associated child records
* The user has permission to view records in each relevant object class

## Not covered

* How to create parent/child relationships in the Relational modeller
* How to configure parent object classes or create/edit views
* How to configure child summary views beyond noting their effect if missing or disabled
* Anything beyond viewing/opening/navigating associated records in Workspace
* More than 5 levels of parent/child recursion, which is the maximum supported

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequence-actors/invalid-actors-and-best-practice/index.agent.md
---
# Agent guide: Invalid Actors and Best Practice

* **Page path:** `system-configuration/sequence-actors/invalid-actors-and-best-practice/index.md`
* **Page type:** explanation

## What this page is about

This page explains the Release 13.0 change where invalidly configured Actors are marked with warnings and are no longer processed by the Sequencer. It describes why some workflows previously relied on invalid Actors and gives recommended alternatives for reusing Trigger logic and safely synchronising parallel branches.

## User intent

* Understand what changed for invalid Actors in Release 13.0
* Learn why invalid Actors are no longer processed
* Replace invalid Update Record Actors used as workflow merge points
* Reuse complex Trigger logic without manually rebuilding it
* Avoid race conditions when parallel branches converge
* Decide when to use sequential processing instead of parallel branches
* Implement a safe merge pattern using Local Variables and Trigger gates

## Key terms

* Invalid Actors
* Sequencer
* warning icon
* missing or invalid configuration
* Update Record Actor
* Trigger
* Copy Trigger
* Paste Trigger
* parallel workflow branches
* merge point
* Holding Bay
* race condition
* execution queue
* sequential processing
* Local Variables
* Trigger Gates
* gate variable
* Jinja logic

## Terminology links

* [Invalid Actors](/knowledgebase/terminology/#invalid-actors)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [warning icon](/knowledgebase/terminology/#warning-icon)
* [Update Record actor](/knowledgebase/terminology/#update-record-actor)
* [Triggers](/knowledgebase/terminology/#triggers) (matched from `Trigger`)
* [Copy Trigger](/knowledgebase/terminology/#copy-trigger)
* [Paste Trigger](/knowledgebase/terminology/#paste-trigger)
* [parallel branches](/knowledgebase/terminology/#parallel-branches) (matched from `parallel workflow branches`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Sequences, Actors, and Triggers in Autologyx
* Familiarity with parallel versus sequential workflow design
* Basic knowledge of Local Variables
* Awareness of workflow conditions and branching logic

## Not covered

* A full general guide to all Actor types
* Detailed setup instructions for every Trigger condition type
* General Jinja templating documentation beyond the example use here
* Broader release notes outside the invalid Actor behaviour change
* Task completion tracking beyond the note that Local Variables cannot directly reference Task completion

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.2/json-type-field/index.agent.md
---
# Agent guide: JSON type field

* **Page path:** `release-notes/release-notes-1.2/json-type-field/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces a new JSON field type in the Autologyx platform. It explains that JSON fields can be added to classes, used in record forms, and formatted with a beautify icon for easier readability.

## User intent

* Understand what the new JSON field type does
* Learn where JSON fields can be used in Autologyx
* Find out how to format entered JSON data for readability
* Assess whether JSON fields help with storing complex data structures

## Key terms

* JSON field
* classes
* record forms
* beautify icon
* complex data structures
* data readability
* data management

## Terminology links

* [JSON fields](/knowledgebase/terminology/#json-fields) (matched from `JSON field`)
* [classes](/knowledgebase/terminology/#classes)
* [record forms](/knowledgebase/terminology/#record-forms)
* [beautify icon](/knowledgebase/terminology/#beautify-icon)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx classes and record forms
* General understanding of JSON data

## Not covered

* Detailed setup or configuration steps for adding JSON fields
* Validation rules, schema enforcement, or limitations of JSON fields
* Examples of supported JSON structures
* API behavior or export/import implications
* Permissions, security, or governance details for JSON fields

---

---
url: /knowledgebase-agent-guides/terminology/index.agent.md
---
# Agent guide: Knowledgebase terminology index

* **Page path:** `terminology/index.md`
* **Page type:** reference

## What this page is about

A terminology index built from a saved terminology store for Autologyx. It defines UI controls, columns, account types, and related admin/end-user concepts, with short summaries, relevance, and related concepts.

## User intent

* Look up the meaning of a specific Autologyx term or UI label
* Understand what a button, column, or account type does
* See who a term is most relevant to (for example end users, Configuration admins, Super Admins)
* Distinguish closely related concepts such as # Members vs # Owners
* Understand where in the platform a term is used and why it matters

## Key terms

* # Members
* # Owners
* # Tasks created
* * Add as members button
* * Add button
* * Add columns
* * Add columns button
* * Add permission set button
* * Create button
* * Create record button
* * Create task button
* +Add as members
* +Create button
* +Create task
* .docx merge fields
* .embedded
* 1 time completion
* 1 time completion account type
* 1 time completion user

## Terminology links

* [# Members](/knowledgebase/terminology/#members)
* [# Owners](/knowledgebase/terminology/#owners)
* [# Tasks created](/knowledgebase/terminology/#tasks-created)
* [+ Add as members button](/knowledgebase/terminology/#add-as-members-button)
* [+ Add button](/knowledgebase/terminology/#add-button)
* [+ Add columns](/knowledgebase/terminology/#add-columns)
* [+ Add columns button](/knowledgebase/terminology/#add-columns-button)
* [+ Add permission set button](/knowledgebase/terminology/#add-permission-set-button)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the Autologyx platform
* Awareness of Autologyx administration vs workspace areas
* Some understanding of users, user groups, permissions, records, tasks, and document templates

## Not covered

* Step-by-step procedures beyond brief summaries
* Complete documentation for each related concept or page
* Detailed configuration rules except where noted in summaries
* Concepts marked as insufficient evidence, such as +Create task, are not substantively defined here

---

---
url: /knowledgebase-agent-guides/system-configuration/landing-page/index.agent.md
---
# Agent guide: Landing Page

* **Page path:** `system-configuration/landing-page/index.md`
* **Page type:** explanation

## What this page is about

This is a landing page that directs users to browse sections related to configuring the landing page and reading a welcome/introduction to Catalyst Autologyx.

## User intent

* Find where to configure the landing page
* Access the welcome and introduction to Catalyst Autologyx
* Navigate to introductory system-configuration content

## Key terms

* Landing Page
* Configure The Landing Page
* Welcome And Introduction To Catalyst Autologyx
* Catalyst Autologyx

## Terminology links

* [Landing page](/knowledgebase/terminology/#landing-page)
* [How To Configure The Landing Page](/knowledgebase/terminology/#how-to-configure-the-landing-page) (matched from `Configure The Landing Page`)

## Related topics

* Not provided.

## Prerequisites

* No specific prior knowledge is stated

## Not covered

* Detailed landing page configuration steps
* The actual welcome/introduction content
* Broader system configuration details beyond the linked sections

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/landing-page-and-theme/index.agent.md
---
# Agent guide: Landing Page And Theme

* **Page path:** `system-configuration/landing-page-and-theme/index.md`
* **Page type:** explanation

## What this page is about

This page is intended to cover landing page and theme configuration, but it is currently empty or under construction.

## User intent

* Check whether documentation exists for landing page and theme settings
* Find guidance on configuring the landing page or theme

## Key terms

* Landing Page
* Theme
* under construction

## Terminology links

* [Landing page](/knowledgebase/terminology/#landing-page)
* [Theme](/knowledgebase/terminology/#theme)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Any instructions for configuring the landing page
* Any details about theme customization
* Settings, options, or procedures related to this topic

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/formbuilder-components/layout---sections-and-instructions/index.agent.md
---
# Agent guide: Layout - Sections and Instructions

* **Page path:** `record-and-task-forms/formbuilder-components/layout---sections-and-instructions/index.md`
* **Page type:** explanation

## What this page is about

Explains how to use the Formbuilder Layout components for Sections and Instructions, including configuring section properties, columns, spacing, and conditional visibility. It also covers moving/removing sections and adding/editing/removing Instruction components.

## User intent

* Find where Sections and Instructions are located in the formbuilder
* Understand why sections are required and how many can be added
* Configure section properties such as label, alias, header visibility, columns, ratios, and spacing
* Learn which layout options differ by system area or view type
* Use conditional visibility to show or hide sections based on field values
* Move, collapse, and remove sections safely
* Remove columns from a section and understand confirmation behavior
* Add, edit, preview, and delete an Instruction component
* Understand Object class Card view limits and exceptions

## Key terms

* Layout
* Section
* Instruction component
* Section Properties
* Conditional Visibility
* Label
* Alias
* Show this section header
* Columns
* Column ratios
* Spacing around the fields
* Spacing within the fields
* Card view
* Create and edit view
* Summary view
* Standalone forms
* Task Template
* canvas

## Terminology links

* [Layout](/knowledgebase/terminology/#layout)
* [Workspace Sections](/knowledgebase/terminology/#workspace-sections) (matched from `Section`)
* [Sections and Instructions components](/knowledgebase/terminology/#sections-and-instructions-components) (matched from `Instruction component`)
* [Section Properties](/knowledgebase/terminology/#section-properties)
* [Conditional Visibility](/knowledgebase/terminology/#conditional-visibility)
* [Label](/knowledgebase/terminology/#label)
* [Alias](/knowledgebase/terminology/#alias)
* [Show this section header](/knowledgebase/terminology/#show-this-section-header)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the formbuilder interface
* Understanding of forms, fields, and side panel configuration
* Some awareness of different system areas or view types such as Card view and Task Template

## Not covered

* Detailed instructions for configuring fields or other non-layout components
* Full explanation of conditional logic beyond linking to further information
* General form creation outside Sections and Instructions
* Behavior of the Object class Card view beyond the section/component limits and noted exceptions

---

---
url: /api-agent-guides/catalyst/resources/limits/index.agent.md
---
# Agent guide: Limits

* **Page path:** `catalyst/resources/limits.md`
* **Page type:** reference

## What this page is about

This page describes the API endpoint for retrieving system limits in Catalyst. It lists the GET /api/limits/ endpoint, required permissions, and the response structure for counts and maximum limits across various resource types and additional limit categories.

## User intent

* Find the API endpoint for viewing current system limits
* Understand what limit categories are returned by the limits API
* Check which resources include both current count and maximum permitted limit
* See which additional limits are returned without counts
* Understand the response schema for system limits data
* Verify permission requirements for accessing limits information

## Key terms

* GET /api/limits/
* system limits
* permissions
* count
* limit
* object classes
* task group templates
* task templates
* sequences
* user groups
* roles
* single sign on configurations
* authentication objects
* custom components
* additional limits
* object class fields
* object records per object class
* user group members
* object record owners
* object class owners
* object class permission sets
* record permission sets
* ui configs
* public files
* object relations

## Terminology links

* [permissions](/api/terminology/#permissions)
* [count](/api/terminology/#count)
* [limit](/api/terminology/#limit)
* [object classes](/api/terminology/#object-classes)
* [task group templates](/api/terminology/#task-group-templates)
* [task templates](/api/terminology/#task-templates)
* [Sequences](/api/terminology/#sequences)
* [user groups](/api/terminology/#user-groups)

## Related topics

* Custom Components
* Files
* Roles
* Security Rules

## Prerequisites

* Basic familiarity with making authenticated API requests
* Understanding of Catalyst resources such as object classes, roles, user groups, and custom components
* Access with the required permission for the limits endpoint

## Not covered

* How to change or increase any limits
* Examples of request headers or sample requests/responses
* Detailed explanation of the required permission name
* Behavior of related resources beyond their reported limits
* Error details beyond noting standard validation errors

---

---
url: >-
  /knowledgebase-agent-guides/finding-your-way-around/ui-and-navigation/list-page-filter-editor/index.agent.md
---
# Agent guide: List page filter editor

* **Page path:** `finding-your-way-around/ui-and-navigation/list-page-filter-editor/index.md`
* **Page type:** explanation

## What this page is about

This page explains how to use the list page filter editor to narrow list results by defining one or more filter conditions. It covers opening the filter panel, choosing fields/operators/values, applying filters, viewing filtered results, and removing conditions.

## User intent

* Find rows in a list page that match specific conditions
* Open the filter editor and understand where it appears
* Add a filter by selecting a field, operator, and value
* Use multiple filter conditions to narrow results further
* Understand how filtered results are shown and cleared
* Use operator-specific inputs such as date or number ranges
* Remove individual filters or clear all conditions
* Understand filter editor behavior and limitations

## Key terms

* list page filter editor
* filter panel
* filter condition
* field
* operator
* Apply filter
* Filtered results
* Remove all
* side stack
* operator-specific inputs

## Terminology links

* [list page filter editor](/knowledgebase/terminology/#list-page-filter-editor)
* [Panels](/knowledgebase/terminology/#panels) (matched from `filter panel`)
* [Loop filters](/knowledgebase/terminology/#loop-filters) (matched from `filter condition`)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `field`)
* [Apply filter](/knowledgebase/terminology/#apply-filter)
* [Remove all](/knowledgebase/terminology/#remove-all)
* [Components panel](/knowledgebase/terminology/#components-panel) (matched from `side stack`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with navigating list pages
* Understanding that list pages contain rows and columns

## Not covered

* How to create or edit records in list pages
* Detailed definitions of every operator for every field type
* How page controls other than filters work
* Advanced filter logic such as OR conditions; the page only describes conditions that all must match

---

---
url: >-
  /knowledgebase-agent-guides/finding-your-way-around/ui-and-navigation/list-pages/index.agent.md
---
# Agent guide: List pages

* **Page path:** `finding-your-way-around/ui-and-navigation/list-pages/index.md`
* **Page type:** explanation

## What this page is about

This page explains the common layout, controls, columns, and behaviors used on Catalyst list pages. It covers how users view, navigate, sort, resize, scroll, select, and open items in lists.

## User intent

* Understand the standard controls available on Catalyst list pages
* Find out what the list name, results count, create button, filter editor, and column configuration do
* Learn how paging works, including rows per page and infinite scrolling
* See which default columns appear on list pages and how they vary by list type
* Understand how to select a row or open an item for editing
* Learn how sorting and column resizing behave on list pages
* Understand scrolling behavior and which controls remain visible while scrolling

## Key terms

* list pages
* list name
* results
* * Create
* filter editor
* column configuration
* page controls
* rows per page
* infinite scrolling
* First page
* Previous page
* Next page
* Last page
* main content area
* ID
* Name
* Created
* Last Edited
* Last Logged In
* Actions
* kebab menu
* sorting
* column resizing
* vertical scrolling
* horizontal scrolling
* side panel
* Edit mode

## Terminology links

* [list pages](/knowledgebase/terminology/#list-pages)
* [list page filter editor](/knowledgebase/terminology/#list-page-filter-editor) (matched from `filter editor`)
* [Column configuration](/knowledgebase/terminology/#column-configuration)
* [Page controls](/knowledgebase/terminology/#page-controls)
* [main content window](/knowledgebase/terminology/#main-content-window) (matched from `main content area`)
* [Identifier](/knowledgebase/terminology/#identifier) (matched from `ID`)
* [Created status](/knowledgebase/terminology/#created-status) (matched from `Created`)
* [Actions menu](/knowledgebase/terminology/#actions-menu) (matched from `Actions`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with navigating Catalyst
* Awareness that different list pages show different types of system objects
* Relevant permissions to edit items if opening them in Edit mode

## Not covered

* Detailed instructions for using the filter editor
* Detailed instructions for column configuration
* How to create or edit specific record types
* The exact actions available in the Actions menu for each list page or role
* Role and permission configuration
* Detailed behavior of the side panel beyond selection updates

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/apis-and-variables/local-variable-actor/index.agent.md
---
# Agent guide: Local Variable Actor

* **Page path:** `system-configuration/apis-and-variables/local-variable-actor/index.md`
* **Page type:** explanation

## What this page is about

This page explains the Local Variable Actor, which evaluates logic and stores temporary data for use within a Sequence. It covers how to configure variables, supported types and sources, testing, reuse across branches, and important execution limits/behaviour.

## User intent

* Understand what the Local Variable Actor is used for
* Add and configure a Local Variable Actor in a Sequence
* Define a variable name, type, source, and value
* Use Jinja expressions and merge fields in variable values
* Store data from current records, relational data, document pickers, API responses, or loop items
* Reuse or recalculate the same variable later in a Sequence
* Test a variable against a record before running the Sequence
* Know why a variable-based Trigger may not fire before the variable exists
* Understand limitations such as non-persistence, no record updates, and no activity log visibility
* Avoid type mismatches and whitespace issues that cause variable failures

## Key terms

* Local Variable Actor
* Sequence
* Jinja
* merge fields
* relational data
* Name
* Type
* Source
* Value
* Static Value
* Document Picker
* API Call Output
* Loop Item
* Loop Item Processed
* Actor Completed
* Document
* JSON
* Gate Variables
* Trigger
* Is Empty
* Is Not Empty
* Record ID

## Terminology links

* [Local Variable Actor](/knowledgebase/terminology/#local-variable-actor)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequence`)
* [Jinja merge fields](/knowledgebase/terminology/#jinja-merge-fields) (matched from `Jinja`)
* [merge fields](/knowledgebase/terminology/#merge-fields)
* [relational model](/knowledgebase/terminology/#relational-model) (matched from `relational data`)
* [field types](/knowledgebase/terminology/#field-types) (matched from `Type`)
* [Source field](/knowledgebase/terminology/#source-field) (matched from `Source`)
* [Value field](/knowledgebase/terminology/#value-field) (matched from `Value`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Sequences and Actors
* Familiarity with Triggers
* Basic knowledge of Jinja expressions
* Awareness of record fields and relational parent/child data

## Not covered

* How to update records using other Actors
* How Trigger configuration works in general beyond the noted variable existence behaviour
* Detailed Jinja syntax or full whitespace control guidance
* Detailed API Call Actor configuration
* Detailed Document Picker or Loop Actor setup
* Cross-Sequence persistence or long-term data storage

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/about-system-configuration/managing-authentication-methods-by-user-account-type/index.agent.md
---
# Agent guide: Managing authentication methods by user account type

* **Page path:** `system-configuration/about-system-configuration/managing-authentication-methods-by-user-account-type/index.md`
* **Page type:** explanation

## What this page is about

This page explains that from Catalyst version 11.2.0, authentication methods can be configured and enforced per user account type via API. It describes the allowed account types and authentication options, how updates behave, and how enforcement applies to login and password reset flows.

## User intent

* Understand how to control password vs SSO access by user account type
* Find which user account types can have authentication rules configured
* Learn which authentication method values are supported
* Understand how partial API updates affect existing account type settings
* Check how Catalyst enforces authentication restrictions during login
* Understand how authentication rules affect password reset actions
* Avoid locking users out when setting SSO-only authentication

## Key terms

* Catalyst 11.2.0
* authentication methods
* user account type
* API configuration
* password login
* Single Sign On (SSO)
* external users
* internal staff accounts
* Config Admin users
* full platform access accounts
* authentication enforcement
* password reset enforcement

## Terminology links

* [authentication method management](/knowledgebase/terminology/#authentication-method-management) (matched from `authentication methods`)
* [User Account Types](/knowledgebase/terminology/#user-account-types) (matched from `user account type`)
* [API configuration](/knowledgebase/terminology/#api-configuration)
* [Single Sign On (SSO)](/knowledgebase/terminology/#single-sign-on-sso)
* [External users](/knowledgebase/terminology/#external-users)
* [Internal staff accounts](/knowledgebase/terminology/#internal-staff-accounts)
* [Config Admin users](/knowledgebase/terminology/#config-admin-users)
* [Accounts with full platform access](/knowledgebase/terminology/#accounts-with-full-platform-access) (matched from `full platform access accounts`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of user account types in Catalyst
* Knowledge of password-based authentication and SSO
* Appropriate permission to view or change authentication configuration via API
* SSO must already be configured and tested before using SSO-only settings

## Not covered

* Exact API endpoint URLs or example request bodies
* How to configure SSO itself
* How permissions are granted to authorised users
* Detailed error messages shown to users
* UI-based configuration steps

---

---
url: >-
  /knowledgebase-agent-guides/workspace/records/manual-creation-of-object-records/index.agent.md
---
# Agent guide: Manual creation of Object records

* **Page path:** `workspace/records/manual-creation-of-object-records/index.md`
* **Page type:** explanation

## What this page is about

This page explains how to manually create Object records from the Records list in the Workspace and what conditions, validations, and UI behaviors apply during creation.

## User intent

* Create a new Object record from the Records list
* Understand how required fields affect saving a record
* Resolve errors caused by duplicate values in Unique fields
* Know what permissions and configuration are needed to create records
* Understand what happens after a record is created and how to leave the form

## Key terms

* Workspace
* Records
* Tasks
* Object record
* Records list
* * Create record button
* Object class
* create record form
* required fields
* red asterisk
* Unique field
* * Create button
* success toast
* breadcrumb menu
* Create/Edit view
* Display tab
* Permission set
* Super Admin
* Owner
* Revert button
* side panel

## Terminology links

* [Workspace](/knowledgebase/terminology/#workspace)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `Records`)
* [Tasks](/knowledgebase/terminology/#tasks)
* [Records list](/knowledgebase/terminology/#records-list)
* [+ Create record button](/knowledgebase/terminology/#create-record-button)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [create record form](/knowledgebase/terminology/#create-record-form)
* [Required](/knowledgebase/terminology/#required) (matched from `required fields`)

## Related topics

* Not provided.

## Prerequisites

* Access to the Workspace
* Permission to create Object records through Super Admin, Object class ownership, or a suitable Permission set
* An Object class with the Create/Edit view enabled in the Display tab
* Awareness of which Object class you want to create a record in if multiple classes are available

## Not covered

* How to configure Object classes or create forms
* How to enable the Create/Edit view in the Display tab
* How permission sets are configured
* Creating records from methods other than the Records list
* Details of Tasks functionality beyond mentioning its presence
* Anything beyond manual creation, validation, and basic navigation behavior

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/working-with-document-templates/manual-generation-of-a-document-from-a-template/index.agent.md
---
# Agent guide: Manual generation of a document from a template

* **Page path:** `system-configuration/working-with-document-templates/manual-generation-of-a-document-from-a-template/index.md`
* **Page type:** explanation

## What this page is about

Explains how to manually generate documents from a template for a record using the Templates tab, and the two available actions: downloading the document or saving it to a document field.

## User intent

* How do I manually generate a document from a template?
* What does the template Actions menu do?
* How do I generate and download a document for a record?
* How do I generate a document and save it to a document-type field?
* Why did document generation fail or show no status?
* Can manual document generation be repeated multiple times?

## Key terms

* manual generation
* document template
* Templates tab
* Actions menu
* Generate and download document
* Generate and save to field
* Document type fields
* Object class
* record
* status field
* incorrect merges
* IF Statements

## Terminology links

* [manual generation](/knowledgebase/terminology/#manual-generation)
* [Document Templates](/knowledgebase/terminology/#document-templates) (matched from `document template`)
* [Templates tab](/knowledgebase/terminology/#templates-tab)
* [Actions menu](/knowledgebase/terminology/#actions-menu)
* [Generate and download document](/knowledgebase/terminology/#generate-and-download-document)
* [Generate and save to field](/knowledgebase/terminology/#generate-and-save-to-field)
* [document type fields](/knowledgebase/terminology/#document-type-fields)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)

## Related topics

* Not provided.

## Prerequisites

* A document template has already been created with manual generation enabled.
* The template is available for records in the relevant object class.
* The object class includes document-type fields if using save to field.

## Not covered

* How to create or configure the document template itself.
* How to enable manual generation on a template.
* Detailed troubleshooting beyond checking incorrect merges or IF statements.
* Automatic document generation or other generation methods.
* Broader object class or field configuration steps.

---

---
url: /knowledgebase-agent-guides/system-configuration/merge-fields/index.agent.md
---
# Agent guide: Merge Fields

* **Page path:** `system-configuration/merge-fields/index.md`
* **Page type:** explanation

## What this page is about

This page is an index for Merge Fields documentation. It lists the main topics available for working with merge fields in document templates and related configuration details.

## User intent

* Find documentation on using .docx merge fields for document assembly
* Learn how to use conditional logic in merge fields
* Understand configuration and usage of image merge fields
* Learn how whitespace control works in Jinja and why it matters
* Review available field types and formatting options
* Understand record properties syntax for merge fields
* Learn about namespace usage in Jinja2 for document templates
* Find information related to users and groups in the merge field context

## Key terms

* Merge Fields
* Document Assembly
* .docx Merge Field
* Conditional Logic
* Image Merge Field
* Whitespace Control
* Jinja
* Field Types
* Formatting
* Record Properties
* Syntax For Merge Fields
* Namespace
* Jinja2
* Document Templates
* Users And Groups

## Terminology links

* [merge fields](/knowledgebase/terminology/#merge-fields)
* [Dynamic document assembly](/knowledgebase/terminology/#dynamic-document-assembly) (matched from `Document Assembly`)
* [.docx merge fields](/knowledgebase/terminology/#docx-merge-fields) (matched from `.docx Merge Field`)
* [conditional logic](/knowledgebase/terminology/#conditional-logic)
* [Image merge fields](/knowledgebase/terminology/#image-merge-fields) (matched from `Image Merge Field`)
* [whitespace control](/knowledgebase/terminology/#whitespace-control)
* [Jinja merge fields](/knowledgebase/terminology/#jinja-merge-fields) (matched from `Jinja`)
* [field types](/knowledgebase/terminology/#field-types)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with document templates
* Some awareness of merge fields and Jinja-based templating concepts

## Not covered

* Detailed instructions for any listed topic are not included on this page
* Specific examples, procedures, or configuration steps are not provided here
* No nearby related page titles are supplied beyond the section links listed on this page

---

---
url: /api-agent-guides/merge-fields/resources/custom-filters/index.agent.md
---
# Agent guide: Merge fields Custom Filters

* **Page path:** `merge-fields/resources/custom-filters.md`
* **Page type:** explanation

## What this page is about

This page explains custom filters for merge fields, which add advanced operations beyond basic merge fields. It covers filters for date/time shifting, image embedding, DOCX embedding, and rendering merge fields stored inside string content.

## User intent

* Understand what custom merge field filters are used for
* Manipulate date/time values in merge fields
* Embed images from document field attachments into templates
* Control embedded image dimensions and ratio behavior
* Embed DOCX attachments with preserved formatting
* Render nested merge fields contained inside string values
* Learn availability and usage contexts for custom filters
* Understand error handling and limitations of each filter type

## Key terms

* custom filters
* merge fields
* date and time manipulation
* reference date/time
* ISO format
* local time
* weekend exclusion
* image embedding
* document field alias
* attachment index
* supported image formats
* dimension control
* ratio preservation
* DOCX embedding
* paragraph replacement syntax
* docxtpl
* merge field rendering
* nested merge fields
* single level processing
* non recursive processing
* string field types
* Templates panel
* Sequence Actors
* Send Message Actor
* Variable Actor
* API Call Actor
* Doc Auto Actor

## Terminology links

* [Custom filters](/api/terminology/#custom-filters)
* [Merge fields](/api/terminology/#merge-fields)
* [Date and Time Manipulation](/api/terminology/#date-and-time-manipulation)
* [Image embedding](/api/terminology/#image-embedding)
* [Document field alias](/api/terminology/#document-field-alias)
* [DOCX embedding](/api/terminology/#docx-embedding)
* [Paragraph replacement syntax](/api/terminology/#paragraph-replacement-syntax)
* [Merge Field Rendering](/api/terminology/#merge-field-rendering)

## Related topics

* 📄 Autologyx – Merge Fields Guide
* 🎯 MF Context Scopes Availability
* 🎯 MF used in sequencer

## Prerequisites

* Basic understanding of merge fields
* Familiarity with template usage in document generation
* Awareness of document fields and attachments
* Basic knowledge of Jinja-style filter behavior

## Not covered

* General merge field basics in full detail
* Complete syntax examples for every filter
* Implementation details beyond the noted docxtpl usage
* Recursive nested rendering beyond one level
* Formatting customization for embedded DOCX content
* Use of unsupported file formats beyond stated silent ignore behavior

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.8/microsoft-authentication-object/index.agent.md
---
# Agent guide: Microsoft authentication object

* **Page path:** `release-notes/release-notes-1.8/microsoft-authentication-object/index.md`
* **Page type:** release-notes

## What this page is about

This release note describes how to create and configure a Microsoft authentication object in Catalyst using OAuth 2.0 client credentials flow. It lists the required fields and notes testing the object before using it in API call sequences.

## User intent

* Set up a Microsoft authentication object for Catalyst's Microsoft integration
* Understand which OAuth 2.0 provider option to select
* Know the required authentication fields: Tenant, Client ID, Client Secret, and Scope
* Validate the authentication object before using it in sequences with Microsoft APIs

## Key terms

* Microsoft authentication object
* Catalyst Microsoft integration
* OAuth 2.0
* Client Credentials flow
* Tenant
* Client ID
* Client Secret
* Scope
* .default
* Microsoft Graph
* API calls
* sequences

## Terminology links

* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `Microsoft authentication object`)
* [Authentication client credentials flow](/knowledgebase/terminology/#authentication-client-credentials-flow) (matched from `Client Credentials flow`)
* [Tenant](/knowledgebase/terminology/#tenant)
* [Client ID](/knowledgebase/terminology/#client-id)
* [Client Secret](/knowledgebase/terminology/#client-secret)
* [Scope](/knowledgebase/terminology/#scope)
* [API calls](/knowledgebase/terminology/#api-calls)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `sequences`)

## Related topics

* Not provided.

## Prerequisites

* A Microsoft app registration with a Client ID and Client Secret
* Knowledge of the target Microsoft resource/app ID URI
* Basic familiarity with Catalyst sequences and API calls

## Not covered

* Detailed steps for creating a Microsoft app registration
* How to obtain tenant, client ID, or client secret values
* Specific example scope value text beyond noting the .default suffix and Microsoft Graph example
* How to build full Microsoft API sequences after authentication
* Troubleshooting authentication errors or permission configuration details

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.11/microsoft-oauth-in-outbound-mail-setup/index.agent.md
---
# Agent guide: Microsoft oAuth in outbound mail setup

* **Page path:** `release-notes/release-notes-1.11/microsoft-oauth-in-outbound-mail-setup/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces Microsoft Office 365 Exchange (Graph) with OAuth 2.0 as a new outbound mail setup option. It explains that this replaces older SMTP/basic-auth approaches with a more secure Microsoft Graph-based method and outlines the main configuration expectations.

## User intent

* Understand the new outbound mail option for Microsoft Office 365 Exchange (Graph) with OAuth 2.0
* Learn why Microsoft Graph with OAuth 2.0 is being introduced for outbound mail
* Identify what must be configured to use Microsoft client credentials for outbound email
* See which standard outbound mail fields still apply regardless of mail service
* Confirm that the outbound mail setup can be tested before saving

## Key terms

* Microsoft Office 365 Exchange (Graph)
* OAuth 2.0
* Outbound Mail Setup
* Microsoft Graph API
* SMTP
* Basic Authentication
* Microsoft Client Credentials Authentication Object
* Azure environment
* Host and Port
* TLS
* Username
* From email address
* Backend failure alerts email address

## Terminology links

* [Microsoft Office 365 Exchange (Graph) with oAuth 2.0](/knowledgebase/terminology/#microsoft-office-365-exchange-graph-with-oauth-20) (matched from `Microsoft Office 365 Exchange (Graph)`)
* [Outbound mail setup](/knowledgebase/terminology/#outbound-mail-setup)
* [Microsoft Client Credentials Authentication Object](/knowledgebase/terminology/#microsoft-client-credentials-authentication-object)
* [Azure environment](/knowledgebase/terminology/#azure-environment)
* [TLS field](/knowledgebase/terminology/#tls-field) (matched from `TLS`)
* [Username](/knowledgebase/terminology/#username)
* [From email address](/knowledgebase/terminology/#from-email-address)
* [Backend failure alerts email address](/knowledgebase/terminology/#backend-failure-alerts-email-address)

## Related topics

* Configuring Outbound mail setup with Microsoft client credentials

## Prerequisites

* Basic familiarity with outbound mail setup
* An existing Microsoft Client Credentials Authentication Object in the system
* A properly configured Azure environment that allows email sending
* General understanding of Microsoft authentication changes away from Basic Authentication

## Not covered

* Step-by-step Azure configuration details
* How to create the Microsoft Client Credentials Authentication Object
* Detailed Microsoft Graph API implementation specifics
* General inbound mail configuration
* Non-Microsoft mail provider setup instructions

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/working-with-document-templates/ms-word-add-in---configuration/index.agent.md
---
# Agent guide: MS Word add-in - configuration

* **Page path:** `system-configuration/working-with-document-templates/ms-word-add-in---configuration/index.md`
* **Page type:** reference

## What this page is about

This page explains how to configure the Catalyst MS Word add-in, including setting up SSO in Autologyx, creating and configuring the Azure app registration, generating and uploading the manifest file, and making the add-in available in Microsoft Word. It also notes key prerequisites, required Azure permissions, and a few usage constraints.

## User intent

* Understand what is required to configure the Catalyst Word add-in
* Check prerequisite permissions and access needed across Autologyx, Azure, and Microsoft 365
* Generate a manifest file with the Azure Enterprise/Application registration ID embedded
* Configure Azure registration settings, token claims, API permissions, API exposure, and scope
* Find the required Microsoft Office client ID for authorized client applications
* Upload the Word add-in manifest to the Microsoft Admin Center
* Make the add-in available to selected users in Word
* Insert and activate the Catalyst Word add-in inside Microsoft Word
* Confirm minimum Catalyst permissions needed for users to select object record fields
* Understand basic limits such as supported file type and maximum number of SSO configurations

## Key terms

* Catalyst Word add-in
* document templates
* Single sign on settings
* SSO
* Autologyx domain
* Super Admin
* Standard account
* Azure Enterprise Application
* Application registration
* Application (client) ID
* Directory (tenant) ID
* Client secret
* manifest file
* manifest.xml
* Redirect / Callback URI
* Logout URL
* Token configuration
* optional claims
* ID token
* API permissions
* delegated permissions
* email
* User.Read
* User.Read.All
* Expose an API
* Application ID URI
* scope
* openid
* Authorized client applications
* Microsoft Office client ID
* Microsoft Admin Center
* Integrated apps
* Upload custom apps
* Office Add-in
* .docx

## Terminology links

* [Catalyst Word Add in](/knowledgebase/terminology/#catalyst-word-add-in) (matched from `Catalyst Word add-in`)
* [Document Templates](/knowledgebase/terminology/#document-templates)
* [Single sign on settings](/knowledgebase/terminology/#single-sign-on-settings)
* [Single sign on](/knowledgebase/terminology/#single-sign-on) (matched from `SSO`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super Admin`)
* [Standard account type](/knowledgebase/terminology/#standard-account-type) (matched from `Standard account`)
* [Client Secret](/knowledgebase/terminology/#client-secret)
* [Redirect / Callback URI](/knowledgebase/terminology/#redirect-callback-uri)

## Related topics

* Not provided.

## Prerequisites

* Access to the Autologyx domain being configured, with permission to configure Single sign on settings
* A Super Admin account or a Standard account whose role includes Single Sign On create and edit permissions
* Access to the Microsoft Azure domain admin area with permission to create or edit Enterprise Applications
* Access to the Microsoft 365 admin center with permission to upload custom add-ins
* Basic familiarity with Azure application registration and Microsoft admin workflows
* A Word document template in .docx format

## Not covered

* Detailed instructions for configuring User Single Sign on authentication beyond referenced external/help articles
* How to use the Word add-in after configuration
* Broader document template design guidance beyond enabling the add-in
* Troubleshooting failed Azure, Microsoft 365, or Word deployments
* Non-.docx document template formats

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.11/multipart-data-support-in-api-call-actor/index.agent.md
---
# Agent guide: Multipart data support in API Call actor

* **Page path:** `release-notes/release-notes-1.11/multipart-data-support-in-api-call-actor/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces Multipart Data support in the API Call actor for POST requests. It explains how to configure multipart requests containing both text parameters and file attachments, including part types, required fields, and request behavior.

## User intent

* Understand what Multipart Data support adds to the API Call actor
* Configure a POST API Call actor to send text and file parts in one request
* Send metadata and file attachments together to APIs such as DocuSign
* Learn the required fields for text parts and file parts
* Understand how part ordering and file selection work in multipart requests
* Validate and test multipart requests before saving

## Key terms

* API Call actor
* Multipart Data
* POST method
* Multipart Configuration
* Text part
* File part
* Content Disposition
* Content Type
* Body
* Document Picker
* DocuSign
* request parts

## Terminology links

* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [Multipart Data](/knowledgebase/terminology/#multipart-data)
* [Multipart Configuration](/knowledgebase/terminology/#multipart-configuration)
* [Text parts](/knowledgebase/terminology/#text-parts) (matched from `Text part`)
* [File parts](/knowledgebase/terminology/#file-parts) (matched from `File part`)
* [Content Disposition](/knowledgebase/terminology/#content-disposition)
* [Content Type](/knowledgebase/terminology/#content-type)
* [Document Picker actor](/knowledgebase/terminology/#document-picker-actor) (matched from `Document Picker`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with configuring an API Call actor
* Understanding of POST requests
* Knowledge of the target API's required parameter names and multipart format
* A connected Document Picker for file attachments

## Not covered

* General API Call actor setup beyond multipart-specific configuration
* Details for HTTP methods other than POST
* Comprehensive examples for specific third-party APIs
* Authentication, headers, or other non-multipart request settings
* Advanced multipart standards beyond the fields described here

---

---
url: /knowledgebase-agent-guides/finding-your-way-around/my-account/index.agent.md
---
# Agent guide: My Account

* **Page path:** `finding-your-way-around/my-account/index.md`
* **Page type:** explanation

## What this page is about

This page is a brief overview of the My Account area and points users to sections about what is included in My Account and what can be edited there. It does not provide detailed instructions itself.

## User intent

* Understand what is available in My Account
* Find out what can be edited in My Account
* Learn the effect of editing account information

## Key terms

* My Account
* What’s In My Account
* What Can I Edit In My Account
* effect of changes

## Terminology links

* [My account](/knowledgebase/terminology/#my-account)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with navigating the application

## Not covered

* Detailed descriptions of My Account sections
* Step-by-step instructions for editing account information
* Specific effects of individual account changes beyond indicating that this is covered elsewhere

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequences/navigation-and-menus/index.agent.md
---
# Agent guide: Navigation and Menus

* **Page path:** `system-configuration/sequences/navigation-and-menus/index.md`
* **Page type:** explanation

## What this page is about

This page introduces the Sequence design screen’s navigation and menus, including the left-hand Sequence-specific menu and the top horizontal action menu. It explains what items are available, how they appear, and how they are used while building or editing a workflow.

## User intent

* Understand the layout of the Sequence design screen before building a workflow
* Identify the available Actor types and what each one does
* Learn how to drag Actors, Sequences, and templates onto the workflow
* See which Sequences, Task templates, and Task group templates appear in the menu
* Understand how to enter Edit mode and when Save becomes enabled
* Use top menu actions such as Clear, Group/Ungroup, Undo/Redo, Zoom, Delete, Navigator, and Save

## Key terms

* Sequence specific menu
* Actors
* API call
* Local variable
* Send message
* Update record
* Sequences
* When Sequence activated
* Task templates
* Automatic
* Task group templates
* Update object records
* Horizontal action menu
* Edit mode
* Save mode
* Clear
* Group/Ungroup
* Undo/Redo
* Zoom In/Zoom Out
* Reset Zoom
* Delete
* Navigator
* Outline modal
* Zoom Actual
* Saved modal

## Terminology links

* [Sequence specific menu](/knowledgebase/terminology/#sequence-specific-menu)
* [Sequence Actors](/knowledgebase/terminology/#sequence-actors) (matched from `Actors`)
* [API Call actor](/knowledgebase/terminology/#api-call-actor) (matched from `API call`)
* [Local Variable Actor](/knowledgebase/terminology/#local-variable-actor) (matched from `Local variable`)
* [Send Message Actors](/knowledgebase/terminology/#send-message-actors) (matched from `Send message`)
* [Update Record actor](/knowledgebase/terminology/#update-record-actor) (matched from `Update record`)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequences`)
* [Sequence Activated](/knowledgebase/terminology/#sequence-activated) (matched from `When Sequence activated`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Sequences and the Sequence Actions menu
* Access to the Edit design option for a Sequence
* General understanding of Object classes, Tasks, and Task templates

## Not covered

* Step-by-step instructions for building a complete Sequence
* Detailed configuration of each Actor beyond its purpose and basic interaction
* How to define endpoints or authentication for third-party API integrations
* Broader Sequence logic, conditions, or workflow design best practices

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.13/new-ai-models-in-sequencer/index.agent.md
---
# Agent guide: New AI models in Sequencer

* **Page path:** `release-notes/release-notes-1.13/new-ai-models-in-sequencer/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces expanded AI model choices in Sequencer, including new AWS Bedrock options and additional OpenAI GPT-family models. It explains how to match models to legal/business workflow steps based on cost, throughput, context length, and reasoning needs.

## User intent

* See which new AI models/providers are now available in Sequencer
* Understand the difference between AWS Bedrock actor options and the OpenAI: GPT actor options
* Choose suitable models for tasks like bulk tagging, clause normalization, summarization, drafting, or long-document reasoning
* Learn how to orchestrate multiple models across automated legal/business workflows
* Understand practical tradeoffs between cheaper/faster models and richer/long-context models
* Confirm what model controls remain available in Sequencer before testing in production

## Key terms

* Sequencer
* AWS Bedrock actor
* Amazon Bedrock provider
* OpenAI as a Bedrock provider
* Claude 3.7 Sonnet
* gpt oss 20b
* gpt oss 120b
* OpenAI: GPT actor
* o3
* o3 deep research
* o3 pro
* o4 mini
* GPT 4.1
* GPT 5
* GPT 5 mini
* GPT 5 nano
* long context reasoning
* structured summaries
* deep research variants
* price/performance profiles
* throughput
* temperature
* max tokens
* Authentication Object
* orchestration
* audit logging
* Catalyst

## Terminology links

* [Sequencer](/knowledgebase/terminology/#sequencer)
* [AWS Bedrock actor](/knowledgebase/terminology/#aws-bedrock-actor)
* [OpenAI: GPT actor](/knowledgebase/terminology/#openai-gpt-actor)
* [temperature](/knowledgebase/terminology/#temperature)
* [max tokens](/knowledgebase/terminology/#max-tokens)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `Authentication Object`)
* [Catalyst](/knowledgebase/terminology/#catalyst)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Sequencer and its actors
* General understanding of AI model selection and tradeoffs
* Awareness of legal/business automation workflows such as classification, summarization, drafting, and routing
* Some knowledge of authentication/configuration concepts in Sequencer

## Not covered

* Step-by-step setup or configuration instructions for Bedrock or OpenAI actors
* Detailed definitions of every model’s technical specs or benchmarks
* Pricing details or exact performance comparisons
* Broader Sequencer feature documentation beyond this model availability update
* Security/compliance details beyond noting auditable outputs and authentication selection

---

---
url: /knowledgebase-agent-guides/release-notes/index.agent.md
---
# Agent guide: New at Autologyx

* **Page path:** `release-notes/index.md`
* **Page type:** release-notes

## What this page is about

An index page for Autologyx release notes, listing available versions and a preview entry for 1.16 coming on 27 May 2026. It serves as a navigation hub to version-specific release note pages.

## User intent

* Find release notes for a specific Autologyx version
* Check which release note versions are available
* See whether a forthcoming release preview is listed
* Navigate to the latest or historical product updates

## Key terms

* Autologyx
* Release Notes
* 1.16 Preview
* 27 May 2026
* version 1.14
* version 1.13
* version 1.12
* version 1.11
* version 1.10
* version 1.9
* version 1.8
* version 1.6
* version 1.5
* version 1.3
* version 1.2

## Terminology links

* [Release Notes](/knowledgebase/terminology/#release-notes)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx version numbering
* Knowing which product release you want to review

## Not covered

* Detailed feature changes or fixes for any release
* Upgrade instructions or migration guidance
* Technical implementation details
* Release notes for versions not listed on this index page

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.9/new-jinja-filters-for-date-and-time-manipulations/index.agent.md
---
# Agent guide: New Jinja filters for date and time manipulations

* **Page path:** `release-notes/release-notes-1.9/new-jinja-filters-for-date-and-time-manipulations/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces new Jinja filters for date and time manipulation in document generation. It summarizes the syntax, example usage, and outputs for checking date ranges, calculating day differences, and shifting times, dates, and datetimes.

## User intent

* Check whether a date falls within a specified date range
* Calculate the number of days between two dates
* Calculate the number of business days between two dates
* Shift a time by hours, minutes, or seconds
* Shift a datetime by years, months, days, hours, minutes, or seconds
* Shift a date by years, months, or days
* Apply business-day logic when shifting dates or datetimes
* Understand example syntax and expected outputs for the new Jinja filters

## Key terms

* Jinja filters
* in date range
* delta days
* business days
* shift time
* shift datetime
* shift date
* date range
* date manipulations
* time manipulations
* datetime manipulations
* document generation

## Terminology links

* [Jinja filters](/knowledgebase/terminology/#jinja-filters)
* [delta\ days](/knowledgebase/terminology/#delta-days) (matched from `delta days`)
* [business days](/knowledgebase/terminology/#business-days)
* [Document Automation](/knowledgebase/terminology/#document-automation) (matched from `document generation`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Jinja template syntax
* Understanding of date, time, and datetime string formats used in the examples

## Not covered

* Implementation details of how the filters are built
* Full reference documentation beyond the listed examples and syntax
* Timezone conversion rules or locale-specific behavior
* Holiday calendars or business-day rules beyond the examples shown
* Migration guidance from older filters or previous versions

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.3/new-template-merge-fields/index.agent.md
---
# Agent guide: New template & merge fields

* **Page path:** `release-notes/release-notes-1.3/new-template-merge-fields/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces that Jinja merge fields have been integrated across the Autologyx platform. It highlights simpler template creation, more powerful data handling, and standardized merge field syntax across features.

## User intent

* Understand what changed about templates and merge fields in Autologyx
* Learn which parts of the platform now support Jinja merge fields
* See why Jinja was adopted as the standard templating language
* Find out how dynamic content and data handling are improved

## Key terms

* Jinja
* merge fields
* templates
* document templates
* dynamic content
* send email actor
* API calls
* local variables
* standardisation

## Terminology links

* [Jinja merge fields](/knowledgebase/terminology/#jinja-merge-fields) (matched from `Jinja`)
* [merge fields](/knowledgebase/terminology/#merge-fields)
* [Document Templates](/knowledgebase/terminology/#document-templates) (matched from `templates`)
* [dynamic content](/knowledgebase/terminology/#dynamic-content)
* [send email actor](/knowledgebase/terminology/#send-email-actor)
* [API calls](/knowledgebase/terminology/#api-calls)
* [local variables](/knowledgebase/terminology/#local-variables)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx templates and merge fields
* General understanding of dynamic content in documents or workflow automation

## Not covered

* Detailed syntax or examples of Jinja merge fields
* Step-by-step migration guidance from previous merge field formats
* Configuration instructions for specific actors or APIs
* Troubleshooting or limitations of the Jinja implementation

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.8/new-user-account-types/index.agent.md
---
# Agent guide: New user account types

* **Page path:** `release-notes/release-notes-1.8/new-user-account-types/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces new Catalyst user account types and a refreshed user management UI. It explains the purpose, access model, and limitations of each user type, plus the introduction of per-type user limits and counts.

## User intent

* Understand the different user account types available in Catalyst
* Compare what Internal, External, Config Admin, Super Admin, and Time Completion Users can do
* Learn which user types can log in, receive permissions, or be assigned roles
* Understand how user limits and user counts now work per account type
* See what changed in the user management UI in this release

## Key terms

* Internal Users
* External Users
* Time Completion Users
* Config Admin
* Super Admin
* permissions
* role assignment
* user limits
* user count
* user management UI
* Object Classes
* sequences

## Terminology links

* [Internal User](/knowledgebase/terminology/#internal-user) (matched from `Internal Users`)
* [External users](/knowledgebase/terminology/#external-users)
* [Time Completion User](/knowledgebase/terminology/#time-completion-user) (matched from `Time Completion Users`)
* [Config admin account type](/knowledgebase/terminology/#config-admin-account-type) (matched from `Config Admin`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super Admin`)
* [Class permissions](/knowledgebase/terminology/#class-permissions) (matched from `permissions`)
* [role assignment](/knowledgebase/terminology/#role-assignment)
* [user limit](/knowledgebase/terminology/#user-limit) (matched from `user limits`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst user management
* General understanding of permissions and roles

## Not covered

* Step-by-step instructions for creating or editing each user type
* Detailed permission matrices for each account type
* Licensing or exact numeric limits for user counts
* Migration guidance for existing users
* Technical implementation details of the UI changes

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.10/new-autologyx-catalyst-1.10-release-notes/index.agent.md
---
# Agent guide: NEW\* Autologyx Catalyst 1.10 release notes

* **Page path:** `release-notes/release-notes-1.10/new-autologyx-catalyst-1.10-release-notes/index.md`
* **Page type:** release-notes

## What this page is about

Overview of Autologyx Catalyst 1.10 release highlights. It summarizes new Applied AI features, analytics/reporting, user group and access-control enhancements, a new Record Access actor, and broad bug fixes/improvements, with links to deeper feature articles.

## User intent

* Understand what is new in Autologyx Catalyst 1.10
* Identify major platform capabilities added in this release
* See whether 1.10 includes AI integrations such as GPT, embeddings, Bedrock model access
* Learn about new analytics and reporting/database capabilities
* Check updates to user groups, task assignment, visibility controls, and permission management
* Find information about the new Record Access actor
* Review the scale of bug fixes and performance improvements
* Navigate to more detailed articles for each highlighted feature

## Key terms

* Autologyx Catalyst 1.10
* Applied AI
* OpenAI ChatGPT integration
* Amazon Bedrock
* Claude
* Titan
* Llama
* embeddings
* Sequencer
* Analytics and reporting
* Analytics Database
* Resource Database
* History Events Database
* User Groups
* User Type fields
* Class fields
* task forms
* task assignees
* visibility control
* Class Permission Sets
* Record Permission Sets
* API
* Record Access actor
* record ownership
* bug fixes and improvements

## Terminology links

* [Applied AI](/knowledgebase/terminology/#applied-ai)
* [Embeddings](/knowledgebase/terminology/#embeddings)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Analytics Database](/knowledgebase/terminology/#analytics-database)
* [Resource Database](/knowledgebase/terminology/#resource-database)
* [History Events Database](/knowledgebase/terminology/#history-events-database)
* [User Groups](/knowledgebase/terminology/#user-groups)
* [User type fields](/knowledgebase/terminology/#user-type-fields)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the Autologyx platform
* Awareness of concepts such as Sequencer, records, tasks, users/groups, and permission sets
* General understanding of workflow automation and access control

## Not covered

* Step-by-step configuration or setup instructions for the new features
* Detailed technical or API documentation
* Exhaustive change log beyond the summarized highlights
* Migration, upgrade procedure, or rollback guidance
* Licensing, pricing, or entitlement details for premium capabilities

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.11/new-autologyx-catalyst-1.11-release-notes/index.agent.md
---
# Agent guide: NEW\* Autologyx Catalyst 1.11 release notes

* **Page path:** `release-notes/release-notes-1.11/new-autologyx-catalyst-1.11-release-notes/index.md`
* **Page type:** release-notes

## What this page is about

This page summarizes the Autologyx Catalyst 1.11 release, highlighting new AI integrations, authentication and email enhancements, API improvements, real-time data sync, onboarding controls, and general fixes/improvements. It is a feature-focused overview of what was added or changed in this release.

## User intent

* Understand what is new in Autologyx Catalyst 1.11
* Identify new AI-related capabilities such as AWS Bedrock and Azure OpenAI actors
* Learn about new authentication options including ROPC Flow for Objects
* Find outbound mail changes related to Microsoft OAuth and Graph API
* See API enhancements like multipart data support and hierarchical record creation
* Understand new platform features such as WebSockets for Elements and delayed account activation
* Review bug fixes, security enhancements, performance optimisations, and Constants

## Key terms

* Autologyx Catalyst 1.11
* AWS Bedrock integration
* Azure OpenAI Actor
* GPT-4o
* GPT-3.5 Turbo
* o1 series
* Embeddings models
* WebSockets
* Elements
* ROPC Flow
* Authentication Objects
* Microsoft Office 365 Exchange (Graph)
* OAuth 2.0
* Outbound mail
* API Call actor
* Multipart data support
* Delayed account activation
* Hierarchical records creation endpoints
* Constants
* security enhancements
* performance optimisations

## Terminology links

* [Autologyx Catalyst 1.11](/knowledgebase/terminology/#autologyx-catalyst-111)
* [AWS Bedrock integration](/knowledgebase/terminology/#aws-bedrock-integration)
* [Azure OpenAI actor](/knowledgebase/terminology/#azure-openai-actor)
* [WebSockets](/knowledgebase/terminology/#websockets)
* [Elements](/knowledgebase/terminology/#elements)
* [ROPC flow](/knowledgebase/terminology/#ropc-flow)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects)
* [Microsoft Office 365 Exchange (Graph) with oAuth 2.0](/knowledgebase/terminology/#microsoft-office-365-exchange-graph-with-oauth-20) (matched from `Microsoft Office 365 Exchange (Graph)`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst workflows and actors
* General understanding of AI model integrations and enterprise authentication
* Basic knowledge of APIs, outbound email configuration, and user account management

## Not covered

* Detailed setup, configuration, or step-by-step instructions for each feature
* Complete technical specifications, limitations, or compatibility details
* Upgrade procedures or migration guidance
* Issue-by-issue bug fix details beyond the summary
* Broader product documentation outside the 1.11 release scope

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.12/new-autologyx-catalyst-1.12-release-notes/index.agent.md
---
# Agent guide: NEW\* Autologyx Catalyst 1.12 release notes

* **Page path:** `release-notes/release-notes-1.12/new-autologyx-catalyst-1.12-release-notes/index.md`
* **Page type:** release-notes

## What this page is about

This page summarizes the Autologyx Catalyst 1.12 release, which is focused on behind-the-scenes modernization of the frontend and backend technology stack. It highlights performance, security, stability, and maintainability improvements rather than new user-facing features.

## User intent

* Understand what changed in Autologyx Catalyst 1.12
* See which core technologies and dependencies were upgraded
* Learn how the release improves performance, security, and long-term stability
* Confirm whether the release includes visible UI changes or mainly platform/runtime updates
* Understand the practical impact of the release for users and development teams

## Key terms

* Autologyx Catalyst 1.12
* frontend technology stack
* backend runtime
* React 18
* Redux 5
* Redux Toolkit
* modernised routing
* React Query
* legacy dependencies
* CVEs
* Node 22
* TypeScript 5
* Python 3.12
* performance
* security
* stability
* build tooling

## Terminology links

* [Authentication Security](/knowledgebase/terminology/#authentication-security) (matched from `security`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst release notes
* General understanding of software platform upgrades and dependency modernization
* Awareness that CVEs refer to known security vulnerabilities

## Not covered

* Detailed step-by-step upgrade or migration instructions
* Specific bug lists or technical implementation details
* New end-user features or interface redesigns
* Configuration changes, rollout steps, or deployment guidance
* Any topics outside the 1.12 release summary

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.13/new-autologyx-catalyst-1.13-release-notes/index.agent.md
---
# Agent guide: NEW\* Autologyx Catalyst 1.13 release notes

* **Page path:** `release-notes/release-notes-1.13/new-autologyx-catalyst-1.13-release-notes/index.md`
* **Page type:** release-notes

## What this page is about

These are the January 2026 release notes for Autologyx Catalyst 1.13. The page summarizes new features, improvements, and fixes focused on integrations, workflow orchestration, automation, AI model support, and document handling.

## User intent

* See what is new in Autologyx Catalyst 1.13
* Identify newly added features such as the integration hub, iManage integration, file upload component, and Loop actor
* Understand improvements to document assembly, task deletion options, and authentication object management
* Check which AI models and Sequencer capabilities were updated
* Review bug fixes, security updates, and usability improvements in this release

## Key terms

* Autologyx Catalyst 1.13
* release notes
* integration hub
* third party integrations
* iManage Cloud integration
* file upload component
* ZIP file upload
* record generation
* documents
* Sequencer
* AI models
* DeepSeek
* GPT 5
* Loop actor
* arrays
* JSON
* dynamic document assembly
* .docx merge fields
* Set Task actor
* task delete options
* authentication objects
* expiry notifications
* usage panels
* bug fixes
* security
* stability
* Trivy patches
* antivirus scanning
* Constants
* unlimited docs

## Terminology links

* [Autologyx Catalyst 1.13](/knowledgebase/terminology/#autologyx-catalyst-113)
* [Release Notes](/knowledgebase/terminology/#release-notes)
* [Integration hub](/knowledgebase/terminology/#integration-hub)
* [iManage Cloud integration](/knowledgebase/terminology/#imanage-cloud-integration)
* [File upload component](/knowledgebase/terminology/#file-upload-component)
* [Document Fields](/knowledgebase/terminology/#document-fields) (matched from `documents`)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Loop actors](/knowledgebase/terminology/#loop-actors) (matched from `Loop actor`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst workflows and actors
* General understanding of integrations, documents, and task handling in the platform
* Awareness of Sequencer and AI model usage is helpful

## Not covered

* Detailed setup or step-by-step configuration instructions for the listed features
* Comprehensive technical specifications or API details
* Migration guidance from earlier versions
* Troubleshooting procedures beyond noting that fixes and improvements were made

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.14/new-autologyx-catalyst-1.14-release-notes/index.agent.md
---
# Agent guide: NEW\* Autologyx Catalyst 1.14 release notes

* **Page path:** `release-notes/release-notes-1.14/new-autologyx-catalyst-1.14-release-notes/index.md`
* **Page type:** release-notes

## What this page is about

Release notes for Autologyx Catalyst 1.14 (May 2026), summarizing new enhancements across UI/text editing, workflows and Sequencer, document and record handling, APIs, authentication, integrations, and error handling. It highlights user-facing improvements and platform reliability updates introduced in this version.

## User intent

* Understand what changed in Autologyx Catalyst 1.14
* Identify new UI and text field capabilities such as Markdown support
* Learn about Sequencer enhancements including new context menu items and merge fields
* Check updates to real-time task list behavior using WebSockets
* See document and object record improvements, including filtering and file metadata API changes
* Review authentication and security-related updates
* Understand iManage Cloud integration improvements
* Find error handling and reliability changes in this release

## Key terms

* Autologyx Catalyst 1.14
* Markdown text fields
* Create/Edit forms
* Standalone forms
* Self contained tasks
* Update record tasks
* Object Class forms
* display forms
* UI consistency
* Sequencer
* context menu items
* merge fields
* {{ loop item }}
* {{ loop counter }}
* user type merge fields
* User Group members
* real time updates
* Task Lists
* WebSockets
* document metadata
* Object Records
* document type fields
* GET /api/object records/files/
* OPTIONS /api/security/
* authentication method management
* expiry notification email template
* iManage Cloud integration
* records
* non authenticated users
* JSON path errors
* Loop actors
* Object Class relations
* Document Templates

## Terminology links

* [Autologyx Catalyst 1.14](/knowledgebase/terminology/#autologyx-catalyst-114)
* [Create/Edit forms](/knowledgebase/terminology/#createedit-forms)
* [standalone forms](/knowledgebase/terminology/#standalone-forms)
* [Self contained tasks](/knowledgebase/terminology/#self-contained-tasks)
* [Update record tasks](/knowledgebase/terminology/#update-record-tasks)
* [Object Class forms](/knowledgebase/terminology/#object-class-forms)
* [display forms](/knowledgebase/terminology/#display-forms)
* [Sequencer](/knowledgebase/terminology/#sequencer)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst
* Understanding of forms, tasks, records, and Object Classes in Catalyst
* Some knowledge of Sequencer concepts and merge fields
* Awareness of Catalyst APIs and authentication features
* Optional familiarity with iManage Cloud if using document integrations

## Not covered

* Detailed step-by-step setup or configuration instructions for the new features
* Comprehensive API reference beyond the specific endpoints mentioned
* Migration guidance, upgrade procedures, or rollback instructions
* Known issues, bug lists, or deprecations
* Detailed documentation for using linked 'Find out more' or 'how to use these features' content

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.2/new-autologyx-catalyst-1.2-release-notes/index.agent.md
---
# Agent guide: NEW\* Autologyx Catalyst 1.2 release notes

* **Page path:** `release-notes/release-notes-1.2/new-autologyx-catalyst-1.2-release-notes/index.md`
* **Page type:** release-notes

## What this page is about

This page summarizes the Autologyx Catalyst 1.2 release and highlights new features, usability improvements, and fixes. It focuses on faster performance, improved data management, and new capabilities for admins and business users.

## User intent

* Understand what is new in Autologyx Catalyst 1.2
* Identify new features related to relational data modelling
* Learn about improvements to task delegation and workflow automation
* See what usability enhancements were added in this release
* Review bug fixes, performance improvements, and minor enhancements
* Find which new features to explore further from this release

## Key terms

* Autologyx Catalyst 1.2
* release notes
* relational modeller
* relations between object classes
* child records
* record forms
* Relation Lookup
* automation sequences
* Sequence Runner
* breadcrumbs
* one time completion users
* task delegation
* Click to Call
* JSON type field
* forms
* instructions editor
* formatting options
* bug fixes
* performance improvements

## Terminology links

* [Autologyx Catalyst 1.2](/knowledgebase/terminology/#autologyx-catalyst-12)
* [Release Notes](/knowledgebase/terminology/#release-notes)
* [Relational modeller](/knowledgebase/terminology/#relational-modeller)
* [Present child records](/knowledgebase/terminology/#present-child-records) (matched from `child records`)
* [record forms](/knowledgebase/terminology/#record-forms)
* [Relation Lookup](/knowledgebase/terminology/#relation-lookup)
* [Sequence Runner](/knowledgebase/terminology/#sequence-runner)
* [breadcrumbs](/knowledgebase/terminology/#breadcrumbs)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the Autologyx Catalyst platform
* Understanding of records, forms, tasks, and workflows
* Some awareness of object classes and automation sequences

## Not covered

* Detailed setup or step-by-step configuration instructions for each feature
* Technical implementation details beyond high-level feature descriptions
* Version comparison with releases other than 1.2
* Troubleshooting guidance or known issues lists

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.3/new-autologyx-catalyst-1.3-release-notes/index.agent.md
---
# Agent guide: NEW\* Autologyx Catalyst 1.3 release notes

* **Page path:** `release-notes/release-notes-1.3/new-autologyx-catalyst-1.3-release-notes/index.md`
* **Page type:** release-notes

## What this page is about

This page summarizes the new features, usability updates, and fixes introduced in Autologyx Catalyst 1.3. It highlights document automation enhancements, a new platform-wide templating language, workspace improvements, and bug fixes.

## User intent

* Understand what changed in Autologyx Catalyst 1.3
* Identify new document automation capabilities in this release
* Learn about the Catalyst Word Add in
* See how Jinja merge fields are used across the platform
* Find out what User Type Fields are for
* Understand the new record sorting capability
* Review the general bug fixes and improvements included in 1.3

## Key terms

* Autologyx Catalyst 1.3
* Document Automation
* Catalyst Word Add in
* dynamic templates
* workflows
* templating language
* Jinja merge fields
* Sequencer
* send email actor
* API calls
* local variables
* User Type Fields
* sorting records
* records list
* bug fixes
* workspace usability improvements

## Terminology links

* [Document Automation](/knowledgebase/terminology/#document-automation)
* [Catalyst Word Add in](/knowledgebase/terminology/#catalyst-word-add-in)
* [dynamic templates](/knowledgebase/terminology/#dynamic-templates)
* [Catalyst workflows](/knowledgebase/terminology/#catalyst-workflows) (matched from `workflows`)
* [templating language](/knowledgebase/terminology/#templating-language)
* [merge fields](/knowledgebase/terminology/#merge-fields) (matched from `Jinja merge fields`)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [send email actor](/knowledgebase/terminology/#send-email-actor)

## Related topics

* NEW Autologyx Catalyst 1.2 release notes

## Prerequisites

* Basic familiarity with the Autologyx Catalyst platform
* Awareness of workflows and document automation in Autologyx
* Some understanding of records, fields, and the Sequencer is helpful

## Not covered

* Detailed setup or step-by-step instructions for the new features
* Complete technical specification of the Jinja templating language
* Exhaustive bug fix list with issue-by-issue detail
* Migration guidance from earlier versions beyond a brief reference to 1.2
* Broader product documentation outside the 1.3 release changes

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.5/new-autologyx-catalyst-1.5-release-notes/index.agent.md
---
# Agent guide: NEW\* Autologyx Catalyst 1.5 release notes

* **Page path:** `release-notes/release-notes-1.5/new-autologyx-catalyst-1.5-release-notes/index.md`
* **Page type:** release-notes

## What this page is about

This page summarizes the Autologyx Catalyst 1.5 release, highlighting strategic themes and major new features across document automation, workflow/integration, and the new Elements capability. It also introduces specific additions such as Zuva.ai integration, Sequencer enhancements, API key authentication objects, and new task actors.

## User intent

* Understand what is new in Autologyx Catalyst 1.5
* Identify major features added in the 1.5 release
* Learn about enhancements to document automation and the Word add-in
* See what new Sequencer workflow capabilities are available
* Find out about new integration and authentication options
* Understand what Elements is and what it enables

## Key terms

* Autologyx Catalyst 1.5
* Intelligent work
* Ecosystem
* Zuva.ai
* document intelligence
* document automation
* manual document creation
* Templates panel
* Word add-in
* relational support
* Sequencer
* document handling
* binary and multipart document support
* API keys
* bearer token authentication
* authentication objects
* create task actor
* task assignment actor
* Elements
* third party web parts

## Terminology links

* [Autologyx Catalyst 1.5](/knowledgebase/terminology/#autologyx-catalyst-15)
* [Document Automation](/knowledgebase/terminology/#document-automation)
* [Templates panel](/knowledgebase/terminology/#templates-panel)
* [Catalyst Word Add in](/knowledgebase/terminology/#catalyst-word-add-in) (matched from `Word add-in`)
* [relational support](/knowledgebase/terminology/#relational-support)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [binary and multipart document support](/knowledgebase/terminology/#binary-and-multipart-document-support)
* [Authorization Objects API Keys](/knowledgebase/terminology/#authorization-objects-api-keys) (matched from `API keys`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the Autologyx Catalyst platform
* Awareness of concepts such as records, templates, workflows, and integrations
* Some understanding of Sequencer and the Word add-in is helpful

## Not covered

* Detailed setup or configuration steps for the new features
* Full technical documentation for Zuva.ai integration
* Implementation details for Elements development or deployment
* Comprehensive API reference information
* Migration guidance, limitations, or troubleshooting details

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.6/new-autologyx-catalyst-1.6-release-notes/index.agent.md
---
# Agent guide: NEW\* Autologyx Catalyst 1.6 release notes

* **Page path:** `release-notes/release-notes-1.6/new-autologyx-catalyst-1.6-release-notes/index.md`
* **Page type:** release-notes

## What this page is about

Release notes for Autologyx Catalyst 1.6, summarizing new features and improvements introduced in this version. It highlights enhancements to iManage integration, Sequencer capabilities, data handling, and form behavior.

## User intent

* See what is new in Autologyx Catalyst 1.6
* Understand the new iManage Authentication object changes
* Learn about Sequencer enhancements such as file download and the Relationship Created trigger
* Find out how JSON variables can be used for storing large amounts of data
* Discover new Standalone form features like Redirect URL
* Understand the new read only field option in display form design

## Key terms

* Autologyx Catalyst 1.6
* release notes
* iManage Authentication object
* iManage libraries
* Sequencer
* API Call actor
* file download
* Relationship Created trigger
* JSON variable
* Standalone forms
* Redirect URL
* read only fields
* display form design

## Terminology links

* [Release Notes](/knowledgebase/terminology/#release-notes)
* [iManage Authentication Objects](/knowledgebase/terminology/#imanage-authentication-objects) (matched from `iManage Authentication object`)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [File Download](/knowledgebase/terminology/#file-download)
* [Relationship Created trigger](/knowledgebase/terminology/#relationship-created-trigger)
* [JSON type variable](/knowledgebase/terminology/#json-type-variable) (matched from `JSON variable`)
* [standalone forms](/knowledgebase/terminology/#standalone-forms)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst
* Understanding of workflows and Sequencer concepts
* Awareness of forms and variables in Catalyst
* For integration features, familiarity with iManage and authentication setup

## Not covered

* Detailed setup instructions for each feature
* Step-by-step configuration or troubleshooting guidance
* Comprehensive API documentation
* Information about releases other than Catalyst 1.6

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.8/new-autologyx-catalyst-1.8-release-notes/index.agent.md
---
# Agent guide: NEW\* Autologyx Catalyst 1.8 release notes

* **Page path:** `release-notes/release-notes-1.8/new-autologyx-catalyst-1.8-release-notes/index.md`
* **Page type:** release-notes

## What this page is about

This page summarizes the new features, enhancements, and fixes introduced in Autologyx Catalyst version 1.8. It highlights workflow, integration, user management, document automation, data analysis, and usability updates released on February 26th, 2024.

## User intent

* Understand what is new in Catalyst 1.8
* Review major features added in this release
* See improvements to Microsoft and iManage integrations
* Learn about new user account types and group permission controls
* Discover document automation updates such as image merge fields
* Find data-related enhancements like ClickHouse views
* Check what bug fixes and minor improvements are included

## Key terms

* Autologyx Catalyst 1.8
* release notes
* Microsoft Authentication Object
* client credentials flow
* iManage API Call Actor
* Internal user
* External user
* user account types
* User Group Permissions
* group visibility
* image merge fields
* database views
* ClickHouse Views
* historical records
* API Call test log
* standalone forms
* dynamic submit button control

## Terminology links

* [Release Notes](/knowledgebase/terminology/#release-notes)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `Microsoft Authentication Object`)
* [Authentication client credentials flow](/knowledgebase/terminology/#authentication-client-credentials-flow) (matched from `client credentials flow`)
* [iManage API Call actor](/knowledgebase/terminology/#imanage-api-call-actor)
* [Internal User](/knowledgebase/terminology/#internal-user)
* [External users](/knowledgebase/terminology/#external-users) (matched from `External user`)
* [User Account Types](/knowledgebase/terminology/#user-account-types)
* [User Group Permissions](/knowledgebase/terminology/#user-group-permissions)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst
* General understanding of workflows, sequences, and document management in Catalyst
* Awareness of user and group management concepts
* Optional familiarity with Microsoft account integration, iManage, and ClickHouse for the relevant features

## Not covered

* Detailed setup or configuration steps for each feature
* Complete technical documentation for Microsoft authentication or iManage integration
* Full explanation of how to use ClickHouse views
* Exhaustive list of all bug fixes and improvements
* Upgrade, migration, or rollback instructions

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.9/new-autologyx-catalyst-1.9-release-notes/index.agent.md
---
# Agent guide: NEW\* Autologyx Catalyst 1.9 release notes

* **Page path:** `release-notes/release-notes-1.9/new-autologyx-catalyst-1.9-release-notes/index.md`
* **Page type:** release-notes

## What this page is about

Release notes for Autologyx Catalyst 1.9, highlighting new integration/authentication capabilities, document viewer improvements, process engine Jinja date/time filters, API updates, and platform stability/security enhancements.

## User intent

* Understand what is new in Catalyst 1.9
* See which integrations/authentication options were added
* Learn about the new in-app document viewer
* Find process engine/Jinja date and time calculation enhancements
* Check API changes for delayed user account activation
* Review bug fixes, Django upgrade, and security/stability improvements

## Key terms

* Catalyst 1.9
* authentication objects
* integration framework
* Adobe
* Salesforce
* Box
* Generic OAuth 2.0 template
* client credentials
* document viewer panel
* records
* tasks
* process engine
* Jinja merge fields
* Jinja filters
* date and time manipulations
* API
* delay activation parameter
* user activation email
* Django 4.2 LTS
* Sequencer
* history database backup

## Terminology links

* [Autologyx Catalyst 1.9](/knowledgebase/terminology/#autologyx-catalyst-19) (matched from `Catalyst 1.9`)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects)
* [integration framework](/knowledgebase/terminology/#integration-framework)
* [Generic OAuth 2.0 template](/knowledgebase/terminology/#generic-oauth-20-template)
* [client credentials](/knowledgebase/terminology/#client-credentials)
* [document viewer panel](/knowledgebase/terminology/#document-viewer-panel)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `records`)
* [Tasks](/knowledgebase/terminology/#tasks)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst
* Awareness of integrations/authentication concepts such as OAuth 2.0 and client credentials
* Some understanding of records, tasks, APIs, and Jinja templating/process engine features

## Not covered

* Detailed step-by-step setup instructions for each feature
* Complete API reference or payload examples
* Full list of all 25+ bug fixes
* Detailed migration guidance for the Django upgrade
* Deep technical implementation details for backups or security changes

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/object-class-field-types-uses-and-attributes/index.agent.md
---
# Agent guide: Object class field types: uses and attributes

* **Page path:** `system-configuration/object-classes/object-class-field-types-uses-and-attributes/index.md`
* **Page type:** explanation

## What this page is about

Explains the available Object class field types, what data each type is used for, and which field attributes each type supports. It also covers mandatory field properties, special behavior for certain types such as User and Document, and notes on defaults, uniqueness, min/max input, and identifiers.

## User intent

* Understand which Object class field type to use for a given kind of data
* Learn the required properties of every Object class field
* Check what validation or constraints each field type supports
* See which field types allow options, default values, uniqueness, min/max input, or identifier use
* Configure User fields with individual users or user groups
* Understand how end users interact with User, URL, Date, Time, and Document fields
* Know system limits such as option counts, file counts, and label/alias lengths

## Key terms

* Object class field
* Label
* Alias
* Type
* Text
* Integer
* Decimal
* Checkbox
* Single select
* Multi select
* Email
* Phone
* Date
* Date/Time
* Time
* Document
* User
* URL
* JSON
* Default value
* Unique value
* Min/Max input
* Identifier
* Selection options
* User groups
* Allow Syncing Group Members
* Allow Selecting Individual Members

## Terminology links

* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `Object class field`)
* [Label](/knowledgebase/terminology/#label)
* [Alias](/knowledgebase/terminology/#alias)
* [field types](/knowledgebase/terminology/#field-types) (matched from `Type`)
* [Text](/knowledgebase/terminology/#text)
* [Integer](/knowledgebase/terminology/#integer)
* [Decimal](/knowledgebase/terminology/#decimal)
* [Checkboxes in Catalyst](/knowledgebase/terminology/#checkboxes-in-catalyst) (matched from `Checkbox`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Object classes and records
* Awareness of record create/edit forms and views
* Administrator-level need to configure fields

## Not covered

* Step-by-step creation of Object classes beyond the field details described here
* Broader Object class administration outside field types and attributes
* API usage details beyond noting that Alias is used in API requests and responses
* Reporting or analytics design guidance beyond brief recommendations and cautions

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-classes/object-class-forms/index.agent.md
---
# Agent guide: Object Class Forms

* **Page path:** `catalyst/resources/object-classes/object-class-forms.md`
* **Page type:** reference

## What this page is about

Reference for Object Class Forms in the Autologyx backend/API: what forms are used for, their current scope, and the available REST endpoints for creating, listing, retrieving, updating, deleting, and inspecting options. It emphasizes that forms are primarily frontend-defined artifacts, while the backend stores and serves them without validating form logic.

## User intent

* Understand what Object Class Forms are and how they relate to Object Records and Object Classes
* Create a standalone create-form for a specific Object Class via POST /api/object-class-forms/
* List visible forms with pagination, sorting, and filtering via GET /api/object-class-forms/
* Retrieve a specific form by UUID
* Update form fields such as name, enabled flag, configuration, or custom components
* Delete an existing form
* Check what permissions are required for each form API action
* See request/response fields, constraints, and possible error messages for Object Class Forms

## Key terms

* Object Class Forms
* Object Records
* Object Classes
* standalone forms
* create form
* configuration
* custom components
* is enabled
* uuid
* meta.labels
* meta.permissions
* permissions
* filtering
* sorting
* pagination

## Terminology links

* [Object Class Forms](/api/terminology/#object-class-forms)
* [Object Records](/api/terminology/#object-records)
* [object classes](/api/terminology/#object-classes)
* [standalone forms](/api/terminology/#standalone-forms)
* [form configuration](/api/terminology/#form-configuration) (matched from `configuration`)
* [custom components](/api/terminology/#custom-components)
* [meta.labels](/api/terminology/#metalabels)
* [permissions](/api/terminology/#permissions) (matched from `meta.permissions`)

## Related topics

* Object Classes
* Object Class Owners
* Object Classes Permission Sets
* Object Classes Document Template

## Prerequisites

* Basic understanding of Object Classes and Object Records
* Familiarity with authenticated REST API usage
* Awareness that form definitions are created on the frontend and only stored/accessed by the backend
* For filtering details, familiarity with the ALX API standards developers guide

## Not covered

* Frontend form-definition details or UI integration behavior beyond noting that forms may be integrated or standalone
* Backend validation or execution of form logic, since the backend does not validate or use forms in application logic
* Broader support for non-create form types in current scope, even though response enums mention future values like update, summary, and list
* Class relations or associating one form with multiple Object Classes
* Detailed permission-set assignment workflows for users or groups

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-classes/object-class-owners/index.agent.md
---
# Agent guide: Object Class Owners

* **Page path:** `catalyst/resources/object-classes/object-class-owners.md`
* **Page type:** reference

## What this page is about

Reference for the Object Class Owners API: how to create, list, retrieve, delete, and inspect options for owner relations on an object class. It documents endpoints, permissions, parameters, response shapes, validations, and error cases.

## User intent

* Add one or more owners to an object class via API
* List owners assigned to a specific object class
* Fetch a single object class owner relation by owner id
* Remove an owner from an object class
* Check required permissions for Object Class Owners endpoints
* Understand validation limits such as max 100 owners per class or batch
* Diagnose API errors for invalid ids, wrong payload types, or insufficient permissions

## Key terms

* Object Class Owners
* Object Class Owner relation
* class id
* owner id
* Object Class Ownership permission
* users.list permission
* POST /api/object classes/{class id}/owners/
* GET /api/object classes/{class id}/owners/
* GET /api/object classes/{class id}/owners/{owner id}/
* DELETE /api/object classes/{class id}/owners/{owner id}/
* OPTIONS /api/object classes/{class id}/owners/
* owner ids list
* batch limit
* account type validation

## Terminology links

* [Object Class Owners](/api/terminology/#object-class-owners)
* [Object Class Owner relations](/api/terminology/#object-class-owner-relations) (matched from `Object Class Owner relation`)
* [class id](/api/terminology/#class-id)
* [owner id](/api/terminology/#owner-id)
* [users.list permission](/api/terminology/#userslist-permission)
* [owners list](/api/terminology/#owners-list) (matched from `owner ids list`)

## Related topics

* Object Classes
* Object Classes Permission Sets
* Assigning Users for Object Classes Permission Set
* Assigning User Groups for Object Classes Permission Set
* Assigning for Object Classes Permission Set

## Prerequisites

* Know the target Object Class id
* Have required permission or Object Class Ownership access
* For assigning owners, have users.list permission for users included in the payload
* Understand user/account types, since some account types cannot be owners

## Not covered

* How to create or manage Object Classes themselves
* UI workflows for assigning owners
* Detailed meaning of the generic named permission entries in the page
* Updating an existing owner relation beyond create/delete
* Broader permission-set configuration steps, except as related titles

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-class-relationships/index.agent.md
---
# Agent guide: Object Class Relationships

* **Page path:** `system-configuration/object-class-relationships/index.md`
* **Page type:** explanation

## What this page is about

This page is a brief navigation point for object class relationships. It directs the reader to the section on configuring relationships in object classes.

## User intent

* Find where to configure relationships in object classes
* Understand that object class relationships are covered in a dedicated configuration section
* Navigate to documentation about relationships between object classes

## Key terms

* Object Class Relationships
* Configuring Relationships
* Object Classes

## Terminology links

* [Object Class Relationships](/knowledgebase/terminology/#object-class-relationships)
* [Object classes](/knowledgebase/terminology/#object-classes)

## Related topics

* Configuring Relationships In Object Classes

## Prerequisites

* Basic familiarity with object classes
* General understanding of system configuration documentation structure

## Not covered

* Detailed steps for configuring relationships
* Examples of object class relationships
* Conceptual explanation of relationship types
* Any configuration details beyond linking to the relevant section

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-classes/object-classes/index.agent.md
---
# Agent guide: Object Classes

* **Page path:** `catalyst/resources/object-classes/object-classes.md`
* **Page type:** reference

## What this page is about

Technical API reference for Object Classes, covering endpoints to create, list, retrieve, update, delete, autocomplete, inspect usage, and begin creating fields for object classes. It also documents request/response schemas, validations, permissions, sorting, filtering, and common error responses.

## User intent

* Create an object class via the API
* Understand required and optional request fields for object classes
* Validate object class payload rules such as name uniqueness, length, and JSON key constraints
* List object classes with pagination, sorting, and filtering
* Retrieve a single object class by id
* Update an existing object class
* Delete an object class and understand when deletion is blocked because it is in use
* Use autocomplete endpoints for object class selectors, including owned object classes
* Check where an object class is used
* Create fields for an object class

## Key terms

* Object Class
* display configuration
* custom components
* identifier
* object models
* record count
* meta.permissions
* autocomplete
* usage
* owners
* has system fields
* object class fields
* sorting
* filtering
* ALX API standards

## Terminology links

* [object classes](/api/terminology/#object-classes) (matched from `Object Class`)
* [display configuration](/api/terminology/#display-configuration)
* [custom components](/api/terminology/#custom-components)
* [identifier](/api/terminology/#identifier)
* [Object Models](/api/terminology/#object-models)
* [record count](/api/terminology/#record-count)
* [permissions](/api/terminology/#permissions) (matched from `meta.permissions`)
* [autocomplete relative url](/api/terminology/#autocomplete-relative-url) (matched from `autocomplete`)

## Related topics

* Object Class Forms
* Object Class Owners
* Object Classes Document Template
* Object Classes Permission Sets
* Assigning for Object Classes Permission Set
* Assigning User Groups for Object Classes Permission Set
* Assigning Users for Object Classes Permission Set

## Prerequisites

* Familiarity with REST API requests and responses
* Understanding of permissions in the system
* Basic knowledge of JSON payloads
* Awareness of ALX API standards for filtering predicates

## Not covered

* UI workflows for managing object classes outside the API
* Full details of permission names; the page only states that permissions are required
* Complete field-type documentation for object class fields, which appears truncated
* Detailed explanation of related resources such as forms, owners, document templates, and permission set assignment
* General ALX predicate behavior beyond referring to ALX API standards

---

---
url: /knowledgebase-agent-guides/system-configuration/object-classes/index.agent.md
---
# Agent guide: Object Classes

* **Page path:** `system-configuration/object-classes/index.md`
* **Page type:** explanation

## What this page is about

This page introduces Object Classes as a core building block in Autologyx and outlines the topics in this section for designing, structuring, presenting, and governing Object Records. It also suggests a recommended build flow and points to next related areas once an Object Class is established.

## User intent

* Understand what an Object Class is and why it matters
* Find where to create an Object Class
* Learn what parts of an Object Class can be edited
* Define class structure, fields, field types, and attributes
* Configure displays, forms, and standalone forms for user interaction
* Set up class permissions, record permissions, permission sets, and assignee behavior
* Follow a sensible build order for creating and maintaining Object Classes
* Identify what related topics to explore after the Object Class structure is in place

## Key terms

* Object Classes
* Object Records
* fields
* field types
* uses and attributes
* forms
* standalone form
* displays
* class permissions
* record permissions
* permission sets
* assignees
* workflows
* document generation
* reporting

## Terminology links

* [Object classes](/knowledgebase/terminology/#object-classes)
* [Object records](/knowledgebase/terminology/#object-records)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `fields`)
* [field types](/knowledgebase/terminology/#field-types)
* [Uses And Attributes](/knowledgebase/terminology/#uses-and-attributes)
* [Forms tab](/knowledgebase/terminology/#forms-tab) (matched from `forms`)
* [standalone forms](/knowledgebase/terminology/#standalone-forms) (matched from `standalone form`)
* [Displays](/knowledgebase/terminology/#displays)

## Related topics

* Object class relationships
* Relational Modeller
* Task Templates
* Sequences
* Working with Document Templates

## Prerequisites

* Basic familiarity with building or configuring applications in Autologyx
* Understanding that Object Classes define how data is captured, presented, and governed
* Relevance mainly for Config Admins, analysts, and builders

## Not covered

* Detailed instructions for each linked task page
* Implementation details of workflows, task templates, sequences, or document templates
* Topics outside the structure of an Object Class itself, such as broader application design beyond fields, forms, displays, and permissions

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-classes/object-class-document-templates/index.agent.md
---
# Agent guide: Object Classes Document Template

* **Page path:** `catalyst/resources/object-classes/object-class-document-templates.md`
* **Page type:** reference

## What this page is about

Reference for the Object Classes Document Template API. It covers endpoints to create, list, retrieve, update, delete, verify, inspect usage, and download document templates attached to an object class, including validations, permissions, sorting/filtering, and error responses.

## User intent

* Create a document template for an object class
* Validate a .docx template file and its Jinja/merge tags before saving
* List document templates for an object class with pagination, sorting, and filtering
* Retrieve details of a specific document template
* Update a document template's name, description, file, or allow-on-demand-generation flag
* Delete a document template
* Check whether a document template is used by sequences before deletion
* Download the raw template file
* Understand request/response schemas, limits, and common API errors

## Key terms

* Object Class
* Document Template
* object class id
* document template id
* template file
* file token
* Object Class Document File ID
* allow on demand generation
* Jinja template syntax
* merge tags
* related classes
* class fields
* meta.labels.files
* warning
* usage
* sequences
* ordering
* filtering

## Terminology links

* [object classes](/api/terminology/#object-classes) (matched from `Object Class`)
* [Object Classes Document Template](/api/terminology/#object-classes-document-template) (matched from `Document Template`)
* [template file](/api/terminology/#template-file)
* [file token](/api/terminology/#file-token)
* [allow on demand generation](/api/terminology/#allow-on-demand-generation)
* [Jinja template syntax](/api/terminology/#jinja-template-syntax)
* [merge tags](/api/terminology/#merge-tags)
* [related classes](/api/terminology/#related-classes)

## Related topics

* Object Classes
* Object Class Forms
* Object Class Owners
* Object Classes Permission Sets
* Assigning for Object Classes Permission Set
* Assigning User Groups for Object Classes Permission Set
* Assigning Users for Object Classes Permission Set

## Prerequisites

* An existing Object Class and its id
* Appropriate permissions for the relevant document template endpoints
* A .docx template file uploaded as a temporary file token, or an existing Object Class Document File ID for verify
* Basic understanding of Jinja template syntax and merge tags
* Awareness of related classes and class fields used in merge fields

## Not covered

* UI workflow for managing document templates
* Exact permission names; the page only states that permissions are required
* Details of temporary file upload/token generation
* Full ALX API filtering predicate rules beyond referring to API standards
* How Sequences work beyond template usage checks
* General Object Classes concepts outside document template endpoints

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-classes/object-class-permission-sets/index.agent.md
---
# Agent guide: Object Classes Permission Sets

* **Page path:** `catalyst/resources/object-classes/object-class-permission-sets.md`
* **Page type:** reference

## What this page is about

Reference for API endpoints that manage Object Class Permission Sets at the Object Class level. It covers listing, creating, updating, deleting, and OPTIONS behavior, along with permissions, request/response fields, validations, and error cases.

## User intent

* List permission sets for a specific Object Class
* Create a new Object Class Permission Set
* Update the name or permissions of an existing Object Class Permission Set
* Delete an Object Class Permission Set
* Understand which API permissions are required for each endpoint
* See valid resource/action combinations for permission configuration
* Check validation rules such as unique names, max length, and max 10 permission sets per Object Class
* Understand common 400, 403, and 404 error responses

## Key terms

* Object Class Permission Sets
* Object Class
* object class.view
* object class.edit perm set
* permissions
* object classes resource
* object records resource
* tasks resource
* actions: list, edit, view, delete
* actions: create, complete, assign
* GET /api/object classes/{object class id}/permission sets/
* POST /api/object classes/{object class id}/permission sets/
* PATCH /api/object classes/{object class id}/permission sets/{id}/
* DELETE /api/object classes/{object class id}/permission sets/{id}/
* OPTIONS /api/object classes/{object class id}/permission sets/

## Terminology links

* [object class permission sets](/api/terminology/#object-class-permission-sets)
* [object classes](/api/terminology/#object-classes) (matched from `Object Class`)
* [object class.view](/api/terminology/#object-classview)
* [object class.edit perm set](/api/terminology/#object-classedit-perm-set)
* [permissions](/api/terminology/#permissions)
* [object classes resource](/api/terminology/#object-classes-resource)
* [object records resource](/api/terminology/#object-records-resource)
* [tasks resource](/api/terminology/#tasks-resource)

## Related topics

* Assigning User Groups for Object Classes Permission Set
* Assigning Users for Object Classes Permission Set
* Assigning for Object Classes Permission Set
* Object Classes
* Object Class Owners

## Prerequisites

* Basic understanding of Object Classes
* Familiarity with REST API requests and responses
* Knowledge of Catalyst permission concepts and Object Class-level configuration
* Understanding that permission dependencies are converted according to a separate technical design/doc

## Not covered

* How to assign permission sets to users or user groups
* Detailed explanation of permission dependency conversion logic beyond noting it exists in a technical doc
* UI workflows
* General Object Class setup outside permission set endpoints
* Endpoint support for item-detail GET on /permission sets/{id}/, which is listed as not allowed

---

---
url: >-
  /api-agent-guides/catalyst/resources/relational-model/object-models/index.agent.md
---
# Agent guide: Object Models

* **Page path:** `catalyst/resources/relational-model/object-models.md`
* **Page type:** reference

## What this page is about

Reference for the Object Models API that manages relations between Object Classes, including create, list, retrieve, update, and parent/child lookup endpoints. It also notes that the POST creation endpoint is deprecated from Catalyst API 11.0.0 in favor of hierarchical records creation endpoints.

## User intent

* Create an object model that defines relations between object classes
* List available object models
* Retrieve a single object model by ID
* Update an existing object model
* Understand request/response schemas for object model endpoints
* Validate object class relations, multiplicity, parent links, and constraints
* Interpret common 400/403/404 API errors for object models
* Get parent classes for a specific object class in an object model
* Get child classes and multiplicity for a specific object class in an object model
* Check permission requirements for object model operations

## Key terms

* Object Model
* Object Class
* relation
* parent
* children
* multiplicity
* zero or more
* zero or one
* removable relation
* modifiable multiplicity
* meta.permissions
* meta.labels
* relation loop
* relation depth limit
* top parents limit
* children limit
* deprecated endpoint
* Hierarchical records creation endpoints

## Terminology links

* [Object Models](/api/terminology/#object-models) (matched from `Object Model`)
* [object classes](/api/terminology/#object-classes) (matched from `Object Class`)
* [multiplicity](/api/terminology/#multiplicity)
* [removable relation](/api/terminology/#removable-relation)
* [modifiable multiplicity](/api/terminology/#modifiable-multiplicity)
* [permissions](/api/terminology/#permissions) (matched from `meta.permissions`)
* [meta.labels](/api/terminology/#metalabels)
* [relation depth limit](/api/terminology/#relation-depth-limit)

## Related topics

* Hierarchical records creation endpoints

## Prerequisites

* Familiarity with Catalyst REST API usage
* Understanding of Object Classes and their IDs
* Knowledge of permissions required to perform API actions
* Basic understanding of hierarchical parent-child relations

## Not covered

* Detailed guidance for the replacement hierarchical records creation endpoints
* Broader conceptual explanation of relational modeling beyond the endpoint schemas
* Delete endpoint for object models
* Complete details for the truncated final endpoint shown as GET /api/object models/ /obj
* Examples with concrete sample request/response payload values

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-records/object-record-documents/index.agent.md
---
# Agent guide: Object Record Documents

* **Page path:** `catalyst/resources/object-records/object-record-documents.md`
* **Page type:** reference

## What this page is about

Reference for the Object Record Documents API, covering manual document generation from document templates for a specific Object Record, plus listing templates, checking generated document status/details, canceling generation, downloading output, and listing document fields.

## User intent

* Start document generation for an object record from a document template
* Provide an optional object record document-type field for generated output
* Understand validation rules for object record, template, and field compatibility
* Handle duplicate generation attempts when a request is already processing
* List document templates available for a specific object record
* Filter and sort the document template list
* Retrieve a single object record document/template entry and its generated document info
* Cancel a document generation request that is still processing
* Download a generated document
* List document fields available on an object record
* Determine required permissions and expected error responses for each endpoint

## Key terms

* Object Record Documents
* document template
* object record
* object record field
* document type field
* ObjectClass
* generated document
* allow on demand generation
* processing status
* cancel generation
* download generated document
* document fields
* Object Record view permission
* object records.view
* object records.edit

## Terminology links

* [Object Record Documents](/api/terminology/#object-record-documents)
* [Object Classes Document Template](/api/terminology/#object-classes-document-template) (matched from `document template`)
* [Object Records](/api/terminology/#object-records) (matched from `object record`)
* [object record field](/api/terminology/#object-record-field)
* [document type field](/api/terminology/#document-type-field)
* [ObjectClass](/api/terminology/#objectclass)
* [generated document](/api/terminology/#generated-document)
* [allow on demand generation](/api/terminology/#allow-on-demand-generation)

## Related topics

* Object Record Uploads
* Object Records
* Object Record Owners
* Object Records Permission Sets
* Assigning for Object Records Permission Set

## Prerequisites

* Basic understanding of Object Records and ObjectClass
* A valid object record ID and document template ID
* Knowledge of object record fields, especially document-type fields and slug names
* Appropriate permissions to view/edit records and view required object classes used by template merge fields
* Authentication to call protected API endpoints

## Not covered

* How document templates are created or configured
* How merge fields are defined beyond permission visibility rules
* Detailed meanings of all generated document status enum values
* The actual binary/file response format for download
* Business workflow outside the listed endpoints
* Permission set setup steps, which are covered in related permission-set pages

---

---
url: /api-agent-guides/websockets/resources/object-records/index.agent.md
---
# Agent guide: Object Record Events

* **Page path:** `websockets/resources/object-records.md`
* **Page type:** reference

## What this page is about

This page documents the Catalyst WebSocket endpoint for receiving real-time Object Record change events. It explains the endpoint, filters, payload structure, delivery behavior, and error cases for implementations that need live record updates without polling.

## User intent

* Subscribe to real-time Object Record events over WebSocket
* Understand which Object Record changes are emitted
* Filter events by Object Class IDs or changed field IDs
* Parse the event payload returned by the WebSocket
* Understand ordering, batching, and delivery behavior
* Handle connection and protocol errors for this endpoint

## Key terms

* WebSocket endpoint
* GET /ws/events/object records/
* Object Record events
* real time updates
* object class ids
* field ids
* query string authentication
* value changed notifications
* object record id
* object class id
* event
* field ids array
* timestamp
* creation order
* rate limit exceeded
* RFC 6455

## Terminology links

* [GET /ws/events/object records/](/api/terminology/#get-wseventsobject-records)
* [real time updates](/api/terminology/#real-time-updates)
* [Object Records](/api/terminology/#object-records) (matched from `object record id`)
* [object classes](/api/terminology/#object-classes) (matched from `object class id`)
* [History Events](/api/terminology/#history-events) (matched from `event`)
* [event timestamp](/api/terminology/#event-timestamp) (matched from `timestamp`)

## Related topics

* File Upload Events
* Task Events

## Prerequisites

* Basic understanding of WebSocket connections and upgrade requests
* Knowledge of Catalyst Object Records, Object Classes, and Object Class Fields
* Access to the required permission for the endpoint
* Ability to provide authentication via query string when opening the WebSocket

## Not covered

* End-user workflows or UI usage; this is implementation reference material
* Detailed permission names or authorization setup
* Exact event value list contents, which are referenced but not shown in the supplied text
* Concrete request/response examples, which are referenced but not included in the supplied text
* Client-side sending of messages, which is explicitly unsupported on this WebSocket

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-records/object-record-owners/index.agent.md
---
# Agent guide: Object Record Owners

* **Page path:** `catalyst/resources/object-records/object-record-owners.md`
* **Page type:** reference

## What this page is about

Reference for the Object Record Owners API endpoints used to create, list, delete, and inspect owner relations for an Object Record. It documents routes, permissions, request/response shapes, validations, filtering, sorting, and error cases.

## User intent

* Create an owner relation for a specific Object Record
* List owners assigned to an Object Record
* Delete a single Object Record owner relation
* Understand required permissions for Object Record Owners endpoints
* Know validation limits such as maximum owners per record and batch size
* See supported sorting and filtering fields for owner listings
* Check expected response schema and common error messages

## Key terms

* Object Record Owners
* Object Record Owner relation
* record id
* owner id
* Object Record Ownership permission
* users.list permission
* POST /api/object\_records/{record\_id}/owners/
* GET /api/object\_records/{record\_id}/owners/
* DELETE /api/object\_records/{record\_id}/owners/{object\_record\_owner\_id}/
* OPTIONS
* batch size limit
* maximum owners per Object Record
* sorting
* filtering
* 403 Forbidden
* 400 Bad Request

## Terminology links

* [Object Record Owners](/api/terminology/#object-record-owners)
* [Object Record Owner relations](/api/terminology/#object-record-owner-relations) (matched from `Object Record Owner relation`)
* [Object Record ID](/api/terminology/#object-record-id) (matched from `record id`)
* [owner id](/api/terminology/#owner-id)
* [users.list permission](/api/terminology/#userslist-permission)
* [ordering](/api/terminology/#ordering) (matched from `sorting`)
* [filtering](/api/terminology/#filtering)

## Related topics

* Object Records
* Object Records Permission Sets
* Assigning for Object Records Permission Set
* Assigning Users for Object Records Permission Set
* Assigning User Groups for Object Records Permission Set
* Object Records History Events

## Prerequisites

* Basic understanding of Object Records
* Knowledge of API request/response conventions
* Awareness of permission handling in the system
* Knowing valid user IDs and Object Record IDs

## Not covered

* Implementation details beyond the API contract; those are delegated to an external technical design document
* How to configure permission sets in detail
* Business workflows for selecting owners beyond the stated validations
* Document or upload behavior for Object Records
* Detailed event history behavior beyond the external reference

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-records/object-record-uploads/index.agent.md
---
# Agent guide: Object Record Uploads

* **Page path:** `catalyst/resources/object-records/object-record-uploads.md`
* **Page type:** reference

## What this page is about

Reference documentation for the Object Record Uploads API. It covers creating an upload session and retrieving a user's upload sessions, upload summaries, and completed upload files, including validation rules, permissions, sorting/filtering, and error responses.

## User intent

* Create an Object Record Upload instance via POST /api/object records/uploads/
* Find the required request fields for starting an upload session
* Understand validation rules for object class and object class field
* Check what permissions are needed to create or view upload data
* List my upload sessions with GET /api/object records/uploads/me/
* Retrieve a completed upload's summary
* Retrieve files from a completed upload
* Filter upload sessions or files by status
* See available sorting for uploaded files
* Handle expected 400, 401, and 404 API errors

## Key terms

* Object Record Uploads
* upload id
* object class
* object class field
* document field
* upload session
* summary
* files
* status
* process initiated
* process completed
* successful count
* failed count
* meta.permissions

## Terminology links

* [Object Record Uploads](/api/terminology/#object-record-uploads)
* [upload id](/api/terminology/#upload-id)
* [object classes](/api/terminology/#object-classes) (matched from `object class`)
* [object class fields](/api/terminology/#object-class-fields) (matched from `object class field`)
* [Document fields](/api/terminology/#document-fields) (matched from `document field`)
* [upload session](/api/terminology/#upload-session)
* [Task status](/api/terminology/#task-status) (matched from `status`)
* [successful count](/api/terminology/#successful-count)

## Related topics

* Object Records
* Object Record Documents
* Object Record Owners
* Object Records History Events
* Object Records Permission Sets
* Assigning for Object Records Permission Set
* Assigning Users for Object Records Permission Set
* Assigning User Groups for Object Records Permission Set

## Prerequisites

* Authentication for all non-OPTIONS endpoints
* Knowledge of Object Classes and Object Class Fields
* Access to a valid Object Class Field of type "document"
* Permission to object records.create for the specified Object Class when creating an upload
* Familiarity with ALX API filtering predicates

## Not covered

* How the actual file or ZIP content is uploaded after creating the upload instance
* Definitions of the specific permission names omitted in the page text for read/list endpoints
* Detailed enum values for status
* Full request/response examples, which are referenced but not included
* How Object Record Documents are created from uploaded files beyond the listed results endpoints
* General Object Records behavior outside upload-related endpoints

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-records/object-records/index.agent.md
---
# Agent guide: Object Records

* **Page path:** `catalyst/resources/object-records/object-records.md`
* **Page type:** reference

## What this page is about

Reference for the Object Records API design and implementation, focused on creating and updating object records via POST and PATCH endpoints. It details permissions, request/response fields, validation rules, limits, and error messages for supported field types.

## User intent

* Create a new Object Record with POST /api/object records/
* Update an existing Object Record with PATCH /api/object records/{id}/
* Understand who becomes owner when a record is created
* Check required permissions for create and edit operations
* Know which request fields are accepted, including object name, object class, and class-defined fields
* Validate field values for supported field types before sending API requests
* Interpret API responses, including meta, permissions, labels, users, and user groups objects
* Handle common 400 and 403 error responses
* Understand record limits per Object Class
* Know when certain field values are set to null on create or update

## Key terms

* Object Record
* Object Records API
* POST /api/object records/
* PATCH /api/object records/{id}/
* object name
* object class
* Object Class Ownership
* Object Record Ownership
* permission set
* status: initiated
* meta
* field validations
* user field
* document field
* set field
* enum
* json
* email
* phone
* url
* date
* time
* datetime
* max 500,000 Object Records in one Object Class

## Terminology links

* [Object Records](/api/terminology/#object-records) (matched from `Object Record`)
* [Object Records API](/api/terminology/#object-records-api)
* [object name](/api/terminology/#object-name)
* [object classes](/api/terminology/#object-classes) (matched from `object class`)
* [Object Class Ownership](/api/terminology/#object-class-ownership)
* [Object Record Ownership](/api/terminology/#object-record-ownership)
* [object class permission sets](/api/terminology/#object-class-permission-sets) (matched from `permission set`)
* [meta result](/api/terminology/#meta-result) (matched from `meta`)

## Related topics

* Object Record Owners
* Object Record Documents
* Object Record Uploads
* Object Records History Events
* Object Records Permission Sets
* Assigning Users for Object Records Permission Set
* Assigning User Groups for Object Records Permission Set
* Assigning for Object Records Permission Set

## Prerequisites

* Know the target Object Class and its configured fields
* Have valid user credentials and sufficient permissions
* Understand primary key references for object class
* Know the field definitions and constraints configured on the Object Class

## Not covered

* Deletion, retrieval/listing, or search endpoints for Object Records are not described
* Detailed Object Class configuration is referenced but not defined here
* Permission set assignment steps are not explained here
* Document upload/token generation workflow is not explained here
* Owner management, history events, and related document/upload resources are only referenced indirectly

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-records/object-record-history-events/index.agent.md
---
# Agent guide: Object Records History Events

* **Page path:** `catalyst/resources/object-records/object-record-history-events.md`
* **Page type:** reference

## What this page is about

Reference for the Object Records History Events API endpoint that returns stored history events for a specific object record. It outlines the endpoint, permissions, URL parameter, paginated response structure, and event data formats for different event types.

## User intent

* Find the API endpoint for retrieving history events for an object record
* Understand what permissions are required to access object record history events
* See which users are blocked from using this endpoint
* Learn the request parameter needed to identify the target object record
* Understand the paginated response fields such as limit, offset, total count, filtered count, next, and previous
* Identify the supported history event types
* Interpret the event data payload returned for different event types
* Understand extra attributes returned for document-type and user-type field values in field change events

## Key terms

* Object Records History Events
* GET /api/object records/{record id}/history/
* record id
* permissions
* external type users
* limit
* offset
* total count
* filtered count
* results
* event id
* event datetime
* event type
* source type
* source name
* source id
* event data
* record created
* owner initialized
* owners added
* owners removed
* assignees added
* assignees removed
* field values changed
* record deleted
* document generated
* status initialized
* permission set
* user group

## Terminology links

* [Object Record History Events](/api/terminology/#object-record-history-events) (matched from `Object Records History Events`)
* [Object Record ID](/api/terminology/#object-record-id) (matched from `record id`)
* [permissions](/api/terminology/#permissions)
* [limit](/api/terminology/#limit)
* [total count](/api/terminology/#total-count)
* [filtered count](/api/terminology/#filtered-count)
* [event type](/api/terminology/#event-type)
* [source type](/api/terminology/#source-type)

## Related topics

* Object Records
* Object Record Owners
* Object Record Documents
* Object Record Uploads
* Object Records Permission Sets
* Assigning for Object Records Permission Set
* Assigning Users for Object Records Permission Set
* Assigning User Groups for Object Records Permission Set

## Prerequisites

* Familiarity with Object Records and Object Classes
* Knowledge of authentication and permission checking
* Understanding of users, user groups, and permission sets
* Basic understanding of paginated REST API responses
* Ability to interpret JSON response payloads

## Not covered

* Implementation details of the history events API microservice
* Technical design details beyond the referenced external documents
* How to create, modify, or delete history events
* How permissions are configured in detail
* Filtering or sorting request options beyond the documented pagination fields
* Full schemas for related objects outside the event data examples

---

---
url: >-
  /api-agent-guides/catalyst/resources/object-records/object-record-permission-sets/index.agent.md
---
# Agent guide: Object Records Permission Sets

* **Page path:** `catalyst/resources/object-records/object-record-permission-sets.md`
* **Page type:** reference

## What this page is about

Reference for API endpoints that manage Object Record Permission Sets on an Object Class. It covers listing, creating, updating, deleting, and OPTIONS behavior, plus permission rules, request/response fields, validations, and errors.

## User intent

* List Object Record Permission Sets for a specific Object Class
* Create a new Object Record Permission Set for an Object Class
* Update the name or permissions of an existing Object Record Permission Set
* Delete an Object Record Permission Set
* Understand which permissions are required to use each endpoint
* Learn allowed resources and actions in the permissions payload
* Check validation limits such as unique names, max length, and max 10 permission sets per Object Class
* See possible error responses for permission-set API operations

## Key terms

* Object Record Permission Sets
* Object Class
* object class.view
* object class.edit perm set
* permissions
* object records
* tasks
* actions
* GET /api/object classes/{object class id}/record permission sets/
* POST /api/object classes/{object class id}/record permission sets/
* PATCH /api/object classes/{object class id}/record permission sets/{id}/
* DELETE /api/object classes/{object class id}/record permission sets/{id}/
* OPTIONS /api/object classes/{object class id}/record permission sets/
* name uniqueness
* case-insensitive uniqueness
* pagination
* dependencies conversion

## Terminology links

* [Object Record permission sets](/api/terminology/#object-record-permission-sets)
* [object classes](/api/terminology/#object-classes) (matched from `Object Class`)
* [object class.view](/api/terminology/#object-classview)
* [object class.edit perm set](/api/terminology/#object-classedit-perm-set)
* [permissions](/api/terminology/#permissions)
* [Object Records](/api/terminology/#object-records)
* [tasks resource](/api/terminology/#tasks-resource) (matched from `tasks`)
* [permission actions](/api/terminology/#permission-actions) (matched from `actions`)

## Related topics

* Assigning Users for Object Records Permission Set
* Assigning User Groups for Object Records Permission Set
* Assigning for Object Records Permission Set
* Object Records

## Prerequisites

* Know the target Object Class ID
* Understand Object Class-level configuration context
* Know basic API request/response patterns and HTTP methods
* Understand that user assignment endpoints are documented separately

## Not covered

* Endpoints for assigning users to a specific Object Record Permission Set
* Detailed dependency rules for permission conversion beyond noting they are described in a technical document
* Sorting or filtering options beyond stating they are unavailable for list results
* Detailed semantics of Object Records, Tasks, or other object-related resources outside permission-set management
* GET of a single Object Record Permission Set by ID

---

---
url: >-
  /knowledgebase-agent-guides/administration/communication/okta-sso-in-catalyst/index.agent.md
---
# Agent guide: Okta SSO in Catalyst

* **Page path:** `administration/communication/okta-sso-in-catalyst/index.md`
* **Page type:** explanation

## What this page is about

This page explains how to configure Okta Single Sign-On for the Catalyst platform using OpenID Connect (OIDC). It covers creating an Okta app, retrieving credentials, configuring Catalyst, updating redirect/logout URIs, setting Okta access policies, and enabling SSO for users.

## User intent

* Set up Okta SSO for Catalyst
* Create an Okta OIDC web application for Catalyst
* Find the Client ID, Client Secret, and Okta Domain needed for Catalyst configuration
* Configure an Okta OpenID Connect provider in Catalyst
* Understand what the Catalyst login support and Automatically create user options do
* Add Catalyst callback and logout URIs back into the Okta application
* Configure Okta authorization server access policies and rules for the app
* Enable users to sign in to Catalyst with existing Okta credentials

## Key terms

* Okta Single Sign On (SSO)
* Catalyst
* OpenID Connect (OIDC)
* Web Application
* Okta Admin Console
* App Integration
* Client ID
* Client Secret
* Okta Domain
* Single Sign On Settings
* Okta OpenID Connect (OIDC)
* Catalyst login support
* Automatically create user
* Redirect / Callback URI
* Logout URL
* Authorization Server
* Access Policy
* Authorization Code grant type
* Internal User
* active status

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst)
* [Client ID](/knowledgebase/terminology/#client-id)
* [Client Secret](/knowledgebase/terminology/#client-secret)
* [Single sign on settings](/knowledgebase/terminology/#single-sign-on-settings)
* [Okta OpenID Connect (OIDC)](/knowledgebase/terminology/#okta-openid-connect-oidc)
* [Catalyst login support](/knowledgebase/terminology/#catalyst-login-support)
* [Automatically create user](/knowledgebase/terminology/#automatically-create-user)
* [Redirect / Callback URI](/knowledgebase/terminology/#redirect-callback-uri)

## Related topics

* Not provided.

## Prerequisites

* Administrator access to both the Okta account and the Autologyx Catalyst platform
* A user in Catalyst with permission to create SSO configuration
* Basic familiarity with Okta administration and OIDC-based application setup

## Not covered

* Troubleshooting failed Okta/Catalyst authentication flows
* Detailed explanation of OIDC concepts beyond the configuration steps
* Advanced Okta security policy design or recommended policy values
* Non-Okta SSO providers or non-OIDC SSO methods
* User/group provisioning beyond Catalyst's automatic first-login user creation option

---

---
url: >-
  /knowledgebase-agent-guides/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.agent.md
---
# Agent guide: OpenAI

* **Page path:** `applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`
* **Page type:** reference

## What this page is about

This page explains how to use OpenAI within Autologyx Sequences using ChatGPT actors, embedding actors, or generic API actors. It outlines when to use each option, how to configure them, and how to handle model outputs safely in workflow automation.

## User intent

* Understand when to use OpenAI in an Autologyx workflow
* Choose between ChatGPT actors, embedding actors, and direct API calls
* Configure a ChatGPT actor in a Sequence
* Configure an OpenAI embedding actor
* Use merge fields, authentication objects, and test records with OpenAI actors
* Store or parse OpenAI responses for later Sequence steps
* Design structured JSON outputs for deterministic workflow processing
* Apply validation and human review to AI-generated outputs

## Key terms

* Autologyx
* Sequence
* Sequencer
* OpenAI
* ChatGPT Actor
* OpenAI: GPT or ChatGPT actor
* Embedding Actor
* embeddings
* generic API actors
* Authentication Object
* prompt
* context
* temperature
* merge fields
* Record ID
* Test Integration
* Encoding format
* dimensions
* JSON outputs
* Local Variable actor
* deterministic validation
* human review

## Terminology links

* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequence`)
* [OpenAI](/knowledgebase/terminology/#openai)
* [ChatGPT Actor](/knowledgebase/terminology/#chatgpt-actor)
* [OpenAI Embedding Actors](/knowledgebase/terminology/#openai-embedding-actors) (matched from `Embedding Actor`)
* [generic API actors](/knowledgebase/terminology/#generic-api-actors)
* [Authentication Object](/knowledgebase/terminology/#authentication-object)
* [Merge fields](/knowledgebase/terminology/#merge-fields)
* [Record ID](/knowledgebase/terminology/#record-id)

## Related topics

* Not provided.

## Prerequisites

* An Autologyx environment with the relevant OpenAI integration enabled
* An OpenAI platform account where required
* Ability to create and manage OpenAI API keys
* An Authentication Object configured for the OpenAI API key
* Permission to edit the relevant Sequence
* Basic familiarity with Sequences, actors, records, and merge fields

## Not covered

* Detailed instructions for making direct API calls beyond noting that generic API actors can be used
* Guaranteed model availability or exact model lists for every environment
* A full specification of OpenAI endpoint payloads or response schemas
* Vector storage, retrieval infrastructure, or downstream embedding comparison implementation details
* Any guarantee that model outputs will be complete, accurate, or deterministic

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/integrations/openai-embeddings-integration/index.agent.md
---
# Agent guide: OpenAI Embeddings integration

* **Page path:** `system-configuration/integrations/openai-embeddings-integration/index.md`
* **Page type:** explanation

## What this page is about

This page explains the OpenAI Embeddings integration in Catalyst workflows and how it enables semantic search and semantic analysis by converting text into vector representations. It outlines common use cases, example business scenarios, configurable settings, and how the integration can connect with other systems and workflow components.

## User intent

* Understand what the OpenAI Embeddings integration does
* Learn how embeddings support semantic search and similarity analysis
* Identify suitable business use cases for embeddings in Catalyst workflows
* See example scenarios such as clause searching, document review, and fraud investigation support
* Review what settings can be configured for the integration
* Understand which systems and workflow components embeddings can be combined with
* Know the key limitations and considerations when using embeddings

## Key terms

* OpenAI Embeddings integration
* semantic search
* semantic analysis
* vector representations
* contextual similarity
* similarity matching
* document retrieval
* data classification
* clustering and grouping
* models
* input formats
* encoding methods
* vector dimensions
* Catalyst workflows
* iManage
* Salesforce
* Microsoft Graph
* DocuSign
* Sequencer tasks and records

## Terminology links

* [OpenAI Embeddings integration](/knowledgebase/terminology/#openai-embeddings-integration)
* [vector dimensions](/knowledgebase/terminology/#vector-dimensions)
* [Catalyst workflows](/knowledgebase/terminology/#catalyst-workflows)
* [iManage template](/knowledgebase/terminology/#imanage-template) (matched from `iManage`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Catalyst workflows
* General familiarity with document or workflow integrations
* Basic concept of semantic search versus keyword-based search

## Not covered

* Step-by-step setup or installation instructions
* Detailed configuration procedures for models or encoding settings
* How conversational text generation works
* Implementation details for external document system integrations
* Performance tuning, evaluation, or troubleshooting guidance

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/integrations/openai-gpt-integration/index.agent.md
---
# Agent guide: OpenAI GPT integration

* **Page path:** `system-configuration/integrations/openai-gpt-integration/index.md`
* **Page type:** explanation

## What this page is about

This page explains how the OpenAI GPT integration lets Catalyst workflows use ChatGPT capabilities inside Sequencer via the OpenAI GPT actor. It outlines supported uses, dynamic prompting with merge fields, output handling, configurable behaviour, example use cases, and key implementation reminders.

## User intent

* Understand what the OpenAI GPT integration does in Catalyst workflows
* Learn what the OpenAI GPT actor can be used for
* See how to build dynamic AI prompts using merge fields
* Find out how AI-generated outputs can be reused in workflows
* Understand which AI behaviour settings can be configured
* Review typical business use cases for the integration
* Check important requirements and cautions before operational use

## Key terms

* OpenAI GPT integration
* Catalyst workflows
* Sequencer
* OpenAI GPT actor
* ChatGPT capabilities
* merge fields
* dynamic prompts
* AI-generated responses
* workflow decisions
* temperature
* model selection
* authentication configuration
* Authentication Objects

## Terminology links

* [OpenAI: GPT integration](/knowledgebase/terminology/#openai-gpt-integration) (matched from `OpenAI GPT integration`)
* [Catalyst workflows](/knowledgebase/terminology/#catalyst-workflows)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [OpenAI: GPT actor](/knowledgebase/terminology/#openai-gpt-actor) (matched from `OpenAI GPT actor`)
* [merge fields](/knowledgebase/terminology/#merge-fields)
* [temperature](/knowledgebase/terminology/#temperature)
* [model selection](/knowledgebase/terminology/#model-selection)
* [authentication configuration](/knowledgebase/terminology/#authentication-configuration)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Catalyst workflows
* Familiarity with Sequencer
* Awareness of records, tasks, and workflow steps
* Understanding that the OpenAI integration must be enabled
* Possible need for Authentication Objects depending on deployment configuration

## Not covered

* Step-by-step setup or installation instructions
* Detailed authentication configuration process
* Specific model options or parameter values
* Prompt engineering guidance beyond noting that prompt quality matters
* Governance, validation, or review procedures in detail
* Troubleshooting or error handling

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.10/openai-embeddings-integration/index.agent.md
---
# Agent guide: OpenAI: Embeddings integration

* **Page path:** `release-notes/release-notes-1.10/openai-embeddings-integration/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces the integration of OpenAI Embeddings into the platform. It explains that embeddings can be configured in the Sequencer and used with records, tasks, templates, and external integrations to add semantic search, analysis, and workflow automation.

## User intent

* Understand what the OpenAI Embeddings integration enables on the platform
* Learn how embeddings can be configured in the Sequencer
* Identify example business use cases for embeddings with unstructured data
* See how embeddings connect with records, tasks, templates, and existing integrations
* Assess potential legal, risk, and financial analysis applications

## Key terms

* OpenAI Embeddings
* Sequencer
* semantic intelligence
* unstructured data
* models
* input formats
* encoding methods
* dimensions
* records
* tasks
* templates
* semantic search
* contract review
* risk insights
* automation
* iManage
* Salesforce
* DocuSign
* Microsoft Graph

## Terminology links

* [OpenAI: Embeddings](/knowledgebase/terminology/#openai-embeddings) (matched from `OpenAI Embeddings`)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `records`)
* [Tasks](/knowledgebase/terminology/#tasks)
* [Document Templates](/knowledgebase/terminology/#document-templates) (matched from `templates`)
* [iManage template](/knowledgebase/terminology/#imanage-template) (matched from `iManage`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the platform and its automation workflows
* Understanding of records, tasks, templates, and the Sequencer
* General awareness of business integrations such as Salesforce, iManage, DocuSign, or Microsoft Graph

## Not covered

* Step-by-step setup or implementation instructions
* Technical API details or authentication requirements
* Pricing, licensing, or availability constraints
* Model-specific guidance or recommended parameter values
* Performance benchmarks or limitations
* Security, compliance, or data handling specifics beyond the public classification note

---

---
url: >-
  /knowledgebase-agent-guides/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.agent.md
---
# Agent guide: OpenAI: GPT Actor

* **Page path:** `applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`
* **Page type:** explanation

## What this page is about

This page explains how to enable, configure, and use the OpenAI: GPT actor in Autologyx Catalyst Sequencer workflows. It covers setup requirements, authentication, actor configuration options, testing, and how to store and reuse GPT responses in a sequence.

## User intent

* Understand what the OpenAI: GPT actor does in Autologyx Catalyst
* Enable access to the OpenAI: GPT integration
* Set up the required authentication object using an OpenAI API key
* Add the OpenAI: GPT actor to a sequence
* Configure model, prompt, context, temperature, and authentication settings
* Use merge fields to dynamically customise prompts from record data
* Test GPT actor responses using a record ID
* Store the GPT response in a local variable for later use in the workflow
* Use GPT output to update records, generate summaries, reports, or emails

## Key terms

* OpenAI: GPT actor
* Autologyx Catalyst
* Sequencer
* Sequence
* Authentication Object
* API Key
* merge fields
* Prompt
* Context
* Temperature
* Model
* GPT 3.5
* GPT 4.0
* GPT 4
* Local Variable actor
* JSON
* Record ID
* Test Integration

## Terminology links

* [OpenAI: GPT actor](/knowledgebase/terminology/#openai-gpt-actor)
* [Autologyx Catalyst](/knowledgebase/terminology/#autologyx-catalyst)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Authentication Object](/knowledgebase/terminology/#authentication-object)
* [Merge fields](/knowledgebase/terminology/#merge-fields)
* [Local Variable actor](/knowledgebase/terminology/#local-variable-actor)
* [Record ID](/knowledgebase/terminology/#record-id)
* [Test Integration](/knowledgebase/terminology/#test-integration)

## Related topics

* OpenAI: GPT integration
* Azure OpenAI integration
* OpenAI: Embeddings integration

## Prerequisites

* Access to Autologyx Catalyst administration and sequence configuration
* An OpenAI platform account
* Ability to create and manage OpenAI API keys
* The OpenAI: GPT integration being enabled as a premium service via a client manager
* Basic familiarity with Sequences, triggers, actors, and record data in Autologyx

## Not covered

* Detailed OpenAI model behavior or prompt engineering best practices beyond basic examples
* Pricing, subscription details, or commercial terms beyond noting it is a premium service
* Troubleshooting authentication, API errors, or failed responses
* Detailed schema of the full JSON response beyond basic usage guidance
* Implementation details of Azure OpenAI or embeddings beyond links to those topics

---

---
url: /knowledgebase-agent-guides/applied-ai/openai-gpt-actor/index.agent.md
---
# Agent guide: OpenAI: GPT Actor

* **Page path:** `applied-ai/openai-gpt-actor/index.md`
* **Page type:** explanation

## What this page is about

This page introduces the OpenAI: GPT actor in Autologyx Catalyst and explains how to enable, configure, test, and use it inside Sequences. It focuses on sending prompts and record data to GPT models and storing the response for downstream workflow steps.

## User intent

* Understand what the OpenAI: GPT actor does in workflows
* Learn how to enable the premium OpenAI: GPT integration
* Set up authentication for the actor using an OpenAI API key
* Add the OpenAI: GPT actor to a Sequence
* Configure model, prompt, context, temperature, and authentication
* Use merge fields to inject record data into prompts
* Test GPT responses using a record ID
* Store and reuse the actor response with a Local Variable actor
* Extract JSON attributes from the GPT response for later sequence steps

## Key terms

* OpenAI: GPT actor
* Autologyx Catalyst
* Sequence
* Authentication Object
* API Key
* merge fields
* Prompt
* Context
* Temperature
* Model
* Local Variable actor
* JSON
* Record ID
* Test Integration

## Terminology links

* [OpenAI: GPT actor](/knowledgebase/terminology/#openai-gpt-actor)
* [Catalyst](/knowledgebase/terminology/#catalyst) (matched from `Autologyx Catalyst`)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequence`)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `Authentication Object`)
* [Authorization Objects API Keys](/knowledgebase/terminology/#authorization-objects-api-keys) (matched from `API Key`)
* [merge fields](/knowledgebase/terminology/#merge-fields)
* [temperature](/knowledgebase/terminology/#temperature)
* [Local Variable Actor](/knowledgebase/terminology/#local-variable-actor)

## Related topics

* OpenAI: GPT integration
* Azure OpenAI integration
* OpenAI: Embeddings integration

## Prerequisites

* Access to Autologyx Catalyst administration and Sequence builder
* An OpenAI platform account
* Ability to create and manage OpenAI API keys
* The premium OpenAI: GPT integration enabled on the subscription

## Not covered

* Detailed explanation of each GPT model beyond listing available options
* OpenAI account creation or API key generation steps
* Prompt engineering best practices beyond basic examples
* Full JSON schema details for all possible actor responses
* Advanced sequence design patterns beyond using a Local Variable actor
* Azure OpenAI or embeddings setup details

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.10/openai-gpt-integration/index.agent.md
---
# Agent guide: OpenAI: GPT integration

* **Page path:** `release-notes/release-notes-1.10/openai-gpt-integration/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces the OpenAI: GPT actor in Sequencer, available to clients with OpenAI integration enabled. It explains the actor’s configurable capabilities, how GPT outputs can be used in workflows, and example business use cases across sectors.

## User intent

* Understand what the OpenAI: GPT integration in Sequencer does
* Learn how GPT can be embedded into workflow automation
* See what configuration options are available for the GPT actor
* Find examples of sector-specific use cases for legal, financial services, accounting, and HR
* Assess the business benefits of enabling ChatGPT in processes

## Key terms

* OpenAI: GPT actor
* Sequencer
* OpenAI integration enabled
* workflow automation
* ChatGPT
* dynamic prompt customisation
* merge fields
* records
* versatile responses
* API configuration
* context
* temperature
* authentication objects
* model version
* context aware AI capabilities

## Terminology links

* [OpenAI: GPT actor](/knowledgebase/terminology/#openai-gpt-actor)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [OpenAI integration enabled](/knowledgebase/terminology/#openai-integration-enabled)
* [Dynamic Prompt Customisation](/knowledgebase/terminology/#dynamic-prompt-customisation)
* [merge fields](/knowledgebase/terminology/#merge-fields)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `records`)
* [Versatile Responses](/knowledgebase/terminology/#versatile-responses)
* [API configuration](/knowledgebase/terminology/#api-configuration)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Sequencer workflows
* Understanding of records and merge fields
* Awareness that OpenAI integration must be enabled for access
* Basic understanding of ChatGPT/OpenAI-style model configuration

## Not covered

* Step-by-step setup or enablement instructions
* Detailed API request/response examples
* Pricing, licensing, or entitlement details beyond availability to enabled clients
* Security, governance, or data handling specifics
* Limits, model support matrix, or troubleshooting guidance

---

---
url: >-
  /knowledgebase-agent-guides/administration/communication/outbound-mail-setup/index.agent.md
---
# Agent guide: Outbound mail setup

* **Page path:** `administration/communication/outbound-mail-setup/index.md`
* **Page type:** explanation

## What this page is about

Explains how to configure the system’s outbound email service for all outgoing notifications, including supported mail service options, required settings, testing, and validation. It also notes access restrictions and the recommended Microsoft Office 365 Exchange (Graph) with OAuth 2.0 setup.

## User intent

* Find where outbound mail settings are configured
* Understand who can access and edit outbound mail setup
* Choose which mail service option to use for outgoing email
* Learn why Microsoft Office 365 Exchange (Graph) with OAuth 2.0 is recommended
* Identify requirements for Microsoft client credentials setup
* Enter Microsoft client credentials settings such as host, port, username, and TLS
* Test outbound mail credentials and interpret test results
* Understand why mail may not send even if settings can be saved
* Configure mandatory From and backend failure alert email addresses
* Resolve common validation errors for backend failure alert email addresses
* Understand how existing password fields behave when editing basic auth settings

## Key terms

* Outbound mail setup
* Super admin
* Mail service
* Microsoft Office 365 Exchange (Graph)
* OAuth 2.0
* Basic Authentication
* SMTP
* Azure Active Directory
* Application registration
* Authentication Object
* Microsoft Client Credentials
* Host
* Port
* Username
* TLS
* Test mail settings
* Authentication success!
* Authentication Error
* Connection error
* From email address
* Backend failure alerts email address
* Validation errors

## Terminology links

* [Outbound mail setup](/knowledgebase/terminology/#outbound-mail-setup)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [mail service](/knowledgebase/terminology/#mail-service)
* [Microsoft Office 365 Exchange (Graph) with oAuth 2.0](/knowledgebase/terminology/#microsoft-office-365-exchange-graph-with-oauth-20) (matched from `Microsoft Office 365 Exchange (Graph)`)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `Authentication Object`)
* [Microsoft Client Credentials](/knowledgebase/terminology/#microsoft-client-credentials)
* [Host selection](/knowledgebase/terminology/#host-selection) (matched from `Host`)
* [Username](/knowledgebase/terminology/#username)

## Related topics

* Configuring Outbound mail setup with Microsoft client credentials
* Creating an Authentication Object

## Prerequisites

* Super admin access
* Understanding of outbound email/mail services
* Access to Azure Active Directory for Microsoft client credentials setup
* Ability to register and configure an application in Azure AD
* Possibly assistance from an IT department for Microsoft/OAuth setup

## Not covered

* Detailed step-by-step Microsoft client credentials configuration instructions
* Detailed instructions for creating an Authentication Object
* General email notification behavior outside outbound mail configuration
* Troubleshooting beyond the listed authentication, connection, and email field validation errors

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/formbuilder-components/overview-of-formbuilder/index.agent.md
---
# Agent guide: Overview of formbuilder

* **Page path:** `record-and-task-forms/formbuilder-components/overview-of-formbuilder/index.md`
* **Page type:** explanation

## What this page is about

This page gives a quick overview of the Catalyst formbuilder and its main components. It explains what the formbuilder is used for and how its canvas and side panel vary by configuration area.

## User intent

* Understand what the Catalyst formbuilder is used for
* See which kinds of forms and views can be created with formbuilder
* Learn the basic layout of the formbuilder interface
* Check which side panel sections are available in different system areas
* Understand the basic drag-and-drop and configuration workflow

## Key terms

* Catalyst formbuilder
* record displays
* standalone forms
* Task templates
* canvas
* side panel
* Layout
* Fields
* Object Class Fields
* Properties
* Child Object Classes
* Elements
* Object class Card view
* Object class Create and edit view
* Object class Summary view
* Task template self contained form
* Task template update object record

## Terminology links

* [Catalyst formbuilder](/knowledgebase/terminology/#catalyst-formbuilder)
* [record Displays](/knowledgebase/terminology/#record-displays)
* [standalone forms](/knowledgebase/terminology/#standalone-forms)
* [Task templates](/knowledgebase/terminology/#task-templates)
* [Sequence canvas](/knowledgebase/terminology/#sequence-canvas) (matched from `canvas`)
* [side panels](/knowledgebase/terminology/#side-panels) (matched from `side panel`)
* [Layout](/knowledgebase/terminology/#layout)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `Fields`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with records, object classes, and task templates in Catalyst
* Awareness that different system areas have different formbuilder options

## Not covered

* Detailed instructions for configuring individual components
* Step-by-step procedures for building specific forms or views
* Explanations of each side panel section beyond availability by area
* Advanced configuration behavior or validation rules

---

---
url: >-
  /knowledgebase-agent-guides/administration/roles-and-permissions/overview-of-user-permissions/index.agent.md
---
# Agent guide: Overview of User Permissions

* **Page path:** `administration/roles-and-permissions/overview-of-user-permissions/index.md`
* **Page type:** explanation

## What this page is about

This page gives a high-level overview of the main factors that determine what a Catalyst user can see and do. It explains how permissions are influenced by account type, roles, object class permissions, record permissions, and user groups, and points readers to the relevant configuration areas.

## User intent

* Understand what controls user permissions in Catalyst
* Learn the differences between the five account types
* Identify which areas are restricted to Super Admin users
* Understand how Config admin users get permissions through roles
* Understand the difference between object class class permissions and record permissions
* Learn how record permission sets can be assigned directly or through the Sequencer
* Understand how user groups are used in permission management
* Determine where to configure different kinds of user access

## Key terms

* account type
* Super Admin
* Config Admin
* 1 time completion
* Internal
* External
* role
* object class permissions
* class permissions
* record permissions
* permission set
* owner
* record access tab
* Record Access actor
* Sequencer
* user group

## Terminology links

* [account type](/knowledgebase/terminology/#account-type)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super Admin`)
* [Config admin account type](/knowledgebase/terminology/#config-admin-account-type) (matched from `Config Admin`)
* [1 time completion account type](/knowledgebase/terminology/#1-time-completion-account-type) (matched from `1 time completion`)
* [Internal account type](/knowledgebase/terminology/#internal-account-type) (matched from `Internal`)
* [External account type](/knowledgebase/terminology/#external-account-type) (matched from `External`)
* [Roles](/knowledgebase/terminology/#roles) (matched from `role`)
* [object class permissions](/knowledgebase/terminology/#object-class-permissions)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst users and system configuration areas
* General understanding of object classes, records, tasks, and the Sequencer

## Not covered

* Step-by-step configuration instructions for each permission area
* Detailed setup of roles, object classes, or user groups
* Full explanation of task templates, sequences, relational model, SSO, or authentication
* Specific examples beyond the overview-level descriptions

---

---
url: >-
  /knowledgebase-agent-guides/getting-started/performing-work-delivery/index.agent.md
---
# Agent guide: Performing Work Delivery

* **Page path:** `getting-started/performing-work-delivery/index.md`
* **Page type:** getting-started

## What this page is about

This page currently contains no instructional content beyond the classification label. It does not describe how to perform work delivery.

## User intent

* Not provided.

## Key terms

* Autologyx Classification
* Unrestricted
* Public

## Terminology links

* No matched terminology links found.

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Steps for performing work delivery
* Work delivery concepts or workflows
* Configuration, setup, or usage guidance
* Examples, troubleshooting, or related process details

---

---
url: >-
  /knowledgebase-agent-guides/getting-started/platform-admin-administrators/index.agent.md
---
# Agent guide: Platform administrators

* **Page path:** `getting-started/platform-admin-administrators/index.md`
* **Page type:** getting-started

## What this page is about

This page introduces the responsibilities of a Catalyst platform administrator, typically someone with a Super admin account. It highlights the main global administration areas used to manage users, access, authentication, company details, integrations, and outbound communications.

## User intent

* Understand what a platform administrator is responsible for in Catalyst
* Find the main global settings available under Administration
* Learn where to manage users, roles, and user groups
* Identify where to configure password rules and account activation behavior
* Find where to set up single sign-on providers like Microsoft or Google
* Understand where authentication objects are used for third-party API credentials
* Locate outbound mail configuration for system notifications
* See how company details are used in merge fields and message templates

## Key terms

* Platform administrator
* Catalyst
* Super admin
* Administration
* Users
* Roles
* User groups
* Workspace
* Company details
* Merge fields
* Message templates
* Standard authentication
* Password rules
* Single sign on
* Authentication Objects
* API calls
* Outbound mail setup
* Outgoing notifications

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Administration Sections](/knowledgebase/terminology/#administration-sections) (matched from `Administration`)
* [Users list](/knowledgebase/terminology/#users-list) (matched from `Users`)
* [Roles](/knowledgebase/terminology/#roles)
* [User Groups](/knowledgebase/terminology/#user-groups)
* [Workspace](/knowledgebase/terminology/#workspace)
* [Company details](/knowledgebase/terminology/#company-details)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst
* Administrative access, typically a Super admin account
* General understanding of users, authentication, and company access policies

## Not covered

* Step-by-step instructions for each administration feature
* Detailed configuration of users, roles, or user groups
* Detailed setup of SSO providers
* Detailed outbound mail setup procedures
* Workspace-specific record or task usage
* Non-administrative end-user workflows

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.2/present-child-records/index.agent.md
---
# Agent guide: Present child records

* **Page path:** `release-notes/release-notes-1.2/present-child-records/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces a feature for presenting child records in workflows by creating relations between object classes in the Relational modeller. It explains how child records can be configured for display, navigated by end users, and controlled through permissions.

## User intent

* Understand what the new child records feature does
* Learn how child records are enabled through relations between object classes
* See how to configure the child record component in the Form builder
* Understand what information can be shown in child record lists
* Know how end users interact with related child records on a record page
* Understand how adding related records works
* Check how permissions affect visibility and access to child record details

## Key terms

* child records
* related records
* object classes
* Relational modeller
* child record component
* Form builder
* Record properties
* Class fields
* Create and edit view display
* pagination
* results count
* search engine
* Child Record Summary side tab panel
* permissions

## Terminology links

* [Present child records](/knowledgebase/terminology/#present-child-records) (matched from `child records`)
* [related records](/knowledgebase/terminology/#related-records)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [Relational modeller](/knowledgebase/terminology/#relational-modeller)
* [child record component](/knowledgebase/terminology/#child-record-component)
* [Form builder](/knowledgebase/terminology/#form-builder)
* [Object Record properties](/knowledgebase/terminology/#object-record-properties) (matched from `Record properties`)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `Class fields`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of records and object classes in Autologyx
* Familiarity with the Relational modeller
* Familiarity with the Form builder
* Awareness of user permissions and access control

## Not covered

* Step-by-step setup instructions for the Relational modeller or Form builder
* Detailed permission configuration
* Technical implementation details
* Behavior outside the Create and edit view display context
* Any unrelated workflow or record-management features

---

---
url: >-
  /knowledgebase-agent-guides/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/index.agent.md
---
# Agent guide: Private Cloud Ai

* **Page path:** `applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/index.md`
* **Page type:** explanation

## What this page is about

This page currently contains no substantive documentation and only indicates that the Private Cloud Ai page is being prepared. It is marked as unrestricted and public.

## User intent

* Check whether documentation for Private Cloud Ai is available
* Confirm the publication status of the Private Cloud Ai page
* See the classification or access level of this page

## Key terms

* Private Cloud Ai
* Status
* being prepared
* Autologyx Classification
* Unrestricted
* Public

## Terminology links

* [Private Cloud Ai](/knowledgebase/terminology/#private-cloud-ai)
* [Autologyx Classification](/knowledgebase/terminology/#autologyx-classification)
* [Unrestricted, Public](/knowledgebase/terminology/#unrestricted-public) (matched from `Unrestricted`)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Any explanation of what Private Cloud Ai is
* Architecture, setup, or configuration details
* Usage instructions or workflows
* Technical requirements or prerequisites
* Related features, integrations, or examples

---

---
url: >-
  /knowledgebase-agent-guides/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.agent.md
---
# Agent guide: Privately hosted models

* **Page path:** `applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`
* **Page type:** reference

## What this page is about

This page explains how Autologyx integrates privately hosted AI or machine learning models by calling their API endpoints through generic API integration patterns in a Sequence. It covers when to use this approach, how it works, design and governance considerations, and typical use cases.

## User intent

* Understand when to use privately hosted models instead of standard OpenAI, Azure OpenAI, or AWS Bedrock actors
* Learn how a Sequence calls a private model endpoint using an API Call actor or generic API integration
* Plan the request/response contract for integrating a private model with Autologyx
* Identify suitable use cases such as redaction, risk scoring, document classification, and multimodal processing
* Understand governance, validation, and human review considerations for private model outputs
* Prepare a private model endpoint and Autologyx configuration for production use

## Key terms

* Privately hosted models
* Sequence
* Sequencer
* API Call actor
* generic API integration
* API endpoint
* API contract
* Authentication Object
* Object Record
* structured response
* deterministic logic
* human review
* fine tuning
* post training optimisation
* customer AI gateway
* private cloud
* private network
* conventional machine learning
* LLM
* risk scoring
* PII detection and redaction
* named entity recognition

## Terminology links

* [Privately hosted models](/knowledgebase/terminology/#privately-hosted-models)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequence`)
* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [Authentication Object](/knowledgebase/terminology/#authentication-object)
* [Object Records](/knowledgebase/terminology/#object-records) (matched from `Object Record`)
* [human review task](/knowledgebase/terminology/#human-review-task) (matched from `human review`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Autologyx Sequences and actors
* Familiarity with API-based integrations
* Awareness of authentication and network access requirements
* Understanding of the customer's model endpoint, request format, and response format

## Not covered

* Step-by-step configuration details for a specific model serving platform
* Detailed setup instructions for cloud infrastructure, GPUs, or Kubernetes
* Implementation specifics for individual providers or tools such as Hugging Face, vLLM, or Ray Serve
* A dedicated built-in Autologyx actor for privately hosted models
* Guarantees of deterministic, accurate, or risk-free model outputs

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/formbuilder-components/properties/index.agent.md
---
# Agent guide: Properties

* **Page path:** `record-and-task-forms/formbuilder-components/properties/index.md`
* **Page type:** explanation

## What this page is about

This page explains the built-in Properties available in form side panels for Card, Create and edit, and Summary views, and how they behave when added to forms. It also describes when these values are shown or automatically populated during record creation and editing.

## User intent

* Identify which built-in Properties are available on supported form views
* Understand what ALX ID, Created date/time, Updated date/time, and Owners mean
* Learn how to add Properties to a form using drag and drop
* Understand why some Properties appear as visible only when editing during record creation
* Understand how the Owners property behaves and when it is set automatically

## Key terms

* Properties
* side panel
* Card view
* Create and edit view
* Summary view
* ALX ID
* record ID
* Identifier
* Created date/time
* Updated date/time
* Owners
* owner avatar
* drag and drop
* record creation
* editing

## Terminology links

* [Properties](/knowledgebase/terminology/#properties)
* [side panels](/knowledgebase/terminology/#side-panels) (matched from `side panel`)
* [Card view](/knowledgebase/terminology/#card-view)
* [Create and edit view](/knowledgebase/terminology/#create-and-edit-view)
* [summary view](/knowledgebase/terminology/#summary-view)
* [ALX ID](/knowledgebase/terminology/#alx-id)
* [Identifier](/knowledgebase/terminology/#identifier)
* [Created date/time](/knowledgebase/terminology/#created-datetime)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with record and task forms
* Basic understanding of form builder components
* Understanding of records and object classes

## Not covered

* Detailed configuration options beyond adding Properties to a form
* How to change which field is used as the Identifier for an Object class
* Any Properties beyond ALX ID, Created date/time, Updated date/time, and Owners
* Broader form design or layout guidance outside this Properties component page

---

---
url: >-
  /knowledgebase-agent-guides/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/index.agent.md
---
# Agent guide: Public Ai Providers

* **Page path:** `applied-ai/applied-ai-and-the-sequencer/public-ai-providers/index.md`
* **Page type:** explanation

## What this page is about

This page is a placeholder for information about Public Ai Providers. It does not yet provide substantive content beyond indicating the topic and that the page is being prepared.

## User intent

* Check whether documentation about Public Ai Providers exists
* Determine if this page contains guidance or details on Public Ai Providers
* Understand the current availability/status of this topic in the docs

## Key terms

* Public Ai Providers
* Autologyx Classification
* Unrestricted, Public

## Terminology links

* [Public Ai Providers](/knowledgebase/terminology/#public-ai-providers)
* [Autologyx Classification](/knowledgebase/terminology/#autologyx-classification)
* [Unrestricted, Public](/knowledgebase/terminology/#unrestricted-public)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Any definition or explanation of Public Ai Providers
* Configuration, setup, or usage instructions
* Examples, provider lists, or comparisons
* Security, governance, or integration details

---

---
url: >-
  /knowledgebase-agent-guides/workspace/the-task-panel/re-assigning-tasks/index.agent.md
---
# Agent guide: Re-assigning Tasks

* **Page path:** `workspace/the-task-panel/re-assigning-tasks/index.md`
* **Page type:** explanation

## What this page is about

This page appears intended to explain re-assigning tasks, but the provided content contains only a placeholder heading and no substantive instructions or explanation.

## User intent

* Find information on how to re-assign a task
* Understand task reassignment in the task panel

## Key terms

* Re-assigning Tasks
* Task Panel

## Terminology links

* [Re Assigning Tasks](/knowledgebase/terminology/#re-assigning-tasks) (matched from `Re-assigning Tasks`)
* [Task Panel](/knowledgebase/terminology/#task-panel)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with tasks and the task panel

## Not covered

* Actual steps for re-assigning a task
* Requirements, permissions, or constraints for reassignment
* Outcomes or effects of re-assigning tasks

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.6/read-only-fields/index.agent.md
---
# Agent guide: Read-only fields

* **Page path:** `release-notes/release-notes-1.6/read-only-fields/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces Read only fields, a feature for display forms that lets designers make fields visible but not manually editable by end users. It explains how to enable the option and notes that Sequencer can still update those fields automatically under defined conditions.

## User intent

* Understand what Read only fields do
* Learn how to configure a field as read only in a display form
* Determine how read only fields affect end-user editing
* See how Sequencer can update read only fields automatically
* Find a use case for protecting values such as Status during record creation

## Key terms

* Read only fields
* display form
* Read only option
* field setup
* end users
* manual modifications
* Sequencer
* automatic update
* Status field
* field accessibility

## Terminology links

* [Read only fields](/knowledgebase/terminology/#read-only-fields)
* [display forms](/knowledgebase/terminology/#display-forms) (matched from `display form`)
* [Read only option](/knowledgebase/terminology/#read-only-option)
* [end users](/knowledgebase/terminology/#end-users)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [status field](/knowledgebase/terminology/#status-field)
* [field accessibility](/knowledgebase/terminology/#field-accessibility)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with display forms
* Understanding of field configuration during form setup
* Basic awareness of Sequencer and condition-based updates

## Not covered

* Detailed Sequencer configuration steps
* Any limitations, exceptions, or edge cases for read only fields
* Permissions or role-based access behavior beyond end-user manual editing
* Technical implementation details
* Examples beyond the Status field scenario

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.14/real-time-workflow-improvements/index.agent.md
---
# Agent guide: Real-Time & Workflow Improvements

* **Page path:** `release-notes/release-notes-1.14/real-time-workflow-improvements/index.md`
* **Page type:** release-notes

## What this page is about

Release notes for workflow and real-time enhancements in version 1.14, covering new Sequencer merge field shortcuts, loop-related merge fields, expanded User Group member resolution, and WebSocket-based live task updates.

## User intent

* Understand which new merge fields were added in Sequencer and what values they resolve to
* Use {{ loop item }} in Local Variables for loop-driven document workflows
* Use {{ loop counter }} to generate indexed values in loop-based automation
* Learn how User type Object Class merge fields now return User Group members
* Understand the new real-time task list update behavior powered by WebSockets

## Key terms

* Sequencer
* merge fields
* Send Message actor
* API Call
* Variables
* {{client.name}}
* {{client.url}}
* {{current date}}
* {{current datetime}}
* Local Variables
* Document Type source
* {{ loop item }}
* Loop actor
* {{ loop counter }}
* User type Object Class fields
* User Group Members
* document templates
* WebSockets
* Task List
* Task Panel
* Landing Page

## Terminology links

* [Sequencer](/knowledgebase/terminology/#sequencer)
* [merge fields](/knowledgebase/terminology/#merge-fields)
* [Send Message Actors](/knowledgebase/terminology/#send-message-actors) (matched from `Send Message actor`)
* [API Call actor](/knowledgebase/terminology/#api-call-actor) (matched from `API Call`)
* [local variables](/knowledgebase/terminology/#local-variables) (matched from `Variables`)
* [Document Type source](/knowledgebase/terminology/#document-type-source)
* [Loop actors](/knowledgebase/terminology/#loop-actors) (matched from `Loop actor`)
* [user type Object Class fields](/knowledgebase/terminology/#user-type-object-class-fields)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Sequencer and sequence actors
* Understanding of merge fields and runtime resolution
* Knowledge of Loop actors and Local Variables
* Some awareness of User type Object Class fields and User Groups

## Not covered

* Detailed setup instructions or UI walkthroughs beyond the release summary
* Exact syntax/example payload for the User Group member response structure
* Comprehensive list of all actors supporting these merge fields
* Implementation details of the WebSocket API
* General platform concepts outside these specific 1.14 improvements

---

---
url: >-
  /knowledgebase-agent-guides/workspace/records/record-access---adding-and-removing-assignees/index.agent.md
---
# Agent guide: Record access - adding and removing Assignees

* **Page path:** `workspace/records/record-access---adding-and-removing-assignees/index.md`
* **Page type:** explanation

## What this page is about

Explains who can use the Record access tab and how to add, inspect, and remove record Assignees using record Permission sets. It also covers immediate access changes and key limits such as assignee capacity per Permission set.

## User intent

* Find out who is allowed to manage record access
* Give another user access to a record
* Assign users to a record via a specific Permission set
* Add multiple assignees to a record
* Check which Permission sets a user has on a record
* Remove a user from a record Permission set
* Understand what happens when a Permission set is removed
* Know record owner vs assignee rules and assignee limits

## Key terms

* Record access tab
* Assignee
* Record Permission set
* Owner
* Object class owner
* Record owner
* Super admin
* Permission sets link
* Owner/Assignees list
* Give access button
* Add people
* success toast
* confirmation modal

## Terminology links

* [Record access tab](/knowledgebase/terminology/#record-access-tab)
* [Assignees](/knowledgebase/terminology/#assignees) (matched from `Assignee`)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `Record Permission set`)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Owner`)
* [Object class Owners](/knowledgebase/terminology/#object-class-owners) (matched from `Object class owner`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Permission sets link](/knowledgebase/terminology/#permission-sets-link)
* [Owner/Assignees counter](/knowledgebase/terminology/#ownerassignees-counter) (matched from `Owner/Assignees list`)

## Related topics

* Not provided.

## Prerequisites

* Know what a record is
* Know what Permission sets are
* Be one of: object class owner, record owner, or Super admin
* Have access to the Record access tab

## Not covered

* General explanation of the Record access tab beyond the brief reference to another page
* How Permission sets are created or configured
* What permissions each Permission set contains
* How record ownership is changed
* Any access model outside record-specific assignees and owners
* The meaning of the removed 'All' option beyond noting it is no longer available

---

---
url: >-
  /knowledgebase-agent-guides/workspace/records/record-access---owners/index.agent.md
---
# Agent guide: Record access - Owners

* **Page path:** `workspace/records/record-access---owners/index.md`
* **Page type:** explanation

## What this page is about

Explains who can access the Record access tab for a record and how to assign an Owner when a record currently has no Owner or Assignees. It also states the one-owner limit for a record.

## User intent

* Find out who is allowed to view/use the Record access tab
* Enable the Record access tab from the View menu
* Assign an Owner to a record that currently has no Owner or Assignees
* Understand the restriction on how many owners a record can have

## Key terms

* Record access tab
* Owner
* Object class owner
* record owner
* Super admin
* Give access
* Add people
* Add as dropdown
* Owner/Assignees list
* Owner/Assignees counter

## Terminology links

* [Record access tab](/knowledgebase/terminology/#record-access-tab)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Owner`)
* [Object class Owners](/knowledgebase/terminology/#object-class-owners) (matched from `Object class owner`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Give access button](/knowledgebase/terminology/#give-access-button) (matched from `Give access`)
* [Add people function](/knowledgebase/terminology/#add-people-function) (matched from `Add people`)
* [Add as dropdown menu](/knowledgebase/terminology/#add-as-dropdown-menu) (matched from `Add as dropdown`)
* [Owner/Assignees counter](/knowledgebase/terminology/#ownerassignees-counter) (matched from `Owner/Assignees list`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Object records and the side panel
* Ability to open the Record access tab via the View menu
* Appropriate permission level: Object class owner, record owner, or Super admin

## Not covered

* General details of the Record access tab beyond the linked 'more information' reference
* How to manage Assignees in detail
* Changing or removing an existing Owner
* Access rules for users who are not Object class owners, record owners, or Super admins

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.10/record-access-actor/index.agent.md
---
# Agent guide: Record Access actor

* **Page path:** `release-notes/release-notes-1.10/record-access-actor/index.md`
* **Page type:** release-notes

## What this page is about

Release notes introducing the Record Access actor in Sequencer, which centralizes record ownership and permission set management. It explains supported ownership/permission actions, dynamic assignment options, processing behavior, and system limits/safeguards.

## User intent

* Understand what the Record Access actor does
* Configure record ownership in different modes: remove, set if empty, override, or append
* Assign ownership by specific user or from a field value
* Manage permission set assignees by removing, appending, or overriding access
* Use dynamic user/group assignments based on record fields
* Learn limits and execution behavior when ownership or permission assignments exceed allowed constraints
* Understand sequencing rules when multiple permission set configurations are defined

## Key terms

* Record Access actor
* Sequencer
* record ownership
* ownership configuration
* permission sets
* permission set configuration
* remove access
* append
* override
* dynamic assignment
* By User
* By Field
* database limits
* assignees
* user groups
* 1TC users
* sequential processing

## Terminology links

* [Record Access actor](/knowledgebase/terminology/#record-access-actor)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [record ownership](/knowledgebase/terminology/#record-ownership)
* [Permission Sets](/knowledgebase/terminology/#permission-sets)
* [permission set configuration](/knowledgebase/terminology/#permission-set-configuration)
* [remove access](/knowledgebase/terminology/#remove-access)
* [append option](/knowledgebase/terminology/#append-option) (matched from `append`)
* [override option](/knowledgebase/terminology/#override-option) (matched from `override`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Sequencer
* Understanding of records, users, groups, and permission sets in the system

## Not covered

* Step-by-step setup instructions or UI walkthroughs
* Definitions of Sequencer, permission sets, or user groups beyond their use here
* Details of database limit customization beyond the stated defaults
* Examples of specific business workflows or field mappings
* General security model outside this actor

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequence-actors/record-access-actor/index.agent.md
---
# Agent guide: Record Access Actor

* **Page path:** `system-configuration/sequence-actors/record-access-actor/index.md`
* **Page type:** explanation

## What this page is about

This page explains how the Record Access actor controls record ownership and record access through record permission sets in a sequence. It covers how to configure ownership changes, permission set assignees, limits, and behavior when configuration cannot be applied.

## User intent

* Understand what the Record Access actor does
* Remove, set, or override a record owner after record creation
* Assign record ownership by a specific user or by a user field
* Append, override, or remove record permission set assignees
* Assign permission sets to users, user groups, or values from a field
* Remove all non-owner permission set access from a record
* Understand execution behavior when ownership or assignee limits are exceeded
* Label the actor meaningfully in a sequence
* Understand how to propagate matching access across related object classes using cascading sequences

## Key terms

* Record Access actor
* record ownership
* record owner
* record permission set
* permission set assignment
* Remove owners
* Override owners
* Set owners
* By user
* By field
* Append assignees
* Override assignees
* Remove assignees
* Remove all
* Users
* User groups
* user type fields
* sequence's object class
* Super Admin
* class permissions
* cascading sequences
* Relation Lookup actor
* Sequence Runner actor

## Terminology links

* [Record Access actor](/knowledgebase/terminology/#record-access-actor)
* [record ownership](/knowledgebase/terminology/#record-ownership)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `record owner`)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `record permission set`)
* [Remove owners](/knowledgebase/terminology/#remove-owners)
* [Override owners](/knowledgebase/terminology/#override-owners)
* [Set owners](/knowledgebase/terminology/#set-owners)
* [By users](/knowledgebase/terminology/#by-users) (matched from `By user`)

## Related topics

* Relation Lookup
* Sequence Runner

## Prerequisites

* Basic familiarity with sequences and sequence actors
* Understanding of the sequence's object class
* Knowledge of users, user groups, and user type fields
* At least one record permission set configured on the object class before configuring permission set assignment

## Not covered

* How to create or configure record permission sets themselves
* How class permissions work in detail
* How Super Admin permissions work in detail
* Detailed setup of Relation Lookup or Sequence Runner actors
* General sequence design beyond this actor
* Cross-object access syncing except for the note that it requires cascading sequences and matching permission sets

---

---
url: /knowledgebase-agent-guides/workspace/records/record-access-tab/index.agent.md
---
# Agent guide: Record access tab

* **Page path:** `workspace/records/record-access-tab/index.md`
* **Page type:** explanation

## What this page is about

This page explains the Record access tab available on an Object record side panel, including who can view it, what information it shows, and what access-management actions can be performed there. It also summarizes the tab’s UI components and key rules around record ownership and assignees.

## User intent

* Understand what the Record access tab is used for
* Find out who can access the Record access tab
* See what components and filters appear in the tab
* Learn how to view a record's owner and assignees
* Add, change, or remove a record owner
* Give or remove record access for users assigned through permission sets
* Understand limits and rules for record owners and assignees

## Key terms

* Record access tab
* Object record
* side panel
* View menu
* Owner
* Assignees
* Record Permission set
* Object class
* Super admin
* record Identifier
* Give access button
* Users' search field
* 1 time completion account type
* API call in a sequence

## Terminology links

* [Record access tab](/knowledgebase/terminology/#record-access-tab)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `Object record`)
* [side panels](/knowledgebase/terminology/#side-panels) (matched from `side panel`)
* [View menu](/knowledgebase/terminology/#view-menu)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Owner`)
* [Assignees](/knowledgebase/terminology/#assignees)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `Record Permission set`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Object records and Object classes
* Awareness of user roles such as Owner and Super admin
* Familiarity with record permission sets

## Not covered

* How to create record permission sets
* Detailed steps for changing ownership via API call in a sequence
* General user account management beyond the note about 1 time completion accounts
* Broader record configuration outside the Record access tab

---

---
url: /knowledgebase-agent-guides/record-and-task-forms/index.agent.md
---
# Agent guide: Record and Task Forms

* **Page path:** `record-and-task-forms/index.md`
* **Page type:** explanation

## What this page is about

This page introduces how forms are designed and configured in Autologyx for both Object Records and Tasks. It explains the role of forms in Catalyst, outlines the main subtopics in this section, and shows how forms relate to the wider platform.

## User intent

* Understand what record and task forms are used for in Autologyx
* Learn which parts of the documentation cover formbuilder components, form design, and conditional logic
* See how forms support creating, editing, validating, and updating information
* Understand how forms relate to Object Records, Tasks, Object Classes, Task Templates, Standalone Forms, and Create and edit view
* Find a recommended learning path for getting started with form configuration

## Key terms

* Record Forms
* Task Forms
* Autologyx
* Catalyst
* formbuilder
* Formbuilder Components
* The Form Builder
* Using Conditional Logic in Forms
* Object Records
* Tasks
* layout
* properties
* Elements
* child Object Classes
* task form fields
* conditional logic
* Object Classes
* Task Templates
* Standalone Forms
* Create and edit view

## Terminology links

* [record forms](/knowledgebase/terminology/#record-forms)
* [task forms](/knowledgebase/terminology/#task-forms)
* [Catalyst](/knowledgebase/terminology/#catalyst)
* [Form builder](/knowledgebase/terminology/#form-builder) (matched from `formbuilder`)
* [Formbuilder Components](/knowledgebase/terminology/#formbuilder-components)
* [Conditional Logic in Forms](/knowledgebase/terminology/#conditional-logic-in-forms) (matched from `Using Conditional Logic in Forms`)
* [Object records](/knowledgebase/terminology/#object-records)
* [Tasks](/knowledgebase/terminology/#tasks)

## Related topics

* Object Classes
* Task Templates
* Standalone Forms
* Create and edit view

## Prerequisites

* Basic familiarity with Autologyx and Catalyst
* Awareness of records, tasks, and form-based user interactions
* Some understanding of platform configuration roles such as Config Admins, analysts, or builders

## Not covered

* Detailed workflow design
* Detailed data model design beyond how forms relate to it
* Step-by-step configuration instructions for specific forms
* Broader platform behavior outside form building and form logic

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/merge-fields/record-properties/index.agent.md
---
# Agent guide: Record Properties

* **Page path:** `system-configuration/merge-fields/record-properties/index.md`
* **Page type:** explanation

## What this page is about

This page lists the built-in Object record properties that can be inserted into templates using merge fields. It shows the supported properties, their Jinja syntax, and a couple of usage limitations.

## User intent

* Find which record-level properties are available in template merge fields
* Insert a record ID, created date/time, or modified date/time into a template
* Understand the shorthand behavior of {{ record }} in templates
* Check limitations around referencing the record identifier field in Jinja merge fields

## Key terms

* Record properties
* Object records
* merge fields
* templates
* Jinja
* record.id
* record.created at
* record.modified at
* shorthand {{ record }}

## Terminology links

* [Object Record properties](/knowledgebase/terminology/#object-record-properties) (matched from `Record properties`)
* [Object records](/knowledgebase/terminology/#object-records)
* [merge fields](/knowledgebase/terminology/#merge-fields)
* [Document Templates](/knowledgebase/terminology/#document-templates) (matched from `templates`)
* [Jinja merge fields](/knowledgebase/terminology/#jinja-merge-fields) (matched from `Jinja`)
* [shorthand {{ record }}](/knowledgebase/terminology/#shorthand-record)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with templates and merge fields
* Basic understanding of Jinja syntax

## Not covered

* Any record properties beyond ID, Created, and Modified
* How to configure templates generally
* Detailed Jinja syntax rules beyond the listed notes
* How to reference the record identifier field successfully if not supported by the noted syntax

---

---
url: /knowledgebase-agent-guides/workspace/records/index.agent.md
---
# Agent guide: Records

* **Page path:** `workspace/records/index.md`
* **Page type:** explanation

## What this page is about

This page is about records in Catalyst and specifically working with object records. It appears to be a high-level explanation page.

## User intent

* Understand what records are in Catalyst
* Learn about working with object records

## Key terms

* Records
* object records
* Catalyst

## Terminology links

* [Object records](/knowledgebase/terminology/#object-records) (matched from `Records`)
* [Catalyst](/knowledgebase/terminology/#catalyst)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst

## Not covered

* Detailed procedures or examples for working with records
* Specific record types beyond object records
* Configuration, permissions, or API details

---

---
url: /knowledgebase-agent-guides/workspace/records/records-list/index.agent.md
---
# Agent guide: Records list

* **Page path:** `workspace/records/records-list/index.md`
* **Page type:** explanation

## What this page is about

Explains the Records list in the Workspace, including how records are grouped by Object class, what columns and actions are available, and how list/card views, side panel tabs, and filtering work. It also notes permissions-dependent behavior and record creation limits.

## User intent

* Understand how to access and use the Records list from the Workspace
* See how records are grouped and selected by Object class
* Learn what default columns and actions appear in the Records list
* Switch between list view and card view for records
* Use the side panel tabs to view summary, tasks, activity log, and record access
* Filter records by record properties and class fields
* Configure visible columns using Object class fields
* Know when users can open, edit, delete, or view activity/access details based on permissions
* Understand what happens when creating a new record from the list

## Key terms

* Records list
* Workspace
* Record
* Object class
* ALX ID
* Identifier
* list view
* card view
* side panel
* Summary
* Tasks
* Activity log
* Record access
* Record Owner
* Super Admin
* Object class Owner
* filter
* column configuration
* * Create record
* view record permission
* External account type

## Terminology links

* [Records list](/knowledgebase/terminology/#records-list)
* [Workspace](/knowledgebase/terminology/#workspace)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `Record`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [ALX ID](/knowledgebase/terminology/#alx-id)
* [Identifier](/knowledgebase/terminology/#identifier)
* [list view](/knowledgebase/terminology/#list-view)
* [Card view](/knowledgebase/terminology/#card-view)

## Related topics

* List pages
* editing object class configuration displays
* Editing Object records
* list page filter editor

## Prerequisites

* Basic familiarity with the Workspace
* Understanding that access to records and actions depends on user permissions
* Basic awareness of Object classes and their fields

## Not covered

* Detailed instructions for List pages in general
* Detailed steps for editing object class configuration displays
* Detailed guidance for the list page filter editor
* Detailed procedures for editing Object records
* How permissions are configured
* How tasks or task templates are configured

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.6/redirect-url-on-standalone-forms/index.agent.md
---
# Agent guide: Redirect URL on Standalone forms

* **Page path:** `release-notes/release-notes-1.6/redirect-url-on-standalone-forms/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces a Redirect URL feature for standalone forms. It explains that admins can enable a redirect in standalone form settings so users are sent to a specified website or another standalone form after submission.

## User intent

* Understand what the Redirect URL feature on standalone forms does
* Learn how to configure post-submission redirection for a standalone form
* Find out whether users can be redirected to websites or other standalone forms
* Replace a generic thank-you page with a personalized destination after form submission

## Key terms

* Redirect URL
* Standalone forms
* Form settings
* Destination URL
* Post-submission redirection
* Thank you pages

## Terminology links

* [Redirect URL](/knowledgebase/terminology/#redirect-url)
* [standalone forms](/knowledgebase/terminology/#standalone-forms)
* [destination URL](/knowledgebase/terminology/#destination-url)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with standalone forms
* Access to standalone form settings
* A target destination URL to redirect users to

## Not covered

* Detailed step-by-step configuration instructions
* Validation rules or limitations for destination URLs
* Conditional or dynamic redirect logic
* Behavior on redirect failure
* Permissions, security, or access control considerations
* Any broader form design or submission handling features beyond redirection

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.2/relation-lookup/index.agent.md
---
# Agent guide: Relation Lookup

* **Page path:** `release-notes/release-notes-1.2/relation-lookup/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces the Relation Lookup actor in the Sequence designer. It explains that, when used with the Sequence Runner, it can find parent or child records of an object class that match configured conditions and run sequences for those matched related records.

## User intent

* Understand what the Relation Lookup actor does
* Learn how Relation Lookup works with Sequence Runner
* Find parent or child records related to an object class
* Run a sequence for matched related records based on conditions
* Know what is required before using Relation Lookup
* Assess the workflow benefits of using Relation Lookup in sequence design

## Key terms

* Relation Lookup actor
* Sequence designer
* Sequence Runner
* parent records
* child records
* object class
* conditions
* relational model
* sequence
* workflow automation

## Terminology links

* [Relation Lookup](/knowledgebase/terminology/#relation-lookup) (matched from `Relation Lookup actor`)
* [Sequence designers](/knowledgebase/terminology/#sequence-designers) (matched from `Sequence designer`)
* [Sequence Runner](/knowledgebase/terminology/#sequence-runner)
* [parent records](/knowledgebase/terminology/#parent-records)
* [Present child records](/knowledgebase/terminology/#present-child-records) (matched from `child records`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [Filter conditions](/knowledgebase/terminology/#filter-conditions) (matched from `conditions`)
* [relational model](/knowledgebase/terminology/#relational-model)

## Related topics

* Not provided.

## Prerequisites

* A defined relational model
* Basic familiarity with the Sequence designer
* Basic understanding of Sequence Runner
* Understanding of parent-child record relationships and object classes

## Not covered

* Step-by-step configuration instructions
* Detailed examples of condition setup
* Technical implementation details
* UI walkthroughs or screenshots
* Limitations, edge cases, or troubleshooting guidance
* Broader documentation for Sequence Runner or relational modeling

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequence-actors/relation-lookup-actor/index.agent.md
---
# Agent guide: Relation Lookup Actor

* **Page path:** `system-configuration/sequence-actors/relation-lookup-actor/index.md`
* **Page type:** explanation

## What this page is about

Explains how the Relation Lookup actor finds related parent or child records that meet configured conditions, stores the matched records for later use, and how to configure it in a sequence. It also highlights trigger setup, especially using Matched Records conditions to control downstream processing safely.

## User intent

* Understand what the Relation Lookup actor does
* Configure a Relation Lookup actor in a sequence
* Set up parent vs child lookups correctly based on the sequence object class
* Add record and field-data conditions to the lookup
* Use Relation Lookup results with downstream actors such as Sequence Runner
* Configure triggers so downstream workflow only runs when the expected number of related records is matched
* Apply naming best practices for the actor
* Understand limits of Relation Lookup conditions and actor usage

## Key terms

* Relation Lookup actor
* sequencer
* parent records
* child records
* relational model
* sequence object class
* lookup options
* Children
* Parents
* conditions
* matched records
* trigger condition
* When Actor Completed
* Sequence Runner actor
* record conditions
* field data conditions
* backend

## Terminology links

* [Relation Lookup](/knowledgebase/terminology/#relation-lookup) (matched from `Relation Lookup actor`)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [parent records](/knowledgebase/terminology/#parent-records)
* [Present child records](/knowledgebase/terminology/#present-child-records) (matched from `child records`)
* [relational model](/knowledgebase/terminology/#relational-model)
* [sequence object class](/knowledgebase/terminology/#sequence-object-class)
* [children records](/knowledgebase/terminology/#children-records) (matched from `Children`)
* [parent object class](/knowledgebase/terminology/#parent-object-class) (matched from `Parents`)

## Related topics

* Not provided.

## Prerequisites

* A Catalyst system with a relational model defined
* Basic familiarity with sequence workspace and sequence actors
* Understanding of parent/child object classes in the relational model

## Not covered

* Detailed instructions for creating the relational model
* General documentation for the Sequence Runner actor beyond its mention here
* Advanced nested condition logic, which Relation Lookup does not support
* Broader sequence design outside the actor’s configuration and trigger behavior

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.2/relational-modeller/index.agent.md
---
# Agent guide: Relational modeller

* **Page path:** `release-notes/release-notes-1.2/relational-modeller/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces the Relational modeller feature in Autologyx. It explains that it is a drag-and-drop tool for defining parent-child relationships between object classes, visualizing those relationships, and exposing child object classes within the parent’s create/edit view.

## User intent

* Understand what Relational modeller does
* Learn how parent and child object class relationships are configured
* See how related child data becomes available from a parent object class
* Check supported relationship patterns such as one-to-one and one-to-many
* Find the feature limits for roots, children, and hierarchy depth

## Key terms

* Relational modeller
* object classes
* parent class
* child object classes
* drag and drop
* one to one relationship
* one to many relationship
* Create and edit view
* root parent object classes
* parent/child levels

## Terminology links

* [Relational modeller](/knowledgebase/terminology/#relational-modeller)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [parent object class](/knowledgebase/terminology/#parent-object-class) (matched from `parent class`)
* [Child Object Classes](/knowledgebase/terminology/#child-object-classes)
* [drag and drop tool](/knowledgebase/terminology/#drag-and-drop-tool) (matched from `drag and drop`)
* [one to one relationship](/knowledgebase/terminology/#one-to-one-relationship)
* [one to many relationship](/knowledgebase/terminology/#one-to-many-relationship)
* [Create and edit view](/knowledgebase/terminology/#create-and-edit-view)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx object classes
* Understanding of parent-child data relationships

## Not covered

* Step-by-step setup instructions
* Detailed UI walkthroughs or screenshots
* Behavior beyond the stated relationship limits
* Advanced modeling patterns outside one-to-one and one-to-many
* Any topics outside this release-note overview

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/relational-modeller/index.agent.md
---
# Agent guide: Relational Modeller

* **Page path:** `system-configuration/relational-modeller/index.md`
* **Page type:** explanation

## What this page is about

This page is a brief index for the Relational Modeller section. It points readers to subtopics on creating and editing a relational model, what the relational modeller is, and who can create a relational model.

## User intent

* Find where to learn how to create a relational model
* Find where to learn how to edit a relational model
* Understand what the relational modeller is
* Check who is allowed to create a relational model

## Key terms

* Relational Modeller
* Relational Model
* Creating The Relational Model
* Editing The Relational Model
* What Is The Relational Modeller
* Who Can Create A Relational Model

## Terminology links

* [Relational modeller](/knowledgebase/terminology/#relational-modeller)
* [relational model](/knowledgebase/terminology/#relational-model)

## Related topics

* Not provided.

## Prerequisites

* General familiarity with the idea of a relational model may be helpful

## Not covered

* Detailed steps for creating a relational model
* Detailed steps for editing a relational model
* A definition or explanation of the relational modeller itself
* Specific permissions or roles for who can create a relational model

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.5/relational-support-in-word-add-in/index.agent.md
---
# Agent guide: Relational support in Word Add-in

* **Page path:** `release-notes/release-notes-1.5/relational-support-in-word-add-in/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces relational support in the Catalyst Word Add-in. It explains that document templates can now use data from related object classes instead of being limited to a single object class.

## User intent

* Understand what relational support in the Word Add-in does
* Learn how document templates can include data from related object classes
* See the benefits of using a relational tree for document generation
* Determine whether this feature helps reduce manual merging across templates or data sources
* Assess how the feature improves document accuracy and consistency

## Key terms

* Relational support
* Catalyst Word Add-in
* document templates
* object class
* related object classes
* relational tree
* document generation
* related data

## Terminology links

* [relational support](/knowledgebase/terminology/#relational-support)
* [Catalyst Word Add in](/knowledgebase/terminology/#catalyst-word-add-in) (matched from `Catalyst Word Add-in`)
* [Document Templates](/knowledgebase/terminology/#document-templates)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [related object classes](/knowledgebase/terminology/#related-object-classes)
* [relational tree](/knowledgebase/terminology/#relational-tree)
* [Document Automation](/knowledgebase/terminology/#document-automation) (matched from `document generation`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the Catalyst Word Add-in
* Understanding of document templates
* Basic concept of object classes and related data

## Not covered

* Step-by-step setup or configuration instructions
* Technical details of how relational support is implemented
* Specific examples of supported relationships or data models
* Limitations, constraints, or compatibility details
* Troubleshooting guidance

---

---
url: /knowledgebase-agent-guides/release-notes/release-notes-1.10/index.agent.md
---
# Agent guide: Release Notes 1.10

* **Page path:** `release-notes/release-notes-1.10/index.md`
* **Page type:** release-notes

## What this page is about

This page is an index for Autologyx Catalyst 1.10 release notes. It lists the feature areas, integrations, permissions updates, and fixes included in version 1.10.

## User intent

* See what changed in Autologyx Catalyst 1.10
* Find release note sections for specific 1.10 features or fixes
* Locate updates related to groups, permissions, record access, and visibility control
* Identify new integrations such as OpenAI Embeddings and OpenAI GPT

## Key terms

* Autologyx Catalyst 1.10
* release notes
* Analytics Database API
* groups
* record permission sets
* groups as task assignees
* groups in class permission sets
* groups in user type class fields
* groups in user type fields
* OpenAI Embeddings Integration
* OpenAI GPT Integration
* record access
* actor users and groups visibility control
* bug fixes and improvements

## Terminology links

* [Release Notes](/knowledgebase/terminology/#release-notes)
* [Analytics Database API](/knowledgebase/terminology/#analytics-database-api)
* [User Groups](/knowledgebase/terminology/#user-groups) (matched from `groups`)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `record permission sets`)
* [Groups as Task Assignees](/knowledgebase/terminology/#groups-as-task-assignees)
* [Groups in Class Permission Sets](/knowledgebase/terminology/#groups-in-class-permission-sets)
* [Groups in User Type Class Fields](/knowledgebase/terminology/#groups-in-user-type-class-fields)
* [Groups in User Type Fields](/knowledgebase/terminology/#groups-in-user-type-fields)

## Related topics

* Not provided.

## Prerequisites

* Familiarity with Autologyx Catalyst
* Basic understanding of product release notes and platform feature areas such as permissions, groups, and integrations

## Not covered

* Detailed explanations of each listed feature or fix
* Step-by-step setup or configuration instructions
* Upgrade procedures or migration guidance
* Technical implementation details beyond the section titles

---

---
url: /knowledgebase-agent-guides/release-notes/release-notes-1.11/index.agent.md
---
# Agent guide: Release Notes 1.11

* **Page path:** `release-notes/release-notes-1.11/index.md`
* **Page type:** release-notes

## What this page is about

This page is an index for Autologyx Catalyst 1.11 release notes. It lists the feature, integration, authentication, API, and bug-fix sections available for version 1.11.

## User intent

* Find what changed in Autologyx Catalyst 1.11
* Navigate to specific 1.11 release note sections such as integrations, API support, authentication, or bug fixes
* Check whether version 1.11 includes updates for AWS Bedrock, Azure OpenAI, OAuth, ROPC, websockets, or record creation endpoints

## Key terms

* Autologyx Catalyst 1.11
* release notes
* AWS Bedrock integration
* Azure OpenAI integration
* bug fixes and improvements
* delayed account activation
* hierarchical records creation endpoints
* Microsoft OAuth in outbound mail setup
* multipart data support in API call
* actor
* ROPC flow authentication objects
* websockets

## Terminology links

* [Autologyx Catalyst 1.11](/knowledgebase/terminology/#autologyx-catalyst-111)
* [Release Notes](/knowledgebase/terminology/#release-notes)
* [AWS Bedrock integration](/knowledgebase/terminology/#aws-bedrock-integration)
* [Azure OpenAI actor](/knowledgebase/terminology/#azure-openai-actor) (matched from `Azure OpenAI integration`)
* [delayed account activation](/knowledgebase/terminology/#delayed-account-activation)
* [hierarchical records creation endpoints](/knowledgebase/terminology/#hierarchical-records-creation-endpoints)
* [Microsoft OAuth in Outbound Mail Setup](/knowledgebase/terminology/#microsoft-oauth-in-outbound-mail-setup)
* [Multipart Data Support in API Call](/knowledgebase/terminology/#multipart-data-support-in-api-call)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst
* Understanding of product release notes structure
* Optional familiarity with APIs, authentication flows, and third-party integrations mentioned in the section titles

## Not covered

* Detailed explanations of each listed feature or fix
* Configuration steps or implementation guidance
* Version comparisons beyond identifying 1.11 topics
* Troubleshooting or technical deep dives for the listed sections

---

---
url: /knowledgebase-agent-guides/release-notes/release-notes-1.12/index.agent.md
---
# Agent guide: Release Notes 1.12

* **Page path:** `release-notes/release-notes-1.12/index.md`
* **Page type:** release-notes

## What this page is about

This page is a minimal landing page for Release Notes 1.12. It directs readers to browse the sections for the new Autologyx Catalyst 1.12 release notes and indicates the classification as unrestricted/public.

## User intent

* Find the release notes for Autologyx Catalyst version 1.12
* Confirm that version 1.12 has a dedicated release notes section
* Check the document classification/public availability

## Key terms

* Release Notes 1.12
* Autologyx Catalyst 1.12
* New release notes
* Classification: Unrestricted, Public

## Terminology links

* [Release notes 1.12](/knowledgebase/terminology/#release-notes-112)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst versioning and release notes structure

## Not covered

* Specific features, fixes, or changes in version 1.12
* Upgrade instructions or migration guidance
* Known issues, limitations, or compatibility details
* Links or summaries of the individual release note sections

---

---
url: /knowledgebase-agent-guides/release-notes/release-notes-1.13/index.agent.md
---
# Agent guide: Release Notes 1.13

* **Page path:** `release-notes/release-notes-1.13/index.md`
* **Page type:** release-notes

## What this page is about

This page is an index-style release notes page for version 1.13. It lists the sections and feature/update topics included in the 1.13 release notes.

## User intent

* See what changed in version 1.13
* Find specific 1.13 release note topics such as authentication changes, integrations, AI models, or bug fixes
* Navigate to detailed sections for features and improvements introduced in 1.13

## Key terms

* Release Notes 1.13
* Authentication Object Changes
* Bug Fixes And Improvements
* Delete Option In Set Task Actor
* Dynamic Document Assembly With .Docx Merge Fields
* File Upload Component
* How Do I Create A Test User Account
* Imanage Integration
* Integrations
* New Ai Models In Sequencer
* New Autologyx Catalyst 1.13 Release Notes
* The Loop Actor

## Terminology links

* [Release notes 1.13](/knowledgebase/terminology/#release-notes-113)
* [File upload component](/knowledgebase/terminology/#file-upload-component)
* [iManage integration](/knowledgebase/terminology/#imanage-integration)
* [Integrations](/knowledgebase/terminology/#integrations)
* [AI models in Sequencer](/knowledgebase/terminology/#ai-models-in-sequencer) (matched from `New Ai Models In Sequencer`)
* [Loop actors](/knowledgebase/terminology/#loop-actors) (matched from `The Loop Actor`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the product and its components such as actors, integrations, authentication, and document assembly
* Context that this is a versioned release notes page for version 1.13

## Not covered

* Detailed explanations of each listed change or feature
* Step-by-step setup or usage instructions
* Information about releases other than 1.13

---

---
url: /knowledgebase-agent-guides/release-notes/release-notes-1.14/index.agent.md
---
# Agent guide: Release Notes 1.14

* **Page path:** `release-notes/release-notes-1.14/index.md`
* **Page type:** release-notes

## What this page is about

This page is a top-level index for Autologyx Catalyst 1.14 release notes. It lists the main areas of change covered in version 1.14, such as Authentication, Security, Document Records Enhancements, Error Handling Reliability, Real Time Workflow Improvements, and User Experience Interface Improvements.

## User intent

* Find what categories of updates are included in Autologyx Catalyst 1.14
* Navigate to specific release note sections for version 1.14
* Check whether changes in 1.14 relate to authentication, security, workflows, or user interface improvements

## Key terms

* Release Notes 1.14
* Autologyx Catalyst 1.14
* Authentication
* Security
* Document Records Enhancements
* Error Handling Reliability
* Real Time Workflow Improvements
* User Experience Interface Improvements

## Terminology links

* [Release notes 1.14](/knowledgebase/terminology/#release-notes-114)
* [Autologyx Catalyst 1.14](/knowledgebase/terminology/#autologyx-catalyst-114)
* [Authentication](/knowledgebase/terminology/#authentication)
* [Authentication Security](/knowledgebase/terminology/#authentication-security) (matched from `Security`)
* [Document Records Enhancements](/knowledgebase/terminology/#document-records-enhancements)
* [Error Handling Reliability](/knowledgebase/terminology/#error-handling-reliability)
* [Real Time Workflow Improvements](/knowledgebase/terminology/#real-time-workflow-improvements)
* [User Experience Interface Improvements](/knowledgebase/terminology/#user-experience-interface-improvements)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst
* Understanding of release notes as a summary of product changes

## Not covered

* Detailed descriptions of the individual changes in each section
* Step-by-step configuration or upgrade instructions
* Any content outside the listed 1.14 release note categories

---

---
url: /knowledgebase-agent-guides/release-notes/release-notes-1.15/index.agent.md
---
# Agent guide: Release Notes 1.15 \[DRAFT]

* **Page path:** `release-notes/release-notes-1.15/index.md`
* **Page type:** release-notes

## What this page is about

This is a draft placeholder for Release Notes 1.15. It indicates that sections should be browsed below, but no actual release-note content is provided on this page text.

## User intent

* Check whether Release Notes 1.15 are available
* Look for sections describing changes in version 1.15
* Confirm the page classification/status as a public draft

## Key terms

* Release Notes 1.15
* DRAFT
* Autologyx Classification
* Unrestricted
* Public

## Terminology links

* No matched terminology links found.

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with product versioning and release notes

## Not covered

* Any actual features, fixes, improvements, or breaking changes in 1.15
* Upgrade instructions or migration guidance
* Detailed section content, since it is not present in the supplied text

---

---
url: /knowledgebase-agent-guides/release-notes/release-notes-1.2/index.agent.md
---
# Agent guide: Release Notes 1.2

* **Page path:** `release-notes/release-notes-1.2/index.md`
* **Page type:** release-notes

## What this page is about

This page is an index for Autologyx Catalyst 1.2 release notes. It lists the sections covering bug fixes, improvements, and specific 1.2 features.

## User intent

* Find what changed in Autologyx Catalyst 1.2
* Navigate to specific 1.2 release note sections
* Review bug fixes and improvements in version 1.2
* Identify new or updated features such as Click To Call, Json Type Field, Relational Modeller, and Sequence Runner tasks

## Key terms

* Autologyx Catalyst 1.2
* Release Notes 1.2
* Bug Fixes And Improvements
* Click To Call On Autologyx
* Improved Breadcrumbs
* Improved Instructions Editor
* Json Type Field
* Present Child Records Relation Lookup
* Relational Modeller
* Sequence Runner Tasks For One Time Completion Users

## Terminology links

* [Autologyx Catalyst 1.2](/knowledgebase/terminology/#autologyx-catalyst-12)
* [Release notes 1.2](/knowledgebase/terminology/#release-notes-12)
* [Click to Call](/knowledgebase/terminology/#click-to-call) (matched from `Click To Call On Autologyx`)
* [breadcrumbs](/knowledgebase/terminology/#breadcrumbs) (matched from `Improved Breadcrumbs`)
* [instructions editor](/knowledgebase/terminology/#instructions-editor) (matched from `Improved Instructions Editor`)
* [JSON fields](/knowledgebase/terminology/#json-fields) (matched from `Json Type Field`)
* [Relational modeller](/knowledgebase/terminology/#relational-modeller)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst
* Awareness of product features and release note structure

## Not covered

* Detailed explanations of each listed feature or fix
* Step-by-step configuration or usage guidance
* Information about releases other than 1.2

---

---
url: /knowledgebase-agent-guides/release-notes/release-notes-1.3/index.agent.md
---
# Agent guide: Release Notes 1.3

* **Page path:** `release-notes/release-notes-1.3/index.md`
* **Page type:** release-notes

## What this page is about

This page is a top-level index for Autologyx Catalyst 1.3 release notes. It points readers to sections covering bug fixes, improvements, the Catalyst Word Add In, and new features in version 1.3.

## User intent

* Find what changed in Autologyx Catalyst 1.3
* Navigate to release note sections for bug fixes and improvements
* See updates related to the Catalyst Word Add In
* Review new features such as template merge fields, sorting records, and the user type field

## Key terms

* Release Notes 1.3
* Bug Fixes And Improvements
* Catalyst Word Add In
* Autologyx Catalyst 1.3 Release Notes
* New Template Merge Fields
* Sorting Records
* User Type Field
* Autologyx

## Terminology links

* [Release notes 1.3](/knowledgebase/terminology/#release-notes-13)
* [Catalyst Word Add in](/knowledgebase/terminology/#catalyst-word-add-in)
* [Sorting records](/knowledgebase/terminology/#sorting-records)
* [User type fields](/knowledgebase/terminology/#user-type-fields) (matched from `User Type Field`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst and its features

## Not covered

* Detailed descriptions of each fix or feature
* Step-by-step usage instructions
* Upgrade, installation, or migration guidance
* Context beyond Autologyx Catalyst 1.3 release-note navigation

---

---
url: /knowledgebase-agent-guides/release-notes/release-notes-1.5/index.agent.md
---
# Agent guide: Release Notes 1.5

* **Page path:** `release-notes/release-notes-1.5/index.md`
* **Page type:** release-notes

## What this page is about

This page is an index for Autologyx Catalyst 1.5 release notes, listing the sections available for new features and changes in version 1.5. It points readers to topics such as Authentication Objects, API Keys, Task Actor Documents in Sequencer Elements, relational support in the Word Add-in, Task Assignment Actor Templates Panel, and Create Task Actor updates.

## User intent

* Find what changed in Autologyx Catalyst 1.5
* Navigate to specific 1.5 release note sections
* Identify whether 1.5 includes updates for authentication, API keys, sequencer elements, Word Add-in relational support, or task assignment templates

## Key terms

* Autologyx Catalyst 1.5
* Release Notes
* Authentication Objects
* API Keys
* Create Task Actor
* Task Actor Documents
* Sequencer Elements
* Relational Support
* Word Add-in
* Task Assignment Actor Templates Panel

## Terminology links

* [Autologyx Catalyst 1.5](/knowledgebase/terminology/#autologyx-catalyst-15)
* [Release Notes](/knowledgebase/terminology/#release-notes)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects)
* [Authorization Objects API Keys](/knowledgebase/terminology/#authorization-objects-api-keys) (matched from `API Keys`)
* [Create task actor](/knowledgebase/terminology/#create-task-actor)
* [Sequencer Elements](/knowledgebase/terminology/#sequencer-elements)
* [relational support](/knowledgebase/terminology/#relational-support)
* [Catalyst Word Add in](/knowledgebase/terminology/#catalyst-word-add-in) (matched from `Word Add-in`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst
* Understanding of the product areas referenced in the listed release note sections

## Not covered

* Detailed explanations of each listed feature or change
* Step-by-step instructions
* Configuration or usage guidance beyond section navigation
* Release notes for versions other than 1.5

---

---
url: /knowledgebase-agent-guides/release-notes/release-notes-1.6/index.agent.md
---
# Agent guide: Release Notes 1.6

* **Page path:** `release-notes/release-notes-1.6/index.md`
* **Page type:** release-notes

## What this page is about

This page is an index for Autologyx Catalyst 1.6 release notes. It lists the new features and changes included in version 1.6 and links to their individual sections.

## User intent

* See what changed in Autologyx Catalyst 1.6
* Find specific 1.6 features such as iManage Authentication Objects or Json Type variables
* Navigate to detailed release note sections for individual enhancements

## Key terms

* Autologyx Catalyst 1.6
* Release Notes
* iManage Authentication Objects
* Read Only Fields
* Redirect Url On Standalone Forms
* Sequencer File Download
* Json Type variable
* Relationship Created trigger
* Sequencer

## Terminology links

* [Release Notes](/knowledgebase/terminology/#release-notes)
* [iManage Authentication Objects](/knowledgebase/terminology/#imanage-authentication-objects)
* [Read only fields](/knowledgebase/terminology/#read-only-fields)
* [Redirect Url On Standalone Forms](/knowledgebase/terminology/#redirect-url-on-standalone-forms)
* [Sequencer file download](/knowledgebase/terminology/#sequencer-file-download)
* [JSON type variable](/knowledgebase/terminology/#json-type-variable)
* [Relationship Created trigger](/knowledgebase/terminology/#relationship-created-trigger)
* [Sequencer](/knowledgebase/terminology/#sequencer)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst
* Awareness of product features such as forms, variables, and sequencer

## Not covered

* Detailed explanations of each listed feature
* Implementation steps or configuration guidance
* Changes outside version 1.6

---

---
url: /knowledgebase-agent-guides/release-notes/release-notes-1.8/index.agent.md
---
# Agent guide: Release Notes 1.8

* **Page path:** `release-notes/release-notes-1.8/index.md`
* **Page type:** release-notes

## What this page is about

This page is an index for Autologyx Catalyst 1.8 release notes. It lists the main sections covering bug fixes, improvements, and feature-specific updates in version 1.8.

## User intent

* Find what changed in Autologyx Catalyst 1.8
* Navigate to specific 1.8 release note sections
* Check whether updates were made to database views, image merge fields, iManage, Microsoft authentication, API call actor, object new, user account types, or user group permissions
* Review bug fixes and improvements included in release 1.8

## Key terms

* Autologyx Catalyst 1.8
* Release Notes
* Bug Fixes And Improvements
* Database Views
* Image Merge Fields
* Imanage
* Api Call Actor
* Microsoft Authentication
* Object New
* New User Account Types
* User Group Permissions

## Terminology links

* [Release Notes](/knowledgebase/terminology/#release-notes)
* [Database views](/knowledgebase/terminology/#database-views)
* [Image merge fields](/knowledgebase/terminology/#image-merge-fields)
* [iManage template](/knowledgebase/terminology/#imanage-template) (matched from `Imanage`)
* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [User Group Permissions](/knowledgebase/terminology/#user-group-permissions)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst and its features

## Not covered

* Detailed descriptions of each change
* Configuration or usage instructions for the listed features
* Version history beyond release 1.8

---

---
url: /knowledgebase-agent-guides/release-notes/release-notes-1.9/index.agent.md
---
# Agent guide: Release Notes 1.9

* **Page path:** `release-notes/release-notes-1.9/index.md`
* **Page type:** release-notes

## What this page is about

This page is an index for Autologyx Catalyst 1.9 release notes. It points readers to the main sections covering new features, fixes, and improvements introduced in version 1.9.

## User intent

* Find what changed in Autologyx Catalyst 1.9
* Browse new features added in the 1.9 release
* Locate bug fixes and improvements in version 1.9
* See release-note sections such as authentication objects, delayed user account activation, Jinja filters, and viewer panel updates

## Key terms

* Autologyx Catalyst 1.9
* release notes
* API for delaying user account activation
* authentication objects
* bug fixes and improvements
* new Jinja filters
* date and time manipulations
* viewer panel

## Terminology links

* [Autologyx Catalyst 1.9](/knowledgebase/terminology/#autologyx-catalyst-19)
* [Release Notes](/knowledgebase/terminology/#release-notes)
* [API for delaying user account activation](/knowledgebase/terminology/#api-for-delaying-user-account-activation)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects)
* [Jinja filters](/knowledgebase/terminology/#jinja-filters) (matched from `new Jinja filters`)
* [Viewer panel](/knowledgebase/terminology/#viewer-panel)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst
* Understanding of product release notes and versioned changes

## Not covered

* Detailed explanations of each listed feature or fix
* Configuration, usage steps, or examples for the referenced sections
* Information about releases other than version 1.9

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/task-templates/response-configuration---task-type---complete-self-contained-form/index.agent.md
---
# Agent guide: Response Configuration - Task type - Complete self-contained form

* **Page path:** `system-configuration/task-templates/response-configuration---task-type---complete-self-contained-form/index.md`
* **Page type:** explanation

## What this page is about

This page explains how to configure the task type "Complete self contained form" on the Response configuration tab, including building the form, configuring sections and fields, previewing, and saving. It also outlines example uses and where these tasks are available depending on whether task creation is Automatic or Manual.

## User intent

* Understand what the "Complete self contained form" task type is used for
* Create a response form using the Form builder
* Configure form sections, columns, labels, and conditional visibility
* Add and configure components such as Single Select, Date/Time Picker, Textbox, Instruction, and File upload
* Understand how aliases and labels work for fields
* Preview, save, or cancel form creation
* See example use cases such as claim forms, consent declarations, statements, and document upload tasks
* Determine where these task templates appear for Automatic versus Manual task creation

## Key terms

* Response configuration tab
* Task type
* Complete self contained form
* Response Form
* Create response form
* Form builder
* section header
* layout panel
* Label
* Show this section header
* columns
* column ratios
* Conditional Visibility
* Single Select
* radio buttons
* drop down list
* default value
* Date/Time Picker
* future date
* Textbox
* single line input
* multi line input
* alias
* Instruction component
* Preview
* Save
* Cancel
* unsaved changes
* File upload
* Task creation mechanism
* Automatic
* Manual
* Sequence designer
* Task Templates menu
* Workflow
* Object class
* Record
* Tasks tab

## Terminology links

* [Response configuration tab](/knowledgebase/terminology/#response-configuration-tab)
* [Task type](/knowledgebase/terminology/#task-type)
* [Complete self contained form](/knowledgebase/terminology/#complete-self-contained-form)
* [Response form](/knowledgebase/terminology/#response-form)
* [Create response form](/knowledgebase/terminology/#create-response-form)
* [Form builder](/knowledgebase/terminology/#form-builder)
* [sections](/knowledgebase/terminology/#sections) (matched from `section header`)
* [Layout panel](/knowledgebase/terminology/#layout-panel)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with creating or configuring task templates
* Understanding of Records and Object classes
* Awareness of Automatic versus Manual task creation mechanisms

## Not covered

* Details of the other task type
* Detailed instructions for field type configuration beyond the examples given
* The separate documentation linked as "CLICK HERE" for Conditional Visibility
* The separate documentation linked for configuration of field types
* Full task configuration steps outside the Response configuration tab

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/task-templates/response-configuration---task-type---update-object-record/index.agent.md
---
# Agent guide: Response configuration - Task type - Update object record

* **Page path:** `system-configuration/task-templates/response-configuration---task-type---update-object-record/index.md`
* **Page type:** explanation

## What this page is about

Explains how to configure the Response configuration tab for the task type "Update object record", including selecting an Object class and building the response form. It also covers how these task templates are available in Sequence designer or manual task creation, and what happens when the task is completed.

## User intent

* Select the Object class for an Update object record task template
* Create and configure the response form in the Form builder
* Use Object class fields versus generic Fields in the form
* Set section properties such as label, header visibility, columns, ratios, and conditional visibility
* Understand which properties of Object class fields can and cannot be edited
* Add instructional text to the form
* Preview, save, or cancel form changes safely
* Understand when these task templates appear in the Sequence designer or for manual creation
* Know how task completion updates the target record

## Key terms

* Response configuration tab
* Update object record
* Object class
* Form builder
* Fields
* Object Class Fields
* section header
* Conditional Visibility
* Instruction component
* Preview
* Save
* Cancel
* Task creation mechanism
* Automatic
* Manual
* Sequence designer
* Record

## Terminology links

* [Response configuration tab](/knowledgebase/terminology/#response-configuration-tab)
* [Update object records](/knowledgebase/terminology/#update-object-records) (matched from `Update object record`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Form builder](/knowledgebase/terminology/#form-builder)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `Fields`)
* [sections](/knowledgebase/terminology/#sections) (matched from `section header`)
* [Conditional Visibility](/knowledgebase/terminology/#conditional-visibility)
* [Sections and Instructions components](/knowledgebase/terminology/#sections-and-instructions-components) (matched from `Instruction component`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with task templates
* Understanding of Object classes and Records
* Awareness of Task creation mechanism options such as Automatic and Manual

## Not covered

* Detailed instructions for the separate Task creation mechanism configuration
* Further information behind the linked Conditional Visibility help
* General form-building behavior beyond what is described for this task type
* Broader Create task template configuration outside the Response configuration tab

---

---
url: /api-agent-guides/catalyst/resources/roles/index.agent.md
---
# Agent guide: Roles

* **Page path:** `catalyst/resources/roles.md`
* **Page type:** reference

## What this page is about

This page describes the ALX roles system, where roles are sets of permissions assigned to users to control endpoint access. It documents the Roles API for listing, creating, retrieving, updating, and inspecting role endpoints.

## User intent

* Understand how roles and permissions work in ALX
* List existing roles via the API
* Create a new role with a permissions object
* Retrieve details of a specific role
* Update a role's name, description, or permissions
* See supported sorting and filtering for role lists
* Check authentication and permission requirements for role endpoints
* Review possible unauthenticated error responses

## Key terms

* roles
* permissions
* endpoint access
* user assigned to several roles
* meta.permissions
* GET /api/roles/
* POST /api/roles/
* GET /api/roles/{id}/
* PATCH /api/roles/{id}/
* OPTIONS /api/roles/
* sorting
* filtering
* authentication
* available permissions

## Terminology links

* [Roles](/api/terminology/#roles)
* [permissions](/api/terminology/#permissions)
* [ordering](/api/terminology/#ordering) (matched from `sorting`)
* [filtering](/api/terminology/#filtering)

## Related topics

* Security Rules
* Company details

## Prerequisites

* Basic understanding of users, permissions, and API endpoints
* Authentication for accessing protected API routes
* Familiarity with ALX API filtering and sorting conventions

## Not covered

* UI workflows for assigning roles to users
* Detailed semantics of each individual permission bit/value
* Full standard predicate definitions beyond referencing the ALX API standards guide
* Broader security policy design outside the roles endpoints
* Implementation details for related resources beyond the listed available permissions

---

---
url: >-
  /knowledgebase-agent-guides/administration/roles-and-permissions/index.agent.md
---
# Agent guide: Roles And Permissions

* **Page path:** `administration/roles-and-permissions/index.md`
* **Page type:** explanation

## What this page is about

This page is a navigation overview for understanding roles and permissions in Autologyx. It points readers to sections on creating roles, user permissions, editing roles, and why roles are needed.

## User intent

* Find where to create a role
* Understand what user permissions are
* Learn what happens when a role is edited
* Understand why users need roles

## Key terms

* Roles
* Permissions
* User permissions
* Create a role
* Edit a role

## Terminology links

* [Roles](/knowledgebase/terminology/#roles)
* [Class permissions](/knowledgebase/terminology/#class-permissions) (matched from `Permissions`)
* [Permissions](/knowledgebase/terminology/#permissions) (matched from `User permissions`)
* [Create a Role](/knowledgebase/terminology/#create-a-role)
* [Edit a Role](/knowledgebase/terminology/#edit-a-role)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with users and access control concepts in Autologyx

## Not covered

* Step-by-step instructions for creating or editing roles
* Detailed definitions of specific permissions
* Configuration procedures beyond the linked sections
* Any content outside the listed roles and permissions topics

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.11/ropc-flow-authentication-objects/index.agent.md
---
# Agent guide: ROPC flow Authentication Objects

* **Page path:** `release-notes/release-notes-1.11/ropc-flow-authentication-objects/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces a new Generic ROPC (Resource Owner Password Credentials) flow in Authentication Objects and an Expiry Date feature for managing credential lifecycles. It explains the required and optional configuration fields and how expiry tracking and notifications help prevent authentication failures.

## User intent

* Understand what the new Generic ROPC Authentication Object supports
* Learn when ROPC flow is useful, such as system-to-system or backend authentication
* Identify the required parameters to configure ROPC authentication
* See which optional ROPC fields can be provided for additional control
* Understand how the new Expiry Date feature works for Authentication Objects
* Learn how to track expiring credentials and configure reminder notifications

## Key terms

* ROPC
* Resource Owner Password Credentials
* Authentication Objects
* Generic ROPC flow
* Token URL
* Username
* Password
* Refresh Token URL
* Client ID
* Client Secret
* Scope
* Expiry Date
* credential expiration
* Sequencer
* email reminders
* access token

## Terminology links

* [Authentication Objects](/knowledgebase/terminology/#authentication-objects)
* [Generic ROPC Authentication Object](/knowledgebase/terminology/#generic-ropc-authentication-object) (matched from `Generic ROPC flow`)
* [Token URL](/knowledgebase/terminology/#token-url)
* [Username](/knowledgebase/terminology/#username)
* [Client ID](/knowledgebase/terminology/#client-id)
* [Client Secret](/knowledgebase/terminology/#client-secret)
* [Scope](/knowledgebase/terminology/#scope)
* [Expiry Date feature](/knowledgebase/terminology/#expiry-date-feature) (matched from `Expiry Date`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of authentication flows and access tokens
* Familiarity with Authentication Objects
* Awareness of external identity providers and credential-based integrations

## Not covered

* Step-by-step UI instructions for creating the Authentication Object
* Provider-specific ROPC implementation details
* Security tradeoffs or best practices for using ROPC
* Detailed Sequencer configuration steps
* Any authentication flows other than Generic ROPC

---

---
url: /api-agent-guides/catalyst/resources/security-rules/index.agent.md
---
# Agent guide: Security Rules

* **Page path:** `catalyst/resources/security-rules.md`
* **Page type:** reference

## What this page is about

This page documents configurable security rules in Autologyx and the API endpoints used to retrieve and update them. It focuses on password complexity, password reuse prevention, password rotation interval, activation link validity, and authentication method settings, including validations and permission requirements.

## User intent

* Understand which security rules can be configured in the system
* Find the API endpoints for reading and updating security rules
* Learn the request and response schema for /api/security/
* Check validation limits for password complexity and system configuration fields
* Understand how password rules apply across account activation, password reset, and user editing
* Determine which authentication method values are allowed
* See which security settings are publicly readable versus restricted

## Key terms

* Security Rules
* Password Complexity
* Prevent password re use
* Password rotation interval
* Activation link valid period
* authentication method
* systemconf
* max repeating chars
* min letters
* min numbers
* min symbols
* min lower case
* min upper case
* min length
* internal
* external
* service internal
* service external
* full
* super admin
* enum
* GET /api/security/
* PATCH /api/security/
* OPTIONS /api/security/

## Terminology links

* [Security Rules](/api/terminology/#security-rules)
* [Password Complexity](/api/terminology/#password-complexity)
* [Prevent password re use](/api/terminology/#prevent-password-re-use)
* [Password rotation interval](/api/terminology/#password-rotation-interval)
* [Activation link valid period](/api/terminology/#activation-link-valid-period)
* [authentication method](/api/terminology/#authentication-method)
* [systemconf](/api/terminology/#systemconf)
* [max repeating chars](/api/terminology/#max-repeating-chars)

## Related topics

* Roles
* Limits

## Prerequisites

* Basic understanding of REST APIs
* Familiarity with authentication and permissions
* Awareness of account types and authentication methods in the system

## Not covered

* Detailed permission names are not specified
* Standard error definitions are referenced but not described here
* UI implementation details beyond the requirement for frontend/backend consistency are not provided
* No explanation of account type meanings or role behavior beyond field names
* No broader security architecture or policy guidance outside these specific settings

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequence-actors/send-message-actor/index.agent.md
---
# Agent guide: Send Message Actor

* **Page path:** `system-configuration/sequence-actors/send-message-actor/index.md`
* **Page type:** explanation

## What this page is about

This page explains how the Send Message actor is used in a sequence to automatically send configurable emails during a workflow. It covers who can receive messages, how to compose and personalize emails, how to test them, and key conditions that can prevent test delivery.

## User intent

* Understand what the Send Message actor does in a workflow sequence
* Configure the actor to send emails to specific recipients
* Add CC and BCC recipients
* Insert merge fields from record fields, Constants, and Variables into subject or message
* Format the email body with text styling, links, images, and tables
* Attach a document when the actor follows a document picker
* Test the email using a record ID
* Troubleshoot why a test email did not arrive
* Save the actor and sequence configuration correctly

## Key terms

* Send Message actor
* sequence
* workflow
* recipients
* record creator
* record owner
* individual users
* user groups
* specified email addresses
* email addresses stored in record fields
* CC
* BCC
* Subject
* Message
* merge fields
* record fields
* Constants
* Variables
* document picker
* attachment
* record ID
* Test Email
* syntax error
* merge field error
* Outbound mail setup

## Terminology links

* [Send Message Actors](/knowledgebase/terminology/#send-message-actors) (matched from `Send Message actor`)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `sequence`)
* [Workflow area](/knowledgebase/terminology/#workflow-area) (matched from `workflow`)
* [record creator](/knowledgebase/terminology/#record-creator)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `record owner`)
* [User Groups](/knowledgebase/terminology/#user-groups)
* [merge fields](/knowledgebase/terminology/#merge-fields)
* [Record Fields](/knowledgebase/terminology/#record-fields)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with sequences/workflows
* Ability to add and configure an actor in a sequence
* Access to a relevant record ID for testing
* Outbound mail setup configured correctly for test delivery

## Not covered

* Detailed setup of outbound mail
* General sequence design beyond adding and configuring this actor
* How document picker works in detail
* Detailed syntax rules for merge fields beyond example errors like missing curly brackets or endifs
* Advanced email deliverability or mailbox troubleshooting

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequence-actors/index.agent.md
---
# Agent guide: Sequence Actors

* **Page path:** `system-configuration/sequence-actors/index.md`
* **Page type:** explanation

## What this page is about

This page is an index for Sequence Actors documentation. It lists the available actor topics that can be used within sequences.

## User intent

* Find documentation for a specific sequence actor
* Browse the available sequence actor types
* Identify best-practice guidance for invalid actors

## Key terms

* Sequence Actors
* Create Task Actor
* Docauto Actor
* Document Picker Actor
* Invalid Actors And Best Practice
* Record Access Actor
* Relation Lookup Actor
* Send Message Actor
* Sequence Runner Actor
* Set Task Actor
* Task Assignment Actor
* Update Record Actor

## Terminology links

* [Sequence Actors](/knowledgebase/terminology/#sequence-actors)
* [Create task actor](/knowledgebase/terminology/#create-task-actor)
* [DocAuto actor](/knowledgebase/terminology/#docauto-actor)
* [Document Picker actor](/knowledgebase/terminology/#document-picker-actor)
* [Invalid Actors And Best Practice](/knowledgebase/terminology/#invalid-actors-and-best-practice)
* [Record Access actor](/knowledgebase/terminology/#record-access-actor)
* [Relation Lookup](/knowledgebase/terminology/#relation-lookup) (matched from `Relation Lookup Actor`)
* [Send Message Actors](/knowledgebase/terminology/#send-message-actors) (matched from `Send Message Actor`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with sequences and actors in the system

## Not covered

* Detailed behavior or configuration of any individual actor
* Step-by-step setup instructions
* Conceptual overview of sequences beyond the actor list

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.2/sequence-runner/index.agent.md
---
# Agent guide: Sequence Runner

* **Page path:** `release-notes/release-notes-1.2/sequence-runner/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces the Sequence Runner actor in Autologyx 1.2 and summarizes its new configuration and trigger capabilities. It explains that Sequence Runner can run sequences on the current record, related records via Relation Lookup, or the same object class, with customizable trigger conditions.

## User intent

* Understand what the new Sequence Runner actor does
* Learn how Sequence Runner can be configured for current or related records
* See how Sequence Runner works with the Relation Lookup actor
* Find what trigger options and parameters are available
* Determine whether Sequence Runner can run sequences independently on the same object class

## Key terms

* Sequence Runner
* automation workflows
* Flexible configuration
* Relation Lookup
* current record
* parent object class
* child object class
* same object class
* trigger configuration
* custom trigger options
* connected actor completion
* designated milestone
* records
* fields
* tasks
* task groups
* variables

## Terminology links

* [Sequence Runner](/knowledgebase/terminology/#sequence-runner)
* [Relation Lookup](/knowledgebase/terminology/#relation-lookup)
* [current record](/knowledgebase/terminology/#current-record)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `parent object class`)
* [same object class](/knowledgebase/terminology/#same-object-class)
* [trigger configuration](/knowledgebase/terminology/#trigger-configuration)
* [milestone](/knowledgebase/terminology/#milestone) (matched from `designated milestone`)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `records`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx automation concepts and actors
* Understanding of records and object classes
* Awareness of the Relation Lookup actor

## Not covered

* Step-by-step setup or configuration instructions
* Detailed examples or use cases
* UI navigation or screenshots
* Technical limitations, constraints, or error handling
* Any content beyond the release-note summary of capabilities

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequence-actors/sequence-runner-actor/index.agent.md
---
# Agent guide: Sequence Runner Actor

* **Page path:** `system-configuration/sequence-actors/sequence-runner-actor/index.md`
* **Page type:** explanation

## What this page is about

Explains how the Sequence Runner actor starts one sequence from another, either on the same record or on records returned by a Relation Lookup. It covers configuration, usage patterns, naming guidance, and important behavioral limits.

## User intent

* Understand what the Sequence Runner actor does
* Configure a Sequence Runner in a sequence
* Run a sub-process from a main sequence on the same object class
* Use Sequence Runner together with Relation Lookup to run sequences on related records
* Know which sequences are available for selection based on trigger type and record source
* Apply best practices for naming and documenting Sequence Runner actors
* Understand execution constraints such as terminal behavior and trigger limitations
* See example use cases for branching into specialist or escalation processes

## Key terms

* Sequence Runner actor
* Relation Lookup actor
* Self
* From Relation lookup
* When sequence activated
* object class
* sub process
* starting trigger
* trigger conditions
* terminal actor
* sequence workspace
* Properties
* Name
* Description

## Terminology links

* [Sequence Runner](/knowledgebase/terminology/#sequence-runner) (matched from `Sequence Runner actor`)
* [Relation Lookup](/knowledgebase/terminology/#relation-lookup) (matched from `Relation Lookup actor`)
* [Self records](/knowledgebase/terminology/#self-records) (matched from `Self`)
* [From Relation lookup](/knowledgebase/terminology/#from-relation-lookup)
* [Sequence Activated](/knowledgebase/terminology/#sequence-activated) (matched from `When sequence activated`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [sub process](/knowledgebase/terminology/#sub-process)
* [starting trigger](/knowledgebase/terminology/#starting-trigger)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of sequences and sequence actors
* Familiarity with object classes and records
* Awareness of sequence triggers such as "When sequence activated" and "When Record Updated"
* Optional familiarity with the Relation Lookup actor

## Not covered

* Detailed instructions for configuring the Relation Lookup actor
* General sequence design beyond Sequence Runner usage
* Full trigger configuration rules outside the examples shown
* Broader workflow concepts unrelated to starting one sequence from another

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.6/sequencer-file-download/index.agent.md
---
# Agent guide: Sequencer file download

* **Page path:** `release-notes/release-notes-1.6/sequencer-file-download/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces an enhancement to the API Call actor that lets users retrieve files from different sources and store them securely in Sequencer for use in workflows. It also outlines how saved documents can be passed to other actors such as Document Picker, Update Record, Send Message Actors, or another API Call actor.

## User intent

* Understand the new file download capability in the API Call actor
* Learn how to configure the API Call actor to retrieve documents from a chosen source
* See how downloaded documents are stored and reused in Sequencer
* Find ways to pass saved documents to other actors in a workflow
* Identify workflow scenarios supported by document retrieval and sharing

## Key terms

* Sequencer
* API Call actor
* file download
* document source
* authentication method
* securely stored document
* Document Picker actor
* Update Record actor
* Send Message Actors
* workflow automation
* sequences

## Terminology links

* [Sequencer](/knowledgebase/terminology/#sequencer)
* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [File Download](/knowledgebase/terminology/#file-download)
* [source](/knowledgebase/terminology/#source) (matched from `document source`)
* [authentication method management](/knowledgebase/terminology/#authentication-method-management) (matched from `authentication method`)
* [Document Picker actor](/knowledgebase/terminology/#document-picker-actor)
* [Update Record actor](/knowledgebase/terminology/#update-record-actor)
* [Send Message Actors](/knowledgebase/terminology/#send-message-actors)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Sequencer workflows
* Basic understanding of actors such as API Call, Document Picker, Update Record, and Send Message

## Not covered

* Detailed step-by-step configuration instructions
* Specific supported file sources or connectors
* Authentication setup details beyond choosing a method
* Limits, formats, storage behavior, or security implementation details
* Troubleshooting or error handling guidance

---

---
url: /knowledgebase-agent-guides/system-configuration/sequences/index.agent.md
---
# Agent guide: Sequences

* **Page path:** `system-configuration/sequences/index.md`
* **Page type:** explanation

## What this page is about

This page is an index for the Sequences section. It points readers to subpages about creating, editing, navigating, and understanding sequences and the sequencer.

## User intent

* Find where to learn how to create a sequence
* Find instructions for adding conditions for sequence commencement
* Learn how to edit a sequence’s design or properties
* Understand navigation and menus related to sequences
* View information about the sequences list
* Understand what the sequencer is

## Key terms

* Sequences
* Sequence commencement conditions
* Creating a sequence
* Editing a sequence design
* Editing sequence properties
* Navigation and menus
* Sequences list
* Sequencer

## Terminology links

* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequences`)
* [Sequence commencement conditions](/knowledgebase/terminology/#sequence-commencement-conditions)
* [Creating a sequence](/knowledgebase/terminology/#creating-a-sequence)
* [Sequence design](/knowledgebase/terminology/#sequence-design) (matched from `Editing a sequence design`)
* [Navigation and menus](/knowledgebase/terminology/#navigation-and-menus)
* [sequences](/knowledgebase/terminology/#sequences) (matched from `Sequences list`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx terminology and interface

## Not covered

* Detailed procedures for any sequence task
* Conceptual explanation of sequences beyond linking to subpages
* Configuration steps or examples not contained in the listed subsections

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequences-for-relational-records/index.agent.md
---
# Agent guide: Sequences For Relational Records

* **Page path:** `system-configuration/sequences-for-relational-records/index.md`
* **Page type:** explanation

## What this page is about

This page is an overview hub for working with sequences for relational records. It points readers to sections on using Relation Lookup with Sequence Runner, running sequences for a single object class, and what relational records can do in a sequence.

## User intent

* Find guidance on using Relation Lookup and Sequence Runner together
* Learn how to use the Sequence Runner actor for one object class
* Understand what is possible with relational records in a sequence

## Key terms

* relational records
* Relation Lookup
* Sequence Runner
* actor
* object class
* sequence

## Terminology links

* [relational records](/knowledgebase/terminology/#relational-records)
* [Relation Lookup](/knowledgebase/terminology/#relation-lookup)
* [Sequence Runner](/knowledgebase/terminology/#sequence-runner)
* [Sequence Actors](/knowledgebase/terminology/#sequence-actors) (matched from `actor`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `sequence`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with sequences
* Basic understanding of relational records
* Awareness of actors such as Relation Lookup and Sequence Runner
* Understanding of object classes

## Not covered

* Detailed instructions for any of the linked sections
* Configuration steps or examples on this overview page
* Concepts unrelated to relational records in sequences

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequences/sequences-list/index.agent.md
---
# Agent guide: Sequences list

* **Page path:** `system-configuration/sequences/sequences-list/index.md`
* **Page type:** explanation

## What this page is about

This page explains what the Sequences list is, what users can see and do there, and which columns and actions are available. It also describes visibility rules, sequence states, and some useful optional columns.

## User intent

* Understand what can be done from the Sequences list
* Check who can view the Sequences list
* Learn which permissions are needed to edit sequence properties or design
* Understand the meaning of sequence states such as Paused and Running
* See what default columns appear in the list
* Find out what actions are available for super admins, editors, and object class owners
* Identify useful optional columns related to API actors
* Know the maximum number of sequences allowed in the system

## Key terms

* Sequences list
* Sequencer
* Super Admin
* Role permissions
* Sequencer tab permissions
* Object class Owner
* Edit properties
* Edit design
* Resume
* Pause
* State
* Paused
* Running
* Object class
* Task group templates
* Default task assignees
* API actors
* Send messages
* Update record

## Terminology links

* [sequences](/knowledgebase/terminology/#sequences) (matched from `Sequences list`)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super Admin`)
* [Roles and Permissions](/knowledgebase/terminology/#roles-and-permissions) (matched from `Role permissions`)
* [Object class Owners](/knowledgebase/terminology/#object-class-owners) (matched from `Object class Owner`)
* [Edit properties](/knowledgebase/terminology/#edit-properties)
* [Sequence design](/knowledgebase/terminology/#sequence-design) (matched from `Edit design`)
* [Resume](/knowledgebase/terminology/#resume)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of what a Sequence is and what the Sequencer does
* Familiarity with user roles, system permissions, and object classes
* General knowledge of list behavior in the system

## Not covered

* Detailed explanation of what the Sequencer does
* How to use general list features in the system
* Step-by-step instructions for editing sequence properties
* Step-by-step instructions for editing sequence design
* Full configuration details for API actors, task templates, task group templates, or send message actors

---

---
url: >-
  /knowledgebase-agent-guides/administration/all-about-users/service-accounts/index.agent.md
---
# Agent guide: Service Accounts

* **Page path:** `administration/all-about-users/service-accounts/index.md`
* **Page type:** reference

## What this page is about

This page explains the two Service Account types introduced in release 1.13.0: Internal Service and External Service. It covers their purpose, limits, permissions, how to create them via API, how to reset/change passwords, and how to convert an existing service account.

## User intent

* Understand what Internal Service and External Service accounts are
* Learn why service accounts are needed when SSO is enabled and password authentication is disabled for regular users
* Find the limits and permission model for each service account type
* Create a service account using an API call or API client
* Reset or change a service account password via API
* Convert an existing service account to one of the new service account types
* Confirm activation behavior and email behavior for service accounts

## Key terms

* Service Accounts
* Internal Service account
* External Service account
* SSO
* username/password authentication
* Super Admin
* API integrations
* class permissions
* record permissions
* Sequencer
* Post API call
* Patch API call
* password complexity requirements
* active status

## Terminology links

* [Service Accounts](/knowledgebase/terminology/#service-accounts)
* [Internal Service account](/knowledgebase/terminology/#internal-service-account)
* [External Service account](/knowledgebase/terminology/#external-service-account)
* [Single sign on](/knowledgebase/terminology/#single-sign-on) (matched from `SSO`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super Admin`)
* [Class permissions](/knowledgebase/terminology/#class-permissions)
* [Record Permission Sets](/knowledgebase/terminology/#record-permission-sets) (matched from `record permissions`)
* [Sequencer](/knowledgebase/terminology/#sequencer)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Catalyst user accounts and permissions
* Knowledge of API calls such as POST and PATCH
* Access to a Super admin user for password changes
* Familiarity with the Sequencer or an API client such as Postman

## Not covered

* No UI workflow for creating service accounts
* No detailed API request examples beyond mentioning JSON bodies and endpoint pattern
* No broader explanation of SSO setup or configuration
* No general user management guidance outside service-account-specific behavior
* No explanation of class or record permissions beyond stating they are required for External Service accounts

---

---
url: >-
  /knowledgebase-agent-guides/using-help-and-support/we're-here-to-help/service-levels-and-escalation/index.agent.md
---
# Agent guide: Service levels and escalation

* **Page path:** `using-help-and-support/we're-here-to-help/service-levels-and-escalation/index.md`
* **Page type:** explanation

## What this page is about

This page appears to be a placeholder titled "Service levels and escalation" and only includes the classification note "Autologyx Classification: Unrestricted, Public." No substantive guidance is provided in the supplied text.

## User intent

* Find information about service levels
* Find information about escalation processes
* Confirm the page's classification or visibility

## Key terms

* Service levels
* Escalation
* Autologyx Classification
* Unrestricted
* Public

## Terminology links

* [Service Levels And Escalation](/knowledgebase/terminology/#service-levels-and-escalation) (matched from `Service levels`)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Definitions of service levels
* Escalation criteria or process
* Support response times or SLAs
* Roles and responsibilities
* How to contact support

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequence-actors/set-task-actor/index.agent.md
---
# Agent guide: Set Task Actor

* **Page path:** `system-configuration/sequence-actors/set-task-actor/index.md`
* **Page type:** explanation

## What this page is about

This page explains the Set Task actor in sequences and how it works with task templates created by the Automatic task creation mechanism. It covers configuring the actor to either re-create a completed task or delete tasks for the triggering record.

## User intent

* Understand what the Set Task actor does
* Learn when to use Set Task with automatically created task templates
* Configure a Set Task actor in a sequence
* Select a task template for the actor
* Choose between re-creating or deleting tasks
* Understand the delete scope options for tasks
* Rename the actor for clarity in the sequence workspace
* Understand what happens after the actor completes

## Key terms

* Set Task actor
* sequence workspace
* Configure
* task template
* Automatic task creation mechanism
* Update object record type
* Complete self contained form
* Re-create
* Delete
* All tasks
* All outstanding tasks
* All completed tasks
* Most recent task
* Most recent outstanding task
* Most recent completed task
* Task Assignment actor
* Create Task outgoing trigger
* When Task Created

## Terminology links

* [Set Task actor](/knowledgebase/terminology/#set-task-actor)
* [sequence workspace](/knowledgebase/terminology/#sequence-workspace)
* [Configure](/knowledgebase/terminology/#configure)
* [Task templates](/knowledgebase/terminology/#task-templates) (matched from `task template`)
* [Automatic Task creation mechanism](/knowledgebase/terminology/#automatic-task-creation-mechanism)
* [Update object record type](/knowledgebase/terminology/#update-object-record-type)
* [Complete self contained form](/knowledgebase/terminology/#complete-self-contained-form)
* [Re create](/knowledgebase/terminology/#re-create) (matched from `Re-create`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of sequences and sequence actors
* Familiarity with task templates
* Awareness of the Automatic task creation mechanism
* Understanding of the sequence object class and triggering record

## Not covered

* How to create task templates
* How the Automatic task creation mechanism is set up in general
* Detailed behavior of Task Assignment actor configuration
* Broader sequence design beyond this actor
* Any actor types other than brief mention of Task Assignment and other sequence actors

---

---
url: /api-agent-guides/catalyst/resources/authentication/sso-config/index.agent.md
---
# Agent guide: Single Sign On Configuration

* **Page path:** `catalyst/resources/authentication/sso-config.md`
* **Page type:** reference

## What this page is about

Reference for managing Single Sign On (SSO) configurations and SSO login/callback API endpoints. It documents permissions, CRUD operations, request/response fields, validation rules, filtering/sorting, and common errors.

## User intent

* List available SSO configurations
* View details of a specific SSO configuration
* Create a new SSO configuration
* Update or delete an existing SSO configuration
* Check which permissions are required for SSO config actions
* Understand validation constraints for SSO config fields
* Get an authorization redirect URL for SSO login
* Exchange an SSO authorization code for access and refresh tokens

## Key terms

* SSO configuration
* permissions
* list/view/create/edit/delete
* provider
* Azure
* Okta
* client id
* tenant id
* is enabled
* auto create user
* roles
* is word addin enabled
* redirect uri
* logout url
* meta.permissions
* meta.labels
* ordering
* filtering
* login endpoint
* callback endpoint
* state
* session state

## Terminology links

* [single sign on configurations](/api/terminology/#single-sign-on-configurations) (matched from `SSO configuration`)
* [permissions](/api/terminology/#permissions)
* [provider](/api/terminology/#provider)
* [client id](/api/terminology/#client-id)
* [auto create user](/api/terminology/#auto-create-user)
* [Roles](/api/terminology/#roles)
* [is word addin enabled](/api/terminology/#is-word-addin-enabled)
* [redirect uri](/api/terminology/#redirect-uri)

## Related topics

* Authentication Objects

## Prerequisites

* Basic understanding of REST APIs
* Familiarity with SSO/OAuth-style authorization code flow
* Knowledge of Azure or Okta tenant/application identifiers
* Awareness of role-based permissions

## Not covered

* Detailed SSO technical design beyond the reference mention
* How Authentication Objects are structured
* Frontend/UI setup flows
* Provider-specific setup steps outside listed field notes
* Token semantics beyond returning access and refresh tokens

---

---
url: >-
  /knowledgebase-agent-guides/finding-your-way-around/some-things-you-might-find-useful/index.agent.md
---
# Agent guide: Some Things You Might Find Useful

* **Page path:** `finding-your-way-around/some-things-you-might-find-useful/index.md`
* **Page type:** explanation

## What this page is about

This page is a simple navigation aid that points users to two topics: Autologyx Terminology and Autologyx Classification: Unrestricted, Public. It does not explain those topics itself.

## User intent

* Find links to glossary or terminology information
* Locate information about Autologyx classification levels such as Unrestricted and Public
* Browse useful reference sections

## Key terms

* Autologyx Terminology
* Autologyx Classification
* Unrestricted
* Public

## Terminology links

* No matched terminology links found.

## Related topics

* Not provided.

## Prerequisites

* No specific prior knowledge is stated

## Not covered

* Definitions of Autologyx terms
* Details of classification categories beyond listing Unrestricted and Public
* Procedures, workflows, or instructions

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.3/sorting-records/index.agent.md
---
# Agent guide: Sorting records

* **Page path:** `release-notes/release-notes-1.3/sorting-records/index.md`
* **Page type:** release-notes

## What this page is about

A release note announcing the new sorting feature for records. It explains that users can organize data in ascending or descending order across supported field types to improve clarity and efficiency.

## User intent

* Understand what the new sorting feature does
* Learn which field types can be sorted
* See whether sorting supports ascending and descending order
* Assess how sorting can help organize records and find information faster

## Key terms

* sorting
* records
* ascending order
* descending order
* field types
* integer
* date
* text
* single select
* phone
* e mail

## Terminology links

* [sorting](/knowledgebase/terminology/#sorting)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `records`)
* [ascending or descending order](/knowledgebase/terminology/#ascending-or-descending-order) (matched from `ascending order`)
* [field types](/knowledgebase/terminology/#field-types)
* [Integer](/knowledgebase/terminology/#integer)
* [Text](/knowledgebase/terminology/#text)
* [Single Select field type](/knowledgebase/terminology/#single-select-field-type) (matched from `single select`)
* [phone and e mail](/knowledgebase/terminology/#phone-and-e-mail) (matched from `phone`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with records and data fields

## Not covered

* How to use sorting step by step
* Where sorting is configured in the interface
* Any limitations, exceptions, or advanced sorting behavior
* Examples of sorting in specific workflows

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/merge-fields/syntax-for-merge-fields/index.agent.md
---
# Agent guide: Syntax for merge fields

* **Page path:** `system-configuration/merge-fields/syntax-for-merge-fields/index.md`
* **Page type:** explanation

## What this page is about

Explains how to manually write merge field syntax for document templates and related uses when pulling data from an object class and its related object classes. It shows how relationship paths, object class IDs, indexes, and guard clauses work in Jinja2-based merge expressions.

## User intent

* Understand the syntax for merge fields without using the Word Add in
* Merge fields from the current object class into a document template
* Merge fields from parent, child, grandchild, or indirectly related object classes
* Interpret relational merge syntax, including object class IDs and index values like \[0]
* Use IF/guard clauses to prevent template generation failures when related records may be missing
* Know relationship limits relevant to merge field design

## Key terms

* merge fields
* Document Templates
* Send Message Actors
* Local Variables
* API calls
* Object class
* related Object classes
* relational model
* object class ID
* index \[0]
* guard clause
* IF Statement
* Jinja2
* Word Add in
* parent object class
* child object class
* grandchild object class

## Terminology links

* [merge fields](/knowledgebase/terminology/#merge-fields)
* [Document Templates](/knowledgebase/terminology/#document-templates)
* [Send Message Actors](/knowledgebase/terminology/#send-message-actors)
* [local variables](/knowledgebase/terminology/#local-variables)
* [API calls](/knowledgebase/terminology/#api-calls)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [related object classes](/knowledgebase/terminology/#related-object-classes)
* [relational model](/knowledgebase/terminology/#relational-model)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of object classes and their relationships
* Awareness of the document template's base object class
* Some familiarity with Jinja2/templating syntax is helpful
* Knowing the relevant object class IDs and relationship structure

## Not covered

* The page does not fully spell out each example merge field string in readable form
* It does not explain how to create object relationships themselves
* It does not provide full Jinja2 syntax training beyond brief notes
* It does not cover Word Add in usage in detail
* It does not cover broader template design beyond merge-field syntax and guard-clause guidance

---

---
url: >-
  /knowledgebase-agent-guides/finding-your-way-around/some-things-you-might-find-useful/system-areas/index.agent.md
---
# Agent guide: System Areas

* **Page path:** `finding-your-way-around/some-things-you-might-find-useful/system-areas/index.md`
* **Page type:** explanation

## What this page is about

This page only identifies the topic "System areas" and includes the classification note "Autologyx Classification: Unrestricted, Public." It does not provide explanatory content about system areas.

## User intent

* Confirm the page exists and its title
* Check the document classification/public access level

## Key terms

* System areas
* Autologyx Classification
* Unrestricted
* Public

## Terminology links

* [system areas](/knowledgebase/terminology/#system-areas)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Any definition or explanation of system areas
* Navigation, usage, or configuration details
* Examples, procedures, or screenshots
* Links to related system components or pages

---

---
url: /knowledgebase-agent-guides/system-configuration/index.agent.md
---
# Agent guide: System Configuration

* **Page path:** `system-configuration/index.md`
* **Page type:** explanation

## What this page is about

This page explains what System Configuration is in Autologyx: the area used to build and maintain solutions that solve business problems. It outlines the main configuration areas, who it is relevant for, and a suggested order for building a new solution.

## User intent

* Understand what System Configuration is used for in Autologyx
* Determine whether a task belongs in System Configuration versus Workspace or Administration
* Find the main areas involved in building a solution
* Identify where to configure data models, workflows, tasks, documents, integrations, and user experience
* Follow a recommended sequence for creating a new solution
* Know where to start if new to building in Autologyx

## Key terms

* System Configuration
* Workspace
* Administration
* data model
* Object Classes
* Object class relationships
* Relational Modeller
* Sequences
* Sequence Actors
* Sequences for relational records
* Task Templates
* Task Group Templates
* Task Management
* Document Templates
* Document Automation
* Merge Fields
* APIs and Variables
* DocuSign with Catalyst
* Landing page
* Theme
* AppliedAI

## Terminology links

* [System configuration](/knowledgebase/terminology/#system-configuration)
* [Workspace](/knowledgebase/terminology/#workspace)
* [Administration Sections](/knowledgebase/terminology/#administration-sections) (matched from `Administration`)
* [Catalyst data model](/knowledgebase/terminology/#catalyst-data-model) (matched from `data model`)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [Object Class Relationships](/knowledgebase/terminology/#object-class-relationships)
* [Relational modeller](/knowledgebase/terminology/#relational-modeller)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequences`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of the Autologyx platform
* Awareness of the difference between building a solution, operational work in Workspace, and global settings in Administration
* Relevant mainly for Config Admins, analysts, solution designers, and other builders

## Not covered

* Detailed instructions for each linked configuration area
* Operational day-to-day work in the Workspace
* System-wide administration settings such as users, groups, roles, authentication, and security
* Step-by-step procedures beyond a high-level suggested build path

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.5/task-assignment-actor/index.agent.md
---
# Agent guide: Task assignment actor

* **Page path:** `release-notes/release-notes-1.5/task-assignment-actor/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces the Task assignment actor in Autologyx Catalyst 1.5 for the Sequencer. It explains how it helps configure task assignees and task owners, validates configuration errors, and connects with the Create task actor.

## User intent

* Understand what the Task assignment actor does in Catalyst 1.5
* Learn how to configure task assignees by overriding or appending default assignees
* See how assignees and task owners can be selected from users or user type fields
* Understand what validation and error handling the actor provides
* Learn how to use the actor with the Create task actor via outgoing triggers

## Key terms

* Task assignment actor
* Autologyx Catalyst 1.5
* Sequencer
* task assignees
* default task assignees
* override
* append
* users
* user type field
* task owner
* error handling
* validation
* outgoing triggers
* Create task actor

## Terminology links

* [Task Assignment actor](/knowledgebase/terminology/#task-assignment-actor)
* [Autologyx Catalyst 1.5](/knowledgebase/terminology/#autologyx-catalyst-15)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [task assignees](/knowledgebase/terminology/#task-assignees)
* [Default task assignees](/knowledgebase/terminology/#default-task-assignees)
* [override option](/knowledgebase/terminology/#override-option) (matched from `override`)
* [append option](/knowledgebase/terminology/#append-option) (matched from `append`)
* [Users list](/knowledgebase/terminology/#users-list) (matched from `users`)

## Related topics

* Create task actor
* Connecting actors

## Prerequisites

* Basic familiarity with Autologyx Catalyst Sequencer
* Understanding of tasks, assignees, and task owners in workflow design
* Awareness of users and user type fields

## Not covered

* Step-by-step setup instructions or UI walkthroughs
* Detailed examples of workflow configurations
* Advanced trigger logic or broader actor orchestration beyond Create task actor integration
* General documentation for Sequencer or Create task actor outside this release note

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequence-actors/task-assignment-actor/index.agent.md
---
# Agent guide: Task Assignment Actor

* **Page path:** `system-configuration/sequence-actors/task-assignment-actor/index.md`
* **Page type:** explanation

## What this page is about

This page explains the purpose and configuration of the Task Assignment actor in a sequence. It covers how to assign task assignees and a task owner before a Create Task or Set Task actor, including override/append behavior and selection by users or by field.

## User intent

* Understand when to use the Task Assignment actor in a sequence
* Configure task assignees before creating or setting a task
* Choose whether to override or append default assignees from sequence properties
* Assign users directly or from a user-type field on the record
* Set a single task owner and understand how ownership relates to assignee status
* Know placement rules for the actor within a sequence
* Apply naming best practice for the actor

## Key terms

* Task Assignment actor
* Create Task actor
* Set Task actor
* Task Owner
* Task Assignees
* Sequence Properties
* Override task assignees
* Append task assignees
* By users
* By field
* Record owner
* user type fields
* sequence workspace
* Configure
* Properties
* Sequence Runner

## Terminology links

* [Task Assignment actor](/knowledgebase/terminology/#task-assignment-actor)
* [Create task actor](/knowledgebase/terminology/#create-task-actor)
* [Set Task actor](/knowledgebase/terminology/#set-task-actor)
* [Owners](/knowledgebase/terminology/#owners) (matched from `Task Owner`)
* [task assignees](/knowledgebase/terminology/#task-assignees)
* [Sequence properties](/knowledgebase/terminology/#sequence-properties)
* [Override task assignees](/knowledgebase/terminology/#override-task-assignees)
* [Append task assignees](/knowledgebase/terminology/#append-task-assignees)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with sequences and sequence actors
* Understanding of task concepts such as owner and assignees
* Awareness of sequence properties and record/object class fields
* Knowledge of user and permission setup may be helpful

## Not covered

* Detailed setup of Create Task or Set Task actors
* How sequence properties default assignees/owners are configured
* Permission model details beyond noting tasks can be restricted to owners/assignees
* Configuration of User Groups as assignees, which currently requires an API call after task creation
* General sequence design beyond the Task Assignment actor

---

---
url: /api-agent-guides/websockets/resources/tasks/index.agent.md
---
# Agent guide: Task Events

* **Page path:** `websockets/resources/tasks.md`
* **Page type:** reference

## What this page is about

This page documents the Catalyst WebSocket endpoint for receiving real-time Task change events. It explains the task events stream, event payload fields, delivery behavior, and error conditions for implementations that need live updates without polling.

## User intent

* Find the WebSocket endpoint for subscribing to Task change events
* Understand what Task-related changes are broadcast in real time
* See the structure of each Task event payload
* Learn event ordering and chunked delivery behavior
* Check authentication and permission requirements for the WebSocket connection
* Review possible WebSocket errors and handshake/close conditions

## Key terms

* WebSocket endpoint
* GET /ws/events/tasks/
* Task change events
* real-time updates
* event-driven integrations
* task id
* object class id
* event
* timestamp
* creation order
* ascending event timestamp
* query string authentication
* rate limit exceeded
* RFC 6455

## Terminology links

* [GET /ws/events/tasks/](/api/terminology/#get-wseventstasks)
* [real time update mechanism](/api/terminology/#real-time-update-mechanism) (matched from `real-time updates`)
* [task id](/api/terminology/#task-id)
* [object classes](/api/terminology/#object-classes) (matched from `object class id`)
* [History Events](/api/terminology/#history-events) (matched from `event`)
* [event timestamp](/api/terminology/#event-timestamp) (matched from `timestamp`)

## Related topics

* File Upload Events
* Object Record Events

## Prerequisites

* Basic understanding of WebSockets
* Familiarity with Catalyst Tasks
* Ability to authenticate a WebSocket connection via query string parameter
* Awareness of permissions in Catalyst

## Not covered

* End-user usage guidance; this is implementation reference only
* Detailed permission name/value, which is omitted in the page
* Specific supported event value names, which are referenced but not listed in the excerpt
* Full request upgrade example, success example payload, and detailed error codes/status values, which are not provided in the excerpt
* Sending messages from the client, which is explicitly unsupported

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/formbuilder-components/task-form-fields-and-how-to-configure-them/index.agent.md
---
# Agent guide: Task Form fields and how to configure them

* **Page path:** `record-and-task-forms/formbuilder-components/task-form-fields-and-how-to-configure-them/index.md`
* **Page type:** explanation

## What this page is about

Explains the standalone field types available in Task Templates and how to configure their common properties and validations. It also clarifies how these fields behave in Task forms, including limits and special rules.

## User intent

* Understand which field types are available in Task Templates
* Choose the right standalone field type for a Task form
* Configure common field properties such as label, alias, required, read only, and description
* Set validation rules for text, numeric, date/time, select, email, phone, file upload, URL, and JSON fields
* Understand alias uniqueness and how aliases are used in task responses and conditional visibility
* Know form and template limits such as maximum fields, options, uploads, and file size

## Key terms

* Task Templates
* Standalone fields
* Object class fields
* Update object record type
* Label
* Alias
* Required
* Read only
* Description
* Conditional Visibility
* Textbox
* Numeric
* Date / Time picker
* Checkbox
* Single select
* Multi select
* Email
* Country selector
* Phone number
* File upload
* URL
* JSON
* Validation
* Default value
* Precision

## Terminology links

* [Task templates](/knowledgebase/terminology/#task-templates)
* [Standalone fields](/knowledgebase/terminology/#standalone-fields)
* [Object class fields](/knowledgebase/terminology/#object-class-fields)
* [Update object record type](/knowledgebase/terminology/#update-object-record-type)
* [Label](/knowledgebase/terminology/#label)
* [Alias](/knowledgebase/terminology/#alias)
* [Required option](/knowledgebase/terminology/#required-option) (matched from `Required`)
* [Read only option](/knowledgebase/terminology/#read-only-option) (matched from `Read only`)

## Related topics

* Object class fields

## Prerequisites

* Basic familiarity with creating or editing Task templates
* Awareness that Update object record type templates can mix standalone and object class fields

## Not covered

* Detailed guidance on object class fields beyond noting they exist and can be mixed in Update object record type templates
* Broader form design practices outside field choice and configuration
* Workflow or reporting setup beyond brief notes on how some fields are or are not useful for management information reports

---

---
url: /api-agent-guides/catalyst/resources/tasks/task-group-templates/index.agent.md
---
# Agent guide: Task Group Templates

* **Page path:** `catalyst/resources/tasks/task-group-templates.md`
* **Page type:** reference

## What this page is about

Reference for the Task Group Templates API endpoints. It documents create, update, delete, list, retrieve, autocomplete, usage, and OPTIONS behavior, including request fields, validations, permissions, sorting/filtering, and error responses.

## User intent

* Create a task group template via API
* Update an existing task group template
* Delete a task group template and understand when deletion is blocked
* List task group templates with pagination, sorting, and filtering
* Retrieve one task group template by ID
* Populate autocomplete widgets with task group templates
* Check where a task group template is used
* Understand required fields, validation rules, and common API errors
* Determine required permissions for task group template operations

## Key terms

* Task Group Template
* object classes
* task templates
* manual type Task Templates
* permissions
* validations
* unique (case insensitive)
* autocomplete
* usage
* Sequences
* pagination
* sorting
* filtering
* meta.permission
* labels.object classes
* labels.task templates

## Terminology links

* [task group templates](/api/terminology/#task-group-templates) (matched from `Task Group Template`)
* [object classes](/api/terminology/#object-classes)
* [task templates](/api/terminology/#task-templates)
* [manual type Task Templates](/api/terminology/#manual-type-task-templates)
* [permissions](/api/terminology/#permissions)
* [autocomplete relative url](/api/terminology/#autocomplete-relative-url) (matched from `autocomplete`)
* [Document Template usage](/api/terminology/#document-template-usage) (matched from `usage`)
* [Sequences](/api/terminology/#sequences)

## Related topics

* Task Templates
* Tasks

## Prerequisites

* Basic familiarity with REST API requests and responses
* Understanding of Object Classes IDs and Task Template IDs
* Awareness of permissions/authentication in the API
* For list filtering, familiarity with standard predicates from the ALX API standards Developers guide

## Not covered

* Conceptual explanation of what task group templates are beyond API behavior
* Detailed permission names/roles; the page only states that permission is required
* Full definition of standard filtering predicates; it references another guide
* Business workflows for creating or using task group templates outside these endpoints
* Detailed schemas for related resources such as Task Templates, Tasks, Object Classes, or Sequences

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/task-group-templates/index.agent.md
---
# Agent guide: Task Group Templates

* **Page path:** `system-configuration/task-group-templates/index.md`
* **Page type:** explanation

## What this page is about

This page is a navigation/index page for Task Group Templates. It points readers to sections about what task group templates are, how to create one, and how to edit one.

## User intent

* Understand what task group templates are
* Learn how to create a task group template
* Find instructions for editing a task group template
* Navigate to the relevant task group template documentation section

## Key terms

* Task Group Templates
* Create
* Edit

## Terminology links

* [Task Group Templates](/knowledgebase/terminology/#task-group-templates)
* [Create permission](/knowledgebase/terminology/#create-permission) (matched from `Create`)
* [Edit permission](/knowledgebase/terminology/#edit-permission) (matched from `Edit`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with task groups in Autologyx

## Not covered

* Detailed explanation of task group templates
* Step-by-step creation instructions
* Step-by-step editing instructions
* Any configuration details beyond linking to those sections

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/task-management/index.agent.md
---
# Agent guide: Task Management

* **Page path:** `system-configuration/task-management/index.md`
* **Page type:** explanation

## What this page is about

This page is a placeholder for Task Management documentation and is currently empty or under construction. It does not yet provide explanatory content.

## User intent

* Check whether documentation for Task Management exists
* Determine if this section contains guidance or configuration details
* Confirm the current status of the Task Management documentation

## Key terms

* Task Management
* under construction
* placeholder
* Autologyx Classification
* Unrestricted
* Public

## Terminology links

* [Task Management](/knowledgebase/terminology/#task-management)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Task Management concepts or definitions
* Configuration steps
* Usage instructions
* Administration guidance
* Examples or workflows
* Troubleshooting information

---

---
url: /api-agent-guides/catalyst/resources/tasks/task-templates/index.agent.md
---
# Agent guide: Task Templates

* **Page path:** `catalyst/resources/tasks/task-templates.md`
* **Page type:** reference

## What this page is about

Reference documentation for the Task Templates API, including permissions, CRUD-style endpoints, autocomplete, usage lookup, request/response fields, and noted validation/error behaviors. It defines how to create, update, list, retrieve, delete, and inspect usage of task templates.

## User intent

* Create a task template via the API
* Update an existing task template
* List task templates and inspect pagination fields
* Fetch a single task template by id
* Delete a task template and understand deletion constraints
* Check what permissions are required for task template actions
* Discover valid field validators via OPTIONS /api/task templates/
* Use the autocomplete endpoint for task template pickers
* Find where a task template is used via the usage endpoint
* Understand request and response schemas for reminders, renewals, and task configuration

## Key terms

* Task Templates
* permissions
* POST /api/task templates/
* PATCH /api/task templates/'id'
* OPTIONS /api/task templates/
* GET /api/task templates/
* GET /task templates//
* DELETE /api/task templates//
* GET /api/task templates/autocomplete/
* GET /api/task templates//usage/
* plugin config
* complete by
* task creation
* reminders
* renewals
* approval conditions
* meta.permissions
* usage
* autocomplete

## Terminology links

* [task templates](/api/terminology/#task-templates)
* [permissions](/api/terminology/#permissions)
* [plugin config](/api/terminology/#plugin-config)
* [complete by](/api/terminology/#complete-by)
* [task creation](/api/terminology/#task-creation)
* [reminders](/api/terminology/#reminders)
* [renewals](/api/terminology/#renewals)
* [approval conditions](/api/terminology/#approval-conditions)

## Related topics

* Task Group Templates
* Tasks

## Prerequisites

* Authenticated API access
* Understanding of API request/response structures
* Familiarity with task template concepts such as task type, plugin config, reminders, renewals, and completion/expiry settings
* Awareness that field-level validators are exposed through the OPTIONS endpoint

## Not covered

* Business-level explanation of when to use task templates versus task group templates or tasks
* Detailed meanings of enum values for fields like complete by, expiry, task type, and task creation
* Completed documentation for sorting, filtering, and general errors on the main list endpoint
* Detailed schema semantics for plugin config, configuration JSON, approval conditions, reminders, and renewals beyond listed fields
* Non-API UI workflows

---

---
url: /knowledgebase-agent-guides/system-configuration/task-templates/index.agent.md
---
# Agent guide: Task Templates

* **Page path:** `system-configuration/task-templates/index.md`
* **Page type:** explanation

## What this page is about

This page is a navigation overview for Task Templates. It points readers to subtopics covering what task templates are, how to create and edit them, and response configuration task types.

## User intent

* Understand what task templates are
* Find instructions for creating a task template
* Find instructions for editing a task template
* Learn about response configuration task types
* Learn about the Complete Self Contained Form response configuration task type
* Learn about the Update Object Record response configuration task type

## Key terms

* Task Templates
* Editing A Task Template
* How Do I Create A Task Template
* Response Configuration Task Type
* Complete Self Contained Form
* Update Object Record

## Terminology links

* [Task templates](/knowledgebase/terminology/#task-templates)
* [Editing A Task Template](/knowledgebase/terminology/#editing-a-task-template)
* [Complete self contained form](/knowledgebase/terminology/#complete-self-contained-form)
* [Update object records](/knowledgebase/terminology/#update-object-records) (matched from `Update Object Record`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with task templates in the system context

## Not covered

* Detailed procedures for creating or editing task templates
* Definitions or explanations of task templates beyond linking to a dedicated section
* Step-by-step configuration details for response configuration task types
* Examples, constraints, or best practices for task templates

---

---
url: /api-agent-guides/catalyst/resources/tasks/tasks/index.agent.md
---
# Agent guide: Tasks

* **Page path:** `catalyst/resources/tasks/tasks.md`
* **Page type:** reference

## What this page is about

Reference documentation for the Tasks resource and Tasks API, describing the newer task architecture and the available endpoints, permissions, request/response fields, sorting, filtering, and error cases. It also notes architectural changes such as creating tasks directly from Task Templates, multiple tasks per template/object record, assignees, owners, locking, and expanded statuses/response states.

## User intent

* Understand what changed in the new Tasks architecture
* Create a task via POST /api/tasks/
* List tasks with GET /api/tasks/
* Retrieve a specific task and related task data
* Understand task permissions and visibility rules
* Interpret task response payloads, statuses, stages, next actions, and metadata
* Use sorting and filtering on the tasks list endpoint
* Use complex filtering for tasks
* Understand validation and API error responses for task endpoints
* See examples for saving, completing, uploading files, and related task operations

## Key terms

* Tasks
* Task Templates
* Task Group Templates
* Object Classes
* Object Records
* assignees
* owners
* locking tasks
* task statuses
* response states
* POST /api/tasks/
* GET /api/tasks/
* permissions
* configuration
* response
* stages
* next actions
* meta.labels
* current owner
* current assignees
* sorting
* filtering
* complex filtering

## Terminology links

* [tasks resource](/api/terminology/#tasks-resource) (matched from `Tasks`)
* [task templates](/api/terminology/#task-templates)
* [task group templates](/api/terminology/#task-group-templates)
* [object classes](/api/terminology/#object-classes)
* [Object Records](/api/terminology/#object-records)
* [Object Class Assignees](/api/terminology/#object-class-assignees) (matched from `assignees`)
* [owners type](/api/terminology/#owners-type) (matched from `owners`)
* [Task locking](/api/terminology/#task-locking) (matched from `locking tasks`)

## Related topics

* Task Templates
* Task Group Templates

## Prerequisites

* Basic understanding of Object Classes and Object Records
* Familiarity with Task Templates
* Knowledge of API authentication and permissions
* Awareness of ALX API standard predicates for filtering

## Not covered

* Detailed definitions of Task Templates or Task Group Templates beyond their relationship to Tasks
* Full explanation of Object Classes and Object Records
* General ALX API standards beyond brief references
* Conceptual workflow guidance beyond endpoint behavior and examples
* Implementation details of locking, statuses, and response states beyond the fields and examples shown

---

---
url: /knowledgebase-agent-guides/workspace/tasks/index.agent.md
---
# Agent guide: Tasks

* **Page path:** `workspace/tasks/index.md`
* **Page type:** explanation

## What this page is about

This is a minimal landing page for the Tasks section. It directs readers to browse the available subsections, specifically the Tasks List.

## User intent

* Find where to browse task-related documentation
* Locate the Tasks List section
* Understand that this page is an index rather than detailed task documentation

## Key terms

* Tasks
* Tasks List
* section index

## Terminology links

* [Tasks](/knowledgebase/terminology/#tasks)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Definitions or details of individual tasks
* How to create, manage, or complete tasks
* Task workflows, configuration, or permissions
* Any detailed procedures beyond linking to the Tasks List

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.2/tasks-for-one---time-completion-users/index.agent.md
---
# Agent guide: Tasks for one - time completion users

* **Page path:** `release-notes/release-notes-1.2/tasks-for-one---time-completion-users/index.md`
* **Page type:** release-notes

## What this page is about

This release note announces that one-time completion users can now complete assigned tasks in Autologyx. It explains the email-token access flow, what users see on the form, and why the feature is useful for external task completion.

## User intent

* Understand how one-time completion users access and complete tasks
* Learn whether these users need an account or login
* See what information appears on the task form
* Find out if one-time completion users can save progress and return later
* Understand the business value of assigning tasks to non-team users

## Key terms

* one time completion users
* tasks
* unique token
* email link
* task form
* Standalone form
* Update record
* due date
* instructions
* selected fields
* Save progress
* complete button

## Terminology links

* [one time completion users](/knowledgebase/terminology/#one-time-completion-users)
* [Tasks](/knowledgebase/terminology/#tasks)
* [unique token](/knowledgebase/terminology/#unique-token)
* [task forms](/knowledgebase/terminology/#task-forms) (matched from `task form`)
* [standalone forms](/knowledgebase/terminology/#standalone-forms) (matched from `Standalone form`)
* [Update Record actor](/knowledgebase/terminology/#update-record-actor) (matched from `Update record`)
* [Due Date](/knowledgebase/terminology/#due-date)
* [Instructions component](/knowledgebase/terminology/#instructions-component) (matched from `instructions`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx tasks and forms
* Understanding of assigned tasks and email-based access

## Not covered

* Configuration or setup steps for enabling this feature
* Administrative permissions or assignment workflow details
* Security details of the unique token mechanism
* Limitations, edge cases, or supported task types beyond Standalone form or Update record
* Troubleshooting or error handling

---

---
url: /knowledgebase-agent-guides/workspace/tasks/tasks-list/index.agent.md
---
# Agent guide: Tasks list

* **Page path:** `workspace/tasks/tasks-list/index.md`
* **Page type:** explanation

## What this page is about

This page explains the Workspace Tasks list: who can see tasks, why the list may be empty, the default and notable columns, and when the View and Complete actions are available. It also notes that the Tasks list behaves like other standard list pages in the system.

## User intent

* Understand who can access and see items in the Tasks list
* Work out why the Tasks list is empty
* Identify the default column headers shown in the Tasks list
* Learn what task statuses mean in the list
* Understand when the View action is available
* Understand when the Complete action is available
* Interpret additional task columns such as Completed, Template, Record, Due Date, and Expiry Date

## Key terms

* Tasks list
* Workspace
* permissions
* Super admin
* Object class owner
* Object class Permission set
* Tasks View all
* Record Owner
* Task Assignee
* Tasks View any tasks
* Tasks Complete any tasks
* ID
* Name
* Status
* Outstanding
* Overdue
* Completed
* View
* Complete
* Completed by
* Template
* Record
* Due Date
* Expiry Date
* Lifecycle tab
* Expiry rules
* List Pages

## Terminology links

* [Tasks](/knowledgebase/terminology/#tasks) (matched from `Tasks list`)
* [Workspace](/knowledgebase/terminology/#workspace)
* [Class permissions](/knowledgebase/terminology/#class-permissions) (matched from `permissions`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Object class Owners](/knowledgebase/terminology/#object-class-owners) (matched from `Object class owner`)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `Object class Permission set`)
* [Tasks View all](/knowledgebase/terminology/#tasks-view-all)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Record Owner`)

## Related topics

* List Pages

## Prerequisites

* Basic familiarity with the Workspace left hand menu
* Understanding of user permissions and roles
* Awareness of tasks, task templates, records, and assignees

## Not covered

* How to create tasks or task templates
* How to configure permissions, object class ownership, or permission sets
* How to set due dates or expiry rules in the Lifecycle tab
* Detailed behavior of filters beyond noting they can produce zero results
* General list functionality details beyond referring to List Pages

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.5/templates-panel/index.agent.md
---
# Agent guide: Templates panel

* **Page path:** `release-notes/release-notes-1.5/templates-panel/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces the Templates panel feature in Autologyx. It explains that users can generate customized documents from predefined templates for selected records and have those documents automatically saved to the appropriate record field.

## User intent

* Understand what the Templates panel feature does
* Learn how document generation is made faster with predefined templates
* See how generated documents are stored and managed within records
* Decide whether the Templates panel can replace manual document creation for record-based work

## Key terms

* Templates panel
* document generation
* predefined templates
* selected records
* customized documents
* document management
* record field
* automatically saved documents

## Terminology links

* [Templates panel](/knowledgebase/terminology/#templates-panel)
* [Document Automation](/knowledgebase/terminology/#document-automation) (matched from `document generation`)
* [selected records](/knowledgebase/terminology/#selected-records)
* [Record Fields](/knowledgebase/terminology/#record-fields) (matched from `record field`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with records in Autologyx
* Basic understanding of creating and managing documents manually

## Not covered

* Step-by-step setup or configuration instructions for the Templates panel
* How to create or edit templates
* Technical requirements, permissions, or limitations
* Detailed workflow examples or troubleshooting

---

---
url: /api-agent-guides/event-history/resources/tenants/index.agent.md
---
# Agent guide: Tenants

* **Page path:** `event-history/resources/tenants.md`
* **Page type:** reference

## What this page is about

This page documents internal tenant management endpoints for the Event History API microservice. It explains how tenant records map a client instance to its corresponding ClickHouse history database and covers tenant initialization and deletion operations.

## User intent

* Understand what tenant records are used for in the Event History service
* Initialize a tenant connection and create a tenant entry
* Delete a tenant connection and its related database
* Check required permissions, headers, validation limits, and possible errors for tenant endpoints
* Confirm whether these APIs are internal-only or part of the external integration surface

## Key terms

* Tenants
* Event History API microservice
* tenant record
* client instance
* history database
* ClickHouse database
* default ClickHouse database
* POST /api/initialize tenant
* DELETE /api/delete tenant
* client id
* client secret
* database name
* authorization header
* API key
* UUID v4

## Terminology links

* [Tenants](/api/terminology/#tenants)
* [tenant table](/api/terminology/#tenant-table) (matched from `tenant record`)
* [client instance](/api/terminology/#client-instance)
* [client history database](/api/terminology/#client-history-database) (matched from `history database`)
* [ClickHouse database](/api/terminology/#clickhouse-database)
* [POST /api/initialize tenant](/api/terminology/#post-apiinitialize-tenant)
* [DELETE /api/delete tenant](/api/terminology/#delete-apidelete-tenant)
* [client id](/api/terminology/#client-id)

## Related topics

* Events
* Files

## Prerequisites

* Basic understanding of the Event History service architecture
* Familiarity with client creation in the main Autologyx system
* Knowledge of API authentication headers and permissions
* Awareness that this is an internal platform/engineering API, not a general external integration API

## Not covered

* General-purpose external Catalyst integration usage
* Detailed support guidance beyond contacting Customer Success
* Full request header definitions and exact permission names
* Detailed response codes/messages for several listed errors where values are omitted
* Broader documentation for Events or Files endpoints

---

---
url: >-
  /knowledgebase-agent-guides/finding-your-way-around/some-things-you-might-find-useful/the-new-product-name-ui/index.agent.md
---
# Agent guide: The "new product name" UI

* **Page path:** `finding-your-way-around/some-things-you-might-find-useful/the-new-product-name-ui/index.md`
* **Page type:** explanation

## What this page is about

This page appears to be a placeholder for the "new product name" UI and contains no explanatory content beyond the title and classification notice.

## User intent

* Identify whether documentation exists for the "new product name" UI
* Confirm the page title and publication classification

## Key terms

* new product name UI
* Autologyx
* Classification: Unrestricted, Public

## Terminology links

* No matched terminology links found.

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Any description of the UI
* How to use the UI
* Features, navigation, or workflows
* Configuration, permissions, or troubleshooting

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/the-form-builder/index.agent.md
---
# Agent guide: The Form Builder

* **Page path:** `record-and-task-forms/the-form-builder/index.md`
* **Page type:** explanation

## What this page is about

This page introduces the Form Builder section and explains that it focuses on designing and configuring practical, structured forms in Autologyx for Object Records and Tasks. It emphasizes form design in the context of workflow, user experience, and clear information capture rather than detailed component settings.

## User intent

* Understand how to design forms in Autologyx
* Learn how forms should capture and arrange information for users
* Design intake or record creation forms effectively
* Consider how a form supports the wider workflow and user experience
* Understand practical form construction for creating, updating, or completing information

## Key terms

* Form Builder
* Autologyx
* forms
* Object Records
* Tasks
* intake form
* record creation form
* workflow
* user experience
* form design

## Terminology links

* [Form builder](/knowledgebase/terminology/#form-builder)
* [Forms tab](/knowledgebase/terminology/#forms-tab) (matched from `forms`)
* [Object records](/knowledgebase/terminology/#object-records)
* [Tasks](/knowledgebase/terminology/#tasks)
* [Intake form](/knowledgebase/terminology/#intake-form)
* [record creation form](/knowledgebase/terminology/#record-creation-form)
* [Workflow area](/knowledgebase/terminology/#workflow-area) (matched from `workflow`)
* [User Experience Interface Improvements](/knowledgebase/terminology/#user-experience-interface-improvements) (matched from `user experience`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx
* Awareness of Object Records and Tasks
* General understanding of forms used to create or update information

## Not covered

* Detailed individual component settings inside the form builder
* Low-level configuration of specific form elements
* Topics outside practical form design guidance

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.13/the-loop-actor/index.agent.md
---
# Agent guide: The Loop actor

* **Page path:** `release-notes/release-notes-1.13/the-loop-actor/index.md`
* **Page type:** release-notes

## What this page is about

This release-notes page explains the Loop actor, which processes list-based inputs one item at a time in a controlled, auditable workflow. It covers supported sources, array selection, filtering, trigger behavior, execution rules, and use of the {{loop item}} merge field.

## User intent

* Understand what the Loop actor does
* Learn which sources a Loop actor can iterate over
* Set up looping from Document Picker, tested API Call arrays, or Local Variables
* Use the JSON Explorer to select an array path safely
* Filter looped records before processing
* Choose between per-item and post-loop trigger behaviors
* Understand sequential iteration, parallel branches, and failure handling
* Use {{loop item}} and nested properties in downstream actors
* Know how document-based loop items differ from JSON/object-based loop items

## Key terms

* Loop actor
* Document Picker
* API Call
* JSON array output
* Local Variable
* JSON Explorer
* JSON Path
* filters
* all following rules
* any following rules
* When Loop Item Processed
* When Actor Completed
* sequential iteration
* parallel branches per item
* loop item
* merge field
* document object
* document metadata
* tested API Call

## Terminology links

* [Loop actors](/knowledgebase/terminology/#loop-actors) (matched from `Loop actor`)
* [Document Picker actor](/knowledgebase/terminology/#document-picker-actor) (matched from `Document Picker`)
* [API Call actor](/knowledgebase/terminology/#api-call-actor) (matched from `API Call`)
* [Local Variable Actor](/knowledgebase/terminology/#local-variable-actor) (matched from `Local Variable`)
* [JSON Explorer](/knowledgebase/terminology/#json-explorer)
* [JSON Path field](/knowledgebase/terminology/#json-path-field) (matched from `JSON Path`)
* [filters](/knowledgebase/terminology/#filters)
* [all following rules](/knowledgebase/terminology/#all-following-rules)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Catalyst workflow actors and branching
* Familiarity with arrays/JSON objects and property paths
* Knowledge of merge fields
* For API/local-variable sources, the API Call or Local Variable must already exist and be tested/saved

## Not covered

* General platform setup outside Loop actor configuration
* Detailed configuration of downstream actors like DocuSign, Doc Auto, Send Message, or AI classifiers
* Advanced JSON path syntax beyond the visual selection workflow
* Retry policies or deeper error-recovery strategies beyond skipping failed items
* Performance tuning or concurrency customization beyond the stated sequential item processing and parallel per-item branches

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.6/the-new-type-of-variable-–-json-type/index.agent.md
---
# Agent guide: The new type of variable – JSON type

* **Page path:** `release-notes/release-notes-1.6/the-new-type-of-variable-–-json-type/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces a new JSON variable type for managing complex data structures in automation. It highlights that a single JSON variable can store up to 250,000 characters and can be used to integrate data across actors and sequences.

## User intent

* Understand what the new JSON variable type is
* Learn how much data a JSON variable can store
* See how JSON variables help with complex or detailed datasets
* Understand how JSON variables can be passed or used across actors and sequences
* Assess whether JSON variables improve data handling in automation processes

## Key terms

* JSON type variable
* complex data structures
* 250,000 characters
* data management
* data driven world
* actors
* sequences
* automation capabilities
* data integration

## Terminology links

* [JSON type variable](/knowledgebase/terminology/#json-type-variable)
* [Sequence Actors](/knowledgebase/terminology/#sequence-actors) (matched from `actors`)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `sequences`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of variables
* Familiarity with JSON as a data format
* Basic knowledge of actors and sequences in the platform
* General understanding of automation workflows

## Not covered

* How to create or configure a JSON variable
* Syntax or validation rules for JSON variables
* Examples of JSON variable usage
* Limits other than the 250,000-character capacity
* Error handling or troubleshooting
* Detailed integration steps with specific actors

---

---
url: /knowledgebase-agent-guides/workspace/the-task-panel/index.agent.md
---
# Agent guide: The Task Panel

* **Page path:** `workspace/the-task-panel/index.md`
* **Page type:** explanation

## What this page is about

This page is a brief navigation point for the Task Panel. It directs readers to sections on re-assigning tasks, viewing and completing tasks, and understanding what is in a task card.

## User intent

* Find where to learn how to re-assign tasks
* Find where to learn how to view and complete tasks
* Find where to learn what information appears in a task card
* Understand the scope of Task Panel help content

## Key terms

* Task Panel
* Re Assigning Tasks
* View And Complete Tasks
* What'S In A Task Card

## Terminology links

* [Task Panel](/knowledgebase/terminology/#task-panel)
* [Re Assigning Tasks](/knowledgebase/terminology/#re-assigning-tasks)
* [View And Complete Tasks](/knowledgebase/terminology/#view-and-complete-tasks)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with tasks in the workspace

## Not covered

* Detailed instructions for re-assigning tasks
* Step-by-step guidance for viewing and completing tasks
* Detailed explanation of task card contents
* Any broader workspace concepts beyond the listed Task Panel sections

---

---
url: /knowledgebase-agent-guides/system-configuration/theme/index.agent.md
---
# Agent guide: Theme

* **Page path:** `system-configuration/theme/index.md`
* **Page type:** explanation

## What this page is about

This page is a brief index for the Theme documentation, pointing readers to sections about understanding and creating a theme. It does not itself explain the theme in detail.

## User intent

* Find where to read about the Theme
* Navigate to information about creating a theme
* Locate introductory material in the About The Theme section

## Key terms

* Theme
* About The Theme
* Creating The Theme
* Autologyx Classification
* Unrestricted, Public

## Terminology links

* [Theme](/knowledgebase/terminology/#theme)
* [About The Theme](/knowledgebase/terminology/#about-the-theme)
* [Creating The Theme](/knowledgebase/terminology/#creating-the-theme)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with navigating documentation

## Not covered

* Detailed explanation of what a theme is
* Step-by-step instructions for creating a theme
* Configuration specifics or implementation details

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/the-form-builder/things-to-remember-when-designing-an-intake-or-other-record-creation-form/index.agent.md
---
# Agent guide: Things to remember when designing an intake or other record creation form

* **Page path:** `record-and-task-forms/the-form-builder/things-to-remember-when-designing-an-intake-or-other-record-creation-form/index.md`
* **Page type:** explanation

## What this page is about

This page explains how to design effective intake or other record creation forms in Autologyx Catalyst. It covers the two form types, core usability and workflow-design principles, field-type choices, and testing recommendations.

## User intent

* Understand the difference between Create and edit view forms and standalone forms
* Design a record creation form that captures all information needed to start a process
* Use conditional logic to show only relevant questions
* Choose suitable field types for validation, automation, reporting, API use, and document/email merging
* Make workflow-driving questions mandatory
* Reduce user frustration through clear wording, logical ordering, and concise instructions
* Prevent duplicate records by marking a field as unique
* Test a form effectively before and after launch

## Key terms

* record creation form
* Create and edit view
* standalone form
* object class
* Display tab
* Forms tab
* Catalyst form builder
* sections
* columns
* conditional logic
* field types
* Instruction widget
* mandatory fields
* sequences
* Text field
* Single line
* Multi line
* Single select
* drop down list
* radio buttons
* multi select
* tick boxes
* checkboxes
* placeholder text
* unique field
* internal testing
* external testing

## Terminology links

* [record creation form](/knowledgebase/terminology/#record-creation-form)
* [Create and edit view](/knowledgebase/terminology/#create-and-edit-view)
* [standalone forms](/knowledgebase/terminology/#standalone-forms) (matched from `standalone form`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [Display tab](/knowledgebase/terminology/#display-tab)
* [Forms tab](/knowledgebase/terminology/#forms-tab)
* [Catalyst form builder](/knowledgebase/terminology/#catalyst-form-builder)
* [Workspace Sections](/knowledgebase/terminology/#workspace-sections) (matched from `sections`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst
* Understanding of object classes and their Display and Forms tabs
* Awareness of automated workflows and sequences

## Not covered

* Step-by-step instructions for configuring forms in Catalyst
* Detailed documentation of all available field types
* Broader workflow or sequence design beyond form-related considerations
* Permissions setup details beyond noting access differences between the two form types

---

---
url: >-
  /knowledgebase-agent-guides/finding-your-way-around/ui-and-navigation/index.agent.md
---
# Agent guide: UI And Navigation

* **Page path:** `finding-your-way-around/ui-and-navigation/index.md`
* **Page type:** explanation

## What this page is about

This page is a navigation hub for UI and navigation topics. It points readers to specific sections on configuring columns on list pages, using the list page filter editor, and understanding list pages.

## User intent

* Find documentation about column configuration on list pages
* Access guidance on the list page filter editor
* Learn about list pages within the UI
* Navigate to UI-related documentation sections

## Key terms

* UI and Navigation
* Column Configuration
* List Pages
* Filter Editor

## Terminology links

* [UI and Navigation](/knowledgebase/terminology/#ui-and-navigation)
* [Column configuration](/knowledgebase/terminology/#column-configuration)
* [list pages](/knowledgebase/terminology/#list-pages)
* [list page filter editor](/knowledgebase/terminology/#list-page-filter-editor) (matched from `Filter Editor`)

## Related topics

* Column Configuration On List Pages
* List Page Filter Editor
* List Pages

## Prerequisites

* Basic familiarity with the application's user interface

## Not covered

* Detailed instructions for any listed topic
* Step-by-step UI procedures
* Concepts outside the listed UI and list page navigation topics

---

---
url: /api-agent-guides/catalyst/resources/landing-page/ui-config/index.agent.md
---
# Agent guide: UI Config

* **Page path:** `catalyst/resources/landing-page/ui-config.md`
* **Page type:** reference

## What this page is about

Reference for the UI Config API used to create, update, and retrieve configuration for UI components. It documents the POST and GET `/ui-config/{component}/` behavior, permissions, request fields, validation rules, and error responses.

## User intent

* Create or update UI configuration for a specific component
* Fetch stored UI configuration for a component
* Understand required permissions for UI Config endpoints
* Learn request body fields such as `content` and `custom components`
* Check validation rules for component names and upload component metadata
* Diagnose API errors for invalid payloads, permissions, or schema issues

## Key terms

* UI Config
* component
* content
* custom components
* object class
* object class field
* document type
* case insensitive component name
* public theme
* permissions
* JSON compatible content

## Terminology links

* [UI Config](/api/terminology/#ui-config)
* [UI component](/api/terminology/#ui-component) (matched from `component`)
* [custom components](/api/terminology/#custom-components)
* [object classes](/api/terminology/#object-classes) (matched from `object class`)
* [object class fields](/api/terminology/#object-class-fields) (matched from `object class field`)
* [document type field](/api/terminology/#document-type-field) (matched from `document type`)
* [public theme](/api/terminology/#public-theme)
* [permissions](/api/terminology/#permissions)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of REST API requests and responses
* Familiarity with JSON payloads
* Knowledge of component naming used by the application
* Awareness of object classes and object class fields in the system
* Appropriate permissions for protected endpoints

## Not covered

* Examples of complete request or response payloads
* Detailed explanation of permission names beyond stating they are required
* How UI components render or consume the stored configuration
* How to manage custom component definitions themselves
* General authentication setup outside noting some component names are public

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/merge-fields/understanding-namespace-in-jinja2-for-document-templates/index.agent.md
---
# Agent guide: Understanding Namespace in Jinja2 for Document Templates

* **Page path:** `system-configuration/merge-fields/understanding-namespace-in-jinja2-for-document-templates/index.md`
* **Page type:** explanation

## What this page is about

Explains how Jinja2 namespace works in Autologyx document templates and sequencer logic to preserve variable values across loops and blocks. It contrasts plain set inside loops with namespace, and shows how to accumulate totals and structured data like lists of dictionaries.

## User intent

* Understand what a Jinja2 namespace is
* Learn why set does not persist values correctly across loop iterations
* Keep counters or running totals in document templates or sequencer logic
* Accumulate values across child records in loops
* Build lists of dictionaries or other structured objects within Jinja2 templates
* Apply namespace patterns in Autologyx for document merging and API/sequencer scenarios

## Key terms

* Jinja2 namespace
* document templates
* Autologyx Sequencer
* set
* loops
* blocks
* running total
* variable persistence
* list of dictionaries
* guard clauses
* merge fields

## Terminology links

* [Namespace in Jinja2](/knowledgebase/terminology/#namespace-in-jinja2) (matched from `Jinja2 namespace`)
* [Document Templates](/knowledgebase/terminology/#document-templates)
* [Autologyx Sequencer](/knowledgebase/terminology/#autologyx-sequencer)
* [Set](/knowledgebase/terminology/#set)
* [Loop actors](/knowledgebase/terminology/#loop-actors) (matched from `loops`)
* [Guard Clauses](/knowledgebase/terminology/#guard-clauses)
* [merge fields](/knowledgebase/terminology/#merge-fields)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Jinja2 template syntax
* Basic understanding of loops and variables in templates
* Some awareness of Autologyx document templating or sequencer usage
* Understanding of parent/child relational data is helpful

## Not covered

* Full Jinja2 syntax reference
* Detailed setup of the example relational model beyond the brief department/supplier context
* General Python list methods usage in Autologyx beyond noting that append cannot be used
* Detailed explanation of guard clauses; it only notes they should be used when referencing an index
* Broader document template design or sequencer configuration outside namespace usage

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/apis-and-variables/understanding-namespace-in-jinja2-for-local-variables/index.agent.md
---
# Agent guide: Understanding Namespace in Jinja2 for local variables

* **Page path:** `system-configuration/apis-and-variables/understanding-namespace-in-jinja2-for-local-variables/index.md`
* **Page type:** explanation

## What this page is about

Explains how to use Jinja2 namespaces in Autologyx to keep local variables persistent across loops and blocks, especially for counters, calculations, and building structured data in document templates and Sequencer logic. It contrasts namespace with set, which resets inside loops.

## User intent

* Understand what a Jinja2 namespace is
* Learn why set does not preserve values across loop iterations
* Accumulate totals or counters across related records
* Use namespaces in Autologyx document templating
* Use namespaces in Sequencer local variable/API loop logic
* Store and build lists or dictionaries inside a namespace during loops
* Generate structured summary data such as document lists from child records

## Key terms

* Jinja2 namespace
* set
* loop scope
* local variables
* document templating
* Sequencer
* running total
* persist across blocks
* list of dictionaries
* guard clauses
* related records

## Terminology links

* [Namespace in Jinja2](/knowledgebase/terminology/#namespace-in-jinja2) (matched from `Jinja2 namespace`)
* [Set](/knowledgebase/terminology/#set)
* [local variables](/knowledgebase/terminology/#local-variables)
* [Document Templates](/knowledgebase/terminology/#document-templates) (matched from `document templating`)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Guard Clauses](/knowledgebase/terminology/#guard-clauses)
* [related records](/knowledgebase/terminology/#related-records)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Jinja2 template syntax
* Some understanding of Autologyx document templates or Sequencer
* Awareness of looping through related records/relational data

## Not covered

* Full Jinja2 syntax reference
* Detailed relational model setup beyond the brief department/supplier example
* Complete guard clause guidance beyond a note to use them for indexed access
* General Python list methods in Autologyx, except noting append cannot be used here
* Broader Autologyx API configuration topics outside namespace usage

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequence-actors/update-record-actor/index.agent.md
---
# Agent guide: Update Record Actor

* **Page path:** `system-configuration/sequence-actors/update-record-actor/index.md`
* **Page type:** explanation

## What this page is about

Explains how the Update Record actor is used in a workflow sequence to update one or more fields on a record. It also covers configuration steps, field value options, labeling, and how updates appear in the Activity log.

## User intent

* Understand what the Update Record actor does
* Configure an Update Record actor in a sequence
* Update one or more record fields during a workflow
* Know which field types can and cannot be updated
* Choose between setting a static value or clearing a field
* See how updates are recorded in the Activity log
* Rename the actor for clarity in the sequence

## Key terms

* Update Record actor
* workflow
* sequence
* record
* fields
* object class fields
* user fields
* Set Field
* static value
* No value/default
* Null
* single select field
* configuration row
* Properties
* Activity log
* Field value updated
* sequence ID

## Terminology links

* [Update Record actor](/knowledgebase/terminology/#update-record-actor)
* [Workflow area](/knowledgebase/terminology/#workflow-area) (matched from `workflow`)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `sequence`)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `record`)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `fields`)
* [user field](/knowledgebase/terminology/#user-field) (matched from `user fields`)
* [Set Field](/knowledgebase/terminology/#set-field)
* [Static Value](/knowledgebase/terminology/#static-value)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with workflow sequences
* Ability to drag, drop, and configure actors in a sequence
* Understanding of record fields and object class fields

## Not covered

* Updating user fields, which are excluded
* Advanced field-specific behaviors beyond the example shown
* Conditions, validation rules, or error handling for updates
* Any actor types other than Update Record

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.14/user-experience-interface-improvements/index.agent.md
---
# Agent guide: User Experience & Interface Improvements

* **Page path:** `release-notes/release-notes-1.14/user-experience-interface-improvements/index.md`
* **Page type:** release-notes

## What this page is about

This release-notes page summarizes user experience and interface improvements in version 1.14, mainly the introduction of Markdown display for text fields and form usability enhancements. It also notes layout, auto-resizing, and UI consistency updates across the platform.

## User intent

* Understand what UX/UI changes were introduced in release 1.14
* Learn how Markdown text fields can be displayed in forms and elsewhere
* See which field types now expand to full column width in create/edit forms
* Find out how automatic height adjustment works for Multiline and Markdown fields
* Understand general UI consistency improvements across the platform

## Key terms

* Markdown text fields
* source code display
* rendered text
* create/edit record forms
* task forms
* record list columns
* Multiline fields
* JSON fields
* full-width textboxes
* automatic height adjustment
* 500 lines
* UI consistency

## Terminology links

* [rendered text](/knowledgebase/terminology/#rendered-text)
* [Create/Edit record form](/knowledgebase/terminology/#createedit-record-form) (matched from `create/edit record forms`)
* [task forms](/knowledgebase/terminology/#task-forms)
* [record list columns](/knowledgebase/terminology/#record-list-columns)
* [JSON fields](/knowledgebase/terminology/#json-fields)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with record forms, task forms, and record list columns in the platform
* Understanding of text field types such as single line, multiline, Markdown, and JSON

## Not covered

* Detailed setup or configuration steps for enabling Markdown fields
* Any backend, data model, or API changes
* Behavior of Markdown rendering beyond the stated form and list display contexts
* Changes outside the described UX/UI improvements in release 1.14

---

---
url: >-
  /knowledgebase-agent-guides/administration/user-groups/user-group-list/index.agent.md
---
# Agent guide: User Group List

* **Page path:** `administration/user-groups/user-group-list/index.md`
* **Page type:** explanation

## What this page is about

Explains the User Group list page, including its default and optional columns and how available actions vary by account type and group role. It also notes visibility rules for Super admins, Config admin owners, and Config admin members.

## User intent

* Understand what information appears in the User Group list
* Learn what the default column headers mean
* See which additional columns can be enabled
* Find out which user groups are visible to different account types
* Understand which actions are available for Super admins, owners, and members
* Determine when ID and Name fields are useful or required

## Key terms

* User Group list
* ID
* Name
* Description
* Actions
* Super admin
* Config admin
* Owner
* Member
* Open
* View usage
* Delete
* column configuration
* # Members
* # Owners
* Created
* Created by
* Last edited
* Last edited by

## Terminology links

* [User group list](/knowledgebase/terminology/#user-group-list)
* [Identifier](/knowledgebase/terminology/#identifier) (matched from `ID`)
* [Description](/knowledgebase/terminology/#description)
* [Actions menu](/knowledgebase/terminology/#actions-menu) (matched from `Actions`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Config admin account type](/knowledgebase/terminology/#config-admin-account-type) (matched from `Config admin`)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Owner`)
* [Members](/knowledgebase/terminology/#members) (matched from `Member`)

## Related topics

* editing user groups
* common features and functions of the list pages in your system
* using the list pages
* using the list page filter editor

## Prerequisites

* Basic understanding of user groups and user roles
* Awareness of account types such as Super admin and Config admin
* Familiarity with list pages in the system

## Not covered

* Step-by-step instructions for editing user groups
* Detailed creation workflow for a new user group
* How filtering works beyond linking to the filter editor documentation
* Detailed explanations of general list page features
* Permissions outside the specific User Group list visibility and action rules described here

---

---
url: >-
  /api-agent-guides/catalyst/resources/user-groups/user-group-permission-sets/index.agent.md
---
# Agent guide: User Group Permission Sets

* **Page path:** `catalyst/resources/user-groups/user-group-permission-sets.md`
* **Page type:** reference

## What this page is about

Reference for API endpoints that manage User Group Permission Sets at the User Group level. It covers listing, creating, updating, deleting, and OPTIONS behavior, plus rules for special permission set types and validation/errors.

## User intent

* List permission sets for a specific User Group
* Create a custom User Group Permission Set
* Update a User Group Permission Set name or permissions
* Delete a custom User Group Permission Set
* Understand which permission set types are special and restricted
* Check validation rules, limits, and error responses for these endpoints
* Understand allowed resource actions for permission sets

## Key terms

* User Group Permission Set
* User Group
* Custom Permission Set
* special permission sets
* EVERYONE
* MEMBERS
* permissions
* user groups.view
* user groups.edit perm set
* reserved names
* case-insensitive uniqueness
* maximum 10 permission sets per User Group
* restricted system sets
* dependencies conversion
* GET /api/user groups/{user group id}/permission sets/
* POST /api/user groups/{user group id}/permission sets/
* PATCH /api/user groups/{user group id}/permission sets/{id}/
* DELETE /api/user groups/{user group id}/permission sets/{id}/
* OPTIONS /api/user groups/{user group id}/permission sets/

## Terminology links

* [user group permission sets](/api/terminology/#user-group-permission-sets) (matched from `User Group Permission Set`)
* [user groups](/api/terminology/#user-groups) (matched from `User Group`)
* [Custom User Group Permission Set](/api/terminology/#custom-user-group-permission-set) (matched from `Custom Permission Set`)
* [Special Permission Sets](/api/terminology/#special-permission-sets)
* [everyone perm set](/api/terminology/#everyone-perm-set) (matched from `EVERYONE`)
* [members perm set](/api/terminology/#members-perm-set) (matched from `MEMBERS`)
* [permissions](/api/terminology/#permissions)
* [user groups.view](/api/terminology/#user-groupsview)

## Related topics

* Assigning for User Groups Permission Set
* User Groups

## Prerequisites

* Basic understanding of User Groups
* Familiarity with API requests/responses and common HTTP methods
* Awareness that assigning users to custom User Group Permission Sets is documented separately

## Not covered

* Endpoints for assigning users to a custom User Group Permission Set
* Technical design details beyond brief references to dependency conversion
* General User Group management outside permission set endpoints
* GET endpoint for a single permission set is explicitly listed as not allowed

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.8/user-group-permissions/index.agent.md
---
# Agent guide: User group permissions

* **Page path:** `release-notes/release-notes-1.8/user-group-permissions/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces the User Group Permissions feature in Catalyst. It explains how custom permission sets, default group permission sets, and group-based assignment let administrators control who can view, edit, or delete groups and manage member visibility.

## User intent

* Understand what the new User Group Permissions feature does
* Learn how permission sets are created for groups
* See what default permission sets exist when a group is created
* Understand what access group owners have by default
* Learn how to assign permissions to users or entire groups
* Understand how permissions change when group membership changes

## Key terms

* User Group Permissions
* custom permission sets
* default permission sets
* group owners
* Members permission set
* Everyone permission set
* group-based assignment
* group visibility
* edit permissions
* delete permissions

## Terminology links

* [User Group Permissions](/knowledgebase/terminology/#user-group-permissions)
* [custom permission sets](/knowledgebase/terminology/#custom-permission-sets)
* [Default User Group Permissions](/knowledgebase/terminology/#default-user-group-permissions) (matched from `default permission sets`)
* [group owners](/knowledgebase/terminology/#group-owners)
* [Members](/knowledgebase/terminology/#members) (matched from `Members permission set`)
* [Everyone](/knowledgebase/terminology/#everyone) (matched from `Everyone permission set`)
* [group based assignment](/knowledgebase/terminology/#group-based-assignment) (matched from `group-based assignment`)
* [group visibility](/knowledgebase/terminology/#group-visibility)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Catalyst groups and group membership
* Familiarity with permission/access control concepts

## Not covered

* Detailed step-by-step setup or configuration instructions
* UI navigation or screenshots
* Exact permission matrix or all available actions
* Administrative requirements or role limitations beyond group owners
* Implementation details for future planned expansions

---

---
url: >-
  /knowledgebase-agent-guides/administration/user-groups/user-group-permissions/index.agent.md
---
# Agent guide: User Group Permissions

* **Page path:** `administration/user-groups/user-group-permissions/index.md`
* **Page type:** explanation

## What this page is about

Explains how permissions work within a User group, including the default permission sets and how Super admins or User group Owners can create additional permission sets and assign users or user groups to them. It also describes how to access the Permissions tab and key limits related to user groups.

## User intent

* Understand who can manage User group permissions
* Learn the default permission sets for a User group
* Find out how to access the Permissions tab of a User group
* Create an additional User group permission set
* Assign individual users or user groups to a permission set
* Understand when permission changes take effect
* Check limits such as maximum Owners, Members, and total User groups

## Key terms

* User group permissions
* Super admin
* User group Owners
* Permissions tab
* Default permission sets
* Owners
* Everyone
* Members
* Additional permission sets
* Assignees
* Edit permission
* View permission
* Delete permission

## Terminology links

* [User Group Permissions](/knowledgebase/terminology/#user-group-permissions)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [User group Owner](/knowledgebase/terminology/#user-group-owner) (matched from `User group Owners`)
* [Permissions tab](/knowledgebase/terminology/#permissions-tab)
* [Default User Group Permissions](/knowledgebase/terminology/#default-user-group-permissions) (matched from `Default permission sets`)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Owners`)
* [Everyone](/knowledgebase/terminology/#everyone)
* [Members](/knowledgebase/terminology/#members)

## Related topics

* Editing a User group
* editing user group permissions

## Prerequisites

* Access to a Super admin account or being a User group Owner
* Basic familiarity with User groups
* Knowing how to open a User group in the system

## Not covered

* Detailed limitations of editing a User group beyond referring to another article
* A full explanation of editing existing permissions beyond a brief reference
* General user management outside the context of User group permission sets
* Permissions for 1 time completion users who do not log in

---

---
url: /api-agent-guides/catalyst/resources/user-groups/user-groups/index.agent.md
---
# Agent guide: User Groups

* **Page path:** `catalyst/resources/user-groups/user-groups.md`
* **Page type:** reference

## What this page is about

Reference for the User Groups API, covering CRUD operations, listing, single-item retrieval, usage checks, autocomplete, and group-user membership listing. It also documents request/response fields, validations, sorting/filtering options, permissions, and error cases.

## User intent

* Create a user group via API
* Update an existing user group
* List user groups with pagination, sorting, and filtering
* Retrieve a single user group by id
* Delete a user group and understand why deletion may be blocked
* Check where a user group is in use before deleting it
* Use user group autocomplete endpoints
* Understand the deprecated combined users-and-user-groups autocomplete endpoint
* List users that belong to a specific user group
* Learn validation rules for name and description fields
* See permission requirements and common API error responses

## Key terms

* User Groups
* POST /api/user groups/
* PATCH /api/user groups/{id}/
* GET /api/user groups/
* GET /api/user groups/{id}/
* DELETE /api/user groups/{id}/
* GET /api/user groups/{id}/usage/
* GET /api/user groups/autocomplete/
* GET /api/user groups/autocomplete/users combined/
* GET /api/user groups/{id}/users/
* name
* description
* meta.permissions
* num of members
* num of owners
* ordering
* filtering
* usage
* permission sets
* deprecated endpoint

## Terminology links

* [user groups](/api/terminology/#user-groups)
* [permissions](/api/terminology/#permissions) (matched from `meta.permissions`)
* [num of members](/api/terminology/#num-of-members)
* [num of owners](/api/terminology/#num-of-owners)
* [ordering](/api/terminology/#ordering)
* [filtering](/api/terminology/#filtering)
* [Document Template usage](/api/terminology/#document-template-usage) (matched from `usage`)
* [Permission Set](/api/terminology/#permission-set) (matched from `permission sets`)

## Related topics

* Assigning for User Groups Permission Set
* User Group Permission Sets

## Prerequisites

* Basic understanding of REST API requests and responses
* Authentication/authorization concepts
* Familiarity with ALX API standards for filtering predicates
* Knowledge of user groups, users, and permission sets in the product

## Not covered

* Detailed explanation of specific permission names/roles required for each endpoint
* How to assign permission sets to user groups
* Business workflow guidance beyond the API contract
* Full ALX API standards for predicates and filtering behavior
* Implementation details for membership modification endpoints beyond listing users

---

---
url: /knowledgebase-agent-guides/administration/user-groups/index.agent.md
---
# Agent guide: User Groups

* **Page path:** `administration/user-groups/index.md`
* **Page type:** explanation

## What this page is about

This page is an overview for User Groups and points readers to related sections about creating, editing, listing, permissions, and visibility for user groups. It serves as a navigation page rather than providing detailed procedures itself.

## User intent

* Find where to edit a user group
* Find where to edit user group permissions
* View information about the user group list
* Understand user group permissions
* Learn about users and groups visibility
* Understand what is needed before creating a user group
* Learn why user groups are needed

## Key terms

* User Groups
* Editing A User Group
* Editing User Group Permissions
* User Group List
* User Group Permissions
* Users And Groups Visibility
* Creating A User Group

## Terminology links

* [User Groups](/knowledgebase/terminology/#user-groups)
* [Editing A User Group](/knowledgebase/terminology/#editing-a-user-group)
* [Editing User Group Permissions](/knowledgebase/terminology/#editing-user-group-permissions)
* [User group list](/knowledgebase/terminology/#user-group-list)
* [User Group Permissions](/knowledgebase/terminology/#user-group-permissions)
* [Users And Groups Visibility](/knowledgebase/terminology/#users-and-groups-visibility)
* [Creating A User Group](/knowledgebase/terminology/#creating-a-user-group)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with users and groups in the system

## Not covered

* Detailed steps for creating a user group
* Detailed instructions for editing a user group
* Specific permission definitions or configuration details
* Examples or best practices for structuring user groups

---

---
url: /api-agent-guides/catalyst/resources/users/user-preferences/index.agent.md
---
# Agent guide: User Preferences

* **Page path:** `catalyst/resources/users/user-preferences.md`
* **Page type:** reference

## What this page is about

This page documents the API for storing and retrieving authenticated users' frontend layout preferences. It covers a POST endpoint to create or overwrite preferences by key and a GET endpoint to fetch preferences for a key.

## User intent

* Save a user's frontend layout settings such as table columns, sorting, filtering, and similar UI preferences
* Overwrite existing authenticated user preferences for a given key
* Retrieve stored preferences for a given key
* Understand request fields, validation limits, and error responses for the user preferences API

## Key terms

* user preferences
* frontend application layout settings
* key
* preferences
* authenticated user
* POST /api/users/preferences/
* GET /api/users/preferences/
* validation
* max length
* 404 Not Found
* 400 Bad Request

## Terminology links

* [User Preferences](/api/terminology/#user-preferences)
* [frontend application layout settings](/api/terminology/#frontend-application-layout-settings)
* [preferences key](/api/terminology/#preferences-key) (matched from `key`)

## Related topics

* Users

## Prerequisites

* Basic understanding of authenticated API requests
* Knowledge of sending headers, URL parameters, and request bodies
* Awareness that preferences are stored per authenticated user and identified by a key

## Not covered

* Exact permission names or authentication mechanism details
* Supported sorting or filtering on the API itself, which are explicitly not supported
* Detailed schema examples beyond the listed fields and validations
* Any broader user management behavior outside preferences

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.3/user-type-field/index.agent.md
---
# Agent guide: User type field

* **Page path:** `release-notes/release-notes-1.3/user-type-field/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces the User Type Field in the Autologyx Catalyst platform. It explains that System Administrators can configure a field that lets record pages select users registered in the system, including minimum and maximum selection limits.

## User intent

* Understand what the User Type Field does
* Learn who the feature is intended for
* See how administrators can configure user selection on record pages
* Identify example use cases such as assigning responsible parties, approvers, or team members
* Confirm that minimum and maximum user selections can be defined

## Key terms

* User Type Field
* Autologyx Catalyst platform
* System Administrators
* field configuration
* record page
* minimum selections
* maximum selections
* record creation
* record editing
* approval workflows
* authorised approvers
* team collaboration

## Terminology links

* [User type fields](/knowledgebase/terminology/#user-type-fields) (matched from `User Type Field`)
* [Autologyx Catalyst platform](/knowledgebase/terminology/#autologyx-catalyst-platform)
* [System Administrators](/knowledgebase/terminology/#system-administrators)
* [field configurations](/knowledgebase/terminology/#field-configurations) (matched from `field configuration`)
* [record's page](/knowledgebase/terminology/#records-page) (matched from `record page`)
* [record creation](/knowledgebase/terminology/#record-creation)
* [editing records](/knowledgebase/terminology/#editing-records) (matched from `record editing`)
* [approval workflows](/knowledgebase/terminology/#approval-workflows)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx Catalyst
* Understanding of records and record pages
* System Administrator access or responsibilities

## Not covered

* Step-by-step setup instructions
* Detailed UI workflow or screenshots
* Technical limitations or validation behavior beyond min/max selections
* Permissions model details for which users can be selected
* Integration with other features beyond the example use cases

---

---
url: /api-agent-guides/catalyst/resources/users/users/index.agent.md
---
# Agent guide: Users

* **Page path:** `catalyst/resources/users/users.md`
* **Page type:** reference

## What this page is about

Reference for the Users API: creating, listing, retrieving, updating, deleting users, resending activation emails, and assigning/unassigning roles. It documents request/response fields, permissions, validations, limits, filtering/sorting, and error cases.

## User intent

* Create a user with POST /api/users/
* List users with pagination, filtering, and ordering via GET /api/users/
* Retrieve a single user by ID
* Update user fields, account type, password, timezone, roles, and IP restriction settings via PATCH
* Delete a user
* Resend a user's activation email
* Add roles to a user in batch
* Remove roles from a user in batch
* Understand per-account-type limits and validation rules
* Handle documented 400/403/404 error responses

## Key terms

* Users API
* account type
* roles
* delay activation
* timezone
* is ip restriction enabled
* allowed ip ranges
* password complexity requirements
* activation email
* meta.permissions
* filtering
* ordering
* per-account-type limits
* Service accounts
* config admin account

## Terminology links

* [account type](/api/terminology/#account-type)
* [Roles](/api/terminology/#roles)
* [delay activation](/api/terminology/#delay-activation)
* [password complexity requirements](/api/terminology/#password-complexity-requirements)
* [send activation email](/api/terminology/#send-activation-email) (matched from `activation email`)
* [permissions](/api/terminology/#permissions) (matched from `meta.permissions`)
* [filtering](/api/terminology/#filtering)
* [ordering](/api/terminology/#ordering)

## Related topics

* User Preferences

## Prerequisites

* Basic understanding of REST APIs and HTTP methods
* Ability to authenticate and supply required permissions
* Knowledge of user/account concepts such as roles, status, and account types
* For enum values, use OPTIONS /api/users/ details.schema where referenced

## Not covered

* Detailed definitions of permission names/authorization model
* Full enum values for account type, status, timezone, and next actions
* ALX API standards predicate details beyond referencing them for filtering
* Detailed request examples/schemas for some role endpoints
* User preferences behavior itself; only nearby related title is mentioned

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/merge-fields/users-and-groups/index.agent.md
---
# Agent guide: Users and Groups

* **Page path:** `system-configuration/merge-fields/users-and-groups/index.md`
* **Page type:** explanation

## What this page is about

This page explains how Catalyst user-type fields expose users and user groups in merge fields. It contrasts legacy ID-based access with object-based access and outlines available user/group object data, indexing, iteration, deleted-user behavior, and supported contexts.

## User intent

* Understand how to access users and user groups from user-type merge fields
* Choose between ID-based access for compatibility and object-based access for full properties
* See what properties are available on user objects and user group objects
* Handle indexing, looping, and mixed user/group access in templates or sequencer contexts
* Know what happens when referenced users have been deleted
* Confirm where user-type merge fields are supported and how empty fields behave

## Key terms

* user type fields
* users
* user groups
* ID based access
* legacy compatibility
* object based access
* user object properties
* user group object properties
* indexing users
* indexing user groups
* hidden properties
* deleted users handling
* iteration
* supported contexts
* document templates
* sequencer actors
* related records merge fields
* empty field

## Terminology links

* [User type fields](/knowledgebase/terminology/#user-type-fields)
* [Users list](/knowledgebase/terminology/#users-list) (matched from `users`)
* [User Groups](/knowledgebase/terminology/#user-groups)
* [ID based access](/knowledgebase/terminology/#id-based-access)
* [object based access](/knowledgebase/terminology/#object-based-access)
* [hidden properties](/knowledgebase/terminology/#hidden-properties)
* [deleted users handling](/knowledgebase/terminology/#deleted-users-handling)
* [Document Templates](/knowledgebase/terminology/#document-templates)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst merge fields
* Understanding of users and user groups in the system
* Some awareness of templates or sequencer contexts where merge fields are used

## Not covered

* Exact merge field syntax examples are referenced but not fully shown in the provided text
* Definitions of account type enum values are not provided
* Broader user/group administration outside merge field access is not covered
* Non-user-type merge fields and unrelated merge field behaviors are not discussed

---

---
url: >-
  /knowledgebase-agent-guides/administration/user-groups/users-and-groups-visibility/index.agent.md
---
# Agent guide: Users and Groups visibility

* **Page path:** `administration/user-groups/users-and-groups-visibility/index.md`
* **Page type:** explanation

## What this page is about

This page explains how user and group visibility is controlled in Catalyst from version 1.10.0 onward using List permissions tied to user and group view permissions and User Group Permission Sets. It also describes exceptions, special cases like 1TC accounts, and where these permissions affect selection across the platform.

## User intent

* Understand how users and groups become visible or selectable in the system
* Learn what List permissions are and how they work
* Find out how List permissions are granted through group permission sets, API roles, or Super Admin access
* Understand the default visibility behavior for Owners, Members, and Everyone in user groups
* Check how visibility works for One Time Completion (1TC) accounts
* See where List permissions matter in workflows such as task assignment, ownership, permission sets, and filters
* Identify exceptions where users may still appear in configured user type fields

## Key terms

* List permissions
* User Group Permission Sets
* view permission
* Owners
* Members
* Everyone
* Custom Permission Sets
* Config Admins
* users.list
* API
* Super Admins
* One Time Completion (1TC) accounts
* user visibility
* group visibility

## Terminology links

* [List permissions](/knowledgebase/terminology/#list-permissions)
* [User Group Permission Sets](/knowledgebase/terminology/#user-group-permission-sets)
* [view permissions](/knowledgebase/terminology/#view-permissions) (matched from `view permission`)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Owners`)
* [Members](/knowledgebase/terminology/#members)
* [Everyone](/knowledgebase/terminology/#everyone)
* [custom permission sets](/knowledgebase/terminology/#custom-permission-sets)
* [Config Admins](/knowledgebase/terminology/#config-admins)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of users, groups, and permissions in Catalyst
* Familiarity with user group membership and permission sets
* Awareness of admin roles such as Config Admin and Super Admin

## Not covered

* Step-by-step configuration instructions for creating or editing permission sets
* Detailed API implementation steps for granting users.list
* Broader user management features outside visibility and listing behavior
* Detailed setup of object classes, sequences, or task configuration beyond where list permissions apply

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.10/users-and-groups-visibility-control/index.agent.md
---
# Agent guide: Users and groups visibility control

* **Page path:** `release-notes/release-notes-1.10/users-and-groups-visibility-control/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces user and group visibility control via list permissions, explaining how visibility is granted and where it affects selection of users and groups across the platform. It also highlights special handling for group permission sets, API-granted admin access, super admins, and One Time Completion (1TC) accounts.

## User intent

* Understand what list permissions are and how they control visibility of users and groups
* Learn how list permissions are granted through user group permission sets, API roles for Config Admins, and Super Admin access
* Determine who can view or list members of a user group
* Understand default behavior for Owners, Members, and Everyone permission sets
* Learn how visibility works for One Time Completion (1TC) accounts
* Identify where in the system list permissions affect user/group selection

## Key terms

* List permissions
* User Group Permission Sets
* Owners
* Members
* Everyone
* Custom Permission Sets
* Config Admins
* users.list permission
* API
* Super Admins
* One Time Completion (1TC) Accounts
* view permission
* user visibility
* group visibility

## Terminology links

* [List permissions](/knowledgebase/terminology/#list-permissions)
* [User Group Permission Sets](/knowledgebase/terminology/#user-group-permission-sets)
* [record owners](/knowledgebase/terminology/#record-owners) (matched from `Owners`)
* [Members](/knowledgebase/terminology/#members)
* [Everyone](/knowledgebase/terminology/#everyone)
* [custom permission sets](/knowledgebase/terminology/#custom-permission-sets)
* [Config Admins](/knowledgebase/terminology/#config-admins)
* [users.list permission](/knowledgebase/terminology/#userslist-permission)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of users, user groups, and permissions in the platform
* Familiarity with admin roles such as Config Admin and Super Admin
* Awareness of places where users or groups are selected, such as task assignment or permission settings

## Not covered

* Step-by-step configuration instructions or UI procedures
* Detailed API request examples or role setup details
* General permission model beyond visibility/list behavior
* Broader release notes outside this specific visibility control update

---

---
url: >-
  /knowledgebase-agent-guides/administration/users-roles-and-user-groups/index.agent.md
---
# Agent guide: Users Roles And User Groups

* **Page path:** `administration/users-roles-and-user-groups/index.md`
* **Page type:** explanation

## What this page is about

This page is intended to cover users, roles, and user groups, but it is currently empty or under construction.

## User intent

* Check whether documentation exists for users, roles, and user groups
* Find guidance on administering users and permissions

## Key terms

* users
* roles
* user groups

## Terminology links

* [Users list](/knowledgebase/terminology/#users-list) (matched from `users`)
* [Roles](/knowledgebase/terminology/#roles)
* [User Groups](/knowledgebase/terminology/#user-groups)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Any actual explanation of users, roles, or user groups
* Procedures for creating, editing, or managing users
* Role-based permissions details
* How user groups are structured or used

---

---
url: >-
  /knowledgebase-agent-guides/administration/authentication-objects/using-an-authentication-object-in-an-api-call/index.agent.md
---
# Agent guide: Using an Authentication object in an API call

* **Page path:** `administration/authentication-objects/using-an-authentication-object-in-an-api-call/index.md`
* **Page type:** how-to

## What this page is about

This page explains how to use an existing Authentication object in an API call configuration. It describes selecting the Auth Object option in the API call actor and choosing one of the available stored authentication objects.

## User intent

* Use an Authentication object when configuring an API call
* Select stored credentials for a supported provider in an API call actor
* Understand the setup steps needed to make the API call active
* Check the system limit for Authentication objects

## Key terms

* Authentication object
* API call actor
* Authentication menu
* Auth Object
* provider
* Type
* Method
* Data Type
* credentials
* supported providers

## Terminology links

* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `Authentication object`)
* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [Authentication menu](/knowledgebase/terminology/#authentication-menu)
* [providers](/knowledgebase/terminology/#providers) (matched from `provider`)
* [field types](/knowledgebase/terminology/#field-types) (matched from `Type`)
* [Method](/knowledgebase/terminology/#method)
* [Data Type](/knowledgebase/terminology/#data-type)

## Related topics

* How to configure an Authentication object

## Prerequisites

* An Authentication object has already been configured
* The provider is supported
* The user can configure an API call actor

## Not covered

* How to configure or create an Authentication object
* Provider-specific authentication flows or details
* How authentication works for unsupported providers
* General API design or troubleshooting beyond basic setup

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/using-conditional-logic-in-forms/using-conditional-logic-in-a-form/index.agent.md
---
# Agent guide: Using conditional logic in a form

* **Page path:** `record-and-task-forms/using-conditional-logic-in-forms/using-conditional-logic-in-a-form/index.md`
* **Page type:** how-to

## What this page is about

Explains how to add conditional logic to forms so sections display based on user input, using a task template form example. It focuses on configuring conditional visibility for sections in supported form types.

## User intent

* Understand which forms support conditional logic
* Build a form with sections that appear based on selected field values
* Use a control field such as a single select to drive section visibility
* Configure section conditional visibility rules in section properties
* Apply multiple conditions to a section and understand they work as AND conditions
* Use preview mode to test how conditional sections display

## Key terms

* conditional logic
* conditional visibility
* task templates
* object classes
* create/edit view
* summary view
* standalone forms
* section properties
* field properties
* control field
* single select field
* required field
* field alias
* operator
* is not empty
* is equal to
* is not equal to
* AND conditions
* preview mode

## Terminology links

* [conditional logic](/knowledgebase/terminology/#conditional-logic)
* [Conditional Visibility](/knowledgebase/terminology/#conditional-visibility)
* [Task templates](/knowledgebase/terminology/#task-templates)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [create/edit view](/knowledgebase/terminology/#createedit-view)
* [summary view](/knowledgebase/terminology/#summary-view)
* [standalone forms](/knowledgebase/terminology/#standalone-forms)
* [Section Properties](/knowledgebase/terminology/#section-properties)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with creating and editing forms or task template response forms
* Ability to add sections and fields and configure field/section properties

## Not covered

* Advanced logic beyond section visibility
* OR logic; the page only states multiple conditions are AND conditions
* Detailed setup of unrelated task template tabs
* A full catalog of all field types or layout options beyond the example
* General form creation from scratch in depth

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/using-conditional-logic-in-forms/index.agent.md
---
# Agent guide: Using Conditional Logic in Forms

* **Page path:** `record-and-task-forms/using-conditional-logic-in-forms/index.md`
* **Page type:** how-to

## What this page is about

This page explains how to use conditional logic in Autologyx forms to make them dynamic based on user input, such as showing or hiding fields and sections. It also outlines practical considerations when changing forms that already use existing conditional rules.

## User intent

* Understand how conditional logic works in forms
* Use conditional logic to show or hide fields, sections, or other form content based on user input
* Improve form user experience by making forms clearer and more relevant
* Learn what happens when changing properties of fields used in conditional logic
* Learn the impact of removing columns, fields, or sections that are involved in conditional logic

## Key terms

* conditional logic
* forms
* user input
* show or hide fields
* sections
* form content
* field properties
* columns
* controlling field
* user experience

## Terminology links

* [conditional logic](/knowledgebase/terminology/#conditional-logic)
* [Forms tab](/knowledgebase/terminology/#forms-tab) (matched from `forms`)
* [Workspace Sections](/knowledgebase/terminology/#workspace-sections) (matched from `sections`)
* [Record properties](/knowledgebase/terminology/#record-properties) (matched from `field properties`)
* [columns](/knowledgebase/terminology/#columns)
* [Conditional Logic controlling field](/knowledgebase/terminology/#conditional-logic-controlling-field) (matched from `controlling field`)
* [User Experience Interface Improvements](/knowledgebase/terminology/#user-experience-interface-improvements) (matched from `user experience`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with creating or editing forms in Autologyx
* Understanding of form fields, sections, and columns

## Not covered

* Wider form layout or structure beyond behavior based on user input
* General form design outside conditional logic
* Detailed topics not listed in this section overview

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/using-docusign-with-catalyst/index.agent.md
---
# Agent guide: Using Docusign With Catalyst

* **Page path:** `system-configuration/using-docusign-with-catalyst/index.md`
* **Page type:** how-to

## What this page is about

This page is an overview/index for using DocuSign with Catalyst. It lists the main setup and workflow sections, from creating a developer account through sending, monitoring, and retrieving signed documents.

## User intent

* Understand the end-to-end DocuSign integration workflow in Catalyst
* Set up a free DocuSign developer account
* Create an authentication object for DocuSign
* Configure an API call to create an envelope in DocuSign
* Monitor the status of a DocuSign envelope
* Monitor signing status for individual recipients
* Retrieve a signed document and store it in Catalyst
* Understand how system migrations affect DocuSign authentication objects

## Key terms

* DocuSign
* Catalyst
* developer account
* authentication object
* API call
* envelope
* envelope status
* recipient signing status
* signed document
* system migrations

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst)
* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `authentication object`)
* [API Call actor](/knowledgebase/terminology/#api-call-actor) (matched from `API call`)
* [Envelope](/knowledgebase/terminology/#envelope)
* [envelope status](/knowledgebase/terminology/#envelope-status)
* [Recipient status](/knowledgebase/terminology/#recipient-status) (matched from `recipient signing status`)
* [Signed Document](/knowledgebase/terminology/#signed-document)
* [System Migrations](/knowledgebase/terminology/#system-migrations)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Catalyst
* Basic understanding of DocuSign concepts such as envelopes and recipients
* Some awareness of API-based configuration and authentication

## Not covered

* Detailed instructions for any listed section are not present in this page text
* Specific API payloads, authentication parameters, or configuration examples
* General e-signature theory beyond the listed DocuSign workflow topics
* Any integrations other than DocuSign with Catalyst

---

---
url: /knowledgebase-agent-guides/using-help-and-support/index.agent.md
---
# Agent guide: Using Help and Support

* **Page path:** `using-help-and-support/index.md`
* **Page type:** how-to

## What this page is about

This page appears to be a Help and Support landing or index page. It points users to help resources such as sections and FAQs and states that support is available.

## User intent

* Find help and support resources
* Browse help sections
* Access FAQs
* Confirm that support is available

## Key terms

* Help and Support
* Sections
* FAQs
* We're here to help
* Autologyx
* Classification: Unrestricted, Public

## Terminology links

* [Help and Support](/knowledgebase/terminology/#help-and-support)
* [Workspace Sections](/knowledgebase/terminology/#workspace-sections) (matched from `Sections`)
* [FAQs](/knowledgebase/terminology/#faqs)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Specific support procedures or contact methods
* Detailed FAQ content
* Troubleshooting steps
* Technical setup or configuration guidance
* Escalation paths or service levels

---

---
url: >-
  /knowledgebase-agent-guides/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/index.agent.md
---
# Agent guide: Using the API Call actor with AI services

* **Page path:** `applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/index.md`
* **Page type:** how-to

## What this page is about

This page is a placeholder for future guidance on using the Sequencer API Call actor to make outbound REST requests to AI services. It also संकेतs intended coverage of patterns using Loop actors and playbook-style Object Classes for reusable prompt functions.

## User intent

* Learn how to use the Sequencer API Call actor to call external AI service APIs
* Understand patterns for outbound REST requests to AI services
* See how Loop actors may be used in AI service call workflows
* See how playbook-style Object Classes can support reusable prompt functions

## Key terms

* API Call actor
* Sequencer
* outbound REST requests
* AI services
* Loop actors
* playbook style Object Classes
* reusable prompt functions

## Terminology links

* [API Call actor](/knowledgebase/terminology/#api-call-actor)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Loop actors](/knowledgebase/terminology/#loop-actors)
* [playbook style Object Classes](/knowledgebase/terminology/#playbook-style-object-classes)
* [reusable prompt functions](/knowledgebase/terminology/#reusable-prompt-functions)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the Sequencer
* Basic understanding of REST API calls
* General awareness of AI service integrations

## Not covered

* Step-by-step instructions are not provided
* Configuration details for the API Call actor are not included
* Specific examples for OpenAI or other providers are not included
* Implementation details for Loop actors and Object Classes are not yet documented

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequences-for-relational-records/using-the-sequence-runner-actor-for-one-object-class/index.agent.md
---
# Agent guide: Using the Sequence Runner Actor for one Object Class

* **Page path:** `system-configuration/sequences-for-relational-records/using-the-sequence-runner-actor-for-one-object-class/index.md`
* **Page type:** how-to

## What this page is about

Explains how to use the Sequence Runner actor by itself to launch a sub-process on the same object class within a larger sequence. It uses a mortgage application escalation example to show activation, conditional triggering, and rejoining the main workflow.

## User intent

* Understand when to use Sequence Runner without Relation Lookup
* Run another sequence against records in the same object class
* Break large sequences into smaller, maintainable sub-processes
* Configure a Sequence Runner to target 'Self' records
* Trigger different sub-processes based on subject matter or conditions
* Set up an escalation sequence and return to the main sequence afterward

## Key terms

* Sequence Runner actor
* Relation Lookup actor
* object class
* Self records
* starting sequence
* sub process
* trigger conditions
* When Sequence Activated
* When Record Updated
* supplementary condition
* Update object record
* main sequence
* escalation sequence

## Terminology links

* [Sequence Runner](/knowledgebase/terminology/#sequence-runner) (matched from `Sequence Runner actor`)
* [Relation Lookup](/knowledgebase/terminology/#relation-lookup) (matched from `Relation Lookup actor`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [Self records](/knowledgebase/terminology/#self-records)
* [main sequence](/knowledgebase/terminology/#main-sequence) (matched from `starting sequence`)
* [sub process](/knowledgebase/terminology/#sub-process)
* [Sequence commencement conditions](/knowledgebase/terminology/#sequence-commencement-conditions) (matched from `trigger conditions`)
* [Sequence Activated](/knowledgebase/terminology/#sequence-activated) (matched from `When Sequence Activated`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of sequences and actors
* Familiarity with trigger conditions and supplementary conditions
* Knowledge of object classes and record fields/tasks

## Not covered

* Detailed steps for using Sequence Runner with Relation Lookup
* Full configuration instructions for every actor shown in screenshots
* General sequence design beyond the one-object-class use case
* Anything outside the provided mortgage application escalation example

---

---
url: >-
  /api-agent-guides/catalyst/resources/platform-information/version/index.agent.md
---
# Agent guide: Version

* **Page path:** `catalyst/resources/platform-information/version.md`
* **Page type:** reference

## What this page is about

This page documents version information endpoints. It covers a public global endpoint for current platform versions and an Admin Portal API endpoint for component versions on a specific cluster and namespace.

## User intent

* Find the current platform version
* Check version and version history values returned by the public API
* Retrieve installed component versions for a specific cluster and namespace
* Understand which version endpoint is public versus Admin Portal API protected
* Identify authentication requirements and possible authorization errors for the cluster-specific version endpoint

## Key terms

* GET /api/version/
* platform version information
* global endpoint
* tenant domain
* public access
* Admin Portal API
* cluster specific
* cluster and namespace
* API key
* HTTPS
* version
* version history
* version ui
* 401 Unauthorized
* 403 Forbidden

## Terminology links

* [api key](/api/terminology/#api-key)

## Related topics

* Health Check

## Prerequisites

* Basic understanding of HTTP GET endpoints
* Knowledge of request headers
* For the Admin Portal API endpoint, access to a valid Admin Portal API Key
* Awareness of tenant or instance domains

## Not covered

* Detailed request and response examples beyond the listed fields
* How to obtain or manage Admin Portal API keys
* Exact domain format details for deployed instances
* How version values are generated beyond noting git describe or a related file
* Operational guidance for interpreting version compatibility or upgrade status

---

---
url: >-
  /knowledgebase-agent-guides/workspace/the-task-panel/view-and-complete-tasks/index.agent.md
---
# Agent guide: View and Complete Tasks

* **Page path:** `workspace/the-task-panel/view-and-complete-tasks/index.md`
* **Page type:** explanation

## What this page is about

This page appears intended to explain how to view and complete tasks in the task panel, but the provided body text contains only placeholder text and a classification label.

## User intent

* Understand how to view tasks
* Learn how to complete tasks in the task panel

## Key terms

* task panel
* tasks
* view tasks
* complete tasks
* Autologyx Classification: Unrestricted, Public

## Terminology links

* [Task Panel](/knowledgebase/terminology/#task-panel)
* [Tasks](/knowledgebase/terminology/#tasks)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the workspace and task panel

## Not covered

* Actual steps for viewing tasks
* Actual steps for completing tasks
* Task states, actions, or workflow details
* Any UI descriptions beyond the page title

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.9/viewer-panel/index.agent.md
---
# Agent guide: Viewer panel

* **Page path:** `release-notes/release-notes-1.9/viewer-panel/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces the new Viewer panel for streamlining document review within the product. It explains where the panel opens, what document actions changed, and the main viewing features available.

## User intent

* Understand what the new Viewer panel does
* Learn where the Viewer panel opens in the workflow
* Find available document viewing features like thumbnails, pagination, zoom, search, fit to width, print, and download
* See where document actions such as delete or download are now located
* Assess whether the Viewer panel helps with high-volume document review tasks

## Key terms

* Viewer panel
* saved document
* Card view
* editing records
* Task completion pages
* document actions
* action menu
* thumbnail view
* pagination
* zoom in and out
* search
* fit to width
* print
* download

## Terminology links

* [Viewer panel](/knowledgebase/terminology/#viewer-panel)
* [saved document](/knowledgebase/terminology/#saved-document)
* [Card view](/knowledgebase/terminology/#card-view)
* [editing records](/knowledgebase/terminology/#editing-records)
* [Task completion pages](/knowledgebase/terminology/#task-completion-pages)
* [Actions menu](/knowledgebase/terminology/#actions-menu) (matched from `action menu`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with working with saved documents in the product
* Awareness of Card view, record editing, and Task completion pages
* General understanding of document upload/view workflows

## Not covered

* Detailed step-by-step usage instructions
* Configuration or admin setup for the Viewer panel
* Technical implementation details
* Limitations, supported file types, or browser compatibility
* Any topics beyond this release-note summary

---

---
url: >-
  /knowledgebase-agent-guides/using-help-and-support/we're-here-to-help/index.agent.md
---
# Agent guide: We'Re Here To Help

* **Page path:** `using-help-and-support/we're-here-to-help/index.md`
* **Page type:** explanation

## What this page is about

This page is a simple support hub that directs users to help-related sections. It points to topics about creating a support ticket, understanding service levels and escalation, and knowing what to expect after submitting a ticket.

## User intent

* Find where to create a support ticket
* Learn about service levels and escalation
* Understand what happens after submitting a support ticket
* Navigate to support-related help sections

## Key terms

* support ticket
* service levels
* escalation
* submit a support ticket
* support

## Terminology links

* [Support Ticket](/knowledgebase/terminology/#support-ticket)
* [Service Levels And Escalation](/knowledgebase/terminology/#service-levels-and-escalation) (matched from `service levels`)

## Related topics

* Creating A Support Ticket
* Service Levels And Escalation
* What To Expect When You Submit A Support Ticket

## Prerequisites

* No specific prior knowledge is stated

## Not covered

* Detailed instructions for creating a support ticket
* Specific service level definitions or escalation rules
* The actual support process details after ticket submission
* Any troubleshooting or product-specific guidance

---

---
url: /knowledgebase-agent-guides/administration/web-sockets/index.agent.md
---
# Agent guide: Web Sockets

* **Page path:** `administration/web-sockets/index.md`
* **Page type:** explanation

## What this page is about

This page is intended to cover Web Sockets, but it is currently empty or under construction.

## User intent

* Check whether documentation about Web Sockets exists on this page
* Determine if any guidance or explanation is currently available

## Key terms

* Web Sockets

## Terminology links

* [Web Sockets](/knowledgebase/terminology/#web-sockets)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Any explanation of Web Sockets
* Configuration, setup, or administration details
* Usage examples, troubleshooting, or implementation guidance

---

---
url: >-
  /knowledgebase-agent-guides/release-notes/release-notes-1.11/websockets/index.agent.md
---
# Agent guide: WebSockets

* **Page path:** `release-notes/release-notes-1.11/websockets/index.md`
* **Page type:** release-notes

## What this page is about

This release note introduces WebSockets in Catalyst for real-time updates to Object Records. It explains the basic connection flow, authentication via a one-time UUID token, event types delivered, environment scoping, and performance limits.

## User intent

* Understand what the WebSockets feature in Catalyst does
* Learn how real-time Object Record updates are delivered
* See how to authenticate before opening a WebSocket connection
* Identify which record events are streamed to clients
* Check connection and event throughput limits
* Assess the release impact for Catalyst Elements and real-time UI behavior

## Key terms

* WebSockets
* Catalyst
* real-time updates
* Object Records
* persistent connection
* authentication token
* one-time use UUID
* GET request
* event streaming
* record creation
* record updates
* record deletions
* Catalyst Elements
* landing pages
* environment-scoped events
* 100 concurrent connections per client
* 1,000 events per broadcast every 5 seconds

## Terminology links

* [WebSockets](/knowledgebase/terminology/#websockets)
* [Catalyst](/knowledgebase/terminology/#catalyst)
* [Object records](/knowledgebase/terminology/#object-records)
* [authentication token](/knowledgebase/terminology/#authentication-token)
* [record creation](/knowledgebase/terminology/#record-creation)
* [Catalyst Elements](/knowledgebase/terminology/#catalyst-elements)
* [Landing page](/knowledgebase/terminology/#landing-page) (matched from `landing pages`)
* [100 concurrent connections per client](/knowledgebase/terminology/#100-concurrent-connections-per-client)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Catalyst and Object Records
* Familiarity with WebSocket connections
* Basic API usage, including making GET requests
* Awareness of client-server event-driven updates

## Not covered

* Exact endpoint URLs for token generation or WebSocket connection
* Detailed API request/response examples
* Client implementation code for subscribing to events
* Error handling, reconnect logic, or token expiry details
* Configuration steps in Catalyst UI
* Non-Object-Record event types
* Detailed security model beyond environment scoping and one-time token use

---

---
url: /knowledgebase-agent-guides/welcome-introduction-to-catalyst/index.agent.md
---
# Agent guide: Welcome & Introduction to Catalyst

* **Page path:** `welcome-introduction-to-catalyst/index.md`
* **Page type:** getting-started

## What this page is about

An introductory overview of Catalyst, the Autologyx platform for designing, running, and improving complex operational processes. It explains who the documentation is for, what Catalyst helps organisations do, and where different user types should start.

## User intent

* Understand what Catalyst is and why organisations use it
* Identify whether Catalyst fits complex, high-volume, regulated operational work
* Learn what kinds of use cases Catalyst supports
* Find the right documentation starting point as an end user, admin, super admin, developer, or integrator
* Get a high-level view of core platform capabilities such as workflows, data, tasks, forms, documents, integrations, and AI-enabled features
* Understand how the documentation is organised between knowledgebase and API/reference material

## Key terms

* Catalyst
* Autologyx platform
* workflow orchestration
* structured data
* tasks
* forms
* document automation
* integrations
* AI enabled capabilities
* Object classes
* Object Records
* Task templates
* Task Group Templates
* Sequences
* Sequencer
* Document Templates
* merge fields
* Authentication Objects
* Catalyst API
* Event History API
* WebSockets
* system configuration
* administration
* capacity and system limits
* auditability
* operational visibility

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst)
* [Tasks](/knowledgebase/terminology/#tasks)
* [Forms tab](/knowledgebase/terminology/#forms-tab) (matched from `forms`)
* [Document Automation](/knowledgebase/terminology/#document-automation)
* [Integrations](/knowledgebase/terminology/#integrations)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [Object records](/knowledgebase/terminology/#object-records)
* [Task templates](/knowledgebase/terminology/#task-templates)

## Related topics

* Not provided.

## Prerequisites

* No specific prior knowledge is assumed
* Basic understanding of organisational processes, workflows, or operational systems may help
* Technical familiarity is only needed if the reader is approaching developer or integration topics

## Not covered

* Step-by-step instructions for using Catalyst features
* Detailed configuration procedures for admins or super admins
* API endpoint specifics or implementation details
* Technical standards, limits, or capacity planning details
* Deep guidance on integrations, WebSockets, or Event History API behaviour
* Detailed use-case implementation examples

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/landing-page/welcome-and-introduction-to-catalyst/index.agent.md
---
# Agent guide: Welcome and introduction to Catalyst

* **Page path:** `system-configuration/landing-page/welcome-and-introduction-to-catalyst/index.md`
* **Page type:** getting-started

## What this page is about

A brief landing page that welcomes users to Catalyst and points them to help content. It references an article about the UI and navigation but contains no substantive product guidance itself.

## User intent

* Understand what the Catalyst landing page is for
* Find introductory help resources
* Locate information about the UI and navigation

## Key terms

* Catalyst
* Landing page
* Help
* UI and navigation
* Autologyx Classification: Unrestricted, Public

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst)
* [Landing page](/knowledgebase/terminology/#landing-page)
* [UI and Navigation](/knowledgebase/terminology/#ui-and-navigation)

## Related topics

* UI and navigation

## Prerequisites

* None explicit.

## Not covered

* Detailed explanation of Catalyst features
* Step-by-step setup or configuration
* Actual UI and navigation guidance
* Workflows, permissions, or system configuration details

---

---
url: >-
  /knowledgebase-agent-guides/welcome-introduction-to-catalyst/in-application-help/welcome-to-in-application-help/index.agent.md
---
# Agent guide: Welcome to in-application help

* **Page path:** `welcome-introduction-to-catalyst/in-application-help/welcome-to-in-application-help/index.md`
* **Page type:** getting-started

## What this page is about

This page is a brief introduction to the in-application help for Autologyx Catalyst, the operations platform for legal and compliance. It explains where to find getting-started information, the wider Zendesk knowledgebase, and additional support options.

## User intent

* Understand what the in-application help is for
* Find where to get started with Catalyst help content
* Locate the full Catalyst knowledgebase via Zendesk
* Know where to get further help with process design, configuration, and testing
* Understand that the current page is being viewed from the Landing page

## Key terms

* in-application help
* Autologyx Catalyst
* operations platform
* legal & compliance
* Zendesk knowledgebase
* Landing page
* customer success team
* process design
* configuration
* testing

## Terminology links

* [Catalyst](/knowledgebase/terminology/#catalyst) (matched from `Autologyx Catalyst`)
* [Landing page](/knowledgebase/terminology/#landing-page)
* [customer success team](/knowledgebase/terminology/#customer-success-team)

## Related topics

* Not provided.

## Prerequisites

* No specific prior knowledge is stated

## Not covered

* Detailed product features or workflows
* Specific instructions for process design, configuration, or testing
* End-user training content itself
* Detailed explanation of Landing page configuration

---

---
url: >-
  /knowledgebase-agent-guides/administration/elements/what-are-elements-and-what-can-you-do-with-them/index.agent.md
---
# Agent guide: What are Elements and what can you do with them?

* **Page path:** `administration/elements/what-are-elements-and-what-can-you-do-with-them/index.md`
* **Page type:** faq

## What this page is about

This page explains what Elements are in Catalyst, where they can be used, how they are hosted, and how administrators can access and manage them. It also outlines list page fields, installation statuses, and key usage limits.

## User intent

* Understand what Elements are in Catalyst
* Learn what Elements can be used for
* See where Elements can be embedded in the application
* Understand how Elements are hosted and secured
* Find who can access Elements administration
* Review the Elements list page columns and statuses
* Learn limits and naming considerations for Elements

## Key terms

* Elements
* Catalyst system
* custom components
* Git repository
* landing page
* object classes
* create/edit view
* summary view
* standalone forms
* IFRAME
* pub/sub mechanism
* event listener
* logged in user auth tokens
* record ID
* Administration
* Super admin
* Publisher
* Enabled
* Status
* Processing
* Installed
* Failed

## Terminology links

* [Elements](/knowledgebase/terminology/#elements)
* [Catalyst system](/knowledgebase/terminology/#catalyst-system)
* [Git repository](/knowledgebase/terminology/#git-repository)
* [Landing page](/knowledgebase/terminology/#landing-page)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [create/edit view](/knowledgebase/terminology/#createedit-view)
* [summary view](/knowledgebase/terminology/#summary-view)
* [standalone forms](/knowledgebase/terminology/#standalone-forms)

## Related topics

* creating Elements

## Prerequisites

* Basic familiarity with Catalyst
* Understanding that Elements are created by developers
* Access to a Super admin account to manage Elements

## Not covered

* Detailed steps for creating Elements
* Technical implementation details for coding Elements
* Full configuration file specification
* Detailed integration with third party applications
* How the pub/sub mechanism is implemented
* Future disable action behavior beyond noting it will follow shortly

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/what-are-object-classes/index.agent.md
---
# Agent guide: What are Object Classes?

* **Page path:** `system-configuration/object-classes/what-are-object-classes/index.md`
* **Page type:** faq

## What this page is about

This page explains what Object Classes are, how they function like database tables for grouping same-type records, and how they are used with Sequencer processes, update-object-record tasks, and task group templates. It also summarizes visibility, permissions, list features, usage details, and system limits for Object Classes.

## User intent

* Understand what an Object Class is
* Learn how Object Classes are used to store records of the same type
* See how Object Classes relate to Sequencer processes
* Understand how Object Classes are used with "Update object record" tasks and task group templates
* Find out who can see Object Classes in System Configuration
* Understand how Object Class permissions affect visibility and access
* Learn what information appears in the Object Classes list
* See what the "View usage" action shows for an Object Class
* Check system limits for number of Object Classes, fields, and records

## Key terms

* Object Classes
* records
* database table
* Sequencer
* Update object record
* Task group templates
* Role
* Object class permissions
* Permission sets
* Object records
* Tasks
* System Configuration
* Object classes list
* Owners
* Records
* Actions menu
* View usage
* Sequences
* Super admin

## Terminology links

* [Object classes](/knowledgebase/terminology/#object-classes)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `records`)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Update object records](/knowledgebase/terminology/#update-object-records) (matched from `Update object record`)
* [Task Group Templates](/knowledgebase/terminology/#task-group-templates)
* [Roles](/knowledgebase/terminology/#roles) (matched from `Role`)
* [object class permissions](/knowledgebase/terminology/#object-class-permissions)
* [Permission Sets](/knowledgebase/terminology/#permission-sets)

## Related topics

* editing object class permissions
* list page features

## Prerequisites

* Basic understanding of users, roles, and permissions
* Familiarity with System Configuration navigation
* Basic awareness of tasks, records, and sequences in the platform

## Not covered

* Step-by-step instructions for creating or editing an Object Class
* Detailed configuration of fields within an Object Class
* Detailed instructions for creating Permission sets
* Detailed explanation of editing object class permissions
* Detailed explanation of list page features
* How to create Sequences or Task group templates

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/task-group-templates/what-are-task-group-templates/index.agent.md
---
# Agent guide: What are task group templates?

* **Page path:** `system-configuration/task-group-templates/what-are-task-group-templates/index.md`
* **Page type:** faq

## What this page is about

Explains what task group templates are, what they are used for, who can access the task group template list, and the main list columns and limits. It also notes where templates are created/edited and a key restriction on which tasks can be included.

## User intent

* Understand the purpose of task group templates
* Learn how task group templates are used in Sequences and reporting
* Find where task group templates are created and edited
* Check who can view or manage the Task group templates list
* See the default columns shown in the list
* Know system limits and restrictions for task group templates

## Key terms

* Task group templates
* Tasks
* Sequence
* Object record
* Reporting
* Task group template list
* Super Admin
* Role permissions
* Task configuration tab
* Create
* Edit
* ID
* Name
* # Of Task Templates
* Created
* Actions
* Object Classes
* Task creation mechanism Automatic

## Terminology links

* [Task Group Templates](/knowledgebase/terminology/#task-group-templates)
* [Tasks](/knowledgebase/terminology/#tasks)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequence`)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `Object record`)
* [reporting](/knowledgebase/terminology/#reporting)
* [Task group template list](/knowledgebase/terminology/#task-group-template-list)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super Admin`)
* [Roles and Permissions](/knowledgebase/terminology/#roles-and-permissions) (matched from `Role permissions`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Tasks
* Basic understanding of Sequences
* Basic understanding of Object records
* Awareness of user roles and system permissions

## Not covered

* How to create a task group template step by step
* How to edit or delete a template in detail
* How reporting determines completion in practice
* Details of list features beyond a reference to general list behavior
* How Object Classes are configured
* Any task creation mechanisms other than the note that only Automatic tasks can be added

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/task-templates/what-are-task-templates/index.agent.md
---
# Agent guide: What are Task templates?

* **Page path:** `system-configuration/task-templates/what-are-task-templates/index.md`
* **Page type:** faq

## What this page is about

This page explains what Task templates are, what they control when creating Tasks for Object records, and what information appears in the Task templates list. It also states who can view the list and summarizes key columns and limits.

## User intent

* Understand the purpose of a Task template
* Learn what aspects of a Task are defined by a template
* Find where Task templates can be created and edited
* Know who can access the Task templates list
* Understand the default and optional columns in the Task templates list
* Distinguish Task template IDs from Task IDs
* Understand the two Task types available
* Know the system limit for number of Task templates

## Key terms

* Task template
* Task
* Object record
* Task templates list
* Super Admin
* Role permissions
* Task configuration tab
* ID
* Task ID
* Name
* Task creation mechanism
* Manual Task
* Sequence
* Task type
* Self contained form
* Update object record
* Object class
* Description
* Actions
* Edit
* # Tasks created
* Last task created

## Terminology links

* [Task templates](/knowledgebase/terminology/#task-templates) (matched from `Task template`)
* [Tasks](/knowledgebase/terminology/#tasks) (matched from `Task`)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `Object record`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super Admin`)
* [Roles and Permissions](/knowledgebase/terminology/#roles-and-permissions) (matched from `Role permissions`)
* [Task configuration tab](/knowledgebase/terminology/#task-configuration-tab)
* [Identifier](/knowledgebase/terminology/#identifier) (matched from `ID`)
* [Task ID](/knowledgebase/terminology/#task-id)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Tasks and Object records in the system
* Awareness of user roles and system permissions

## Not covered

* Step-by-step instructions for creating or editing a Task template
* Detailed explanation of list features beyond noting they are standard
* Detailed information behind the referenced HERE links
* Configuration details for Sequences or manual task creation workflows
* Full edit behavior for template elements

---

---
url: >-
  /knowledgebase-agent-guides/administration/all-about-users/what-can-i-edit-in-a-user-account/index.agent.md
---
# Agent guide: What can I edit in a user account?

* **Page path:** `administration/all-about-users/what-can-i-edit-in-a-user-account/index.md`
* **Page type:** faq

## What this page is about

Explains what fields and settings can be edited in a user account and the rules that apply. It covers who can edit users, editable account types, username, status, roles, and personal information.

## User intent

* Find out who is allowed to edit user accounts
* Change a user's account type
* Understand which account type conversions are allowed or blocked
* Update a user's username/email address
* Understand how activation email choices affect account status
* Check what account statuses mean
* Manage roles for Config admin users
* Update a user's personal information
* Understand what users can edit themselves in My Account
* Know whether passwords can be changed from the Edit user page

## Key terms

* Super admin
* Edit user page
* User account type
* Internal
* External
* Config admin
* Super admin account type
* 1 time completion
* Activation email
* Status
* Created
* Pending
* Active
* Username
* Password reset
* My Account
* Roles
* Permissions
* Personal Information
* Single sign on

## Terminology links

* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Edit user page](/knowledgebase/terminology/#edit-user-page)
* [User Account Types](/knowledgebase/terminology/#user-account-types) (matched from `User account type`)
* [Internal account type](/knowledgebase/terminology/#internal-account-type) (matched from `Internal`)
* [External account type](/knowledgebase/terminology/#external-account-type) (matched from `External`)
* [Config admin account type](/knowledgebase/terminology/#config-admin-account-type) (matched from `Config admin`)
* [1 time completion account type](/knowledgebase/terminology/#1-time-completion-account-type) (matched from `1 time completion`)
* [activation email](/knowledgebase/terminology/#activation-email)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of user accounts and account types
* Access as a Super admin to edit other users
* Familiarity with the Users list and Edit action

## Not covered

* How to create or delete user accounts
* Detailed instructions for password reset from the login page
* Detailed explanation of user roles beyond a brief reference
* Any workflow outside the Edit user page and My Account except activation email behavior
* How single sign on is configured

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/object-classes/what-can-i-edit-in-an-object-class/index.agent.md
---
# Agent guide: What can I edit in an Object class?

* **Page path:** `system-configuration/object-classes/what-can-i-edit-in-an-object-class/index.md`
* **Page type:** faq

## What this page is about

Explains what parts of an Object class can be edited, which changes are allowed, and who is permitted to edit an Object class. It also notes that edits take effect immediately and outlines the available configuration tabs.

## User intent

* Understand which fields of an Object class can be changed after creation
* Learn what can be configured in each edit tab of an Object class
* Find out who is allowed to edit an Object class
* Check whether Object class name and description can be amended
* Understand form, display, document template, field, and permission editing options

## Key terms

* Object class
* Object class Name
* description
* Fields
* Display
* Forms
* Document Templates
* Permissions
* permission set
* Super admin
* Role
* owner
* Create record permission
* standalone form
* record
* task

## Terminology links

* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object class`)
* [Object Class name](/knowledgebase/terminology/#object-class-name)
* [Description](/knowledgebase/terminology/#description)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `Fields`)
* [Display tab](/knowledgebase/terminology/#display-tab) (matched from `Display`)
* [Forms tab](/knowledgebase/terminology/#forms-tab) (matched from `Forms`)
* [Document Templates](/knowledgebase/terminology/#document-templates)
* [Class permissions](/knowledgebase/terminology/#class-permissions) (matched from `Permissions`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of what an Object class is
* Familiarity with records, fields, forms, and permission sets in the system
* Awareness of user roles and account types

## Not covered

* Step-by-step instructions for editing fields, forms, document templates, or permissions
* Detailed explanation of field types and attributes
* Full guidance on creating standalone forms
* Detailed document template creation and usage instructions
* Broader Object class creation process beyond editable elements and permissions

---

---
url: >-
  /knowledgebase-agent-guides/finding-your-way-around/my-account/what-can-i-edit-in-my-account-and-what-effect-will-this-have/index.agent.md
---
# Agent guide: What can I edit in My account and what effect will this have?

* **Page path:** `finding-your-way-around/my-account/what-can-i-edit-in-my-account-and-what-effect-will-this-have/index.md`
* **Page type:** faq

## What this page is about

This page explains which settings can be edited in the My account page and what happens after saving them. It covers the effects of changing Username and Row density.

## User intent

* Understand what fields can be edited in My account
* Learn what happens when a Username is changed
* Find out whether changing Username affects login or activation emails
* Understand how Row density settings affect list pages
* See the available Row density options and their sizes

## Key terms

* My account
* Username
* user account page
* activation email
* token
* active account
* standard admin
* super admin
* Row density
* list pages
* Comfortable
* Default
* Compact
* row height
* header height
* preview

## Terminology links

* [My account](/knowledgebase/terminology/#my-account)
* [Username](/knowledgebase/terminology/#username)
* [user account page](/knowledgebase/terminology/#user-account-page)
* [activation email](/knowledgebase/terminology/#activation-email)
* [Tokens](/knowledgebase/terminology/#tokens) (matched from `token`)
* [account Status](/knowledgebase/terminology/#account-status) (matched from `active account`)
* [standard admin](/knowledgebase/terminology/#standard-admin)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `super admin`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the My account page
* Understanding of user accounts and login usernames
* Awareness that list pages have configurable display density

## Not covered

* How to access the My account page
* How to activate an account
* How activation emails are delivered or managed beyond the automatic resend
* Any editable My account fields other than Username and Row density
* Troubleshooting save failures or login issues
* Permissions or restrictions for who can edit these settings

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequences-for-relational-records/what-can-you-do-with-relational-records-in-a-sequence/index.agent.md
---
# Agent guide: What can you do with relational records in a sequence?

* **Page path:** `system-configuration/sequences-for-relational-records/what-can-you-do-with-relational-records-in-a-sequence/index.md`
* **Page type:** faq

## What this page is about

This FAQ explains extra sequence features available when the object class in a sequence participates in parent/child relationships. It focuses on using Relation Lookup and Sequence Runner to find related records and act on them or trigger sub-process sequences.

## User intent

* Understand what relational records can do in a sequence
* Find parent or child records from within a sequence
* Use Relation Lookup to identify related records matching conditions
* Use Sequence Runner with Relation Lookup to perform actions on identified related records
* Run another sequence as a sub-process on the same object class
* Understand traversal limits for relational lookups in the relational model
* Know whether multiple Relation Lookup and Sequence Runner actors can be used in one sequence

## Key terms

* relational records
* sequence
* object class
* parent object class
* child object class
* Relation Lookup actor
* Sequence Runner actor
* associated parent records
* associated child records
* conditions
* assigning a task
* updating a field
* sub process
* relational model

## Terminology links

* [relational records](/knowledgebase/terminology/#relational-records)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `sequence`)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `object class`)
* [Relation Lookup](/knowledgebase/terminology/#relation-lookup) (matched from `Relation Lookup actor`)
* [Sequence Runner](/knowledgebase/terminology/#sequence-runner) (matched from `Sequence Runner actor`)
* [parent records](/knowledgebase/terminology/#parent-records) (matched from `associated parent records`)
* [child records](/knowledgebase/terminology/#child-records) (matched from `associated child records`)
* [Filter conditions](/knowledgebase/terminology/#filter-conditions) (matched from `conditions`)

## Related topics

* step by step guide on configuration and use of these actors

## Prerequisites

* Basic understanding of sequences
* Familiarity with object classes and parent/child relationships in the relational model
* Awareness of sequence actors

## Not covered

* Detailed configuration steps for Relation Lookup or Sequence Runner
* General sequence concepts beyond relational-record features
* Traversal beyond one level up or down in the relational model
* Anything outside acting on related records or running sub-process sequences

---

---
url: >-
  /knowledgebase-agent-guides/administration/user-groups/what-do-i-need-to-know-about-creating-a-user-group/index.agent.md
---
# Agent guide: What do I need to know about creating a user group?

* **Page path:** `administration/user-groups/what-do-i-need-to-know-about-creating-a-user-group/index.md`
* **Page type:** faq

## What this page is about

This page explains the permissions required to create a user group and the basic process for creating it, naming it, saving it, and optionally adding members. It also lists key limits and behaviors for membership, owners, and bulk actions.

## User intent

* Find out who is allowed to create a user group
* Learn where to create a new user group
* Understand what information is required when creating a group
* Know what happens after saving a new user group
* Add members immediately or later
* Understand how to add members individually or in bulk
* See group ownership and membership limits

## Key terms

* User group
* Super admin
* Config Admin
* Create permission
* User Groups
* System permissions
* Administration tab
* * Create button
* unique name
* description
* Membership tab
* Permissions tab
* Owner
* Members
* Non members
* Actions menu
* Add as member
* Add as owner
* bulk add
* success toast

## Terminology links

* [User Groups](/knowledgebase/terminology/#user-groups) (matched from `User group`)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Config admin account type](/knowledgebase/terminology/#config-admin-account-type) (matched from `Config Admin`)
* [Create permission under User Groups](/knowledgebase/terminology/#create-permission-under-user-groups) (matched from `Create permission`)
* [System permissions](/knowledgebase/terminology/#system-permissions)
* [Administration tab of System permissions](/knowledgebase/terminology/#administration-tab-of-system-permissions) (matched from `Administration tab`)
* [+ Create button](/knowledgebase/terminology/#create-button)
* [Description](/knowledgebase/terminology/#description)

## Related topics

* Not provided.

## Prerequisites

* Access to the User group list
* A Super admin account type, or a Config Admin account type with the User Groups Create permission enabled under Administration > System permissions
* Basic familiarity with users in the system

## Not covered

* Detailed handling of making another member an Owner
* Detailed handling of removing users from a group
* Any broader explanation of user group permissions configuration beyond the required Create permission
* Management of topics said to be covered in a separate article

---

---
url: >-
  /knowledgebase-agent-guides/getting-started/building-applications-analysts/what-goes-into-a-typical-application/index.agent.md
---
# Agent guide: What goes into a typical application?

* **Page path:** `getting-started/building-applications-analysts/what-goes-into-a-typical-application/index.md`
* **Page type:** faq

## What this page is about

This FAQ outlines the main components to consider before building a first process in Catalyst. It emphasizes defining required outcomes and planning data, integrations, people, permissions, communications, and documents.

## User intent

* Understand what elements make up a typical Catalyst application
* Identify what to plan before building a first process
* Learn which setup areas are important for application design
* Determine how outcomes, data, users, communications, and documents fit together

## Key terms

* required outcomes
* data model
* Object Classes
* reporting requirements
* task forms
* task templates
* sequences
* integrations
* API
* Client Value team
* people and permissions
* User roles
* role permissions
* User groups
* communication
* Outbound mail setup
* documents
* stand alone forms
* DocAuto actor
* Document templates

## Terminology links

* [required outcomes](/knowledgebase/terminology/#required-outcomes)
* [Catalyst data model](/knowledgebase/terminology/#catalyst-data-model) (matched from `data model`)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [task forms](/knowledgebase/terminology/#task-forms)
* [Task templates](/knowledgebase/terminology/#task-templates)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `sequences`)
* [Integrations](/knowledgebase/terminology/#integrations)
* [API](/knowledgebase/terminology/#api)

## Related topics

* checklist for things to set up once only and for each application

## Prerequisites

* Basic familiarity with Catalyst as a platform for building processes
* Awareness that applications involve workflows, data capture, users, and documents

## Not covered

* Step-by-step instructions for configuring any component
* Detailed explanation of the Catalyst data model
* How to create task templates or sequences in detail
* API implementation details
* Detailed role and permission configuration
* Outbound mail configuration steps
* Document automation setup details

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-change-the-properties-of-a-field-used-in-conditional-logic/index.agent.md
---
# Agent guide: What happens if I change the properties of a field used in conditional logic?

* **Page path:** `record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-change-the-properties-of-a-field-used-in-conditional-logic/index.md`
* **Page type:** faq

## What this page is about

This FAQ explains what happens when you change validation or options on a field that is already used in conditional logic. It describes how impossible conditions are flagged and how to fix affected sections.

## User intent

* Understand why a conditional logic section is highlighted in red after changing a field
* Learn what happens if numeric field validation makes an existing condition impossible
* Learn what happens if a single-select or multi-select option used in a condition is changed or removed
* Find ways to restore or fix invalid conditional visibility rules
* Know best practices for fields that control conditional logic

## Key terms

* conditional logic
* conditional visibility
* numeric field
* validation
* minimum allowed value
* single select field
* multi select field
* option removed
* option amended
* Edit condition modal
* highlighted in red
* Required field
* standalone field
* Task template

## Terminology links

* [conditional logic](/knowledgebase/terminology/#conditional-logic)
* [Conditional Visibility](/knowledgebase/terminology/#conditional-visibility)
* [Numeric field](/knowledgebase/terminology/#numeric-field)
* [Validation section](/knowledgebase/terminology/#validation-section) (matched from `validation`)
* [Single select fields](/knowledgebase/terminology/#single-select-fields) (matched from `single select field`)
* [Multi select field type](/knowledgebase/terminology/#multi-select-field-type) (matched from `multi select field`)
* [Edit condition modal](/knowledgebase/terminology/#edit-condition-modal)
* [Required](/knowledgebase/terminology/#required) (matched from `Required field`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of forms or Task templates
* Familiarity with fields, sections, and conditional logic setup

## Not covered

* Step-by-step instructions for creating conditional logic from scratch
* Detailed configuration of every field type beyond numeric, single select, and multi select
* Broader form design guidance outside fixing invalid conditions

---

---
url: >-
  /knowledgebase-agent-guides/administration/roles-and-permissions/what-happens-if-i-edit-a-role/index.agent.md
---
# Agent guide: What happens if I edit a role?

* **Page path:** `administration/roles-and-permissions/what-happens-if-i-edit-a-role/index.md`
* **Page type:** faq

## What this page is about

Explains what changes take effect when an existing role is edited, especially how removing Create, Edit, or Delete permissions immediately changes what users can see and do. It also notes who can edit roles and the maximum number of roles allowed.

## User intent

* Understand the impact of editing a role
* Check what happens when Create permission is removed
* Check what happens when Edit permission is removed
* Check what happens when Delete permission is removed
* Understand whether permission changes apply immediately
* Confirm who is allowed to create or edit users and roles
* Find the maximum number of roles supported

## Key terms

* role
* permissions
* Create permission
* Edit permission
* Delete permission
* Super admin
* Roles list
* Actions menu
* list page
* * Create button
* left hand menu
* Access denied
* Object classes
* Permission set

## Terminology links

* [Roles](/knowledgebase/terminology/#roles) (matched from `role`)
* [Class permissions](/knowledgebase/terminology/#class-permissions) (matched from `permissions`)
* [Create permission under User Groups](/knowledgebase/terminology/#create-permission-under-user-groups) (matched from `Create permission`)
* [Edit permission for Single sign on](/knowledgebase/terminology/#edit-permission-for-single-sign-on) (matched from `Edit permission`)
* [Delete permission](/knowledgebase/terminology/#delete-permission)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super admin`)
* [Actions menu](/knowledgebase/terminology/#actions-menu)
* [list pages](/knowledgebase/terminology/#list-pages) (matched from `list page`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of roles and permissions
* Awareness of the Roles list and Actions menu in administration
* Knowing that only Super admin users can create and edit users and roles

## Not covered

* How to create a new role
* How to assign roles to users
* Detailed definitions of each permission beyond the described outcomes
* How permission sets are configured for Object classes
* Any workflow for reverting or auditing role changes

---

---
url: >-
  /knowledgebase-agent-guides/administration/authentication-objects/what-happens-if-i-edit-an-authentication-object/index.agent.md
---
# Agent guide: What happens if I edit an Authentication object?

* **Page path:** `administration/authentication-objects/what-happens-if-i-edit-an-authentication-object/index.md`
* **Page type:** faq

## What this page is about

This page explains what occurs when you edit an Authentication object and how updates to stored credentials affect all system areas that reference that object. It also notes restrictions during editing and a token refresh delay for Autologyx internal authentication objects.

## User intent

* Understand the impact of changing credentials in an Authentication object
* Learn how to update an existing Authentication object
* Check which fields can and cannot be edited
* Know who can access Authentication object editing
* Understand why updated internal authentication credentials may not take effect immediately

## Key terms

* Authentication object
* credentials
* provider field
* Actions menu
* Super Admin
* Config Admin
* role permissions
* Autologyx internal authentication object
* tokens
* token refresh
* sequencer

## Terminology links

* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `Authentication object`)
* [Provider field](/knowledgebase/terminology/#provider-field)
* [Actions menu](/knowledgebase/terminology/#actions-menu)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super Admin`)
* [Config admin account type](/knowledgebase/terminology/#config-admin-account-type) (matched from `Config Admin`)
* [Roles and Permissions](/knowledgebase/terminology/#roles-and-permissions) (matched from `role permissions`)
* [Autologyx internal authentication object](/knowledgebase/terminology/#autologyx-internal-authentication-object)
* [Tokens](/knowledgebase/terminology/#tokens)

## Related topics

* Not provided.

## Prerequisites

* Access to the Authentication objects list
* Appropriate role permissions such as Super Admin or Config Admin access
* Basic understanding of where the Authentication object is used in the system

## Not covered

* How to create or delete an Authentication object
* How Authentication objects are initially configured
* Detailed explanation of providers or provider-specific settings
* How to force immediate token refresh
* Broader authentication architecture or security model

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-remove-a-column-that-has-a-field-which-is-used-in-conditional-logic/index.agent.md
---
# Agent guide: What happens if I remove a column that has a field which is used in conditional logic?

* **Page path:** `record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-remove-a-column-that-has-a-field-which-is-used-in-conditional-logic/index.md`
* **Page type:** faq

## What this page is about

This FAQ explains what happens when you remove a form column that contains a field used in conditional logic. It describes the warnings shown and the result of deleting that column and its related logic.

## User intent

* Understand the impact of removing a column that contains a conditional-logic field
* Know what on-screen messages appear when reducing the number of columns
* Decide whether to cancel or proceed with removing a column tied to conditional sections
* Learn whether related conditional logic is deleted along with the column

## Key terms

* column
* field
* conditional logic
* conditional logic icon
* section
* conditionally displayed sections
* Remove
* Cancel

## Terminology links

* [columns](/knowledgebase/terminology/#columns) (matched from `column`)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `field`)
* [conditional logic](/knowledgebase/terminology/#conditional-logic)
* [conditional logic icon](/knowledgebase/terminology/#conditional-logic-icon)
* [Workspace Sections](/knowledgebase/terminology/#workspace-sections) (matched from `section`)
* [conditionally displayed sections](/knowledgebase/terminology/#conditionally-displayed-sections)
* [Remove](/knowledgebase/terminology/#remove)
* [Cancel](/knowledgebase/terminology/#cancel)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with record and task forms
* Understanding that fields can control whether sections are shown or hidden
* Awareness of form layouts with multiple columns

## Not covered

* How to create or configure conditional logic
* How to restore deleted columns or conditional logic
* Other effects of changing form layout beyond column removal
* Detailed steps for editing forms outside this specific removal scenario

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-remove-a-field-which-controls-conditional-logic-in-a-form/index.agent.md
---
# Agent guide: What happens if I remove a field which controls conditional logic in a form?

* **Page path:** `record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-remove-a-field-which-controls-conditional-logic-in-a-form/index.md`
* **Page type:** faq

## What this page is about

This page explains what occurs when you attempt to remove a form field that is used to control conditional logic. It describes the warning shown and the choice to keep the field or delete both the field and its associated conditions.

## User intent

* Understand the impact of deleting a field used in conditional logic
* Know whether conditional logic is automatically removed with the field
* See what warning message appears before deletion
* Decide whether to cancel or confirm deletion of the field

## Key terms

* conditional logic
* field
* warning message
* conditions being deleted
* conditionally displayed sections
* selection
* input

## Terminology links

* [conditional logic](/knowledgebase/terminology/#conditional-logic)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `field`)
* [on screen warning message](/knowledgebase/terminology/#on-screen-warning-message) (matched from `warning message`)
* [conditionally displayed sections](/knowledgebase/terminology/#conditionally-displayed-sections)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with forms and conditional logic in forms

## Not covered

* How to create or edit conditional logic
* How to restore deleted fields or conditions
* Detailed behavior beyond the warning and confirmation choices
* Other effects of field deletion outside conditional logic

---

---
url: >-
  /knowledgebase-agent-guides/record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-remove-a-section-that-has-a-field-which-is-used-in-conditional-logic/index.agent.md
---
# Agent guide: What happens if I remove a section that has a field which is used in conditional logic?

* **Page path:** `record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-remove-a-section-that-has-a-field-which-is-used-in-conditional-logic/index.md`
* **Page type:** faq

## What this page is about

This FAQ explains what warning appears when you try to remove a section containing a field used in conditional logic, and what happens if you proceed. It states that deleting the section also deletes the related conditional logic tied to that field.

## User intent

* Understand the impact of deleting a section that contains a field referenced by conditional logic
* Know what the on-screen warning message will say
* Decide whether to keep the section or confirm deletion
* See which conditionally displayed sections are affected before deleting

## Key terms

* section
* field
* conditional logic
* on-screen warning message
* conditions
* conditionally displayed sections
* controlling field
* delete section
* retain section

## Terminology links

* [Workspace Sections](/knowledgebase/terminology/#workspace-sections) (matched from `section`)
* [Object class fields](/knowledgebase/terminology/#object-class-fields) (matched from `field`)
* [conditional logic](/knowledgebase/terminology/#conditional-logic)
* [Filter conditions](/knowledgebase/terminology/#filter-conditions) (matched from `conditions`)
* [conditionally displayed sections](/knowledgebase/terminology/#conditionally-displayed-sections)
* [Conditional Logic controlling field](/knowledgebase/terminology/#conditional-logic-controlling-field) (matched from `controlling field`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with forms that use sections and fields
* Awareness that conditional logic can control the display of sections

## Not covered

* How to create or edit conditional logic
* How to restore deleted conditional logic after removal
* Detailed behavior beyond the warning and confirmation choices
* Other effects of deleting sections unrelated to conditional logic

---

---
url: >-
  /knowledgebase-agent-guides/administration/all-about-users/what-happens-when-a-user-clicks-the-forgot-your-password-link-on-the-login-page/index.agent.md
---
# Agent guide: What happens when a user clicks the "Forgot your password?" link on the login page?

* **Page path:** `administration/all-about-users/what-happens-when-a-user-clicks-the-forgot-your-password-link-on-the-login-page/index.md`
* **Page type:** faq

## What this page is about

Explains the password reset flow triggered by the "Forgot your password?" link on the login page for regular Catalyst users. It describes eligibility, the email/reset steps, link validity, and behavior differences when SSO is enabled.

## User intent

* Understand what a user experiences after clicking "Forgot your password?"
* Learn how a regular user resets their Catalyst password
* Check which account types can use password reset
* See what information is included in the password reset email
* Know how long the reset link remains valid
* Understand how password policy and password reuse settings affect reset
* Confirm what happens if SSO is enabled

## Key terms

* Forgot your password?
* regular user
* username
* email address
* password reset email
* unique reset link
* Reset password modal
* password requirements
* Company details page
* Internal Service account
* External Service account
* Standard authentication configuration
* Prevent password re use
* SSO
* workspace

## Terminology links

* [Username](/knowledgebase/terminology/#username)
* [Company details page](/knowledgebase/terminology/#company-details-page)
* [Internal Service account](/knowledgebase/terminology/#internal-service-account)
* [External Service account](/knowledgebase/terminology/#external-service-account)
* [Standard authentication configuration](/knowledgebase/terminology/#standard-authentication-configuration)
* [Prevent password re use](/knowledgebase/terminology/#prevent-password-re-use)
* [Single sign on](/knowledgebase/terminology/#single-sign-on) (matched from `SSO`)
* [Workspace](/knowledgebase/terminology/#workspace)

## Related topics

* Not provided.

## Prerequisites

* User has a valid regular Catalyst account that uses username/email and password authentication
* User knows their username/email address
* Access to the account email inbox

## Not covered

* How administrators configure password policies or standard authentication settings
* How to complete or edit the Company details page
* How SSO authentication is configured
* Password reset behavior for Internal Service or External Service accounts beyond stating they cannot use this flow
* Troubleshooting email delivery or invalid account issues

---

---
url: >-
  /knowledgebase-agent-guides/administration/all-about-users/what-happens-when-an-individual-uses-single-sign-on/index.agent.md
---
# Agent guide: What happens when an individual uses Single sign-on?

* **Page path:** `administration/all-about-users/what-happens-when-an-individual-uses-single-sign-on/index.md`
* **Page type:** faq

## What this page is about

Explains the login behavior when Single sign-on (SSO) is enabled in Autologyx, including what users see on the login page and what happens based on account status. It also describes automatic user creation when the SSO configuration has that feature enabled.

## User intent

* Understand what the login page looks like when SSO is enabled
* Learn what happens when a user selects an SSO provider
* Check how Autologyx handles active, non-active, or missing user accounts during SSO login
* Understand when a user is redirected to the identity provider login page
* Learn how Automatically create user works for users who do not already exist in Autologyx
* See which user fields and roles are set when an account is auto-created via SSO

## Key terms

* Single sign-on
* SSO provider
* Log in page
* Single sign on drop-down
* Email and Password fields
* active user account
* non active account
* Access denied
* Automatically create user
* Account type
* Standard
* First name
* Last name
* Account status
* Activation date
* Roles to assign to created user
* landing page

## Terminology links

* [Single sign on](/knowledgebase/terminology/#single-sign-on) (matched from `Single sign-on`)
* [Single sign on provider](/knowledgebase/terminology/#single-sign-on-provider) (matched from `SSO provider`)
* [account Status](/knowledgebase/terminology/#account-status) (matched from `non active account`)
* [Access denied](/knowledgebase/terminology/#access-denied)
* [Automatically create user](/knowledgebase/terminology/#automatically-create-user)
* [account type](/knowledgebase/terminology/#account-type)
* [Standard account type](/knowledgebase/terminology/#standard-account-type) (matched from `Standard`)
* [activation date](/knowledgebase/terminology/#activation-date)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of Autologyx user accounts
* Awareness that Single sign-on has been enabled and configured
* Understanding of user status concepts such as active and non active

## Not covered

* How to configure Single sign-on itself
* How to enable or disable the Automatically create user feature
* Detailed setup of roles in SSO settings beyond noting that up to 10 can be assigned
* Provider-specific configuration details such as Azure setup steps
* What permissions each role grants in the system

---

---
url: >-
  /knowledgebase-agent-guides/administration/authentication-objects/what-is-an-authentication-object-and-how-do-i-configure-it/index.agent.md
---
# Agent guide: What is an Authentication object and how do I configure it?

* **Page path:** `administration/authentication-objects/what-is-an-authentication-object-and-how-do-i-configure-it/index.md`
* **Page type:** faq

## What this page is about

This page explains what an Authentication object is in Autologyx and how to create and validate one for supported third-party providers. It covers purpose, supported providers, required inputs, limits, and save/test behavior.

## User intent

* Understand what an Authentication object is used for
* See which providers are supported
* Create a new Authentication object in Administration
* Know what information and permissions are required before configuration
* Learn how expiry dates and reminders can be set
* Understand validation, testing, and when Save/Test buttons are enabled or disabled
* Know system limits such as the maximum number of Authentication objects

## Key terms

* Authentication object
* API Actors
* third party systems
* fresh tokens
* one way encryption
* API Calls
* providers
* Autologyx internal
* DocuSign API Key
* Adobe oAuth 2.0 (Client Credentials flow)
* Box oAuth 2.0 (Client Credentials flow)
* Generic oAuth 2.0 (Client Credentials flow)
* Generic oAuth 2.0 (ROPC Grant flow)
* iManage oAuth 2.0 (Password Grant flow)
* Administration
* expiry date
* Sequencer
* validation
* Test authentication object

## Terminology links

* [Authentication Objects](/knowledgebase/terminology/#authentication-objects) (matched from `Authentication object`)
* [API Actors](/knowledgebase/terminology/#api-actors)
* [API calls](/knowledgebase/terminology/#api-calls)
* [providers](/knowledgebase/terminology/#providers)
* [Autologyx internal](/knowledgebase/terminology/#autologyx-internal)
* [DocuSign API Key](/knowledgebase/terminology/#docusign-api-key)
* [Adobe oAuth 2.0 (Client Credentials flow)](/knowledgebase/terminology/#adobe-oauth-20-client-credentials-flow)
* [Box oAuth 2.0 (Client Credentials flow)](/knowledgebase/terminology/#box-oauth-20-client-credentials-flow)

## Related topics

* Not provided.

## Prerequisites

* Appropriate role permissions in Autologyx
* Access to the relevant provider's technical information
* Knowledge of which provider and authentication flow is needed

## Not covered

* Detailed setup instructions for each individual provider
* How API Calls or API Actors are configured beyond using the Authentication object
* How Sequencer notifications are configured in detail
* Credential troubleshooting beyond basic validation/test feedback
* Any topics outside Authentication objects

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/relational-modeller/what-is-the-relational-modeller/index.agent.md
---
# Agent guide: What is the Relational modeller?

* **Page path:** `system-configuration/relational-modeller/what-is-the-relational-modeller/index.md`
* **Page type:** faq

## What this page is about

Explains what the Relational modeller is and what it does in Catalyst: creating and visualising parent/child relationships between object classes. It also outlines how those relationships affect create/edit views, access to child data, and document/send message merging, plus key modelling limits.

## User intent

* Understand the purpose of the Relational modeller
* Learn how parent/child object class relationships work
* See how configured relationships expose child object classes on a parent create/edit view
* Understand how parent records can access and merge data from related child records
* Review example relationship structures and cardinalities such as 1:1 and 1:N
* Check system limits and rules for building a relational model

## Key terms

* Relational modeller
* parent/child relationships
* object classes
* root parent
* direct child
* 1:1 ratio
* 1:N ratio
* create/edit view
* related child records
* merge into documents
* send message actors
* relational model
* Catalyst

## Terminology links

* [Relational modeller](/knowledgebase/terminology/#relational-modeller)
* [parent/child relationships](/knowledgebase/terminology/#parentchild-relationships)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [root parent object class](/knowledgebase/terminology/#root-parent-object-class) (matched from `root parent`)
* [direct child](/knowledgebase/terminology/#direct-child)
* [parent:child ratio](/knowledgebase/terminology/#parentchild-ratio) (matched from `1:1 ratio`)
* [1:N](/knowledgebase/terminology/#1n) (matched from `1:N ratio`)
* [create/edit view](/knowledgebase/terminology/#createedit-view)

## Related topics

* Creating your relational model

## Prerequisites

* Basic understanding of object classes and records in Catalyst
* Basic understanding of parent/child data relationships

## Not covered

* Step-by-step instructions for creating the relational model
* Detailed configuration procedure beyond the high-level explanation
* Advanced relationship behaviors beyond the stated limits and examples
* Any topics outside the single-instance relational modeller in Catalyst

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/sequences/what-is-the-sequencer/index.agent.md
---
# Agent guide: What is the Sequencer?

* **Page path:** `system-configuration/sequences/what-is-the-sequencer/index.md`
* **Page type:** faq

## What this page is about

This page explains that the Sequencer is Autologyx's workflow engine used to build and run automated processes. It also outlines who can access it, what it does, and its main features.

## User intent

* Understand what the Sequencer is in Autologyx
* Learn what the Sequencer is used for
* Check whether a user has access to the Sequencer
* See the main capabilities of the Sequencer
* Understand how automated processes can be triggered and routed

## Key terms

* Sequencer
* workflow engine
* automated processes
* Object classes
* Task templates
* sequence actors
* Records
* tasks
* communications
* expiry dates
* reminders
* drag and drop interface
* intelligent pathways
* API call
* third party systems
* Authentication objects
* Actors
* super admin
* config admin
* sequence permissions

## Terminology links

* [Sequencer](/knowledgebase/terminology/#sequencer)
* [workflow engine](/knowledgebase/terminology/#workflow-engine)
* [Object classes](/knowledgebase/terminology/#object-classes)
* [Task templates](/knowledgebase/terminology/#task-templates)
* [Sequence Actors](/knowledgebase/terminology/#sequence-actors)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `Records`)
* [Tasks](/knowledgebase/terminology/#tasks)
* [Communication](/knowledgebase/terminology/#communication) (matched from `communications`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with Autologyx administration concepts
* Awareness of Object classes, Task templates, Records, and Actors
* Appropriate account type and permissions to access the Sequencer

## Not covered

* Step-by-step instructions for building a sequence
* Detailed navigation or configuration guidance
* How to create Object classes, Task templates, or Actors
* Detailed API integration setup
* Examples of specific sequence designs or use cases

---

---
url: >-
  /knowledgebase-agent-guides/using-help-and-support/we're-here-to-help/what-to-expect-when-you-submit-a-support-ticket/index.agent.md
---
# Agent guide: What to expect when you submit a support ticket

* **Page path:** `using-help-and-support/we're-here-to-help/what-to-expect-when-you-submit-a-support-ticket/index.md`
* **Page type:** faq

## What this page is about

This page appears to be a placeholder titled "What to expect when you submit a support ticket" and contains no substantive guidance beyond the title and classification label.

## User intent

* Understand what happens after submitting a support ticket
* Find expectations for the support ticket process

## Key terms

* support ticket
* Autologyx
* Classification: Unrestricted, Public

## Terminology links

* [Support Ticket](/knowledgebase/terminology/#support-ticket)

## Related topics

* Not provided.

## Prerequisites

* None explicit.

## Not covered

* Any actual steps, timelines, or process details for support tickets
* How to submit a support ticket
* Support response expectations, SLAs, or escalation paths
* Required information for a ticket

---

---
url: >-
  /knowledgebase-agent-guides/workspace/the-task-panel/what's-in-a-task-card/index.agent.md
---
# Agent guide: What's in a Task Card?

* **Page path:** `workspace/the-task-panel/what's-in-a-task-card/index.md`
* **Page type:** faq

## What this page is about

This page appears intended to explain what is contained in a Task Card, but the provided content only includes a placeholder title and classification text with no substantive details.

## User intent

* Find out what information or elements are included in a Task Card

## Key terms

* Task Card
* Autologyx
* Classification
* Unrestricted, Public

## Terminology links

* [Task Card](/knowledgebase/terminology/#task-card)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the concept of a Task Card in the workspace/task panel context

## Not covered

* Any actual description of Task Card fields, sections, or functionality
* How to use, create, edit, or manage a Task Card
* Related task panel navigation or workflow details

---

---
url: >-
  /knowledgebase-agent-guides/finding-your-way-around/my-account/what's-in-my-account/index.agent.md
---
# Agent guide: What's in My Account?

* **Page path:** `finding-your-way-around/my-account/what's-in-my-account/index.md`
* **Page type:** faq

## What this page is about

Explains what appears in the My account page, how to access it, and what can be managed there, including personal information, preferences, and password changes. It also notes who can access My account and that preference settings apply globally.

## User intent

* Find where My account is located in the interface
* Understand what information is shown in My account
* Edit personal information and know how it syncs with the User account
* Change application preferences such as language, localisation, and row density
* Change the system password
* Check which account types have access to My account

## Key terms

* My account
* Log out
* Avatar
* Username
* Personal Information
* User account
* Super Admin
* Preferences
* Language and localisation
* Time zone
* Date format
* Decimal format
* Thousand separator
* Row settings
* Row density
* Password
* Standard authentication
* Super admin
* Standard account type

## Terminology links

* [My account](/knowledgebase/terminology/#my-account)
* [assignee avatars](/knowledgebase/terminology/#assignee-avatars) (matched from `Avatar`)
* [Username](/knowledgebase/terminology/#username)
* [Personal Information](/knowledgebase/terminology/#personal-information)
* [User account](/knowledgebase/terminology/#user-account)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type) (matched from `Super Admin`)
* [Preferences](/knowledgebase/terminology/#preferences)
* [Language and localisation](/knowledgebase/terminology/#language-and-localisation)

## Related topics

* Not provided.

## Prerequisites

* Be signed in to the system
* Have a Super admin or Standard account type to access My account

## Not covered

* How to create or manage user accounts in general
* Detailed password policy beyond noting requirements are shown
* How Super Admin users manage other users' accounts
* Any settings outside My account and Preferences tabs

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/relational-modeller/who-can-create-a-relational-model/index.agent.md
---
# Agent guide: Who can create a relational model?

* **Page path:** `system-configuration/relational-modeller/who-can-create-a-relational-model/index.md`
* **Page type:** faq

## What this page is about

Explains which users can create and edit a relational model, and how access can be granted either through the Super admin account type or specific role permissions for standard users.

## User intent

* Find out who is allowed to create or edit a relational model
* Understand whether standard users can access the relational modeller
* Learn which role permissions are required for relational model access
* Check any additional permissions needed to work with object classes in the model

## Key terms

* relational model
* relational modeller
* Super admin account type
* standard account type
* role permission
* create/edit relational model
* System permissions
* Data model tab
* Object classes
* System configuration

## Terminology links

* [relational model](/knowledgebase/terminology/#relational-model)
* [Relational modeller](/knowledgebase/terminology/#relational-modeller)
* [Super admin account type](/knowledgebase/terminology/#super-admin-account-type)
* [Standard account type](/knowledgebase/terminology/#standard-account-type)
* [Roles and Permissions](/knowledgebase/terminology/#roles-and-permissions) (matched from `role permission`)
* [create/edit relational model](/knowledgebase/terminology/#createedit-relational-model)
* [System permissions](/knowledgebase/terminology/#system-permissions)
* [Data Model tab](/knowledgebase/terminology/#data-model-tab)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of user account types
* Basic understanding of roles and system permissions

## Not covered

* Step-by-step instructions for creating a relational model
* Detailed explanation of all restricted System configuration menu items
* General user creation workflow beyond noting account type is chosen at user creation

---

---
url: >-
  /knowledgebase-agent-guides/administration/user-groups/why-do-i-need-user-groups/index.agent.md
---
# Agent guide: Why do I need user groups?

* **Page path:** `administration/user-groups/why-do-i-need-user-groups/index.md`
* **Page type:** faq

## What this page is about

This FAQ explains why user groups exist in Catalyst alongside roles. It describes user groups as team-based collections of users that make it easier to manage and reference multiple users across system features.

## User intent

* Understand the difference between roles and user groups
* Learn why user groups are useful for managing teams
* See where user groups can be used in the system
* Check limits and rules for user group membership and ownership
* Know who can manage user groups

## Key terms

* user groups
* roles
* permissions
* permission set
* Super admins
* Object Class
* User type field
* task template
* Update object record
* sequencer
* task assignment actor
* record access actor
* Manual task
* send message actor
* owners
* members

## Terminology links

* [User Groups](/knowledgebase/terminology/#user-groups)
* [Roles](/knowledgebase/terminology/#roles)
* [Class permissions](/knowledgebase/terminology/#class-permissions) (matched from `permissions`)
* [Permission Sets](/knowledgebase/terminology/#permission-sets) (matched from `permission set`)
* [Super Admins](/knowledgebase/terminology/#super-admins)
* [Object classes](/knowledgebase/terminology/#object-classes) (matched from `Object Class`)
* [User type fields](/knowledgebase/terminology/#user-type-fields) (matched from `User type field`)
* [Task templates](/knowledgebase/terminology/#task-templates) (matched from `task template`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of users, roles, and permissions in Catalyst
* Familiarity with Object Classes, tasks, and the sequencer is helpful

## Not covered

* Step-by-step instructions for creating or editing user groups
* Detailed configuration of permission sets or sequencer actors
* API setup details beyond noting that some record permission assignment can be done via API
* Full details of the User Group List article or other articles in this section

---

---
url: >-
  /knowledgebase-agent-guides/administration/roles-and-permissions/why-do-users-need-roles/index.agent.md
---
# Agent guide: Why do Users need Roles?

* **Page path:** `administration/roles-and-permissions/why-do-users-need-roles/index.md`
* **Page type:** faq

## What this page is about

This FAQ explains why Roles are needed for Users with the Config admin account type and what Roles control. It also briefly describes the Roles list page, how Roles can be managed, and the system limit for Roles.

## User intent

* Understand why Config admin Users need Roles
* Learn what permissions a Role controls under System Configuration and Administration
* Check what information appears in the Roles list
* Know whether Users can create, edit, or delete Roles
* Find the system limit for the number of Roles

## Key terms

* Roles
* Users
* Config admin account type
* permissions
* System Configuration
* Administration
* Task templates
* Sequences
* Authentication object
* Company details
* Single sign on settings
* Permission sets
* Object class
* Record
* User Group
* Roles list
* Column configuration button
* list page filter editor

## Terminology links

* [Roles](/knowledgebase/terminology/#roles)
* [Users list](/knowledgebase/terminology/#users-list) (matched from `Users`)
* [Config admin account type](/knowledgebase/terminology/#config-admin-account-type)
* [Class permissions](/knowledgebase/terminology/#class-permissions) (matched from `permissions`)
* [System configuration](/knowledgebase/terminology/#system-configuration)
* [Administration Sections](/knowledgebase/terminology/#administration-sections) (matched from `Administration`)
* [Task templates](/knowledgebase/terminology/#task-templates)
* [Sequencer](/knowledgebase/terminology/#sequencer) (matched from `Sequences`)

## Related topics

* creating Permissions
* creating a Role
* common features and functions of the list pages in your system
* using the list page filter editor

## Prerequisites

* Basic understanding of Users and admin account types
* Familiarity with system permissions and administration areas
* Awareness that some Users work with Records through additional Permission sets

## Not covered

* Step-by-step instructions for creating Permissions
* Detailed instructions for creating a Role
* Full explanation of list page features
* Detailed guidance for using the list page filter editor
* How non-Config admin Users are permissioned

---

---
url: >-
  /knowledgebase-agent-guides/system-configuration/working-with-document-templates/index.agent.md
---
# Agent guide: Working With Document Templates

* **Page path:** `system-configuration/working-with-document-templates/index.md`
* **Page type:** explanation

## What this page is about

This page is a navigation overview for working with document templates. It points readers to sections on creating, listing, editing, and generating documents from templates, plus related Word add-in configuration.

## User intent

* Find where to create a document template
* Find the document templates list
* Learn how to edit a document template
* Generate documents automatically via the sequencer
* Generate a document manually from a template
* Locate MS Word Add-In configuration guidance

## Key terms

* document templates
* automatic generation of documents
* sequencer
* create a document template
* document templates list
* edit a document template
* manual generation
* MS Word Add-In configuration

## Terminology links

* [Document Templates](/knowledgebase/terminology/#document-templates)
* [Sequencer](/knowledgebase/terminology/#sequencer)
* [Create A Document Template](/knowledgebase/terminology/#create-a-document-template)
* [Document templates list](/knowledgebase/terminology/#document-templates-list)
* [Edit A Document Template](/knowledgebase/terminology/#edit-a-document-template)
* [manual generation](/knowledgebase/terminology/#manual-generation)
* [Ms Word Add In Configuration](/knowledgebase/terminology/#ms-word-add-in-configuration) (matched from `MS Word Add-In configuration`)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with document templates in the system

## Not covered

* Step-by-step instructions for any template task
* Detailed sequencer setup
* Detailed MS Word Add-In configuration
* Template design specifics or field mapping
* Permissions, troubleshooting, or advanced configuration details

---

---
url: >-
  /knowledgebase-agent-guides/workspace/working-with-relational-records/index.agent.md
---
# Agent guide: Working With Relational Records

* **Page path:** `workspace/working-with-relational-records/index.md`
* **Page type:** explanation

## What this page is about

This page is an overview for working with relational records. It points readers to sections about associating child records with parent records, creating child records from a parent record, and interacting with associated child records via the parent.

## User intent

* Learn how to associate child records with existing parent records
* Learn how to create a child record from a parent record
* Understand how to interact with associated child records via the parent

## Key terms

* relational records
* child records
* parent records
* associated child records

## Terminology links

* [relational records](/knowledgebase/terminology/#relational-records)
* [Present child records](/knowledgebase/terminology/#present-child-records) (matched from `child records`)
* [parent records](/knowledgebase/terminology/#parent-records)
* [child records](/knowledgebase/terminology/#child-records) (matched from `associated child records`)

## Related topics

* Not provided.

## Prerequisites

* Basic understanding of parent-child record relationships

## Not covered

* Detailed procedures for each linked section
* Specific examples, workflows, or configuration steps
* Topics beyond parent-child relational record interactions

---

---
url: /knowledgebase-agent-guides/workspace/index.agent.md
---
# Agent guide: Workspace

* **Page path:** `workspace/index.md`
* **Page type:** explanation

## What this page is about

This page explains the Workspace area of the Autologyx platform, where day-to-day operational work is carried out. It outlines who it is for, what users can do there, and which subtopics cover records, tasks, the Task Panel, and relational records.

## User intent

* Understand what the Workspace is used for
* Determine whether the Workspace is relevant to internal, external, or task-based users
* Learn what kinds of day-to-day actions can be performed in the Workspace
* Find where to learn about working with Records
* Find where to learn about Tasks and task lists
* Find where to learn about using the Task Panel
* Find where to learn about parent/child and related records
* Understand whether to use Workspace documentation versus configuration or administration documentation

## Key terms

* Workspace
* Records
* Tasks
* Task Panel
* related records
* parent / child relationships
* internal operational users
* external users
* case handlers
* reviewers
* Config Admins
* Super Admins
* System Configuration
* Administration

## Terminology links

* [Workspace](/knowledgebase/terminology/#workspace)
* [Object records](/knowledgebase/terminology/#object-records) (matched from `Records`)
* [Tasks](/knowledgebase/terminology/#tasks)
* [Task Panel](/knowledgebase/terminology/#task-panel)
* [related records](/knowledgebase/terminology/#related-records)
* [External users](/knowledgebase/terminology/#external-users)
* [Config Admins](/knowledgebase/terminology/#config-admins)
* [Super Admins](/knowledgebase/terminology/#super-admins)

## Related topics

* Not provided.

## Prerequisites

* Basic familiarity with the Autologyx platform
* A user role involved in day-to-day operational work rather than platform administration

## Not covered

* Platform setup
* Configuration guidance
* Administration guidance
* How the platform behaves from a configuration perspective
* Detailed instructions for Records, Tasks, Task Panel, or relational records beyond pointing to those sections

---

---
url: /knowledgebase/applied-ai/applied-ai-and-the-sequencer.md
---

# AI and the Sequencer

The Sequencer can be used to send structured requests to AI services, receive AI responses, and use those responses inside controlled Autologyx workflows.

This makes Autologyx Catalyst a model-agnostic orchestrator for AI-augmented processing. Catalyst remains responsible for the workflow, data model, permissions, routing, task creation, and audit trail, while AI services can be used for the parts of a process where language understanding, classification, extraction, summarisation, or similar analysis adds value.

Use this section when you want Catalyst to start the AI interaction as part of a workflow.

## How this pattern works

In this pattern, Autologyx starts and controls the AI interaction.

A typical Sequence might:

1. collect structured data from an Object record,
2. prepare a prompt, file, text extract, or structured payload,
3. send an outbound request to an AI service,
4. receive a response,
5. store the result on a record,
6. create, assign, or complete a Task,
7. route the workflow based on the response.

This is different from an AI assistant or agent initiating a request into Autologyx. With the Sequencer pattern, Catalyst is the originator. The workflow decides when AI is used, what context is sent, and what should happen when the response comes back.

## When to use AppliedAI and the Sequencer

Use AI and the Sequencer where AI should support a defined workflow step.

This pattern is useful where you need:

* predictable process control,
* repeatable AI requests,
* structured inputs and outputs,
* workflow routing based on AI analysis,
* human review at defined stages,
* integration with records, tasks, documents, and notifications,
* auditability around how AI is used.

**Common examples include:**

* extracting key terms from contracts or documents,
* classifying inbound requests,
* summarising long documents or message chains,
* triaging work into the right process path,
* identifying risk indicators,
* preparing draft outputs for human review,
* converting unstructured content into structured record data,
* running playbook-style prompt functions against a document or record.

## Autologyx as the model-agnostic orchestrator

AppliedAI in the Sequencer is designed to be model agnostic.

This means the workflow can be designed around the business process rather than around one AI provider. Depending on the customer environment and available integrations, Catalyst can send structured requests to different AI platforms, hosted models, private endpoints, or AI gateways.

The same process design can support different model choices where appropriate. For example, one workflow step might use a model that is well suited to summarisation, while another step might use a different model or endpoint for classification, extraction, or reasoning over a longer context.

This helps customers choose the most appropriate model and provider for the task, while keeping the surrounding workflow stable.

## Native AI connectivity

Catalyst can support AI interaction through dedicated actors and integrations for commonly used AI platforms.

**These may include:**

* OpenAI,
* Anthropic,
* Azure OpenAI and Azure OpenAI,
* AWS Bedrock,
* privately hosted models or customer-specific AI gateways.

Dedicated actors are useful where the platform provides a native configuration experience for a provider. They can make it easier to configure prompts, model settings, authentication, request inputs, and response handling without building a full custom API request from scratch.

Provider availability and supported models depend on the customer environment, licensing, configuration, and enabled integrations.

## Using the API Call actor with AI services

Where there is no dedicated actor for a specific AI service, Catalyst can use API-based integration patterns.

The API Call actor can be used to initiate outbound REST requests to an AI endpoint, gateway, or privately hosted model. This gives configuration teams flexibility where a provider is not covered by a native actor or where a customer has a specific AI service architecture.

**An API Call actor pattern might be used to:**

* send record data to an AI REST endpoint,
* send extracted document text for analysis,
* include structured instructions or prompt variables,
* call a private model endpoint,
* call a customer-controlled AI gateway,
* receive a JSON response,
* store returned values on the source record,
* pass returned data to later actors in the Sequence.

For more information, see [Using the API Call actor with AI services](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/).

## AI tooling for processing content

AppliedAI workflows often need more than a single prompt and response.

Depending on the process, the Sequencer may also use supporting tools and actors for:

* vectorisation,
* text processing,
* document conversion,
* file preparation,
* record lookup,
* relationship lookup,
* looping over repeated items,
* storing intermediate values,
* updating records with structured outputs,
* triggering downstream tasks or communications.

These supporting steps help turn unstructured content into structured information that can be used by the rest of the workflow.

For example, a workflow might convert a document into usable text, split the analysis into several prompt functions, call an AI service for each function, and store the results in structured fields on a record.

## Playbook-style prompt functions

Some AI workflows benefit from separating prompt logic from the Sequence design itself.

One pattern is to use an Object Class to store reusable playbook functions. Each playbook record can define a specific extraction, classification, summary, or review instruction.

A Sequence can then use those playbook records to run a set of repeatable AI checks. For example, a contract review process might use playbook functions to extract:

* parties,
* term,
* renewal provisions,
* termination rights,
* governing law,
* liability caps,
* data protection obligations,
* unusual or missing clauses.

This pattern is especially useful where the same document or record needs to be tested against several review questions. It can also make prompt management easier because prompt functions are held as structured configuration data rather than hidden inside a single long Sequence step.

Where multiple playbook functions need to run against the same source content, the Sequence may use a Loop Actor pattern to repeat the AI request for each function and collect the outputs.

## What happens to AI responses

AI responses are most useful when they are brought back into the workflow as structured information.

Depending on the process design, a response can be used to:

* populate record fields,
* create or update tasks,
* add a summary to a record,
* generate a draft output,
* trigger a review step,
* route the record down a different path,
* prepare content for a message or document,
* support a human decision.

Where an AI response will affect workflow routing, task creation, data changes, or user-facing outputs, the Sequence should be designed carefully. Customers should consider whether the result should be reviewed by a user before it is used to drive important actions.

## Human review and controlled automation

AI and the Sequencer is not an all-or-nothing automation pattern.

Some workflows may use AI only to prepare a draft summary or recommendation. Others may use AI to classify or extract data, but still require a user to review the result before the workflow continues. In lower-risk or highly repeatable use cases, some AI-supported steps may be allowed to continue automatically.

**The right design depends on:**

* the risk of the process,
* the quality and consistency of the source data,
* the confidence required for the output,
* the consequences of an incorrect result,
* the permissions and governance model,
* the customer's internal AI usage policies.

## An important reminder about AI-generated output

::: warning Important reminder
Large language models are not deterministic in the same way as conventional workflow logic.

Even where a prompt, model, workflow, and integration have been carefully designed, an AI model may occasionally produce an inconsistent, unexpected, incomplete, or inaccurate response. This can include hallucinated content.

There are techniques that can reduce this risk, such as carefully designed prompts, structured outputs, validation steps, comparison against source data, deterministic checks in the Sequencer, and secondary model review. However, Autologyx cannot absolutely guarantee that a model will never produce an incorrect or unexpected result.

Where an AI response produces a specific structured value, the Sequencer can often apply deterministic logic to check or gate what happens next. For example, the workflow may test whether a returned value matches an expected option before continuing.

This is more difficult where the model produces output that requires semantic evaluation, such as a narrative summary, legal analysis, interpretation, or recommendation. In those cases, customers should strongly consider a human-in-the-loop review before the output is used for final decisions, external communications, record updates, or other important workflow actions.
:::

## How this differs from MCP services

AI and the Sequencer and MCP services are complementary, but they are not the same pattern.

**With AI and the Sequencer:**

* Catalyst starts the request,
* the workflow decides when AI is used,
* the Sequence controls the context and next step,
* AI responses are processed inside the workflow.

**With MCP services:**

* an approved AI assistant or agent starts the request,
* the assistant uses defined tools to work with Autologyx,
* the agent may read records, work with tasks, retrieve knowledge, or perform controlled actions depending on the enabled service,
* tool access is governed by the MCP service, permissions, and customer configuration.

Use the Sequencer pattern when the workflow should control the AI interaction. Use MCP services when an AI assistant or agent needs to work with Autologyx through defined tools.

For more information, see [MCP services](/knowledgebase/applied-ai/mcp-services/).

## Things to remember

1. The Sequencer pattern is best where Catalyst should initiate and control the AI interaction.
2. AI services should receive only the information needed for the task.
3. Native AI actors can simplify common provider integrations.
4. The API Call actor can support AI endpoints that are not covered by a native actor.
5. AI responses should be treated as workflow inputs, not automatically trusted decisions.
6. Use human review where the output affects important decisions, record data, tasks, or communications.
7. Model choice, prompt design, permissions, auditability, and customer AI policies should be considered before using AppliedAI in production workflows.

---

---
url: /knowledgebase/finding-your-way-around/ui-and-navigation/all-about-panels.md
---

# All about panels

---

---
url: /knowledgebase/administration/all-about-users/all-about-users.md
---

# All about users

The **Users** list is available from:

**Administration** > **Users**

This page allows authorised users to view, create, edit, delete, and monitor user accounts.

## Default columns

The default Users list includes the following columns.

### ID

A unique ID assigned to each user.

This can be useful when configuring Sequences, for example when relating a user to a User-type field or assigning ownership of a record.

### Username

The user's unique email address.

### Account Type

Displays the type of account assigned to the user.

For a description of each account type, see [How do I create a user account?](/knowledgebase/administration/all-about-users/how-do-i-create-a-user-account/).

### Roles

Roles apply only to users with a Config admin account type.

Roles determine which areas of System configuration and Administration those users can access.

### Actions

The **Actions** menu allows authorised users to manage user accounts.

Depending on the account status and your permissions, the following options may be available:

* **Open**
* **Delete**
* **Resend activation email** (shown only when the account status is **Pending**)

![Users list showing the default columns](../../../images2/zendesk_5274369024541_001_82ee8eb091aa.png)

![Actions menu showing available user account actions](../../../images2/zendesk_5274369024541_002_3a95e041f187.png)

## Account status

The **Status** column is not shown by default, but it is one of the most useful columns available.

It shows whether a user account is:

* **Created** – the account has been created but no activation email has been sent.
* **Pending** – the activation email has been sent but the user has not yet activated their account.
* **Active** – the user has activated their account and signed in.

For more information, see [What can I edit in a user account?](/knowledgebase/administration/all-about-users/what-can-i-edit-in-a-user-account/).

## Additional columns

Using the column configuration menu, you can also display:

* **Created**
* **Created by**
* **Last edited**
* **Last edited by**
* **Last logged in**

These columns can help with auditing and user account administration.

![Users list showing additional configurable columns](../../../images2/zendesk_5274369024541_003_c88f8c3e0d66.png)

## Creating a user

To create a new user, click **+ Create**.

For step-by-step guidance, see [How do I create a user account?](/knowledgebase/administration/all-about-users/how-do-i-create-a-user-account/).

## List features

Like all Catalyst list pages, the Users list supports:

* filtering
* sorting
* column configuration
* pagination

Find out more about:

* [List pages](/knowledgebase/finding-your-way-around/ui-and-navigation/list-pages/)
* [List page filter editor](/knowledgebase/finding-your-way-around/ui-and-navigation/list-page-filter-editor/)

## Related articles

* [How do I create a user account?](/knowledgebase/administration/all-about-users/how-do-i-create-a-user-account/)
* [What can I edit in a user account?](/knowledgebase/administration/all-about-users/what-can-i-edit-in-a-user-account/)
* [Service Accounts](/knowledgebase/administration/all-about-users/service-accounts/)
* [What happens when an individual uses Single Sign-on?](/knowledgebase/administration/all-about-users/what-happens-when-an-individual-uses-single-sign-on/)
* [How do I configure user activation rules?](/knowledgebase/administration/communication/how-do-i-configure-user-activation-rules/)

## Things to remember

1. The Users list displays the accounts you have permission to view and manage.
2. The **Status** column is available through column configuration and is useful when managing account activation.
3. Usernames are email addresses and must be unique.
4. Only users with the appropriate permissions can create, edit, or delete user accounts.
5. The maximum number of users supported in your system is 1,000,000.
6. A maximum of 5,000 Roles can be configured.

---

---
url: /knowledgebase/administration/all-about-users.md
---

# All About Users

Users are at the centre of Catalyst. They can be assigned work, access records, participate in workflows, administer the platform, or authenticate integrations and automated processes.

This section explains the different user account types available in Catalyst, how user accounts are created and managed, and how users authenticate and interact with the platform.

## User management

Start here if you need to view, create, or update user accounts.

* [All about users](/knowledgebase/administration/all-about-users/all-about-users/)
* [How do I create a user account?](/knowledgebase/administration/all-about-users/how-do-i-create-a-user-account/)
* [What can I edit in a user account?](/knowledgebase/administration/all-about-users/what-can-i-edit-in-a-user-account/)

## 1-time completion users

1-time completion users are designed for people who need to complete tasks without signing in to Catalyst.

* [Assigning Tasks to 1 Time Completion Users](/knowledgebase/administration/all-about-users/assigning-tasks-to-1-time-completion-users/)
* [How does a 1 Time Completion User interact with Catalyst?](/knowledgebase/administration/all-about-users/how-does-a-1-time-completion-user-interact-with-catalyst/)

## Service Accounts

Service Accounts provide dedicated accounts for integrations, API access, and automated processes.

Learn about:

* Service Internal accounts

* Service External accounts

* authentication methods

* permissions and security considerations

* [Service Accounts](/knowledgebase/administration/all-about-users/service-accounts/)

## Authentication and access

These articles explain how users authenticate and recover access to their accounts.

* [What happens when a user clicks the Forgot your password link on the login page?](/knowledgebase/administration/all-about-users/what-happens-when-a-user-clicks-the-forgot-your-password-link-on-the-login-page/)
* [What happens when an individual uses Single Sign-on?](/knowledgebase/administration/all-about-users/what-happens-when-an-individual-uses-single-sign-on/)

## Things to remember

1. Different user account types are designed for different use cases and permission models.
2. Only Super Admin users can create, edit, and delete user accounts.
3. Service Accounts are intended for integrations and automated processes rather than individual users.
4. 1-time completion users do not sign in to Catalyst and complete tasks using secure email links.
5. Authentication methods available to users depend on your system configuration.

---

---
url: /knowledgebase/release-notes/release-notes-1.10/analytics-database.md
---

# Analytics Database

Have you ever wondered how to connect the dots between your daily operations and their long-term impact? Our new Analytics Database bridges this gap by unifying critical data sources. This powerful combination gives you visibility into both current operations and historical patterns.

Through an **ETL (Extract, Transform, Load) process**, we sync and consolidate data from the two sources into the Analytics Database, built on **ClickHouse**:

1. **Resource Database (PostgreSQL):** The operational backbone of Catalyst, containing real-time, transactional data like object records and task statuses.
2. **History Events Database:** The repository for historical event tracking, including audit trails, permission changes, and field-level updates.

This allows you to work with a single source of truth for reporting while keeping operational and historical data separate for optimal performance. **Incremental updates are synced every 30 minutes** to ensure data freshness. Large datasets are processed in chunks to maintain performance even in high-volume environments.

## What’s inside the Analytics Database?

Here’s what each table brings to your analytics:

**1. Object Records** (`objects_objectrecordfield` - Resource Database)

Analyze the completeness of critical fields, monitor updates to object records, and ensure vital data is consistently captured across workflows.

**2. Tasks** (`tasks_task` - Resource Database)

Gain visibility into task statuses, monitor overdue items, track completion trends, and evaluate workload distribution among team members to optimize project management.

**3. Fields** (`fields` - History Database)

Access detailed information about field configurations, including aliases and labels, to audit and optimize how fields are utilized across your processes.

**4. Object Records History** (`object_records_history` - History Database)

Track historical changes to object records, including event timestamps, event types, and associated record IDs. Ideal for auditing and understanding the lifecycle of key records.

**5. Permission Sets** (`permission_sets` - History Database)

Analyze modifications to permission sets, analyze changes over time, and ensure that access controls are properly configured and enforced throughout your organization.

**6. User Groups** (`user_groups` - History Database)

Leverage user group data to identify group-based actions. This ensures better tracking of team contributions and alignment with role-based responsibilities.

**7. Users** (`users` - History Database)

Analyze user-level activity to determine who created or modified records, completed tasks, or owns specific workflows. This helps in accurately attributing actions to individuals, improving accountability and visibility across processes.

## Analytical potential with ClickHouse

With ClickHouse as its backbone, the new Analitycal database empowers analysts to leverage SQL to extract deep insights tailored to their needs. Whether you want to calculate task completion trends, review audit trails, or assess workflow bottlenecks, the flexibility of SQL opens the door to limitless possibilities.

Moreover, ClickHouse enables the creation of **Views** - virtual tables that can consolidate data from multiple sources, pre-aggregate information, and simplify complex queries. For your organization, this means:

* **Faster, more consistent reporting** with standardized data models.
* **The ability to generate tailored datasets** that align with specific business goals.
* **Easier integration with BI tools**, as Views can act as ready-to-use datasets for visualizations and dashboards.

![Clickhouse.gif](../../../images2/zendesk_4647511973791_001_08bec203ea88.gif)

## Real-world application: enhancing due diligence insights

When legal teams work on a complex M\&A due diligence process, they often face the daunting task of managing and reviewing thousands of documents. The Analytics Database simplifies this process by providing a comprehensive view of all relevant data and enabling detailed analysis to inform decision-making.

### Document Review Intelligence

* Track contracts flagged for high-risk clauses and ensure they receive priority in the review pipeline.
* Monitor the progress of pending document reviews, identifying gaps and delays before they escalate into critical issues.
* Analyze bottlenecks in the workflow to understand where and why delays are occurring in the review process.
* Evaluate reviewer performance to allocate resources more effectively, matching tasks with the right expertise.

### Streamlining Processes with Dashboards

* Visualize average review times for different document types, such as employment agreements or supplier contracts, to identify inefficiencies.
* Pinpoint peak activity periods, enabling better resource planning during critical stages of the process.
* Display completion rates by department, ensuring accountability and alignment across teams.

### Proactive Risk Mitigation

* Quickly identify documents with missing or incomplete data, such as unsigned contracts or missing clauses.
* Detect compliance issues early, such as documents that don’t adhere to legal or regulatory standards, reducing exposure to risk.
* Leverage historical data to understand recurring risk patterns and prevent similar issues in future processes.

![Clickhouse3.gif](../../../images2/zendesk_4647511973791_002_2cfcc938712e.gif)

For organizations with this feature enabled, connecting to the Analytics Database is straightforward through standard BI tools. Whether you're using Power BI's DirectQuery for real-time analysis or Tableau for comprehensive visualizations, you're just a few clicks away from transforming your operational data into strategic insights.

Each table and field is meticulously structured to deliver the depth of analysis you need, without compromising system performance. From operational efficiency to strategic planning, the Analytics Database equips you with the tools to stay ahead in a data-driven world.

---

---
url: /knowledgebase/system-configuration/apis-and-variables/api-call-actor.md
---

# API Call Actor

The **API Call Actor** is used to send HTTP requests to external systems from within a Sequence.

It is one of the main ways to integrate Autologyx with other services and platforms. In practice, it is commonly used to:

* integrate with third-party systems
* send data to external APIs
* retrieve data from external systems
* trigger external processes
* synchronise data between systems
* interact with your own Autologyx environment where a direct native Actor is not available

Because of this, the API Call Actor is a key building block for integrations, automation, and more advanced workflow design.

## Before you start

Before configuring an API Call Actor, it helps to be familiar with:

* Sequences
* Merge fields
* Authentication Objects
* Object Records

Depending on the integration you are building, you may also need:

* [Local Variable Actor](/knowledgebase/system-configuration/apis-and-variables/local-variable-actor/)
* [Document Picker Actor](/knowledgebase/system-configuration/sequence-actors/document-picker-actor/)
* [Update Record Actor](/knowledgebase/system-configuration/sequence-actors/update-record-actor/)

## How to use the API Call Actor

### 1. Add the Actor to your Sequence

From the Actors panel on the left-hand side, drag and drop the API Call Actor onto your Sequence canvas.

![](/knowledgebase/images/img_5666680976799_1776895879.png)

### 2. Open the configuration panel

Right-click the API Call Actor and select **Configure**.

![](/knowledgebase/images/img_5666680976799_1776895879.png)

You can then complete the API Call configuration using the fields described below.

## Configure the API Call

### Template

The **Template** determines the type of API Call configuration.

![](/knowledgebase/images/img_5666680976799_1776895879.png)

**Available options:**

* **Standard Configuration** — used for general API calls
* **iManage** — used when working with the IManage integration

If you are using the iManage option, follow the relevant iManage integration guidance.

::: info
The **iManage** option is only available if the iManage integration has been enabled in your environment.
:::

### Method

The **Method** defines the type of HTTP request being made.

![](/knowledgebase/images/img_5666680976799_1776895880.png)

**Available options:**

* **GET** — retrieve data from a system
* **POST** — create a new resource
* **PUT** — replace an existing resource
* **PATCH** — update part of an existing resource
* **DELETE** — remove a resource

The method determines how data is sent to, or retrieved from, the target system.

### Data Type

The **Data Type** defines how the request payload is structured.

![](/knowledgebase/images/img_5666680976799_1776895880.png)

**Available options:**

* **Form Data** — send simple key/value pairs
* **Multipart Data** — send files alongside form data
* **JSON Data** — send structured data in JSON format
* **XML Data** — send data in XML format
* **Binary Data** — send raw file or binary content

**JSON Data** is the most commonly used option.

**Multipart Data** is typically used when sending files as part of the request, for example when configuring DocuSign envelopes or versioning documents in a document management system.

### Authentication

The **Authentication** field determines whether the API Call uses authentication.

![](/knowledgebase/images/img_5666680976799_1776895880.png)

**Available options:**

* **Auth Object** — use a configured Authentication Object
* **"-----"** — no authentication is applied

::: info
The **Auth Object** option is only available if valid Authentication Objects have already been configured in the system.
:::

### Auth Object

If **Auth Object** is selected, choose the Authentication Object you want to use from the list of those configured in the system.

![](/knowledgebase/images/img_5666680976799_1776895880.png)

### Name

Provide a name for the API Call.

This name must be unique within the Sequence. It is best practice to use a descriptive name that reflects the purpose of the call.

::: tip
This is not the same as the visible name of the Actor on the canvas. The API Call name is stored as backend metadata and is useful when troubleshooting or reviewing logs.
:::

### URL

The **URL** defines the endpoint the API Call will target.

This field supports Merge fields and Jinja expressions, which means the URL can be constructed dynamically at runtime.

**Examples:**

{{ client\_url }}/api/tasks/{{ record.tasks\_2|map(attribute='id')|max }}/stages/stage\_1/owner/

{{ variables.imanage\_url }}/documents/Library!{{ variables.document\_number }}.1/versions

### URL Parameters

**URL Parameters** allow you to pass additional information to the API as part of the URL, for example filters, sorting, or control values.

![](/knowledgebase/images/img_5666680976799_1776895881.png)

**Each parameter consists of:**

* **Name**
* **Value**

Parameters are appended to the URL using `?` and `&`:

* `?` starts the parameters section
* `&` separates multiple parameters

**Example:**

`legaloperations.autologyx.com/workspace/records?isInfinite=true&sort=-id`

This field supports Merge fields and Jinja expressions.

You can add or remove URL Parameters using the **+** and **–** buttons.

### Headers

**Headers** define additional information sent with the request, such as content type or authentication-related metadata.

![](/knowledgebase/images/img_5666680976799_1776895881.png)

**Each header consists of:**

* **Name**
* **Value**

**Example:**

* **Name:** `Content-Type`
* **Value:** `application/json`

Headers also support Merge fields and Jinja expressions.

You can add or remove headers using the **+** and **–** buttons.

### Parameters (Payload)

The **Parameters** field defines the body of the request, also known as the payload.

![](/knowledgebase/images/img_5666680976799_1776895881.png)

**This field supports:**

* Merge fields
* Jinja expressions
* fully dynamic payload construction

This is where you define the data that will be sent to the target API.

For example, when creating a DocuSign envelope, the payload would include the document details, recipients, and any configuration required by the external API.

### Files

If the API Call follows a Document Picker actor, the selected document will be available to attach to the request.

[Document Picker Actor](/knowledgebase/system-configuration/sequence-actors/document-picker-actor/)

![](/knowledgebase/images/img_5666680976799_1776895881.png)

You can select the file and define the name under which it should be sent.

::: info
This file selection is used only when the API Call Actor runs as part of a live Sequence.

It is **not** used during **Test Call** execution. For testing, use the **Document** field described below.
:::

### Retry

The **Retry** setting determines how many times a failed API Call should be retried.

**Key points:**

* Default value: `0`
* Increasing the value allows the system to reattempt failed calls automatically

### Notify

You can provide an email address to receive notifications if the API Call fails.

**The notification includes:**

* Record details
* Sequence information
* error response details

![](/knowledgebase/images/img_5666680976799_1776895882.png)

## Testing the API Call

An API Call must be tested before it can be used successfully in a Sequence.

### Record ID

Provide a **Record ID** to test the API Call against.

![](/knowledgebase/images/img_5666680976799_1776895882.png)

This ensures that Merge fields and any runtime values can be resolved using real data.

If the API Call uses values from the current Object Record, the Record ID must correspond to a valid Record in the relevant Object Class.

If the API Call does **not** reference Record data, for example when making a token request, any valid Record ID may be sufficient.

If an invalid Record ID is used, the Test Call will return an error.

### Document (for testing)

As noted above, a Test Call does **not** use the live file selected in the API Call Actor configuration.

![](/knowledgebase/images/img_5666680976799_1776895882.png)

Instead, the **Document** field allows you to select a Record field containing a test file.

This field must be of the **Document** data type. The Test Call will use the file or files in that field as part of the request.

::: tip
Choose a field that contains a realistic example document, so the API Call can be tested in a meaningful way.
:::

### Test Call

Click **Test Call** to execute the request using the current configuration and the data from the selected Record.

![](/knowledgebase/images/img_5666680976799_1776895882.png)

The Test Call will execute the API request, but it will **not** trigger downstream **Actor Completed** triggers in the Sequence.

If you want to continue the workflow after testing, you will need to re-trigger the Sequence for the Record.

::: warning
If the external API only allows a request to succeed once for a given Record or transaction, you may need to use a different Record for repeated tests.
:::

### Show Log and API Test Call History

Click **Show Log** to view the API test call history.

![](/knowledgebase/images/img_5666680976799_1776895882.png)

**This includes:**

* request details
* rendered Parameters
* response data
* error messages

Use **Clear** if you want to remove old log entries and reduce noise while troubleshooting.

## Using the API Call Actor for debugging

The API Call Actor can also be used as a debugging tool inside a Sequence.

For example, you can configure a simple call like this:

* **Template:** Standard Configuration
* **Method:** GET
* **Authentication:** --------
* **URL:** {{ client\_url }}/api/object-records/{{ record.id }}

This creates an unauthenticated request to the current Record. The request will fail because no authentication is provided, but it can still be useful for debugging.

In this scenario, the **Parameters** field can be used to:

* test Jinja syntax
* validate how values are being rendered
* check what data is available at a particular point in the Sequence
* help identify why a Sequence may have failed for a given Record

Run a **Test Call** and then inspect the rendered **Parameters** output in the test call history.

For example, if the log shows a value such as `variables.test` as blank, that may indicate that the Sequence has not yet reached the point where the Variable is set, or that it attempted to set it and failed.

![](/knowledgebase/images/img_5666680976799_1776895883.png)

::: info
In this type of debugging setup, the error response is expected. The most useful part of the output is usually the rendered **Parameters** content.
:::

You can also use this approach to test Jinja syntax. If an expression contains an error, the API Test Call response may help surface it. For example, a missing `%` in a Jinja statement may result in a merge field or template rendering error.

![](/knowledgebase/images/img_5666680976799_1776895883.png)

## Important behaviour and platform nuances

### API Calls must be tested before use

An API Call Actor will appear **red** if it has not been successfully tested.

A red API Call Actor will **not execute** when the Sequence runs.

**To activate the API Call:**

1. Run a **Test Call**
2. Confirm a successful response
3. Save the configuration

Once the API Call has been successfully tested and saved, it will change from red to yellow.

![](/knowledgebase/images/img_5666680976799_1776895883.png)

::: warning
Any change to the API Call configuration requires it to be tested again.
:::

### API Calls can trigger Sequences

API Calls that interact with Autologyx Records, for example by creating or updating them, are processed in the same way as user-initiated changes.

**This means:**

* the action appears in the Activity Log under the credentials of the user associated with the Authentication Object
* it may trigger other Sequences configured with record-based triggers such as **Record Updated**

::: warning
Using API Calls to update Autologyx Records can introduce unintended side effects, including extra Sequence runs or processing loops.

Where possible, use native Actors such as the [Update Record Actor](/knowledgebase/system-configuration/sequence-actors/update-record-actor/) when changing data inside Autologyx itself.
:::

### Variables must have values when testing

If your API Call uses Variables or Merge fields, they must have valid values during testing.

**In practice, this means:**

* you must provide a valid Record ID where appropriate
* the Sequence must have reached the point at which those values are available

If Variables are not yet populated, the API Call may not render correctly.

For more information, see the [Local Variable Actor](/knowledgebase/system-configuration/apis-and-variables/local-variable-actor/).

## Common use cases

API Call Actors are commonly used for:

* integrating with third-party systems
* creating or updating records in external platforms
* sending structured data to external APIs
* retrieving and processing external data
* interacting with parts of your Autologyx system that are not directly available through a Record’s relational structure

## Key takeaways

* the API Call Actor is used to send HTTP requests from within a Sequence
* it supports dynamic values through Merge fields and Jinja
* API Calls must be successfully tested before they will execute
* test logs are one of the most useful tools for troubleshooting
* if your API Call depends on Variables or Record data, those values must exist at test time
* API Calls that update Autologyx can trigger further activity and should be designed carefully

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.9/api-for-delaying-user-account-activation.md
---

# API for delaying user account activation

Managing intricate workflows can be time-consuming, requiring meticulous process design, user creation, task assignment, and thorough testing before granting access. Delayed account activation addresses this challenge by offering administrators the flexibility to design and prepare the whole process within the platform before triggering the activation email for users.

## Creating users via the API

When creating a user via the API endpoint `POST /api/users/`, administrators can now set the `delay_activation` parameter to true. This ensures that the user remains in the "Created" status without receiving an activation email.

![Delayed1\_article.gif](../../../images2/zendesk_17933761911325_001_cde9b10e865e.gif)

Conversely, setting the parameter to false, or omitting it entirely, triggers the immediate sending of an activation email. The user is then assigned the "Pending" status, indicating that the account activation is pending user confirmation.

![Delayed2\_article.gif](../../../images2/zendesk_17933761911325_002_c76aaef20a24.gif)

The `delay_activation` parameter is not allowed for 1TC (One-Time Completion) users. When changing the account type from a 1TC user to another type, API users can now send the additional `delay_activation` parameter via the `PATCH /api/users/{user_id}` endpoint.

## Activation email behavior

**Activation emails** can now be sent to users in the "Created" or "Pending" statuses. Sending an activation email to a user in the "Created" status automatically changes their status to "Pending."

Only activation emails are allowed to be sent to users in the "Created" and "Pending" statuses. Other system emails, such as those sent by the Send Message actor or task messages, are now blocked for non-active users.

## Availability

**These changes are currently only available via the API** and not on the user interface. This ensures that administrators have full control and visibility over the account activation process, allowing for seamless integration with existing workflows and processes.

## Benefits

Delayed account activation empowers Catalyst administrators to plan and configure business processes before activating users. Assigning roles, designating tasks, and thoroughly testing the setup — all without bombarding new users with immediate login prompts. This approach translates to a smoother experience for everyone. Users receive a well-prepared environment, leading to increased satisfaction and accelerated productivity right from the start.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.10/api-for-groups-in-record-permission-sets.md
---

# API for Groups in Record Permission Sets

Managing permissions can be a real headache, especially for growing teams. That's why we're excited to introduce **User Groups in Record Permission Sets, now available through our API**.

With User Groups, you can now manage permissions for entire teams in one go. This feature marks a substantial step forward in how organisations can manage and scale their access control. This is particularly valuable in industries like healthcare or finance, where data sensitivity is paramount.

**What this means:** dive into the details with our new API endpoints and see how this capability can streamline your permission management like never before.

We've **maintained support for all existing endpoints managing individual users**, ensuring a smooth transition for your current systems, but we've also introduced new, more specific endpoints.

All actions previously performed with `/api/object-records/{record_id}/permission-sets/{permission_set_id}/assignees/` will now also be available in `/api/object-records/{record_id}/permission-sets/{permission_set_id}/assignees/users/`. This means you can expect the same functionality for managing users, now neatly organised under the new `users` endpoint. It’s the same control you’re accustomed to, just with a more refined approach.

## Assign User Groups

**Use** `POST/api/object-records/{record_id}/permission-sets/{permission_set_id}/assignees/user-groups/` **to assign User Groups** by passing a list of group IDs. The payload should include a list of user group IDs:

```
[ <group_id1>, <group_id2>, ... ]
```

Only the User Groups you have permission to view can be assigned. If a group is already assigned, it will be ignored, so you don’t have to worry about duplicates.

Upon successful assignment, the API returns a response that includes the group ID, name, timestamp of the assignment, and the user who performed the action.

## View assigned User Groups

If you need to check which User Groups are already assigned to a Record Permission Set, use `GET/api/object-records/{record_id}/permission-sets/{permission_set_id}/assignees/user-groups/`. This method retrieves the list of User Groups assigned to the specified permission set. This allows you to see exactly which groups have been added and manage them as needed.

## Unassign User Groups

**To unassign a User Group, use** `DELETE/api/object-records/{record_id}/permission-sets/{permission_set_id}/assignees/user-groups/`. Similar to the POST method, you provide a list of group IDs to remove. Groups that aren’t assigned will simply be ignored.

## Limits and behaviour

You can assign up to 10 User Groups at a time to each Record Permission Set, which ensures that the system remains performant even with large numbers of groups.

Every time a User Group is added or removed, **the event is logged in the object’s history**, giving you full traceability of permission changes.

By assigning User Groups to Record Permission Sets, you can effortlessly grant or revoke record permissions for all members of that group. When a user is added to a group, they automatically inherit the permissions associated with that group. Conversely, when a user is removed from a group, their permissions are revoked accordingly.

## Summary

The new API endpoints transform permission management into a seamless, programmable experience. Development teams can now automate complex permission workflows, from bulk group assignments to real-time access updates, all through simple API calls. For enterprises handling thousands of records, this means turning days of manual permission updates into automated processes that execute in seconds.

---

---
url: /api/standards.md
---
# API standards

This page defines the platform-wide API standards used across Autologyx.

These standards exist so that APIs behave consistently across services, resources, and endpoints. They help ensure that request and response structures are predictable, validation behaviour is consistent, filtering and sorting rules are reusable, and error messages can be interpreted reliably by both users and client applications.

## Why standards matter

Autologyx APIs are used across many different areas of the platform, including configuration, workflow execution, integrations, permissions, event handling, and operational services. Without a shared standard, each endpoint could behave differently, making integrations harder to build, maintain, and support.

By applying consistent API standards, Autologyx aims to provide:

* predictable request and response behaviour
* consistent validation and error handling
* reusable filtering, sorting, and schema conventions
* clearer expectations for integrators and internal developers
* a more maintainable platform over time

## Strong typing in the Autologyx API

The Autologyx API takes a strongly typed approach to data.

This means that fields, payload attributes, filters, and schema definitions are expected to have clear and well-defined types. Rather than treating values as loosely structured data wherever possible, the platform distinguishes explicitly between integers, UUIDs, strings, booleans, enums, sets, dates, datetimes, JSON objects, and more complex structured types such as users, owners, and permissions.

In practice, this means:

* values are validated according to their defined type
* invalid data types are rejected with explicit errors
* related resources and enumerated values are handled consistently
* schemas describe both which fields exist and what kind of data each field accepts
* client applications can rely on a stable contract when integrating with the platform

This strongly typed approach reduces ambiguity, makes integrations safer, and supports more reliable platform behaviour across both UI-driven and API-driven workflows.

## How to use this page

Use this page as the baseline reference for designing, reviewing, or implementing Autologyx API endpoints.

It describes the platform-wide rules for:

* data types and structures
* request and response conventions
* validation and error handling
* filtering and sorting behaviour
* schema definitions used in `OPTIONS` responses
* endpoint restrictions and common response patterns

***

## Data types

The API data model uses explicit types so that values can be validated, documented, and handled consistently.

| Type        | Notes                                    |
|-------------|------------------------------------------|
| int         | Integer                                  |
| uuid        | UUID                                     |
| string      | Text value                               |
| url         | URL value                                |
| date        | Date value                               |
| datetime    | Date and time value                      |
| enum        | Consists of predefined values            |
| set         | Collection of predefined values          |
| bool        | Boolean value                            |
| email       | Email address                            |
| json        | JSON                                     |
| user        | Complex object of system user attributes |
| user\_group  | Complex object describing a user group   |
| owners      | Complex object describing owners         |
| permissions | Complex object describing permissions    |

## Data structures

Where response schemas are more complex, the following structural categories can be used.

For simpler nested structures, standard `nested.property` syntax can be used instead.

| Type   | Notes         |
|--------|---------------|
| Array  | A JSON array  |
| Object | A JSON object |

### User type

Example:

```json
{
  "id": 23,
  "first_name": "John",
  "last_name": "Smith",
  "username": "j.smith@autologyx.com",
  "company_name": "Autologyx",
  "is_deleted": false,
  "account_type": "super_admin"
}
```

### Owners type

The `owners` type is used for resources managed by owners. The value is a complex object containing:

* the total number of owners
* the first assigned owner, based on the date and time it was added

Example:

```json
{
  "total_number": 1,
  "first": {
    "id": 13,
    "first_name": "John",
    "last_name": "Smith",
    "username": "j.smith@autologyx.com",
    "company_name": "Autologyx",
    "is_deleted": false,
    "account_type": "full"
  }
}
```

***

## Insufficient permissions

Use the following responses when a user is authenticated but does not have the required permissions.

| Error                                                                                    | Response code   | Message                                                                      |
|------------------------------------------------------------------------------------------|-----------------|------------------------------------------------------------------------------|
| User is authenticated but does not have permission to perform the method on an endpoint  | 403 Forbidden   | `"detail": "You do not have permission to perform this action."`             |
| User does not have permission for a resource instance used as the value of an attribute  | 400 Bad Request | `"{attribute}": [ "You do not have permission to use this {resource name}." ]` |

***

## POST standards

POST endpoints are used for creation operations and should return `201 Created` on success unless there is a documented exception.

### Standard response content

* Success status: `201 Created`

### Error handling

#### Invalid payload properties

##### Common

| Error                                                                                | Response code   | Message                                                                                         |
|--------------------------------------------------------------------------------------|-----------------|-------------------------------------------------------------------------------------------------|
| `{attribute}` is missing                                                             | 400 Bad Request | `"{attribute}": [ "This field is required." ]`                                                  |
| `{attribute}` is an empty string                                                     | 400 Bad Request | `"{attribute}": [ "This field may not be blank." ]`                                             |
| `{attribute}` is null                                                                | 400 Bad Request | `"{attribute}": [ "This field may not be null." ]`                                              |
| `{attribute}` has more than `{number}` characters                                    | 400 Bad Request | `"{attribute}": [ "Ensure this field has no more than {number} characters." ]`                  |
| `{attribute}` is not unique                                                          | 400 Bad Request | `"{attribute}": [ "This field must be unique." ]`                                               |
| Value for an integer field is not an integer                                         | 400 Bad Request | `"{attribute}": [ "A valid integer is required." ]`                                             |
| Value of a different type than list is supplied for list `{attribute}`               | 400 Bad Request | `"{attribute}": [ "Expected a list of items but got type "{type}"." ]`                          |
| Primary key value for enum `{attribute}` is of type `{type}` instead of int          | 400 Bad Request | `"{attribute}": [ "Incorrect type. Expected pk value, received {type}." ]`                      |
| `{resource}` instance for primary key `{value}` of enum `{attribute}` does not exist | 400 Bad Request | `"{attribute}": [ "Invalid pk "{value}" - {resource} does not exist." ]`                        |
| User does not have permission to use a given resource instance                       | 400 Bad Request | `"{attribute}": [ "You do not have permission to use this {resource name}." ]`                  |
| `{value}` for `{attribute}` is out of choices                                        | 400 Bad Request | `"{attribute}": [ ""{value}" is not a valid choice." ]`                                         |
| Max `{number}` of `{resource}` exceeded                                              | 400 Bad Request | `"detail": "Limit of {number} {resource} has been exceeded.", "error_code": "ERR_LIMIT_EXCEEDED"` |
| Max `{number}` `{sub-resource}` per `{resource}` exceeded                            | 400 Bad Request | `"detail": [ "Limit of {number} {sub-resource} for the {resource} has been exceeded." ]`        |
| Insufficient permissions                                                             | 403 Forbidden   | `"detail": "You do not have permission to perform this action."`                                |
| Resource instance with `"id"` does not exist                                         | 404 Not Found   | `"detail": "Not found."`                                                                        |

##### Permission fields

| Error                                                | Response code   | Message                                                              |
|------------------------------------------------------|-----------------|----------------------------------------------------------------------|
| Invalid `{resource}` key for permissions `{attribute}` | 400 Bad Request | `"{attribute}": [ "Invalid resource "{resource}"." ]`                |
| Invalid `{action}` given for resource                | 400 Bad Request | `"{attribute}": [ ""{action}" is not a valid choice." ]`             |
| Value of different type than list given for resource | 400 Bad Request | `"{attribute}": [ "Expected a list of items but got type "{type}"." ]` |

##### File fields

| Error                        | Response code   | Message                                                                                                          |
|------------------------------|-----------------|------------------------------------------------------------------------------------------------------------------|
| Invalid file extension       | 400 Bad Request | `"detail": [ "File extension “{file_extension}” is not allowed. Allowed extensions are: {allowed_extensions}." ]` |
| Missing header with filename | 400 Bad Request | `"detail": [ "Missing filename. Request should include a Content-Disposition header with a filename parameter." ]` |
| File size is over `{max}`    | 400 Bad Request | `"detail": [ "Max file size is {max} MB." ]`                                                                      |

#### Non-modifiable properties

If a value for a non-modifiable property is supplied in the request body, it should be silently ignored unless the endpoint explicitly documents a different behaviour.

***

## URL standards

URLs should use hyphens (`-`) rather than underscores (`_`).

Example:

```text
/api/endpoint/action-name/
```

***

## PATCH standards

PATCH endpoints are used for partial updates and should return `200 OK` on success unless there is a documented exception.

### Standard response content

* Success status: `200 OK`

### Error handling

#### Invalid IDs in the URL

If the `id` or `uuid` in the URL does not match a resource, return:

* `404 Not Found`

#### Invalid payload properties

##### Common

| Error                                                                                | Response code   | Message                                                                                         |
|--------------------------------------------------------------------------------------|-----------------|-------------------------------------------------------------------------------------------------|
| `{attribute}` is an empty string                                                     | 400 Bad Request | `"{attribute}": [ "This field may not be blank." ]`                                             |
| `{attribute}` is null                                                                | 400 Bad Request | `"{attribute}": [ "This field may not be null." ]`                                              |
| `{attribute}` has more than `{number}` characters                                    | 400 Bad Request | `"{attribute}": [ "Ensure this field has no more than {number} characters." ]`                  |
| `{attribute}` is not unique                                                          | 400 Bad Request | `"{attribute}": [ "This field must be unique." ]`                                               |
| Value for an integer field is not an integer                                         | 400 Bad Request | `"{attribute}": [ "A valid integer is required." ]`                                             |
| Value of a different type than list is supplied for list `{attribute}`               | 400 Bad Request | `"{attribute}": [ "Expected a list of items but got type "{type}"." ]`                          |
| Primary key value for enum `{attribute}` is of type `{type}` instead of int          | 400 Bad Request | `"{attribute}": [ "Incorrect type. Expected pk value, received {type}." ]`                      |
| `{resource}` instance for primary key `{value}` of enum `{attribute}` does not exist | 400 Bad Request | `"{attribute}": [ "Invalid pk "{value}" - {resource} does not exist." ]`                        |
| User does not have permission to use a given resource instance                       | 400 Bad Request | `"{attribute}": [ "You do not have permission to use this {resource name}." ]`                  |
| `{value}` for `{attribute}` is out of choices                                        | 400 Bad Request | `"{attribute}": [ ""{value}" is not a valid choice." ]`                                         |
| Max `{number}` of `{resource}` exceeded                                              | 400 Bad Request | `"detail": "Limit of {number} {resource} has been exceeded.", "error_code": "ERR_LIMIT_EXCEEDED"` |
| Max `{number}` `{sub-resource}` per `{resource}` exceeded                            | 400 Bad Request | `"detail": [ "Limit of {number} {sub-resource} for the {resource} has been exceeded." ]`        |
| Insufficient permissions                                                             | 403 Forbidden   | `"detail": "You do not have permission to perform this action."`                                |
| Resource instance with `"id"` does not exist                                         | 404 Not Found   | `"detail": "Not found."`                                                                        |

##### Permission fields

| Error                                                | Response code   | Message                                                              |
|------------------------------------------------------|-----------------|----------------------------------------------------------------------|
| Invalid `{resource}` key for permissions `{attribute}` | 400 Bad Request | `"{attribute}": [ "Invalid resource "{resource}"." ]`                |
| Invalid `{action}` given for resource                | 400 Bad Request | `"{attribute}": [ ""{action}" is not a valid choice." ]`             |
| Value of different type than list given for resource | 400 Bad Request | `"{attribute}": [ "Expected a list of items but got type "{type}"." ]` |

##### File fields

| Error             | Response code   | Message                                 |
|-------------------|-----------------|-----------------------------------------|
| Invalid file type | 400 Bad Request | `"{attribute}": [ "Invalid file type." ]` |

#### Non-modifiable properties

If a value for a non-modifiable property is supplied in the request body, it should be silently ignored unless the endpoint explicitly documents a different behaviour.

#### Preventing some fields from being updated

Some fields can be set during creation but cannot be changed via PATCH.

Instead of returning an error for fields that are only valid during creation, use `apps.api.mixins.CreateOnlyFieldsMixin`.

By adding the mixin to a serializer, the update request will silently ignore those fields.

```python
class ObjectClassFormDetailSerializer(CreateOnlyFieldsMixin, ...):
    ...
    class Meta:
        ...
        create_only_fields = (
            'object_class',
            'type',
        )
```

***

## GET standards

In most cases, the GET method can return:

* a list of items
* a single item in detail form, with an extended set of attributes

### Common standards for list and detail views

#### Serializer text fields with empty values

Text fields such as `description` should allow an empty string (`""`). `NULL` values are not accepted, even if the underlying model allows them. Existing `NULL` values should be serialized as empty strings.

```python
description = serializers.CharField(..., default="")
```

#### Labels

If a list request, for example `/api/task-templates/`, returns a property of type set or enum as a list of integers representing related object IDs:

```json
"task_templates": [1, 2]
```

then the detail request for the same resource, for example `/api/task-templates/{id}/`, should return the same property in the same format:

```json
"task_templates": [1, 2]
```

Additional labels should be provided in the helper `_meta` parameter:

```json
"_meta": {
  "labels": {
    "task_templates": [
      "task template name 1",
      "task template name 2"
    ]
  }
}
```

### List standards

#### Filtering predicates

Legend:

* `+` - operator available for the specific data type
* `c.ins.` - case insensitive

| Predicate            | Operator      | int | uuid | string | url | date | datetime | enum | set | bool | phone | email | user | owners |
|----------------------|---------------|-----|------|--------|-----|------|----------|------|-----|------|-------|-------|------|--------|
| Equal                | =             | +   | +    | +      | +   | +    | +        | +    | +   | +    | +     | +     | +    | +      |
| Equal (c.ins.)       | iexact=       |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Is Empty             | isempty=      |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Contains             | contains=     |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Contains (c.ins.)    | icontains=    |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Starts with          | startswith=   |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Starts with (c.ins.) | istartswith=  |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Ends with            | endswith=     |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Ends with (c.ins.)   | iendswith=    |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Is NULL              | isnull=       | +   |      |        |     | +    | +        | +    | +   |      |       |       | +    | +      |
| Lower than           | lt=           | +   |      |        |     | +    | +        |      |     |      |       |       |      |        |
| Lower/equal than     | lte=          | +   |      |        |     | +    | +        |      |     |      |       |       |      |        |
| Greater than         | gt=           | +   |      |        |     | +    | +        |      |     |      |       |       |      |        |
| Greater/equal than   | gte=          | +   |      |        |     | +    | +        |      |     |      |       |       |      |        |
| Range                | range=        | +   |      |        |     | +    | +        |      |     |      |       |       |      |        |
| Is in                | in=           |     |      |        |     |      |          | +    |     |      |       |       | +    | +      |
| Contains all         | containsall=  |     |      |        |     |      |          |      | +   |      |       |       |      |        |
| Contains some        | containssome= |     |      |        |     |      |          |      | +   |      |       |       |      |        |

Filtering by primary key of integer type does not support `isnull` because a primary key cannot be `NULL`.

Relational complex fields such as `created_by` and `modified_by` should not be sortable, because they require complex queryset annotations and may cause performance degradation.

Operator examples:

* `name=`
* `name__startswith=`
* `created_at__gte=`

To negate an operator, use `!`:

* `name!=`
* `name__endswith!=`
* `count__lt!=`

Example:

```text
/api/object-classes/?id__gte=2005
```

#### Error handling

| Error                                                      | Response code   | Message                                                                                      |
|------------------------------------------------------------|-----------------|----------------------------------------------------------------------------------------------|
| Value for filtering by enum `{parameter}` is out of choices  | 400 Bad Request | `"{parameter}": [ "Select a valid choice. That choice is not one of the available choices." ]` |
| `{value}` for filtering by set `{parameter}` is out of choices | 400 Bad Request | `"{parameter}": [ "“"{value}"” is not a valid value." ]`                                     |
| Value for filtering by date/time `{parameter}` is invalid    | 400 Bad Request | `"{parameter}": [ "Enter a valid date/time." ]`                                              |
| `{value}` for ordering is out of available parameters        | 400 Bad Request | `"ordering": [ "Select a valid choice. {value} is not one of the available choices." ]`      |

### Detail standards

#### Invalid IDs in the URL

If the `id` or `uuid` in the URL does not match a resource, return:

* `404 Not Found`

***

## DELETE standards

DELETE endpoints should return `204 No Content` on success.

### Standard response content

* Success status: `204 No Content`
* Response body: empty

### Error handling

#### Invalid IDs in the URL

If the `id` or `uuid` in the URL does not match a resource, return:

* `404 Not Found`

***

## OPTIONS standards

OPTIONS endpoints provide machine-readable metadata about list views, detail schemas, and endpoint restrictions.

### Status code

* Success status: `200 OK`

### Response structure

The response is a JSON object with the following attributes:

* `list`
* `details`
* `restrictions`

```json
{
  "list": {
    "columns": [...]
  },
  "details": {
    "schema": [...]
  },
  "restrictions": {
    "limit_items": 10000
  }
}
```

Each of the above attributes is optional. Their presence depends on the API endpoint being implemented (`list` or `details`) and whether any restrictions apply.

### `list` attribute

Contains information related to the API list view, for example `/api/task-templates/`.

#### `list.columns` attribute

This is a list of fields available in the list view, including whether sorting or filtering is supported.

```json
"columns": [
  {
    "alias": "<string>",
    "type": "<type>",
    "predicates": ["<string>", "..."],
    "sort_ok": "<bool>"
  }
]
```

Each field, regardless of type, is represented by a JSON object with the following attributes:

* `alias` – field alias used to build filtering and sorting queries
* `type` – field type
* `predicates` – list of available filtering predicates; if empty, filtering is not allowed
* `sort_ok` – boolean flag indicating whether sorting is allowed

Additionally, fields of type `enum` and `set` may have:

* `values` – list of JSON objects with predefined values for the field
* `autocomplete` – relative URL to an API endpoint where available values can be obtained

Example:

```json
"columns": [
  {
    "alias": "id",
    "type": "int",
    "predicates": [
      "exact",
      "gt",
      "gte",
      "lt",
      "lte",
      "range"
    ],
    "sort_ok": true
  },
  {
    "alias": "task_group_templates",
    "type": "enum",
    "predicates": [
      "isnull",
      "containsall",
      "containssome"
    ],
    "sort_ok": false,
    "autocomplete": "/api/task-group-templates/autocomplete/?text__icontains="
  },
  {
    "alias": "status",
    "type": "enum",
    "predicates": [
      "exact"
    ],
    "sort_ok": false,
    "values": [
      {
        "value": 1,
        "text": "Active"
      },
      {
        "value": 2,
        "text": "Archived"
      }
    ]
  }
]
```

### `details` attribute

Contains information related to the API detail view, for example `/api/task-templates/{id}/`.

#### `details.schema` attribute

This is a list of JSON objects of two possible kinds:

* Field – represents a single field
* Nested schema – represents multiple fields grouped as a nested structure

##### Fields

A field object describes field requirements for create and detail views.

```json
"schema": [
  {
    "alias": "<string>",
    "type": "<type>",
    "required": "<bool>"
  }
]
```

Each field, regardless of type, is represented by a JSON object with the following attributes:

* `alias` – field alias
* `type` – field type
* `required` – boolean flag indicating whether the field is required

Optionally, the following attributes may also be used:

* `validators` – list of validators used to check whether the value is valid

```json
"validators": ["<json>", "<json>"]
```

Each validator has at least a `type` attribute and may include additional attributes depending on its type.

```json
{
  "type": "<string>"
}
```

Supported validators:

| Type           | Options                      | Description                    |
|----------------|------------------------------|--------------------------------|
| min\_length     | minimal number of characters | Validates minimum string length |
| max\_length     | maximum number of characters | Validates maximum string length |
| min\_value      | minimal allowed value        | Validates minimum numeric value |
| max\_value      | maximum allowed value        | Validates maximum numeric value |
| date\_in\_future |                              | Validates that a date is in the future |

Additionally, fields of type `enum` and `set` may have:

* `values` – list of JSON objects with predefined values for the field
* `autocomplete` – relative URL to an API endpoint where available values can be obtained

Example:

```json
"schema": [
  {
    "alias": "name",
    "type": "string",
    "required": true,
    "validators": [
      {
        "type": "min_length",
        "length": 1
      },
      {
        "type": "max_length",
        "length": 255
      }
    ]
  },
  {
    "alias": "time_unit",
    "type": "enum",
    "required": true,
    "values": [
      {
        "value": "days",
        "text": "days"
      },
      {
        "value": "weeks",
        "text": "weeks"
      },
      {
        "value": "months",
        "text": "months"
      }
    ]
  }
]
```

##### Nested schema

```json
"schema": [
  {
    "alias": "<string>",
    "schema": ["<json>"]
  }
]
```

A nested schema aggregates multiple fields into a nested JSON object. It always contains at least:

* `alias` – alias of the group
* `schema` – list of fields or another nested schema

Optionally, it may also contain:

* `schema_by_<alias>` – used when the schema depends on the value of another field
* `validators` – list of validators that apply to the entire group of fields

###### Schema by value from a different field

`schema_by_<alias>` means that the schema depends on the value of another field.

At least two attributes are required:

* `alias` – field whose value affects the schema
* `schema` – list of fields in the schema

Example:

```json
{
  "alias": "plugin_config",
  "schema": [
    {
      "alias": "task_type",
      "type": "string",
      "required": true,
      "values": [
        {
          "value": "tt_form",
          "text": "Form"
        }
      ]
    }
  ],
  "schema_by_type": [
    {
      "task_type": "tt_form",
      "schema": [
        {
          "alias": "task_type",
          "schema": [
            {
              "alias": "data_type",
              "type": "string",
              "required": true,
              "values": [
                {
                  "value": "t_form",
                  "text": "Form"
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}
```

###### Related validators

If a validator applies only to some fields in the group, an `apply_to` attribute is used to specify which fields are affected.

Supported validators:

| Type       | Options                              | Description                                   |
|------------|--------------------------------------|-----------------------------------------------|
| max\_length | maximal number of items in the group | Validates the maximum number of items allowed |

Example:

```json
{
  "alias": "reminders",
  "schema": [
    {
      "alias": "notice_type",
      "type": "enum",
      "required": true,
      "values": [
        {
          "value": "task_complete_by",
          "text": "Task to Complete by"
        },
        {
          "value": "task_overdue",
          "text": "Task Overdue"
        }
      ]
    }
  ],
  "validators": [
    {
      "type": "max_length",
      "length": 1,
      "apply_to": {
        "alias": "notice_type",
        "value": "task_complete_by"
      }
    },
    {
      "type": "max_length",
      "length": 10,
      "apply_to": {
        "alias": "notice_type",
        "value": "task_overdue"
      }
    }
  ]
}
```

For the above example:

* only 1 reminder of `notice_type="task_complete_by"` is allowed
* a maximum of 10 reminders of `notice_type="task_overdue"` are allowed

### `restrictions` attribute

Contains any restrictions enforced for a particular endpoint.

***

## Autocomplete

Some related API endpoints use data stored as an `enum` or `set` type.

In these cases, the `OPTIONS` request may include an autocomplete relative URL such as:

```text
/api/users/autocomplete/
```

Only `GET` requests are available on these endpoints.

***

## Restrictions based on limits

When an endpoint is limited by the number of objects that can be created, the response should be:

```text
HTTP 403 Forbidden
```

with the following response body:

```json
{
  "detail": "Limit of {limit} {object_name} has been exceeded.",
  "error_code": "ERR_LIMIT_EXCEEDED"
}
```

---

---
url: /api/standards/index_old.md
---
# API standards

This page outlines the API standards that must be enforced in Autologyx API.

## Data types

The data in the API is categorized by type.

| Type        | Notes                                    |
|-------------|------------------------------------------|
| int         | Integer                                  |
| uuid        | UUID                                     |
| string      |                                          |
| url         |                                          |
| date        |                                          |
| datetime    |                                          |
| enum        | Consists of predefined values            |
| set         |                                          |
| bool        |                                          |
| email       |                                          |
| json        | JSON                                     |
| user        | Complex object of system user attributes |
| user\_group  | Complex object describing user\_group     |
| owners      | Complex object describing owners         |
| permissions | Complex object describing permissions    |

## Data structures

If the response schema is complex, the following data structures can be used for categorization.
The contents should later be described in a separate table.

In case of less complex nested structures, standard `nested.property` syntax can be used instead.

| Type        | Notes                                    |
|-------------|------------------------------------------|
| Array       | A JSON array                             |
| Object      | A JSON object                            |

### User type

Example:

```json
{
    "id": 23,
    "first_name": "John",
    "last_name": "Smith",
    "username": "j.smith@autologyx.com",
    "company_name": "Autologyx",
    "is_deleted": false,
    "account_type": "super_admin"
}
```

### Owners type

Type used for resources managed by owners. Value is complex object contains:

* total number of owners
* first assigned owner, by added at date and time (user type)

Sample:

```json
{
    "total_number": 1,
    "first": {
        "id": 13,
        "first_name": "John",
        "last_name": "Smith",
        "username": "j.smith@autologyx.com",
        "company_name": "Autologyx",
        "is_deleted": false,
        "account_type": "full"
    }
}
```

## Insufficient permissions

| Error                                                                                    | Response code   | Message                                                                      |
|------------------------------------------------------------------------------------------|-----------------|------------------------------------------------------------------------------|
| User is authenticated but has not enough permissions to perform method on an endpoint    | 403 Forbidden   | "detail": "You do not have permission to perform this action."               |
| User has not permission to given resource's instance PK used as value for an {attribute} | 400 Bad Request | "{attribute}": \[ "You do not have permission to use this {resource name}." ] |

## POST standards

### Standard response content

`201 Created` status code is returned on success.

### Error handling

#### Invalid payload properties

* Common

| Error                                                                                | Response code   | Message                                                                                         |
|--------------------------------------------------------------------------------------|-----------------|-------------------------------------------------------------------------------------------------|
| {attribute} is missing                                                               | 400 Bad Request | "{attribute}": \[ "This field is required." ]                                                    |
| {attribute} is empty string                                                          | 400 Bad Request | "{attribute}": \[ "This field may not be blank." ]                                               |
| {attribute} is null                                                                  | 400 Bad Request | "{attribute}": \[ "This field may not be null." ]                                                |
| {attribute} has > {number} chars                                                     | 400 Bad Request | "{attribute}": \[ "Ensure this field has no more than {number} characters." ]                    |
| {attribute} is not unique                                                            | 400 Bad Request | "{attribute}": \[ "This field must be unique." ]                                                 |
| {attribute} is null                                                                  | 400 Bad Request | "{attribute}": \[ "This field may not be null." ]                                                |
| Value for integer field is different type than int                                   | 400 Bad Request | "{attribute}": \[ "A valid integer is required."]                                                |
| Value of different type than list given for list {attribute}                         | 400 Bad Request | "{attribute}": \[ "Expected a list of items but got type "{type}"." ]                          |
| Primary key value for enum {attribute} is different {type} than int                  | 400 Bad Request | "{attribute}": \[ "Incorrect type. Expected pk value, received {type}." ]                        |
| {resource} instance for given primary key {value} of enum {attribute} does not exist | 400 Bad Request | "{attribute}": \[ "Invalid pk \\"{value}\\" - {resource} does not exist." ]                      |
| User has not perm perm to given resource's instance                                  | 400 Bad Request | "{attribute}": \[ "You do not have permission to use this {resource name}." ]                    |
| {value} for {attribute} is out of choices                                            | 400 Bad Request | "{attribute}": \[ "\\"{value}\\" is not a valid choice." ]                                       |
| Max {number} of {resource} exceeded                                                  | 400 Bad Request | "detail": "Limit of {number} {resource} has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED" |
| Max {number} {sub-resource} per {resource} exceeded                                  | 400 Bad Request | "detail": \[ "Limit of {number} {sub-resource} for the {resource} has been exceeded." ]          |
| Insufficient permissions                                                             | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                  |
| Resource's instance with "id" does not exist                                         | 404 Not Found   | "detail": "Not found."                                                                          |

* Permission fields

| Error                                                | Response code   | Message                                                                |
|------------------------------------------------------|-----------------|------------------------------------------------------------------------|
| Invalid {resource} key for permissions {attribute}   | 400 Bad Request | "{attribute}": \[ "Invalid resource "{resource}"." ]                  |
| Invalid {action} given for resource                  | 400 Bad Request | "{attribute}": \[ ""{action}" is not a valid choice." ]               |
| Value of different type than list given for resource | 400 Bad Request | "{attribute}": \[ "Expected a list of items but got type "{type}"." ] |

* File fields

| Error                        | Response code     | Message                                                                                                          |
|------------------------------|-------------------|------------------------------------------------------------------------------------------------------------------|
| Invalid file's extension     | 400 Bad Request   | "detail": \[ "File extension “{file\_extension}” is not allowed. Allowed extensions are: {allowed\_extensions}." ]  |
| Missing header with filename | 400 Bad Request   | "detail": \[ "Missing filename. Request should include a Content-Disposition header with a filename parameter." ] |
| File size is over {max} size | 400 Bad Request   | "detail": \[ "Max file size is {max} MB." ]                                                                       |

#### Non-modifiable properties

If value for non-modifiable property is given in a request's body, then it is silently ignored.

## URL standards

* URL should contain the dash symbol `-` instead of underscore `_` f.e. `/api/endpoint/action-name/`

## PATCH standards

### Standard response content

`200 OK` status code is returned on success.

### Error handling

#### Invalid IDs in the url

`404 Not Found` status code is returned on not matching `id`/`uuid`.

#### Invalid payload properties

* Common

| Error                                                                                | Response code   | Message                                                                                         |
|--------------------------------------------------------------------------------------|-----------------|-------------------------------------------------------------------------------------------------|
| {attribute} is empty string                                                          | 400 Bad Request | "{attribute}": \[ "This field may not be blank." ]                                               |
| {attribute} is null                                                                  | 400 Bad Request | "{attribute}": \[ "This field may not be null." ]                                                |
| {attribute} has > {number} chars                                                     | 400 Bad Request | "{attribute}": \[ "Ensure this field has no more than {number} characters." ]                    |
| {attribute} is not unique                                                            | 400 Bad Request | "{attribute}": \[ "This field must be unique." ]                                                 |
| {attribute} is null                                                                  | 400 Bad Request | "{attribute}": \[ "This field may not be null." ]                                                |
| Value for integer field is different type than int                                   | 400 Bad Request | "{attribute}": \[ "A valid integer is required."]                                                |
| Value of different type than list given for list {attribute}                         | 400 Bad Request | "{attribute}": \[ "Expected a list of items but got type "{type}"." ]                          |
| Primary key value for enum {attribute} is different {type} than int                  | 400 Bad Request | "{attribute}": \[ "Incorrect type. Expected pk value, received {type}." ]                        |
| {resource} instance for given primary key {value} of enum {attribute} does not exist | 400 Bad Request | "{attribute}": \[ "Invalid pk \\"{value}\\" - {resource} does not exist." ]                      |
| User has not perm perm to given resource's instance                                  | 400 Bad Request | "{attribute}": \[ "You do not have permission to use this {resource name}." ]                    |
| {value} for {attribute} is out of choices                                            | 400 Bad Request | "{attribute}": \[ "\\"{value}\\" is not a valid choice." ]                                       |
| Max {number} of {resource} exceeded                                                  | 400 Bad Request | "detail": "Limit of {number} {resource} has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED" |
| Max {number} {sub-resource} per {resource} exceeded                                  | 400 Bad Request | "detail": \[ "Limit of {number} {sub-resource} for the {resource} has been exceeded." ]          |
| Insufficient permissions                                                             | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                  |
| Resource's instance with "id" does not exist                                         | 404 Not Found   | "detail": "Not found."                                                                          |

* Permission fields

| Error                                                | Response code   | Message                                                                |
|------------------------------------------------------|-----------------|------------------------------------------------------------------------|
| Invalid {resource} key for permissions {attribute}   | 400 Bad Request | "{attribute}": \[ "Invalid resource "{resource}"." ]                  |
| Invalid {action} given for resource                  | 400 Bad Request | "{attribute}": \[ ""{action}" is not a valid choice." ]               |
| Value of different type than list given for resource | 400 Bad Request | "{attribute}": \[ "Expected a list of items but got type "{type}"." ] |

* File fields

| Error              | Response code   | Message                                   |
|--------------------|-----------------|-------------------------------------------|
| Invalid file type  | 400 Bad Request | "{attribute}": \[ "Invalid file type." ]   |

#### Non-modifiable properties

If value for non-modifiable property is given in a request's body, then it is silently ignored.

#### Preventing some fields to be updated

Some fields can be set during creation, but they cannot be changed via PATCH.

Instead of handling errors on fields used with Create request we should use `apps.api.mixins.CreateOnlyFieldsMixin`.

By adding it as a mixing to a serializer, we force silently ignore this field in the update request.

```python
class ObjectClassFormDetailSerializer(CreateOnlyFieldsMixin, ...):
    ...
    class Meta:
        ...
        create_only_fields = (
            'object_class',
            'type',
        )
```

## GET standards

In most cases, the GET method can return:

* list of items
* single item (detail, with extended set of attributes)

### Common (list and detail)

#### Serializer's text fields with empty values

Text fields, like description should allow empty string (""). `NULL` values are not accepted, even if model accepts
them. Existing `NULL` values should be serialized as empty strings.

```python
description = serializers.CharField(..., default="")
```

#### Labels

If list request (like `/api/task-templates/`) data for given property of type set or enum is dispalyed in response
json as a list of integers (idents of related objects):

```json
"task_templates": [1, 2],
```

then details request (like `/api/task-templates/{id}/`) data for given property of type set or enum is displayed
in the same format as a list of integers(idents of related objects):

```json
"task_templates": [1, 2],
```

API will deliver details in additional helper parameter `_meta`

```json
"_meta": {
    "labels": {
        "task_templates": [
            "task template name 1",
            "task template name 2",
        ]
    }
}
```

### List standards

#### Filtering predicates

Legend:

* `+` - operator available for specific data type
* `c.ins.` - case insensitive

| Predicate            | Operator      | int | uuid | string | url | date | datetime | enum | set | bool | phone | email | user | owners |
|----------------------|---------------|-----|------|--------|-----|------|----------|------|-----|------|-------|-------|------|--------|
| Equal                | =             | +   | +    | +      | +   | +    | +        | +    | +   | +    | +     | +     | +    | +      |
| Equal (c.ins.)       | iexact=       |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Is Empty             | isempty=      |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Contains             | contains=     |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Contains (c.ins.)    | icontains=    |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Starts with          | startswith=   |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Starts with (c.ins.) | istartswith=  |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Ends with            | endswith=     |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Ends with (c.ins.)   | iendswith=    |     |      | +      | +   |      |          |      |     |      | +     | +     |      |        |
| Is NULL              | isnull=       | +   |      |        |     | +    | +        | +    | +   |      |       |       | +    | +      |
| Lower than           | lt=           | +   |      |        |     | +    | +        |      |     |      |       |       |      |        |
| Lower/equal than     | lte=          | +   |      |        |     | +    | +        |      |     |      |       |       |      |        |
| Greater than         | gt=           | +   |      |        |     | +    | +        |      |     |      |       |       |      |        |
| Greater/equal than   | gte=          | +   |      |        |     | +    | +        |      |     |      |       |       |      |        |
| Range                | range=        | +   |      |        |     | +    | +        |      |     |      |       |       |      |        |
| Is in                | in=           |     |      |        |     |      |          | +    |     |      |       |       | +    | +      |
| Contains all         | containsall=  |     |      |        |     |      |          |      | +   |      |       |       |      |        |
| Contains some        | containssome= |     |      |        |     |      |          |      | +   |      |       |       |      |        |

Filtering by primary key of integer type does not support `isnull` operator due to primary key cannot be NULL.

Relational complex fields like `created_by`, `modified_by` will not be sortable because we expect performance decrease.
Fields are annotated to response queryset with complex database operations.

> Operator should be used with attribute's name:
>
> * `name=`
> * `name__startswith=`
> * `created_at__gte=`

> To negate an operator, please use `!`
>
> * `name!=`
> * `name__endswith!=`
> * `count__lt!=`

Sample: `/api/object-classes/?id__gte=2005`

#### Error handling

| Error                                                      | Response code   | Message                                                                                      |
|------------------------------------------------------------|-----------------|----------------------------------------------------------------------------------------------|
| Value for filtering by enum {parameter} is out of choices  | 400 Bad Request | "{parameter}": \[ "Select a valid choice. That choice is not one of the available choices." ] |
| {value} for filtering by set {parameter} is out of choices | 400 Bad Request | "{parameter}": \[ "“"{value}"” is not a valid value." ]                                     |
| Value for filtering by date/time {parameter} is invalid    | 400 Bad Request | "{parameter}": \[ "Enter a valid date/time." ]                                                |
| {value} for ordering is out of available parameters        | 400 Bad Request | "ordering": \[ "Select a valid choice. {value} is not one of the available choices." ]        |

### Detail standards

#### Invalid IDs in the url

`404 Not Found` status code is returned on not matching `id`/`uuid`.

## DELETE standards

### Standard response content

`204 No Content` response status code.

Response body is empty.

### Error handling

#### Invalid IDs in the url

`404 Not Found` status code is returned on not matching `id`/`uuid`.

## OPTIONS standards

### Status code

`200 OK` status code is returned on success.

### Response structure

Response is a JSON object with following attributes:

* list
* details
* restrictions

```json
{
    "list": {
        "columns": [...]
    },
    "details": {
        "schema": [...]
    },
    "restrictions": {
        "limit_items": 10000
    }
}
```

Each of the above attributes is optional, it's presence depends on API endpoint being implemented (`list` or `details`) and having any limitations (`restrictions`).

### `list` attribute

Contains information related to API list view e.g. /api/task-templates/

#### `list.columns` attribute

It’s a list of fields available for the listing view with information if sorting or filtering is possible for given
field or not.

```json
"columns": [
    {
        "alias": <string>,
        "type": <type>,
        "predicates": [<string>, ...],
        "sort_ok": <bool>
    },
    ...
]
```

Each field (irrespectively of type) is represented by JSON object with following attributes:

* `alias` – field alias used to build filtering and sorting queries
* `type` – field type
* `predicates` – list with available predicates for filtering, if empty then filtering is not allowed
* `sort_ok` – boolean flag determining if sorting is allowed

Additionally, fields of `enum` and `set` types may have additional keys:

* `values` – list of JSON objects with predefined values for the field:

```json
"values": [
    {
        "value": <value>,
        "text": <label>
    },
    ...
]
```

* `autocomplete` – relative URL to API endpoint where available values can be obtained

Sample:

```json
"columns": [
    {
        "alias": "id",
        "type": "int",
        "predicates": [
            "exact",
            "gt",
            "gte",
            "lt",
            "lte",
            "range"
        ],
        "sort_ok": true
    },
    {
        "alias": "task_group_templates",
        "type": "enum",
        "predicates": [
            "isnull",
            "containsall",
            "containssome"
        ],
        "sort_ok": false,
        "autocomplete": "/api/task-group-templates/autocomplete/?text__icontains="
    },
    {
        "alias": "status",
        "type": "enum",
        "predicates": [
            "exact"
        ],
        "sort_ok": false,
        "values": [
            {
                "value": 1,
                "text": "Active"
            },
            {
                "value": 2,
                "text": "Archived"
            }
        ]
    },
]
```

### `details` attribute

Contains information related to API detail view e.g. `/api/task-templates/{id}/`.

#### `details.schema` attribute

It’s a list of JSON objects that can be of two types:

* Field – represents single field
* Nested schema – represents multiple fields as nested group (more can be found in Task Templates - JSON schema for OPTIONS request )

##### Fields

Field object contain requirements around the field for the create and detail views.

```json
"schema": [
    {
        "alias": <string>,
        "type": <type>,
        "required": <bool>
    },
...
]
```

Each field (irrespectively of type) is represented by JSON object with following attributes:

* `alias` – field alias
* `type` – field type
* `required` - boolean flag determining if field is required

Optionally following attributes may be used:

* `validators` – list of validators that checks if value is correct:

```json
"validators": [<json>, <json>, ...]
```

Where each validator has at least one attribute `type` and depending on it’s `type` additional attributes:

```json
{
    "type": <string>,
    ...
}
```

Supported validators:

| Type            | Options                      | Description                        |
|-----------------|------------------------------|------------------------------------|
| min\_length      | minimal number of characters | Validates min length of string     |
| max\_length      | maximum number of characters | Validates max length of string     |
| min\_value       | minimal allowed value        | Validates min value of number      |
| max\_value       | maximum allowed value        | Validates max value of number      |
| date\_in\_future  |                              | Validates if date is in the future |

Additionally, fields of type `enum` and `set` may have:

* `values` – list of JSON objects with predefined values for the field:

```json
"values": [
    {
        "value": <value>,
        "text": <string>
    },
    ...
]
```

* `autocomplete` - relative URL to API endpoint where available values can be obtained.

Sample:

```json
"schema": [
    {
        "alias": "name",
        "type": "string",
        "required": true,
        "validators": [
            {
                "type": "min_length",
                "length": 1
            },
            {
                "type": "max_length",
                "length": 255
            }
        ]
    },
    {
        "alias": "time_unit",
        "type": "enum",
        "required": true,
        "values": [
            {
                "value": "days",
                "text": "days"
            },
            {
                "value": "weeks",
                "text": "weeks"
            },
            {
                "value": "months",
                "text": "months"
            }
        ]
    },
    ...
]
```

##### Nested schema

```json
"schema": [ 
    { 
        "alias": <string>, 
        "schema": [<json>, ...]
    }, 
    ... 
]
```

Aggregates multiple fields as nested JSON object. Always contains at least two attributes:

* `alias` – alias of a group
* `schema` – list of fields or another nested schema

Optionally following attributes may be used:

* `schema_by_&lt;alias&gt;` – similar to schema attribute but used when schema depends on value of another field.
* `validators` – list of validators that checks if entire group of fields is correct.

###### Schema by value from different field

`schema_by_&lt;alias&gt;` - `alias` is a name of a field on which value a schema depends.

Define the schema of a field when schema depends on another field's value.

At least two obligatory attributes are present:

* `alias` - field name which value affects the schema ("task\_type" in the below example)
* `schema` – list of fields in the schema

Sample:

```json
{
    "alias": "plugin_config",
    "schema": [
        {
            "alias": "task_type",
            "type": "string",
            "required": true,
            "values": [
                {
                    "value": "tt_form",
                    "text": "Form"
                }
            ]
        }
    ],
    "schema_by_type": [
        {
            "task_type": "tt_form",
            "schema": [
                {
                    "alias": "task_type",
                    "schema": [
                        {
                            "alias": "data_type",
                            "type": "string",
                            "required": true,
                            "values": [
                                {
                                    "value": "t_form",
                                    "text": "Form"
                                }
                            ]
                        }
                    ]
                }
            ]
        }
    ]
}
```

###### Related validators

If a validator apply to only some Fields in the group an `apply_to` attribute is used to point which Fields are affected.

Supported validators:

| Type         | Options                              | Description                                    |
|--------------|--------------------------------------|------------------------------------------------|
| max\_length   | maximal number of items in the group | Validates maximal number of items in the group |

Example:

```json
{
    "alias": "reminders",
    "schema": [
        {
            "alias": "notice_type",
            "type": "enum",
            "required": true,
            "values": [
                {
                    "value": "task_complete_by",
                    "text": "Task to Complete by"
                },
                {
                    "value": "task_overdue",
                    "text": "Task Overdue"
                },
                ...
            ]
        }
    ],
    "validators": [
        {
            "type": "max_length",
            "length": 1,
            "apply_to": {
                "alias": "notice_type",
                "value": "task_complete_by"
            }
        },
        {
            "type": "max_length",
            "length": 10,
            "apply_to": {
                "alias": "notice_type",
                "value": "task_overdue"
            }
        },
        ...
    ]
}
```

For above example:

* Only 1 reminder of notice\_type=”task\_complete\_by” is allowed
* Maximum 10 reminders of notice\_type=”task\_overdue” are allowed

### `restrictions` attribute

Contains all kinds of limitations that are enforced for particular endpoint.

## Autocomplete

Some related api endpoint uses data stored as an `enum` or `set` type.
OPTIONS request will contain an autocomplete relative url like:
`/api/users/autocomplete/`. Only `GET` request to this endpoint is avaliable

## Restrictions based on limits

When some endpoint is limited by number of objects to create, the response should be:

```
HTTP 403 Forbidden  
```

with response body:

```json
{
    "detail": "Limit of {limit} {object_name} has been exceeded.",
    "error_code": "ERR_LIMIT_EXCEEDED"
}
```

---

---
url: /api/terminology.md
---
# Api terminology index

This file is built from the saved terminology store.

## /api/integrations/

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** /api/integrations/test/, ALX API standards, authentication objects, AuthenticationObjectData, authorization method, details.schema by type

`**/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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## /api/object class forms/

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Object Class Forms, object classes, form configuration, create form type, standalone forms, custom components, Object Records

`**/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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-forms.md`](/api/catalyst/resources/object-classes/object-class-forms.html)

## 1 Time Completion

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** account type, ERR LIMIT EXCEEDED

**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.

* **Pages:**
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## 1 Time Completion account

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** account type, assignees/users endpoint, Permission Set ID, object classes, Object Class Assignees, Object Class ID, Object Record Assignee

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-owners.md`](/api/catalyst/resources/object-classes/object-class-owners.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-assignees.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-user-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-assignees.html)
  * [`catalyst/resources/object-records/object-record-owners.md`](/api/catalyst/resources/object-records/object-record-owners.html)
  * [`catalyst/resources/object-records/object-record-permission-set-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-assignees.html)

::: details Show 2 more pages

* [`catalyst/resources/object-records/object-record-permission-set-user-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-assignees.html)
* [`catalyst/resources/user-groups/user-group-permission-set-assignees.md`](/api/catalyst/resources/user-groups/user-group-permission-set-assignees.html)

:::

## account type

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Users, User Groups, Object Class Owners, Object Record Owners, 1 Time Completion account, 1 Time Completion, config admin account, meta.permissions, users.list permission

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-owners.md`](/api/catalyst/resources/object-classes/object-class-owners.html)
  * [`catalyst/resources/object-records/object-record-owners.md`](/api/catalyst/resources/object-records/object-record-owners.html)
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## actions

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Object Record permission sets, Object Records Permission Sets, Object Records, object class permission sets, permission dependencies

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)

## Activation link valid period

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** authentication method, password, sso, internal, external, full

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## Actor completed

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

**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**.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## add roles

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** account type, is super admin, meta.permissions

**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.

* **Pages:**
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## adding records

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** extract files, object classes, complete multipart upload, progress update, Object Records changes

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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## additional authorization headers

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** authentication objects, additional parameters, api key, credentials, Adobe Client Credentials, Box Client Credentials

**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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## additional limits

* **Mostly relevant to:** Developers / Integrators, Super Admins
* **Closely related concepts:** limit, count, count and 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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## additional parameters

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** authentication objects, credentials, additional authorization headers, api key, Adobe Client Credentials, Box Client Credentials

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## Admin Context

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Merge fields, Client Context, Constants Context, Date and Time Context, Loop Item Context, Document templates, Email templates, Object Record Merge Fields

**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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## AdminContext

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** ClientContext, ConstantContext, Context Availability by Scope, Context scopes, Context types, DateAndTimeContext, Default Contexts, DefaultScope, Document Generation, DocumentContext, DocumentGenerationScope, EmbeddedDocumentContext

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## Adobe Client Credentials

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** authentication objects, credentials, Box Client Credentials, additional authorization headers, additional parameters

**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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## AI Actors

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Merge fields, API Call actor, ALX system

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## All AI Actors

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Custom filters, Merge Field Rendering, Merge fields, API Call actor

**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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## allow on demand generation

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Document templates, document generation process, generated document, Document Template usage, document templates/verify, document templates/download

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## ALX API standards

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Tasks, object classes, /api/integrations/, /api/integrations/test/

**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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

::: details Show 1 more pages

* [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

:::

## ALX API standards Developers guide

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** object classes, task group templates, assignees added, assignees removed

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.

* **Pages:**
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)
  * [`catalyst/resources/tasks/task-group-templates.md`](/api/catalyst/resources/tasks/task-group-templates.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## ALX Catalyst BE

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /api/files/upload\_url, history storage, presigned S3 URL, API History Event microservice, History Events

**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.

* **Pages:**
  * [`event-history/resources/files.md`](/api/event-history/resources/files.html)

## ALX system

* **Mostly relevant to:** End-users, Configuration admins, Developers / Integrators
* **Closely related concepts:** Merge fields, Document templates, Email templates, Object Record Merge Fields

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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## anonymized

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** assignees, Object Class Assignees, Object Classes Permission Set

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-assignees.html)

## anonymized user assignee removal

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** permission set assignees, object class permission sets, user group permission sets, Object Class Assignees, assignees/users endpoint, assignees/user groups endpoint, Permission Set ID, Object Class ID

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-user-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-assignees.html)
  * [`catalyst/resources/user-groups/user-group-permission-set-assignees.md`](/api/catalyst/resources/user-groups/user-group-permission-set-assignees.html)

## any, password, sso

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** authentication method, external, full, internal, min length, min letters, min lower case, min numbers, min symbols, min upper case, max repeating chars, Activation link valid period

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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## API Actor

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

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.

* **Pages:**
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## API Call

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** API Actor, Local Variable, Merge fields
* **Pages:**
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## API Call actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators, End-users
* **Closely related concepts:** Merge fields, AI Actors, API Call test

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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## API Call test

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** API Call actor, downstream actor, Actor completed

**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.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## API History Event microservice

* **Mostly relevant to:** Super Admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** Tenants, Autologyx main system, client history database, client instance database name, clickhouse default database, client id, client secret, api key, Authorization header, Unauthorized Client

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.

* **Pages:**
  * [`event-history/resources/files.md`](/api/event-history/resources/files.html)
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## api key

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** authentication objects, Tenants, additional authorization headers, additional parameters, Authorization header

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## approval conditions

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** task templates, task creation, approval required

**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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## approval required

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** approval conditions, Next actions

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.

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## array index

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Custom filters, Image embedding, DOCX embedding, Merge fields, Merge Field Rendering, Document templates

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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## Array source

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Loop actor, Loop source, loop item, execution context of a single loop iteration, loop iteration index, API Call actor

**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.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## assign users for Object Record Permission Set

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Object Record permission sets, Object Records Permission Sets, Object Records, Object Record Owners, object class permission sets, permission dependencies

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)

## assignees

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Object Class Assignees, Object Records, Object Records Permission Sets, Permission Set ID, assignees added, assignees removed, everyone or members perm set

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-assignees.html)
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.html)

## assignees added

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** assignees removed, event data, field values changed, owner initialized, owners added, owners removed, record created, record deleted, document generated, status initialized, source type

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## assignees removed

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** assignees added, event data, field values changed, owners added, owners removed, owner initialized, record created, record deleted, status initialized, document generated, source type

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## assignees/user groups endpoint

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** permission set assignees, user group permission sets, assignees/users endpoint, Permission Set ID, Users Group Assignees, Users Group ID, user groups.list permission, everyone or members perm set

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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-group-permission-set-assignees.md`](/api/catalyst/resources/user-groups/user-group-permission-set-assignees.html)

## assignees/users endpoint

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Permission Set ID, assignees/user groups endpoint, object class permission sets, Object Class Assignees, Object Class ID, object classes, anonymized user assignee removal, everyone or members perm set

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-user-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-set-user-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-assignees.html)
  * [`catalyst/resources/user-groups/user-group-permission-set-assignees.md`](/api/catalyst/resources/user-groups/user-group-permission-set-assignees.html)

## attached roles ID's after create user

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** auto create user, Azure application SSO, Manageable via Roles, meta.permissions

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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## authenticated user preferences

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** User Preferences, GET /api/users/preferences/{key}/, POST /api/users/preferences/{key}/, preferences key, frontend application layout settings, filtering, sorting, tables columns

**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.

* **Pages:**
  * [`catalyst/resources/users/user-preferences.md`](/api/catalyst/resources/users/user-preferences.html)

## authentication method

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** any, password, sso, external, internal, full

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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## authentication objects

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, additional authorization headers, meta.permissions, Roles, Microsoft Client Credentials, object classes, object class fields

**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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)

## AuthenticationObjectData

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** authentication objects, /api/integrations/, /api/integrations/test/, authorization method, ALX API standards

**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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## 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.

* **Pages:**
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## authorization method

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, authentication objects, AuthenticationObjectData, from email, failure email

**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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## auto create user

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Azure application SSO, Okta tenant (organization) domain, password login only, logout url, Azure tenant identifier

**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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## 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.

* **Pages:**
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## autocomplete relative url

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx API, filtering predicates, nested schema, permission fields, owners type

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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)
  * [`terminology/index.md`](/api/terminology/)

## autocomplete widgets

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** object classes, task templates, task group templates, custom components, ALX API standards

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)
  * [`catalyst/resources/tasks/task-group-templates.md`](/api/catalyst/resources/tasks/task-group-templates.html)
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

## Autologyx

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** authentication objects, credentials, additional authorization headers, additional parameters

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## Autologyx API

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** filtering predicates, list view, detail view, nested schema, ordering, non modifiable properties, permission fields, permissions

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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)
  * [`terminology/index.md`](/api/terminology/)

## Autologyx frontend application

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Object Class Forms, standalone forms, form configuration, custom components, object classes, Object Records

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-forms.md`](/api/catalyst/resources/object-classes/object-class-forms.html)

## Autologyx main system

* **Mostly relevant to:** Super Admins, Developers / Integrators
* **Closely related concepts:** API History Event microservice, client history database, POST /api/initialize tenant, DELETE /api/delete tenant, tenant db, database name, clickhouse default database, Client tenant entry exists
* **Pages:**
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## available resources

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class permission sets, object classes resource, Object Class level, create edit view delete complete assign, edit view delete, list edit view delete

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)

## available use

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** custom components, component status, custom component id, object class create form, object class standalone form, object class summary form, parameter options, meta.permissions, landing page, index url, Custom Component in use, Custom Components Repository

**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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## AWS Event Bridge Lambda

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** ClickHouse database, client history database, event data, event type, ALX API standards Developers guide

**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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## Azure application SSO

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Azure tenant identifier, is word addin enabled, logout url, auto create user, password login only, Okta tenant (organization) domain

**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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## Azure tenant identifier

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Azure application SSO, Okta tenant (organization) domain, logout url, auto create user, password login only

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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## Box Client Credentials

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** authentication objects, credentials, Adobe Client Credentials, additional authorization headers, additional parameters, box subject id, box subject type, expiry applies to, expiry at, api key

**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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## box subject id

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Box Client Credentials, box subject type, authentication objects, credentials, additional parameters

**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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## box subject type

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Box Client Credentials, box subject id, authentication objects, credentials, additional parameters

**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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## buffered events

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Catalyst Websockets API, WebSocket connection, WebSocket response, real time updates, GET /api/users/ws auth/

**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.

* **Pages:**
  * [`websockets/index.md`](/api/websockets/)

## Catalyst

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Catalyst API Reference

**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.

* **Pages:**
  * [`catalyst/index.md`](/api/catalyst/)

## Catalyst API endpoint

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Catalyst Websockets API, GET /api/users/ws auth/, WebSocket connection, real time updates, WebSocket response, buffered events

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.

* **Pages:**
  * [`websockets/index.md`](/api/websockets/)

## Catalyst API Reference

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx API, Catalyst, Catalyst Websockets API, Event History API

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.

* **Pages:**
  * [`catalyst/index.md`](/api/catalyst/)
  * [`terminology/index.md`](/api/terminology/)

## Catalyst Websockets API

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx API, buffered events, Catalyst API endpoint, Catalyst API Reference, GET /api/users/ws auth/, Event History 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.

* **Pages:**
  * [`terminology/index.md`](/api/terminology/)
  * [`websockets/index.md`](/api/websockets/)

## cells

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Catalyst Websockets API, real time updates, rows, record count, WebSocket connection, WebSocket response, buffered events

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.

* **Pages:**
  * [`websockets/index.md`](/api/websockets/)

## Child added/removed event

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Object Models, Related Object Records, removable relation, children limit, multiplicity, modifiable multiplicity, relation depth limit
* **Pages:**
  * [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)

## children limit

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** multiplicity, modifiable multiplicity, object classes, Object Models, relation depth 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.

* **Pages:**
  * [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)

## class fields

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** object classes, Document Template warning, Document Template usage, adding records

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## class id

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** object classes, Object Class Owners, Object Class Owner relations, owner 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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-owners.md`](/api/catalyst/resources/object-classes/object-class-owners.html)

## class relations

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Object Class Forms, object classes, /api/object class forms/, standalone forms, form configuration
* **Pages:**
  * [`catalyst/resources/object-classes/object-class-forms.md`](/api/catalyst/resources/object-classes/object-class-forms.html)

## ClickHouse database

* **Mostly relevant to:** Super Admins, Information Security / Compliance / Analytics, Developers / Integrators
* **Closely related concepts:** client history database, event data, event type, AWS Event Bridge Lambda

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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## clickhouse default database

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** API History Event Health Check, API History Event microservice, Client tenant entry exists, database name, DELETE /api/delete tenant, client history 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.

* **Pages:**
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## Client Context

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Merge fields, Admin Context, Constants Context, Date and Time Context, Loop Item Context, Object Record Merge Fields, Document templates, Email templates

**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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## client history database

* **Mostly relevant to:** Super Admins, Information Security / Compliance / Analytics, Developers / Integrators
* **Closely related concepts:** Tenants, API History Event microservice, ClickHouse database, clickhouse default database, tenant table, Autologyx main system

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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## client id

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** api key, Authorization header, client secret, POST /api/initialize tenant, DELETE /api/delete tenant, Client tenant entry exists, tenant db, database name, client history database, API History Event microservice, Autologyx main system, clickhouse default database

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.

* **Pages:**
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## client instance

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Tenants, Unauthorized Client, client instance database name, GET /api/files/upload\_url, API History Event microservice

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.

* **Pages:**
  * [`event-history/resources/files.md`](/api/event-history/resources/files.html)

## client instance database name

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** client instance, file key prefix, history storage, GET /api/files/upload\_url, file id, API History Event microservice, Tenants

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.

* **Pages:**
  * [`event-history/resources/files.md`](/api/event-history/resources/files.html)

## client secret

* **Mostly relevant to:** Super Admins, Developers / Integrators, Configuration admins
* **Closely related concepts:** client id, POST /api/initialize tenant, Authorization header, api key, tenant db, client history database

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.

* **Pages:**
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## Client tenant entry exists

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** POST /api/initialize tenant, DELETE /api/delete tenant, client id, client secret, tenant db, client history database, database name, Autologyx main system, Authorization header, api key, API History Event microservice, clickhouse default database
* **Pages:**
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## ClientContext

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** AdminContext, ConstantContext, Context Availability by Scope, Context scopes, Context types, DateAndTimeContext, Default Contexts, DefaultScope, Document Generation, DocumentContext, DocumentGenerationScope, EmbeddedDocumentContext

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## Company details

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Company details permissions, GET /api/administration/company details/, OPTIONS /api/administration/company details/, nominated system administrator, meta.permissions

**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.

* **Pages:**
  * [`catalyst/resources/company-details.md`](/api/catalyst/resources/company-details.html)
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)

## Company details permissions

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Company details, GET /api/administration/company details/, OPTIONS /api/administration/company details/, PATCH /api/administration/company details/, meta.permissions, single instance endpoint

**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.

* **Pages:**
  * [`catalyst/resources/company-details.md`](/api/catalyst/resources/company-details.html)

## compatible endpoint supporting uploaded files

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** file token, File uploads Tech design, specific file, store permission, file permissions
* **Pages:**
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)

## complete by

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** expiry, reminders, renewal time unit

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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## complete multipart upload

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** multipart presigned URLs, request presigned url, presigned url, s3 upload id, s3 key, progress update

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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## completed upload files

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Record Uploads, Object Records Uploads API, ALX API standards

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)

## Complex filtering

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** ALX API standards, Next actions, class fields, object classes

**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.

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## component status

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** custom components, Custom Components Repository, Custom Component in use, custom component id, available use

**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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## config admin account

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** account type, add roles, is super admin, meta.permissions

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.

* **Pages:**
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## ConstantContext

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context types, Context scopes, Context Availability by Scope, Default Contexts, AdminContext, ClientContext, DateAndTimeContext, DocumentContext, EmbeddedDocumentContext, DefaultScope, DocumentGenerationScope

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## Constants

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Merge fields, Merge Field Rendering, Custom filters, Document templates

**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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## Constants Context

* **Mostly relevant to:** Configuration admins, Super Admins, End-users
* **Closely related concepts:** Merge fields, Admin Context, Client Context, Date and Time Context, Object Record Merge Fields, Document templates, Email templates, ALX system

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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## Context Availability by Scope

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Context scopes, Context types, Default Contexts, AdminContext, ClientContext, ConstantContext, DateAndTimeContext, DefaultScope, DocumentContext, DocumentGenerationScope, EmbeddedDocumentContext, Document Generation

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## Context scopes

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** Context Availability by Scope, Context types, Default Contexts, DefaultScope, DocumentGenerationScope, AdminContext, ClientContext, ConstantContext, DateAndTimeContext, DocumentContext, EmbeddedDocumentContext, Document Generation

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## Context types

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** AdminContext, ClientContext, ConstantContext, Context Availability by Scope, Context scopes, DateAndTimeContext, Default Contexts, DefaultScope, DocumentContext, DocumentGenerationScope, EmbeddedDocumentContext

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## count

* **Mostly relevant to:** Developers / Integrators, Super Admins, Configuration admins
* **Closely related concepts:** limit, count and limits, additional limits, authentication objects

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## count and limits

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** count, limit, additional limits, authentication objects, custom components, default Task assignees, object class document templates, object class fields, Object Class Owners, object class permission set assignees user groups, object class permission set assignees users, object class permission sets

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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## create edit view delete complete assign

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class permission sets, object classes resource, available resources, Object Class level, tasks, edit view delete, list edit view delete

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)

## create form type

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Object Class Forms, form configuration, object classes, /api/object class forms/, standalone forms, custom components

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-forms.md`](/api/catalyst/resources/object-classes/object-class-forms.html)

## created at

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** created by, Object Record Assignee, assignees/users endpoint, Object Record permission sets, user assignees

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-set-user-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-assignees.html)

## created by

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** created at, Object Record Assignee, Object Record Owners, Object Record Owner ID, assignees/users endpoint

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-owners.md`](/api/catalyst/resources/object-records/object-record-owners.html)
  * [`catalyst/resources/object-records/object-record-permission-set-user-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-assignees.html)

## credentials

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** authentication objects, api key, additional authorization headers, additional parameters, Adobe Client Credentials, Box Client Credentials, box subject id, box subject type, expiry at, expiry applies to, DocuSign

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## current assignees user groups

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Complex filtering, current assignees users, ALX API standards

**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.

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## current assignees users

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Complex filtering, current assignees user groups, ALX API standards, Tasks

**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.

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## custom component id

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** custom components, Custom Component in use, available use, component status, Custom Components Repository, API calls

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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## Custom Component in use

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** custom components, custom component id, component status, available use, meta.permissions

**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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## custom components

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** object classes, meta.permissions, object class fields, standalone forms, upload components, /api/object class forms/, additional limits, ALX API standards

**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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)
  * [`catalyst/resources/landing-page/ui-config.md`](/api/catalyst/resources/landing-page/ui-config.html)
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/object-classes/object-class-forms.md`](/api/catalyst/resources/object-classes/object-class-forms.html)
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)

## Custom Components Repository

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** custom components, custom component id, component status, index url, meta.permissions
* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## Custom filters

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Merge fields, Merge Field Rendering, Document templates, Date and Time Manipulation, array index, Document field alias

**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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## Custom User Group Permission Set

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** user group permission sets, Permission Set type, Special Permission Sets, EVERYONE Permission Set, MEMBERS Permission Set, reserved permission set names, restricted system set, user groups resource, user group owners, permissions object, permission dependencies

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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)

## database name

* **Mostly relevant to:** Super Admins, Developers / Integrators, Configuration admins
* **Closely related concepts:** API History Event microservice, POST /api/initialize tenant, DELETE /api/delete tenant, tenant db, client history database, clickhouse default database, Autologyx main system, Client tenant entry exists

**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.

* **Pages:**
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## Date and Time Context

* **Mostly relevant to:** End-users, Configuration admins
* **Closely related concepts:** Merge fields, ALX system, Admin Context, Client Context, Constants Context, Object Record Merge Fields, Loop Item Context, Document templates, Email templates

**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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## Date and Time Manipulation

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Custom filters, Merge fields, Merge Field Rendering, Document templates

**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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## DateAndTimeContext

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context types, Default Contexts, Context scopes, Context Availability by Scope

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## dedupe

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, details.schema by type

**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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## Default Contexts

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context scopes, Context Availability by Scope, Context types, DefaultScope, AdminContext, ClientContext, ConstantContext, DateAndTimeContext, DocumentContext, EmbeddedDocumentContext, DocumentGenerationScope, Document Generation
* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## default Task assignees

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Sequences, default assignees, task group templates, limit, additional limits, count and limits

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## DefaultScope

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** Context scopes, Context Availability by Scope, Default Contexts, Context types, AdminContext, ClientContext, ConstantContext, DateAndTimeContext, DocumentContext, EmbeddedDocumentContext, DocumentGenerationScope, Document Generation

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## delay activation

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** account type, is super admin, config admin account, add roles, meta.permissions

**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.

* **Pages:**
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## DELETE /api/delete tenant

* **Mostly relevant to:** Developers / Integrators, Super Admins, Configuration admins
* **Closely related concepts:** API History Event microservice, Authorization header, api key, POST /api/initialize tenant, tenant db, client history database, database name, client id, client secret, Client tenant entry exists, clickhouse default database, Autologyx main system

**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.

* **Pages:**
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## delete permission

* **Mostly relevant to:** Super Admins, Configuration admins, Developers / Integrators
* **Closely related concepts:** file permissions, public storage, store permission, list permission, specific file, public file limit

**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.

* **Pages:**
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)

## detail view

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx API, list view, nested schema, non modifiable properties, permission fields, permissions, filtering predicates, ordering

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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)
  * [`terminology/index.md`](/api/terminology/)

## details.schema by type

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, ALX API standards, authentication objects, AuthenticationObjectData, authorization method

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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## display configuration

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** object classes, object class fields, custom components, autocomplete widgets, Object Class usage

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)

## Doc Auto Actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Custom filters, Merge fields, Document templates, DOCX embedding, Image embedding, API Call 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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## Document field alias

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** array index, DOCX embedding, Image embedding, Merge fields, Custom filters, Document templates

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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## document field name

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Record Uploads, Object Records Uploads API, document type, object class fields, object classes, object records.create, completed upload files, error reason

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)

## Document fields

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Object Records, Merge fields, Document Object Structure, document type field, API Call, generated document

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## document generated

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** record created, record deleted, field values changed, status initialized, event data, source type

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## Document Generation

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context Availability by Scope, Context scopes, DocumentGenerationScope, DocumentContext, EmbeddedDocumentContext, Default Contexts, Context types

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## document generation process

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Object Record Documents, generated document, Document templates, Document fields, Merge fields, allow on demand generation

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## Document Object Structure

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Document fields, Merge fields, Document templates

**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.

* **Pages:**
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## Document Picker

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Loop actor, Loop source, Array source, document representation, loop item, execution context of a single loop iteration, loop iteration index, downstream actor

**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.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## document representation

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Document Picker, Loop source, Loop actor, loop item, execution context of a single loop iteration, Array source

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.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## Document Template usage

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** document templates/verify, document templates/download, Object Class Document File, object classes, Merge fields, merge tags, Jinja template syntax, Document Template warning

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)

## Document Template warning

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** document templates/verify, class fields, Document Template usage, Jinja template syntax, merge tags, Merge fields

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)

## Document templates

* **Mostly relevant to:** Configuration admins, Developers / Integrators, End-users
* **Closely related concepts:** Merge fields, Object Records, Object Models, Document fields, allow on demand generation

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)
  * [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## document templates/download

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** object classes, document templates/verify, Object Class Document File, Document Template usage, Merge fields, merge tags, Jinja template syntax, class fields

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)

## document templates/verify

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Document Template usage, document templates/download, Jinja template syntax, Merge fields, merge tags, class fields, object classes, Object Class Document File, Document Template warning

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)

## Document tokens list

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Object Records, Object Class Field options, Object Records API

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)

## document type

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** object classes, document field name, event data, completed upload files

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)

## document type field

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** object class fields, Document fields, document generation process, Document templates, generated document, Merge fields, allow on demand generation, custom components, meta.labels.document, Object Class view

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.

* **Pages:**
  * [`catalyst/resources/landing-page/ui-config.md`](/api/catalyst/resources/landing-page/ui-config.html)
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## DocumentContext

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context types, Context scopes, Context Availability by Scope, Default Contexts, DocumentGenerationScope, EmbeddedDocumentContext

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## DocumentGenerationScope

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** DefaultScope, DocumentContext, EmbeddedDocumentContext, Context Availability by Scope, Context scopes, Context types, Document Generation, Default Contexts

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## DocuSign

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** authentication objects, available system integration, additional authorization headers, additional parameters, api key, app id, Adobe, Adobe Client Credentials, Box

**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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## DOCX embedding

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Custom filters, Document templates, Merge fields, Merge Field Rendering, Document field alias, Image 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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## downstream actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Loop actor, execution context of a single loop iteration, loop item, loop iteration index, Loop source, Array source, Actor completed, Loop item processed

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.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## edit view delete

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class permission sets, object classes resource, object class.view, available resources, Object Class level, list edit view delete, create edit view delete complete assign

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)

## Email templates

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Merge fields, Document templates, Object Record Merge Fields

**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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## EmbeddedDocumentContext

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Document Generation, DocumentContext, DocumentGenerationScope, Context scopes, Context Availability by Scope, Context types

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## ERR LIMIT EXCEEDED

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** object classes, Object Records, permission set assignees, assignees/users endpoint, Object Class Assignees, Permission Set ID, users.list permission, 1 Time Completion account

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-assignees.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-user-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-assignees.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.html)
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)

::: details Show 8 more pages

* [`catalyst/resources/object-records/object-record-permission-set-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-assignees.html)
* [`catalyst/resources/object-records/object-record-permission-set-user-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-assignees.html)
* [`catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.html)
* [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)
* [`catalyst/resources/user-groups/user-group-permission-set-assignees.md`](/api/catalyst/resources/user-groups/user-group-permission-set-assignees.html)
* [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)
* [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)
* [`standards/index.md`](/api/standards/)

:::

## error reason

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Object Record Uploads, Object Records Uploads API, completed upload files, failed count, failed percent

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)

## event data

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics, Configuration admins
* **Closely related concepts:** assignees added, assignees removed, document generated, field values changed, owner initialized, owners added, owners removed, record created, record deleted, source type, status initialized

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## Event History API

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** Autologyx API, Catalyst API Reference, Catalyst Websockets API, filtering predicates, ordering

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.

* **Pages:**
  * [`event-history/index.md`](/api/event-history/)
  * [`terminology/index.md`](/api/terminology/)

## event timestamp

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/tasks/, real time update mechanism, task created, task deleted, task status changed, task assignee added, task assignee removed, task owner added, task owner removed, task id

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.

* **Pages:**
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## event type

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** event data, assignees added, assignees removed, document generated, field id, field name, field type, field value

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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## everyone or members perm set

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** assignees, Object Class Assignees, Permission Set ID, assignees/users endpoint, assignees/user groups endpoint, group permission

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-assignees.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-user-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.html)
  * [`catalyst/resources/user-groups/user-group-permission-set-assignees.md`](/api/catalyst/resources/user-groups/user-group-permission-set-assignees.html)

## everyone perm set

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** members perm set, Object Classes Permission Set, permission set assignees, Permission Set type, user group assignees, Object Class Assignees, user groups, object classes, group permission, ERR LIMIT EXCEEDED

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.html)

## EVERYONE Permission Set

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** MEMBERS Permission Set, Permission Set type, Special Permission Sets, user group permission sets, Custom User Group Permission Set, restricted system set, reserved permission set names, user groups resource

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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)

## execution context of a single loop iteration

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Loop actor, loop item, loop iteration index, Array source, Loop source, downstream actor

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.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## expiry

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Task Templates, complete by, reminders, renewal time unit
* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## expiry applies to

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** authentication objects, expiry at, credentials

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## expiry at

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** authentication objects, credentials, expiry applies to

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## external

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** authentication method, internal, any, password, sso, full

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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## extract files

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** progress update, monitoring update, complete multipart upload, request presigned url, multipart presigned URLs, presigned url, s3 key, s3 upload id

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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## failed count

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Record Uploads, Object Records Uploads API, completed upload files, failed percent, error reason

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)

## failed percent

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Record Uploads, Object Records Uploads API, failed count, error reason, completed upload files, object records.create

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)

## failure email

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, from 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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## field id

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** event data, event type, field name, field type, field value

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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## field name

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** event data, field id, field type, field value, event type

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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## field type

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** event data, event type, field id, field name, field value

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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## field value

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** event data, event type, field id, field name, field type

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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## field values changed

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** record created, record deleted, document generated, status initialized, owner initialized, owners added, owners removed, assignees added, assignees removed, event data, source type

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## file fields

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx API, Catalyst API Reference, nested schema, non modifiable properties

**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.

* **Pages:**
  * [`terminology/index.md`](/api/terminology/)

## file id

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /api/files/upload\_url, History Events, API History Event microservice, presigned S3 URL, history storage, file key prefix

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.

* **Pages:**
  * [`event-history/resources/files.md`](/api/event-history/resources/files.html)

## file key prefix

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** client instance, client instance database name, GET /api/files/upload\_url, file id, presigned S3 URL, history storage, API History Event microservice, History Events, Tenants

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.

* **Pages:**
  * [`event-history/resources/files.md`](/api/event-history/resources/files.html)

## file permissions

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** delete permission, list permission, store permission, specific file, file token, public storage, public file limit, compatible endpoint supporting uploaded files, meta.labels, object record document field, Global scope, File uploads Tech design

**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.

* **Pages:**
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)

## file token

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** compatible endpoint supporting uploaded files, specific file, file permissions, store permission, list permission, delete permission, public storage, public file limit, object record document field, meta.labels, Global scope, File uploads Tech design

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.

* **Pages:**
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)

## File uploads Tech design

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** compatible endpoint supporting uploaded files, file permissions, file token, public storage, specific file, store permission

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)

## filter by

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Merge fields, Document templates, Object Models
* **Pages:**
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## filtered count

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Object Record permission sets, Object Records Permission Sets, Object Records, object class permission sets, permission dependencies

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)

## filtering

* **Mostly relevant to:** End-users, Developers / Integrators
* **Closely related concepts:** authenticated user preferences, frontend application layout settings, GET /api/users/preferences/{key}/, POST /api/users/preferences/{key}/, preferences key, sorting, tables columns, User Preferences

**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.

* **Pages:**
  * [`catalyst/resources/users/user-preferences.md`](/api/catalyst/resources/users/user-preferences.html)

## filtering predicates

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx API, list view, ordering, nested schema

**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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)
  * [`terminology/index.md`](/api/terminology/)

## folder

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, details.schema by type

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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## form configuration

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Object Class Forms, custom components, /api/object class forms/, create form type, standalone forms, object classes, Object Records, Autologyx frontend application, meta.labels, meta.permissions, class relations

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-forms.md`](/api/catalyst/resources/object-classes/object-class-forms.html)

## from email

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, authentication objects, AuthenticationObjectData

**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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## frontend application layout settings

* **Mostly relevant to:** End-users, Developers / Integrators
* **Closely related concepts:** User Preferences, authenticated user preferences, preferences key, GET /api/users/preferences/{key}/, POST /api/users/preferences/{key}/, filtering, sorting, tables columns

**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.

* **Pages:**
  * [`catalyst/resources/users/user-preferences.md`](/api/catalyst/resources/users/user-preferences.html)

## full

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** authentication method, any, password, sso, external, internal

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## generated document

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** document generation process, Document templates, Object Record Documents, Merge fields, Document fields

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## Generic Client Credentials

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** authentication objects, credentials, additional authorization headers, additional parameters, Adobe Client Credentials, Box Client Credentials, api key, expiry applies to

**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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## GET /api/administration/company details/

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Company details, OPTIONS /api/administration/company details/, PATCH /api/administration/company details/, single instance endpoint, meta.permissions, Company details permissions

**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.

* **Pages:**
  * [`catalyst/resources/company-details.md`](/api/catalyst/resources/company-details.html)

## GET /api/files/upload\_url

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** API History Event microservice, presigned S3 URL, History Events, history storage, file id, file key prefix

**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.

* **Pages:**
  * [`event-history/resources/files.md`](/api/event-history/resources/files.html)

## GET /api/history/events

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** event data, event type, ALX API standards Developers guide, client history database, ClickHouse database

**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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## GET /api/history/events/{event\_id}/file

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** event data, event type, ALX API standards Developers guide

**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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

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

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** User Preferences, POST /api/users/preferences/{key}/, preferences key, authenticated user preferences, frontend application layout settings, tables columns, filtering, sorting

**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.

* **Pages:**
  * [`catalyst/resources/users/user-preferences.md`](/api/catalyst/resources/users/user-preferences.html)

## GET /api/users/ws auth/

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Catalyst API endpoint, Catalyst Websockets API, WebSocket connection, WebSocket response, real time updates, buffered events

**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.

* **Pages:**
  * [`websockets/index.md`](/api/websockets/)

## GET /ws/events/object records/

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Records, Object Record ID, Object Class ID, object record created, object record deleted, object record value changed, object record assignee added, object record assignee removed, object record owner added, object record owner initialized, object record owner removed, object record document generated

**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.

* **Pages:**
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)

## GET /ws/events/tasks/

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** real time update mechanism, query string parameter authentication, task created, task deleted, task status changed, task assignee added, task assignee removed, task owner added, task owner removed, task id, event timestamp, Object Class ID

**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.

* **Pages:**
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## Global scope

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** meta.permissions, ALX API standards, /api/integrations/, /api/integrations/test/

**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/.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)
  * [`catalyst/resources/company-details.md`](/api/catalyst/resources/company-details.html)
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## group permission

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** user group assignees, Object Classes Permission Set, Object Record and Permission Set assignee list, Object Class Assignees, assignees, Object Records, object classes, everyone or members perm set, everyone perm set, members perm set

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.html)

## has system fields

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** object classes, object class fields, is system, identifier, is identifier, is unique, display configuration, Object Class usage, meta.permissions

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)

## header key

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** api key, authentication objects, credentials, additional authorization headers, additional parameters

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## History Event microservice

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** event data, event type, ClickHouse database, client history database, AWS Event Bridge Lambda, ALX API standards Developers guide

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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## History Events

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** API History Event microservice, assignees added, assignees removed, document generated, client history database, ClickHouse database

**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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)
  * [`event-history/resources/files.md`](/api/event-history/resources/files.html)

## history storage

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** History Events, GET /api/files/upload\_url, presigned S3 URL, file id, file key prefix, API History Event microservice

**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.

* **Pages:**
  * [`event-history/resources/files.md`](/api/event-history/resources/files.html)

## ID based access

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Merge fields, Object based access, Document templates

**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.

* **Pages:**
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## identifier

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** object class fields, object classes, is identifier, is unique, has system fields, is system, ALX API standards, Object Class usage

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)

## Image embedding

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Custom filters, Merge fields, Merge Field Rendering, Document templates, Document field alias, DOCX 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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## Image Processing

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Merge fields, Document fields, Document templates
* **Pages:**
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## IManage

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** authentication objects, credentials, additional parameters, additional authorization headers

**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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## iManage integration type

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, details.schema by type, authentication objects, AuthenticationObjectData, authorization method

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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## index url

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** custom components, custom component id, component status, Custom Components Repository, meta.permissions

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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## initiated

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Records, Object Records API, object classes, Object Record create permissions, Object Record edit permissions, Object Record Ownership

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)

## integration configuration

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, authentication objects, AuthenticationObjectData, authorization method, details.schema by type, ALX API standards

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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## integration type

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, details.schema by type, authentication objects, AuthenticationObjectData, authorization method, ALX API standards

**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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## Integrations

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, ALX API standards, authentication objects, AuthenticationObjectData, authorization method, details.schema by type

**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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## internal

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** authentication method, any, password, sso, external

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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## is available

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Document fields, API calls, Users

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## is identifier

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** identifier, object class fields, object classes, is unique, is system, has system fields, Object Class usage, display configuration

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)

## is super admin

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** config admin account, account type, add roles, meta.permissions

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.

* **Pages:**
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## 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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)

## is unique

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class fields, object classes, identifier, is identifier, has system fields, is system, display configuration, Object Class usage

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)

## is word addin enabled

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Azure application SSO, auto create user, password login only, logout url, Azure tenant identifier, Okta tenant (organization) domain

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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## Jinja template syntax

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Document Template usage, document templates/verify, Merge fields, merge tags, object classes

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)

## labels.object classes

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** object classes, ALX API standards Developers guide, labels.task templates

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.

* **Pages:**
  * [`catalyst/resources/tasks/task-group-templates.md`](/api/catalyst/resources/tasks/task-group-templates.html)

## labels.task templates

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** task templates, task group templates, labels.object classes, num of task templates, ALX API standards Developers guide

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.

* **Pages:**
  * [`catalyst/resources/tasks/task-group-templates.md`](/api/catalyst/resources/tasks/task-group-templates.html)

## landing page

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** available use, custom components, parameter options, component status, Custom Component in use

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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## last task created

* **Mostly relevant to:** Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** num of tasks created, Task Templates

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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## limit

* **Mostly relevant to:** Developers / Integrators, Super Admins
* **Closely related concepts:** count, count and limits, additional limits

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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## list edit view delete

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class permission sets, object classes resource, object classes, edit view delete, available resources, Object Class level

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)

## list permission

* **Mostly relevant to:** Super Admins, Configuration admins
* **Closely related concepts:** file permissions, public storage, store permission, delete permission, specific file

**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.

* **Pages:**
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)

## list view

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx API, detail view, filtering predicates, ordering, nested schema

**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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)
  * [`terminology/index.md`](/api/terminology/)

## 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.

* **Pages:**
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## logout url

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Azure application SSO, Okta tenant (organization) domain, Azure tenant identifier, auto create user, password login only

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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## Loop actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** API Call actor, Array source, Actor completed

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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## loop item

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Loop actor, execution context of a single loop iteration, loop iteration index, Loop source, Array source

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.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## Loop Item Context

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Loop actor, Merge fields, Object Record Merge Fields, Document templates, Email templates

**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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## Loop item processed

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Loop actor, loop item, execution context of a single loop iteration, loop iteration index, downstream actor, Array source, Loop source, Actor completed

**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.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## loop iteration index

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Loop actor, execution context of a single loop iteration, loop item, Loop source

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.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## Loop source

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Loop actor, Array source, execution context of a single loop iteration, loop item, loop iteration index

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## Manageable via Roles

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** meta.permissions, attached roles ID's after create user, Global scope
* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## manual type Task Templates

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** task group templates, task templates, labels.task templates, num of task templates, ALX API standards Developers guide
* **Pages:**
  * [`catalyst/resources/tasks/task-group-templates.md`](/api/catalyst/resources/tasks/task-group-templates.html)

## max num of files

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Document fields, Object Record Documents, object record field, document type field

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## max repeating chars

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** min length, min letters, min lower case, min numbers, min symbols, min upper case, authentication method, any, password, sso

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

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

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class permission sets, object classes, Object Class level, ERR LIMIT EXCEEDED

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)

## members perm set

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** everyone perm set, Object Classes Permission Set, permission set assignees, user group assignees, Object Class Assignees, Permission Set type, user groups, object classes, group permission

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.html)

## MEMBERS Permission Set

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Permission Set type, Special Permission Sets, EVERYONE Permission Set, user group permission sets, restricted system set, reserved permission set names, Custom User Group Permission Set, user groups resource

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**.

* **Pages:**
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)

## membership

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** num of members, num of owners, meta.permissions, account type

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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

## Merge Field Rendering

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Custom filters, Merge fields, Document templates

**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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## Merge fields

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins, End-users
* **Closely related concepts:** Document templates, Object Records, Document fields, object classes, API Call actor, Send Message, Sequencer actors, Admin Context, AI Actors

**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.

* **Pages:**
  * [`catalyst/resources/company-details.md`](/api/catalyst/resources/company-details.html)
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

::: details Show 2 more pages

* [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)
* [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

:::

## merge tags

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Document Template usage, document templates/verify, Jinja template syntax, Merge fields, class fields

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)

## message templates

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** permissions, Roles, Roles API, meta.permissions

**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.

* **Pages:**
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)

## meta result

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Records, Object Records API

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)

## meta.labels

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** meta.permissions, object classes, ALX API standards, /api/object class forms/, /api/integrations/, /api/integrations/test/, authentication objects, AuthenticationObjectData

**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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)
  * [`catalyst/resources/object-classes/object-class-forms.md`](/api/catalyst/resources/object-classes/object-class-forms.html)
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)
  * [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)

## meta.labels.document

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Record Documents, generated document, Document fields, document generation process

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## meta.labels.files

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Document Template usage, document templates/download, document templates/verify, Object Class Document File, object classes, Merge fields, merge tags

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)

## meta.permissions

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** ALX API standards, object classes, Object Models, Sequences, custom components, Object Records, meta.labels

**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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)
  * [`catalyst/resources/company-details.md`](/api/catalyst/resources/company-details.html)
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)
  * [`catalyst/resources/object-classes/object-class-forms.md`](/api/catalyst/resources/object-classes/object-class-forms.html)
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)

::: details Show 8 more pages

* [`catalyst/resources/object-records/object-record-permission-set-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-assignees.html)
* [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)
* [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)
* [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)
* [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)
* [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)
* [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)
* [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

:::

## Microsoft Client Credentials

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** authentication objects, authorization method, AuthenticationObjectData, /api/integrations/, /api/integrations/test/, Adobe Client Credentials, Box Client Credentials, additional authorization headers, additional parameters

**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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## min length

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** max repeating chars, min letters, min lower case, min numbers, min symbols, min upper case, authentication method, any, password, sso, internal, external, full

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## min letters

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** min length, min lower case, min upper case, min numbers, min symbols, max repeating chars, authentication method, any, password, sso, internal, external, full

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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## min lower case

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** min upper case, min letters, min numbers, min symbols, min length, max repeating chars, authentication method, any, password, sso, internal, external, full, Activation link valid period

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## min numbers

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** min length, min letters, min lower case, min upper case, min symbols, max repeating chars, authentication method, any, password, sso, internal, external, full

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## min symbols

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** min length, min letters, min lower case, min numbers, min upper case, max repeating chars, authentication method, any, password, sso, internal, external, full

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## min upper case

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** min length, min letters, min lower case, min numbers, min symbols, max repeating chars, authentication method, any, password, sso

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## modifiable multiplicity

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** multiplicity, object classes, Object Models, Related Object Records, removable relation, children limit, Relation Lookup, relation depth limit, Child added/removed event

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.

* **Pages:**
  * [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)

## monitoring update

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** progress update, extract files, complete multipart upload, multipart presigned URLs, request presigned url, presigned url, s3 upload id, s3 key

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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## most recently modified Loop actor

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Loop actor, execution context of a single loop iteration, loop item, loop iteration index, downstream 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.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## multipart presigned URLs

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** complete multipart upload, presigned url, request presigned url, s3 key, s3 upload id, progress update, extract files

**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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## multiple Loop connections

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Loop actor, API Call actor, execution context of a single loop iteration, loop iteration index, loop item, downstream actor, API Call test

**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.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## multiplicity

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Object Models, object classes, Related Object Records, modifiable multiplicity, removable relation, children limit, relation depth limit, Relation Lookup, Child added/removed event

**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.

* **Pages:**
  * [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)

## nested merge fields

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Custom filters, Merge Field Rendering, Document templates

**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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## nested properties

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Loop actor, loop item, execution context of a single loop iteration, Array source, loop iteration index

**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.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## 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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)
  * [`terminology/index.md`](/api/terminology/)

## Next actions

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** ALX API standards, current assignees users, current assignees user groups

**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.

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## nominated system administrator

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Company details, Company details permissions, GET /api/administration/company details/, OPTIONS /api/administration/company details/, PATCH /api/administration/company details/, meta.permissions, single instance endpoint, standard message templates, Merge fields, Global scope

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.

* **Pages:**
  * [`catalyst/resources/company-details.md`](/api/catalyst/resources/company-details.html)

## non modifiable properties

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx API, nested schema, permission fields, permissions

**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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)
  * [`terminology/index.md`](/api/terminology/)

## notice type

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** reminders, expiry, complete by, renewal time unit, plugin config

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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## num of members

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** membership, num of owners, autocomplete widgets

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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

## num of owners

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** membership, num of members, meta.permissions, ALX API standards

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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

## num of task templates

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** task group templates, task templates, ALX API standards Developers guide, usage endpoint

**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.

* **Pages:**
  * [`catalyst/resources/tasks/task-group-templates.md`](/api/catalyst/resources/tasks/task-group-templates.html)

## num of tasks created

* **Mostly relevant to:** Configuration admins, Information Security / Compliance / Analytics, Developers / Integrators
* **Closely related concepts:** last task created, Task Templates, API calls

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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## Object based access

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Merge fields, ID based access, Document templates, Document Object Structure, Object Models, object classes

**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.

* **Pages:**
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## Object Class Assignees

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** Object Classes Permission Set, Permission Set ID, Object Class ID, user group assignees, ERR LIMIT EXCEEDED

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-assignees.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-user-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-assignees.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.html)

## object class create form

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** custom components, available use, object class standalone form, object class summary form, custom component id, component status

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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## Object Class Document File

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** document templates/verify, Document Template usage, object classes, document templates/download, Merge fields

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)

## object class document templates

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** limit, count and limits, additional limits, object class fields, object class permission sets

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## Object Class Field options

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object classes, Object Class Ownership, Object Record create permissions, Object Record edit permissions, Object Record Ownership, Object Records, Object Records API, Permission Set

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)

## object class fields

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** object classes, /api/integrations/, additional limits, upload components

**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.

* **Pages:**
  * [`catalyst/resources/landing-page/ui-config.md`](/api/catalyst/resources/landing-page/ui-config.html)
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## Object Class Forms

* **Mostly relevant to:** Configuration admins, Developers / Integrators, End-users, Super Admins
* **Closely related concepts:** /api/object class forms/, Autologyx frontend application, create form type, custom components, form configuration, meta.labels, meta.permissions, object classes, Object Records, standalone 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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-forms.md`](/api/catalyst/resources/object-classes/object-class-forms.html)

## Object Class ID

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Object Class Assignees, Permission Set ID, assignees/users endpoint, assignees

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-assignees.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-user-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-assignees.html)
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## object class ID for Task Templates type

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** autocomplete widgets, object classes, meta.permissions, plugin config

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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## Object Class level

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class permission sets, object classes, maximum number of Object Class Permission Sets per specific Object Class, Object Class Owners, object classes resource

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)

## Object Class Owner relations

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Object Class Owners, Object Class Ownership, object classes, Object Record Owners, owner id, owners list, class id, users.list permission

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-owners.md`](/api/catalyst/resources/object-classes/object-class-owners.html)

## Object Class Owners

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** object classes, object class permission sets, Object Record Owners, object class.edit perm set, object class.view, permission dependencies

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/object-classes/object-class-owners.md`](/api/catalyst/resources/object-classes/object-class-owners.html)
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)

## Object Class Ownership

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** object classes, Object Record Ownership, Object Records, Tasks

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-owners.md`](/api/catalyst/resources/object-classes/object-class-owners.html)
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## object class permission set assignees user groups

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** limit, count and limits, additional limits, object class permission sets, object class permission set assignees users, Object Class Owners, object class fields, object class document templates

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## object class permission set assignees users

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** additional limits, count and limits, limit, object class permission set assignees user groups, object class permission sets

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## Object Class Permission Set permission

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Object Record Permission Set permission, Object Class Ownership, object classes, ALX API standards, Tasks

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## object class permission sets

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** object classes, Object Record permission sets, user groups, Object Class Owners, object class.edit perm set, object class.view, ERR LIMIT EXCEEDED

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-user-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-assignees.html)
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

## object class standalone form

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** custom components, object class create form, object class summary form, custom component id, available use, component status

**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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## object class summary form

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** custom components, available use, object class create form, object class standalone 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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## Object Class usage

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** object classes, object class fields, ALX API standards

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)

## Object Class view

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Document templates, Merge fields, Object Record Documents

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## object class.edit perm set

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class permission sets, Object Class Owners, object class.view, object classes, permission dependencies

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)

## object class.view

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class permission sets, Object Class Owners, object class.edit perm set, object classes, permission dependencies

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)

## object classes

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Object Records, object class fields, Object Class Owners, meta.permissions, Sequences, task templates, task group templates, user groups

**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.

* **Pages:**
  * [`catalyst/resources/landing-page/ui-config.md`](/api/catalyst/resources/landing-page/ui-config.html)
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)
  * [`catalyst/resources/object-classes/object-class-forms.md`](/api/catalyst/resources/object-classes/object-class-forms.html)
  * [`catalyst/resources/object-classes/object-class-owners.md`](/api/catalyst/resources/object-classes/object-class-owners.html)

::: details Show 18 more pages

* [`catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.html)
* [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)
* [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)
* [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
* [`catalyst/resources/object-records/object-record-permission-set-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-assignees.html)
* [`catalyst/resources/object-records/object-record-permission-set-user-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-assignees.html)
* [`catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.html)
* [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)
* [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)
* [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)
* [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)
* [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)
* [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)
* [`catalyst/resources/tasks/task-group-templates.md`](/api/catalyst/resources/tasks/task-group-templates.html)
* [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)
* [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)
* [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)
* [`websockets/resources/files.md`](/api/websockets/resources/files.html)

:::

## Object Classes Document Template

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Document Template usage, document templates/download, document templates/verify, Object Class Document File, class fields, Merge fields, merge tags, Jinja template syntax, allow on demand generation, Document Template warning, meta.labels.files, ERR LIMIT EXCEEDED

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)

## Object Classes owned by user

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** autocomplete widgets, meta.permissions, Object Class usage, object class fields, ALX API standards

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)

## Object Classes Permission Set

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** assignees, group permission, members perm set, everyone perm set, everyone or members perm set, Object Class ID, object classes, permission set assignees, Object Class Assignees

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-assignees.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.html)

## object classes resource

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class permission sets, available resources, Object Class level, object class.view, object class.edit perm set, create edit view delete complete assign, edit view delete, list edit view delete, maximum number of Object Class Permission Sets per specific Object Class, Object Class Owners

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)

## Object Models

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** object classes, meta.permissions, Document templates

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)
  * [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## object name

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Records API, Object Records, object classes

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)

## Object Record and Permission Set assignee list

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** assignees, Object Record ID, Object Records, Object Records Permission Sets, Permission Set ID, user group assignees, user group ids, Object Class Assignees, group permission, everyone or members perm set

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.html)

## Object Record Assignee

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** Object Record permission sets, Object Records, assignees/users endpoint, Object Record Assignees limit, Object Record ID, permission set assignees

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-set-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-set-user-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-assignees.html)

## object record assignee added

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** GET /ws/events/object records/, object record assignee removed, object record owner added, object record owner initialized, object record owner removed, object record value changed, object record created, object record deleted, object record document generated, Object Records, Object Record ID, Object Class ID

**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.

* **Pages:**
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)

## object record assignee removed

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/object records/, object record assignee added, object record owner removed, object record owner added, object record owner initialized, object record created, object record deleted, object record document generated, object record value changed, Object Records, Object Record ID, Object Class ID

**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.

* **Pages:**
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)

## Object Record Assignees limit

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** ERR LIMIT EXCEEDED, Object Record Assignee, Object Record permission sets, Object Records, permission set assignees, Permission Set ID

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-set-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-assignees.html)

## Object Record create permissions

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Permission Set, Object Records, Object Record edit permissions, Object Record Ownership, Object Classes, Object Records API

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)

## object record created

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/object records/, Object Records, Object Record ID, Object Class ID, object record assignee added, object record assignee removed, object record deleted, object record document generated, object record owner added, object record owner initialized, object record owner removed, object record value changed

**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.

* **Pages:**
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)

## object record deleted

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/object records/, object record created, object record value changed, object record assignee added, object record assignee removed, object record owner added, object record owner initialized, object record owner removed, object record document generated, Object Record ID, Object Records, Object Class ID

**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.

* **Pages:**
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)

## object record document field

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** compatible endpoint supporting uploaded files, file permissions, specific file, API calls

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.

* **Pages:**
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)

## object record document generated

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/object records/, object record created, object record deleted, object record value changed, object record assignee added, object record assignee removed, object record owner added, object record owner initialized, object record owner removed, Object Records, Object Record ID, Object Class ID

**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.

* **Pages:**
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)

## Object Record Documents

* **Mostly relevant to:** End-users, Configuration admins, Developers / Integrators
* **Closely related concepts:** Document templates, document generation process, generated document, allow on demand generation, Document fields, Merge fields, object record field, document type field, Object Class view, meta.labels.document, is available, max num of files

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## Object Record edit permissions

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Object Record create permissions, Object Record Ownership, Object Records, Object Records API, Permission Set

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)

## object record field

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Object Record Documents, Document fields, Document templates, document generation process, document type field, Merge fields

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## Object Record History Events

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics, Configuration admins
* **Closely related concepts:** Object Records, Object Records History Events API, event data, field values changed, assignees added, assignees removed, owner initialized, document generated, object classes, Object Records Permission Sets

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)

## Object Record ID

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Object Records, Permission Set ID, assignees, GET /ws/events/object records/

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-owners.md`](/api/catalyst/resources/object-records/object-record-owners.html)
  * [`catalyst/resources/object-records/object-record-permission-set-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.html)
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)

## Object Record Merge Fields

* **Mostly relevant to:** Configuration admins, End-users, Developers / Integrators
* **Closely related concepts:** Merge fields, Document templates, Email templates

**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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## object record owner added

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/object records/, object record assignee added, object record assignee removed, object record created, object record deleted, object record document generated, object record owner initialized, object record owner removed, object record value changed, Object Record ID, Object Records, Object Class ID

**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.

* **Pages:**
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)

## Object Record Owner ID

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Record Owner relations, Object Record Owners, Object Record Ownership, Object Records Owners API, Object Record ID, owner id, Object relation record

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-owners.md`](/api/catalyst/resources/object-records/object-record-owners.html)

## object record owner initialized

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** GET /ws/events/object records/, object record owner added, object record owner removed, object record assignee added, object record assignee removed, object record created, object record deleted, object record document generated, object record value changed, Object Record ID, Object Class ID, Object Records

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.

* **Pages:**
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)

## Object Record Owner relations

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Object Record Owners, Object Record Ownership, Object Records Owners API, Object Record Owner ID, Object Record ID, owner id, created by, Object relation record, users.list permission

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-owners.md`](/api/catalyst/resources/object-records/object-record-owners.html)

## object record owner removed

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/object records/, object record owner added, object record owner initialized, object record assignee added, object record assignee removed, object record created, object record deleted, object record document generated, object record value changed, Object Record ID, Object Class ID, Object Records

**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.

* **Pages:**
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)

## Object Record Owners

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Object Class Owners, object classes, object class permission sets, assign users for Object Record Permission Set, owner id, class id, additional limits, users.list permission

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/object-classes/object-class-owners.md`](/api/catalyst/resources/object-classes/object-class-owners.html)
  * [`catalyst/resources/object-records/object-record-owners.md`](/api/catalyst/resources/object-records/object-record-owners.html)
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)

## Object Record Ownership

* **Mostly relevant to:** Configuration admins, Super Admins, End-users
* **Closely related concepts:** Object Class Ownership, Object Records, object classes

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-owners.md`](/api/catalyst/resources/object-records/object-record-owners.html)
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## object record permission set assignees user groups

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** limit, count and limits, additional limits, object class permission set assignees user groups, object class permission set assignees users, Object Class Owners

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## object record permission set assignees users

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** limit, count and limits, additional limits, object class permission set assignees users, object class permission set assignees user groups, Object Class Owners, default Task assignees, authentication objects

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## Object Record Permission Set permission

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Object Class Permission Set permission, Object Record Ownership, Object Class Ownership, current assignees user groups, current assignees users

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## Object Record permission sets

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** object classes, Object Records, object class permission sets, Object Record Assignee, assign users for Object Record Permission Set, assignees/users endpoint, User Groups, meta.permissions

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-set-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-set-user-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

## Object Record Uploads

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Object Records Uploads API, object records.create, object classes, object class fields, document type, document field name, completed upload files, failed count, failed percent, error reason, meta.permissions, ALX API standards

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)

## object record value changed

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/object records/, object record assignee added, object record assignee removed, object record created, object record deleted, object record document generated, object record owner added, object record owner initialized, object record owner removed, Object Record ID, Object Records

**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.

* **Pages:**
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)

## Object Record view

* **Mostly relevant to:** End-users, Configuration admins
* **Closely related concepts:** Object Record Documents, Object Class view, generated document, Document templates, document generation process, Document fields

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## Object Records

* **Mostly relevant to:** Configuration admins, Developers / Integrators, End-users, Super Admins
* **Closely related concepts:** object classes, Object Record ID, Object Records Permission Sets, Merge fields, Document templates, assignees

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-forms.md`](/api/catalyst/resources/object-classes/object-class-forms.html)
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`catalyst/resources/object-records/object-record-permission-set-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-set-user-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-assignees.html)

::: details Show 7 more pages

* [`catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.html)
* [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)
* [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)
* [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)
* [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)
* [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)
* [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)

:::

## Object Records API

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Object Records, object classes, Object Record create permissions, Object Record edit permissions, Object Record Ownership, Object Class Ownership, Object Class Field options, Permission Set

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)

## Object Records changes

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/object records/, object record created, object record assignee added, object record assignee removed, object classes, Object Class ID, adding records, class fields, monitoring update

**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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)

## Object Records History Events API

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Object Record History Events, Object Records, event data, field values changed, assignees added, assignees removed, owner initialized, document generated, object classes, Object Records Permission Sets

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)

## Object Records Owners API

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Object Record Owners, Object Record Ownership, Object Record Owner relations, Object Record ID, Object Record Owner ID

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-owners.md`](/api/catalyst/resources/object-records/object-record-owners.html)

## object records per object class

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** additional limits, count and limits, limit, count, authentication objects, custom components, object class fields, object class document templates, Object Class Owners, object class permission set assignees user groups, object class permission set assignees users

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## Object Records Permission Sets

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Object Records, assignees, actions, assign users for Object Record Permission Set, everyone or members perm set, object classes

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)

## object records resource

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class permission sets, object classes, available resources, create edit view delete complete assign, edit view delete, list edit view delete, Object Class level

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)

## Object Records Uploads API

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Record Uploads, object records.create, ALX API standards, completed upload files, document field name, document type, error reason, failed count, failed percent, meta.permissions, object class fields, object classes

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)

## object records.create

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** meta.permissions, object classes, Object Record Uploads, Object Records Uploads API, object class fields

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)

## object records.edit permission

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Object Record Documents, Document fields, document generation process, generated document, document type field, Document templates

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## object records.view permission

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Object Record Documents, document generation process, generated document, Document templates, Object Class view

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## Object relation record

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Record Owners, Object Record Owner relations, Object Record Owner ID, Object Records Owners API

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-owners.md`](/api/catalyst/resources/object-records/object-record-owners.html)

## object relations

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** limit, count and limits, additional limits, count

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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## ObjectClass

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Document templates, Document fields, document generation process, authentication objects, AuthenticationObjectData

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## ObjectClassField

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, authentication objects, AuthenticationObjectData, meta.permissions

**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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

## ObjectRecordContext

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context types, Context scopes, Context Availability by Scope, Default Contexts, DefaultScope, Document Generation, DocumentContext, DocumentGenerationScope, AdminContext, ClientContext, ConstantContext, DateAndTimeContext

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## Okta tenant (organization) domain

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Azure application SSO, Azure tenant identifier, logout url, password login only, auto create user

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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## OPTIONS /api/administration/company details/

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Company details, Company details permissions, GET /api/administration/company details/, meta.permissions, PATCH /api/administration/company details/, single instance endpoint

`**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.

* **Pages:**
  * [`catalyst/resources/company-details.md`](/api/catalyst/resources/company-details.html)

## ordering

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx API, filtering predicates, list view, nested schema, permission fields, non modifiable properties, autocomplete relative url

**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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)
  * [`terminology/index.md`](/api/terminology/)

## owner id

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Object Record Owners, Object Class Owners, Object Record Owner ID, class id, Object Class Ownership, Object Class Owner relations

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-owners.md`](/api/catalyst/resources/object-classes/object-class-owners.html)
  * [`catalyst/resources/object-records/object-record-owners.md`](/api/catalyst/resources/object-records/object-record-owners.html)

## owner initialized

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** record created, owners added, owners removed, assignees added, assignees removed, field values changed, record deleted, document generated, status initialized, event data, source type

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## owners

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class fields, Object Class usage, meta.permissions
* **Pages:**
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)

## owners added

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** owner initialized, owners removed, assignees added, assignees removed, record created, record deleted, field values changed, status initialized, event data, source type

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**.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## owners list

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Class Owners, Object Class Owner relations, Object Class Ownership, object classes, class id, owner id

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-owners.md`](/api/catalyst/resources/object-classes/object-class-owners.html)

## owners removed

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** owner initialized, owners added, assignees added, assignees removed, field values changed, record created, record deleted, document generated, status initialized, event data, source type

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## owners type

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Autologyx API, nested schema, permission fields, permissions, user type, user groups

**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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)
  * [`terminology/index.md`](/api/terminology/)

## Paragraph replacement syntax

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Custom filters, Document templates, DOCX embedding, Merge Field Rendering

**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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## parameter options

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** custom components, custom component id, Custom Components Repository

**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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## parameter type

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** custom components, custom component id, component status, index url, landing page, meta.permissions, object class create form, object class standalone form, object class summary form, Custom Components Repository, Custom Component in use, available use

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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## parameters

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** custom components, custom component id, component status, meta.permissions, index url

**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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## Password Complexity

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** min length, min letters, min lower case, min numbers, min symbols, max repeating chars, authentication method, Activation link valid period, any, password, sso, full, internal, external

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## password complexity requirements

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** password prevent reuse, config admin account, account type

**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.

* **Pages:**
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## password login only

* **Mostly relevant to:** Configuration admins, Super Admins, End-users
* **Closely related concepts:** Azure application SSO, auto create user, logout url, Okta tenant (organization) domain, Azure tenant identifier

**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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## password prevent reuse

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** password complexity requirements, config admin account

**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.

* **Pages:**
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## Password rotation interval

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** Activation link valid period, authentication method, any, password, sso, config admin account

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## PATCH /api/administration/company details/

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Company details, Company details permissions, GET /api/administration/company details/, OPTIONS /api/administration/company details/, single instance endpoint, meta.permissions

`**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.

* **Pages:**
  * [`catalyst/resources/company-details.md`](/api/catalyst/resources/company-details.html)

## permission actions

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class permission sets, available resources, create edit view delete complete assign, edit view delete, list edit view delete, Object Class level, object classes

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)

## permission dependencies

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** object class permission sets, object class.edit perm set, object class.view, permissions object, actions, create edit view delete complete assign, Custom User Group Permission Set, assign users for Object Record Permission Set

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)

## permission fields

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Autologyx API, permissions, nested schema, user groups, owners type, user type

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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)
  * [`terminology/index.md`](/api/terminology/)

## Permission Set

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Object Records, assignees, assignees added, assignees removed, event data, object classes, user groups

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)

## permission set assignees

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Permission Set ID, assignees/user groups endpoint, assignees/users endpoint, object classes, ERR LIMIT EXCEEDED, anonymized user assignee removal, everyone or members perm set, everyone perm set, members perm set, group permission, meta.permissions

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-set-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-assignees.html)
  * [`catalyst/resources/user-groups/user-group-permission-set-assignees.md`](/api/catalyst/resources/user-groups/user-group-permission-set-assignees.html)

## Permission Set Assignees limit

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Object Record permission sets, Object Record Assignee, user assignees, assignees/users endpoint, ERR LIMIT EXCEEDED, Object Records

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-set-user-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-assignees.html)

## Permission Set ID

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Object Class ID, Object Record ID, assignees, assignees/users endpoint, Object Class Assignees, everyone or members perm set, Object Records, object classes

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-assignees.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-user-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-set-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.html)
  * [`catalyst/resources/user-groups/user-group-permission-set-assignees.md`](/api/catalyst/resources/user-groups/user-group-permission-set-assignees.html)

## Permission Set Object

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** event data, event type, assignees added, assignees removed

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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## Permission Set type

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Custom User Group Permission Set, EVERYONE Permission Set, MEMBERS Permission Set, Object Classes Permission Set, permission set assignees, Object Class Assignees, group permission

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.html)
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)

## permissions

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** user groups, Autologyx API, ALX API standards Developers guide, nested schema

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)
  * [`catalyst/resources/tasks/task-group-templates.md`](/api/catalyst/resources/tasks/task-group-templates.html)
  * [`standards/index.md`](/api/standards/)
  * [`terminology/index.md`](/api/terminology/)

## permissions object

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** permission dependencies, available resources, create edit view delete complete assign, Custom User Group Permission Set, edit view delete, EVERYONE Permission Set, list edit view delete, maximum number of Object Class Permission Sets per specific Object Class, MEMBERS Permission Set, Object Class level, Object Class Owners

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)

## plugin config

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** task templates, task creation, approval conditions, approval required

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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## POST /api/authentication objects/

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** authentication objects, credentials, api key, additional authorization headers, additional parameters, Adobe Client Credentials, Box Client Credentials, box subject id, box subject type, DocuSign, expiry applies to, Autologyx

`**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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## POST /api/event\_bridge/create\_event

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** AWS Event Bridge Lambda, ClickHouse database, client history database, event data, event type, ALX API standards Developers guide

**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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## POST /api/initialize tenant

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** API History Event microservice, Authorization header, api key, Autologyx main system, client history database, client id, client secret, Client tenant entry exists, database name, DELETE /api/delete tenant, tenant db, clickhouse default database

**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.

* **Pages:**
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

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

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** authenticated user preferences, GET /api/users/preferences/{key}/, preferences key, User Preferences, frontend application layout settings, filtering, sorting, tables columns

`**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.

* **Pages:**
  * [`catalyst/resources/users/user-preferences.md`](/api/catalyst/resources/users/user-preferences.html)

## predefined values

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx API, nested schema, non modifiable properties, permission fields, permissions

**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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)

## preferences key

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** authenticated user preferences, GET /api/users/preferences/{key}/, POST /api/users/preferences/{key}/, User Preferences, frontend application layout settings, tables columns

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.

* **Pages:**
  * [`catalyst/resources/users/user-preferences.md`](/api/catalyst/resources/users/user-preferences.html)

## presigned S3 URL

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** ALX Catalyst BE, API History Event microservice, GET /api/files/upload\_url, History Events, file id, file key prefix, history storage

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.

* **Pages:**
  * [`event-history/resources/files.md`](/api/event-history/resources/files.html)

## presigned url

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** complete multipart upload, event data, ALX API standards Developers guide

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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## Prevent password re use

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** max repeating chars, min length, min letters, min lower case, min numbers, min symbols, authentication method, Activation link valid period, any, password, sso, internal, external, full

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## private rsa key

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** authentication objects, credentials, DocuSign

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## processing

* **Mostly relevant to:** End-users, Configuration admins
* **Closely related concepts:** document generation process, generated document, Object Record Documents, Document templates, allow on demand generation

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## progress update

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** extract files, adding records, monitoring update, Object Records changes

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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## provider

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** authentication objects, Single Sign On Configuration, api key, Adobe Client Credentials, Box Client Credentials, Azure application SSO, Azure tenant identifier, additional parameters

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## provider authorization url

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** Azure application SSO, Okta tenant (organization) domain, logout url, Azure tenant identifier, auto create user

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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## provider integration

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** authentication objects, credentials, additional authorization headers, additional parameters

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## public file limit

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** public storage, store permission, list permission, delete permission, file permissions, specific file, file token, compatible endpoint supporting uploaded files, File uploads Tech design

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.

* **Pages:**
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)

## public files

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** limit, count and limits, additional limits

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## public storage

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** compatible endpoint supporting uploaded files, delete permission, file permissions, file token, File uploads Tech design, list permission, public file limit, specific file, store permission, API calls

**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.

* **Pages:**
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)

## public theme

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** UI Config, UI Config API, UI component

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.

* **Pages:**
  * [`catalyst/resources/landing-page/ui-config.md`](/api/catalyst/resources/landing-page/ui-config.html)

## publisher url

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** custom components, Custom Components Repository, custom component id, component status, index url, landing page, meta.permissions

**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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## query string parameter authentication

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/object records/, GET /ws/events/tasks/

**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.

* **Pages:**
  * [`websockets/resources/object-records.md`](/api/websockets/resources/object-records.html)
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## real time update mechanism

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/tasks/, query string parameter authentication, task created, task deleted, task status changed, task assignee added, task assignee removed, task owner added, task owner removed, event timestamp, task id, Object Class ID

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.

* **Pages:**
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## real time updates

* **Mostly relevant to:** Developers / Integrators, End-users
* **Closely related concepts:** Catalyst Websockets API, WebSocket connection, WebSocket response, GET /api/users/ws auth/, rows, cells, record count, buffered events, Catalyst API endpoint

**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.

* **Pages:**
  * [`websockets/index.md`](/api/websockets/)

## record count

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Catalyst Websockets API, cells, buffered events, Catalyst API endpoint

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)
  * [`websockets/index.md`](/api/websockets/)

## record created

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** owner initialized, owners added, owners removed, assignees added, assignees removed, field values changed, record deleted, document generated, status initialized, event data, source type

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## record deleted

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** record created, field values changed, owner initialized, owners added, owners removed, assignees added, assignees removed, document generated, status initialized, event data, source type

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## record id

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** client history database, event data, event type, field id, ALX API standards Developers guide

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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## record permission sets

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** additional limits, count and limits, limit, object class permission set assignees user groups, object class permission set assignees users

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## record properties

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Merge fields, Document templates, Document fields, Document Object Structure, object classes

**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.

* **Pages:**
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## Record Related Contexts

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context Availability by Scope, Context scopes, Context types, Default Contexts, DefaultScope, AdminContext, ClientContext, ConstantContext, DateAndTimeContext, DocumentContext, Document Generation, DocumentGenerationScope

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## 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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## refresh url

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** authentication objects, additional authorization headers, additional parameters, credentials, expiry applies to

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## related classes

* **Mostly relevant to:** Configuration admins
* **Closely related concepts:** Document Template usage, document templates/verify, Merge fields, merge tags, class fields

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)

## Related Object Records

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Models, Relation Lookup, object classes, meta.permissions, relation depth limit, multiplicity

**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.

* **Pages:**
  * [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)

## Related records

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Merge fields, Document templates, object classes, Document Object Structure

**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.

* **Pages:**
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## related validators

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Autologyx API, nested schema, permission fields, filtering predicates

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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)

## relation depth limit

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** children limit, modifiable multiplicity, multiplicity, object classes, Object Models, Related Object Records, Relation Lookup, removable relation

**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.

* **Pages:**
  * [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)

## Relation Lookup

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Object Models, object classes, removable relation, Related Object Records, multiplicity, modifiable multiplicity
* **Pages:**
  * [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)

## Relational fields

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Custom filters, Constants, Merge Field Rendering, Document templates

**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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## relational MF

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Merge fields, Document templates, Object Record Documents, Document fields, document generation process

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-documents.md`](/api/catalyst/resources/object-records/object-record-documents.html)

## reminders

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Task Templates, notice type, complete by, expiry, renewal time unit, plugin config

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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## removable relation

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** object classes, Object Models, Related Object Records, Relation Lookup, modifiable multiplicity, multiplicity, children limit, relation depth limit, Child added/removed event

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.

* **Pages:**
  * [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)

## renewal time unit

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** expiry, complete by, notice type, reminders, last task created, num of tasks created

**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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## renewal time value

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** complete by, expiry, notice type, reminders, last task created, num of tasks created

**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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## renewals

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** task templates, plugin config, reminders, expiry, complete by, notice type

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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## repository status

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** component status, custom components, Custom Components Repository, custom component id, available use

**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.

* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## request presigned url

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** multipart presigned URLs, presigned url, complete multipart upload, s3 key, s3 upload id

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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## reserved permission set names

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Special Permission Sets, EVERYONE Permission Set, MEMBERS Permission Set, restricted system set, Custom User Group Permission Set, user group permission sets, Permission Set type

**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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)

## resource keys

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** actions, Object Record permission sets, Object Records Permission Sets, assign users for Object Record Permission Set

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)

## resources' permissions configuration

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** object class permission sets, Object Class level, available resources, create edit view delete complete assign, edit view delete, list edit view delete, maximum number of Object Class Permission Sets per specific Object Class, Object Class Owners, object class.edit perm set, object class.view, object classes

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)

## Response state

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** ALX API standards, Next actions, approval conditions

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.

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## restricted system set

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** user group permission sets, Special Permission Sets, Permission Set type, reserved permission set names, EVERYONE Permission Set, MEMBERS Permission Set, permissions object, user groups resource

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)

## Restriction Max Object Records in one Object Class

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object classes, Object Records, Object Records API, Object Record create permissions, Object Record edit permissions, Object Record Ownership, Object Class Ownership, Object Class Field options

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)

## restrictions

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx API, permissions, permission fields, non modifiable properties, list view, detail view, ordering, filtering predicates, nested schema, ERR LIMIT EXCEEDED

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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)

## Result Class filter

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Models, Related Object Records, Relation Lookup, object classes

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.

* **Pages:**
  * [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)

## Roles

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** object class permission sets, object classes, authentication objects, user groups, additional limits, available resources

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)

## Roles API

* **Mostly relevant to:** Developers / Integrators, Super Admins, Configuration admins
* **Closely related concepts:** Roles, permissions, meta.permissions, authentication objects, standard authentication, single sign on, ALX API standards Developers guide, Object Models

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.

* **Pages:**
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)

## ROPC Generic oAuth

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** authentication objects, credentials, additional parameters, additional authorization headers, api key, Adobe Client Credentials, Box Client Credentials, DocuSign, expiry applies to

**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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## rows

* **Mostly relevant to:** Developers / Integrators, End-users
* **Closely related concepts:** Catalyst Websockets API, cells, record count, real time updates, WebSocket response

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.

* **Pages:**
  * [`websockets/index.md`](/api/websockets/)

## s3 key

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** complete multipart upload, multipart presigned URLs, presigned url, request presigned url, s3 upload id

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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## s3 upload id

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** complete multipart upload, multipart presigned URLs, request presigned url, presigned url, s3 key

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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## schema by value

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** nested schema, file fields, non modifiable properties

**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.

* **Pages:**
  * [`terminology/index.md`](/api/terminology/)

## schema by value from different field

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx API, detail view, nested schema

**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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)

## Security Rules

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics, Developers / Integrators
* **Closely related concepts:** Activation link valid period, any, password, sso, authentication method, external, full, internal, max repeating chars, min length, min letters, min lower case, min numbers, min symbols

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## send activation email

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** config admin account, delay activation, password complexity requirements, account type, is super admin, API calls

**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.

* **Pages:**
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## Send Message

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Merge fields, Sequencer actors, API Call, AI Actors, Object Records

**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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## Send Message Actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Custom filters, API Call actor, Merge Field Rendering

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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## Sentry

* **Mostly relevant to:** Developers / Integrators, Super Admins, Configuration admins
* **Closely related concepts:** Merge fields, Document templates, Document fields

**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.

* **Pages:**
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## Sequencer

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** default Task assignees, AI Actors, API Call actor, Document templates, Email templates

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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## Sequencer actors

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** Merge fields, API Call, Send Message, AI Actors, Document templates, Object Records, Admin Context, Client Context

**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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## Sequencer merge fields

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Loop actor, loop item, loop iteration index, execution context of a single loop iteration, downstream actor, Document Picker, document representation, API Call actor, API Call test, Array source, Actor completed, Loop item processed

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## SequencerActorScope

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context Availability by Scope, Context scopes, Context types, Default Contexts, DefaultScope, AdminContext, ClientContext, ConstantContext, DateAndTimeContext, DocumentContext, DocumentGenerationScope

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## Sequences

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** object classes, task group templates, user groups, meta.permissions

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)

::: details Show 3 more pages

* [`catalyst/resources/tasks/task-group-templates.md`](/api/catalyst/resources/tasks/task-group-templates.html)
* [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)
* [`event-history/resources/events.md`](/api/event-history/resources/events.html)

:::

## Service External

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Service Internal, account type, authentication method, Password rotation interval, ERR LIMIT EXCEEDED

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## Service Internal

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Service External, account type, authentication method, Password rotation interval, ERR LIMIT EXCEEDED

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## single instance endpoint

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Company details, GET /api/administration/company details/, OPTIONS /api/administration/company details/, PATCH /api/administration/company details/, meta.permissions, Company details permissions

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.

* **Pages:**
  * [`catalyst/resources/company-details.md`](/api/catalyst/resources/company-details.html)

## Single level processing

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Custom filters, Merge Field Rendering, Document templates

**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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## single sign on

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** permissions, Roles, Roles API, meta.permissions, standard authentication, authentication objects

**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.

* **Pages:**
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)

## Single Sign On Configuration permissions

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Manageable via Roles, meta.permissions, Azure application SSO, Okta tenant (organization) domain, logout url, Azure tenant identifier, auto create user, Global scope

**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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## single sign on configurations

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** authentication objects, Azure application SSO, Azure tenant identifier, auto create user, count and limits

**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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## smtp settings

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, from email, failure email, ALX API standards

**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.

* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## sorting

* **Mostly relevant to:** End-users, Developers / Integrators
* **Closely related concepts:** authenticated user preferences, filtering, frontend application layout settings, GET /api/users/preferences/{key}/, POST /api/users/preferences/{key}/, preferences key, tables columns, User Preferences

**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.

* **Pages:**
  * [`catalyst/resources/users/user-preferences.md`](/api/catalyst/resources/users/user-preferences.html)

## source id

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** event type, event data, field id, field name, field type

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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## source type

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics, Configuration admins
* **Closely related concepts:** event data, record created, record deleted, field values changed, owner initialized, owners added, owners removed, assignees added, assignees removed, document generated, status initialized, Sequences

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## Special Permission Sets

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Custom User Group Permission Set, EVERYONE Permission Set, MEMBERS Permission Set, Permission Set type, reserved permission set names, restricted system set, user group permission sets, user groups resource

**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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)

## Specific Class

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** meta.permissions, object classes, object class ID for Task Templates type

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## specific file

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** file permissions, delete permission, list permission, store permission, Global scope, file token

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.

* **Pages:**
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)

## Specific integration configuration

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** /api/integrations/, /api/integrations/test/, authentication objects, AuthenticationObjectData, authorization method, details.schema by type
* **Pages:**
  * [`catalyst/resources/integrations.md`](/api/catalyst/resources/integrations.html)

## Specific single sign on

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Single Sign On Configuration, meta.permissions, Global scope, Manageable via Roles, Azure application SSO, Okta tenant (organization) domain

**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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## SSO state parameter

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** Azure application SSO, Okta tenant (organization) domain, Azure tenant identifier, logout url, auto create user

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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## standalone forms

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** object classes, /api/object class forms/, Autologyx frontend application, form configuration, count and limits

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/object-classes/object-class-forms.md`](/api/catalyst/resources/object-classes/object-class-forms.html)

## standard authentication

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** permissions, Roles, single sign on, meta.permissions, authentication objects, Roles API

**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.

* **Pages:**
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)

## standard document generation workflows

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Document templates, Image embedding, Merge Field Rendering, Custom filters, Doc Auto Actor
* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## Standard merge syntax

* **Mostly relevant to:** Configuration admins, End-users, Developers / Integrators
* **Closely related concepts:** Custom filters, Doc Auto Actor, Document templates, DOCX embedding, Merge Field Rendering

**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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## standard message templates

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Company details, Merge fields

**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.

* **Pages:**
  * [`catalyst/resources/company-details.md`](/api/catalyst/resources/company-details.html)

## standard predicates

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** ALX API standards Developers guide, Roles API, Object Models, object classes

**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.

* **Pages:**
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)

## status initialized

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** record created, owner initialized, document generated, field values changed, event data, source type

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)

## store permission

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** file permissions, public storage, compatible endpoint supporting uploaded files, delete permission, list permission, specific file, public file limit

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.

* **Pages:**
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)

## successful count

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Records Uploads API, Object Record Uploads, failed count, failed percent, error reason, completed upload files

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)

## successful percent

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Record Uploads, Object Records Uploads API, failed percent, failed count, completed upload files, error reason, ALX API standards

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)

## super admin

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** authentication method, any, password, sso, external, internal, full

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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## sync update

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** progress update, monitoring 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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## System fields

* **Mostly relevant to:** Configuration admins, End-users, Developers / Integrators
* **Closely related concepts:** Custom filters, Merge Field Rendering, Constants, Document templates

**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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## system limits API

* **Mostly relevant to:** Developers / Integrators, Super Admins, Configuration admins
* **Closely related concepts:** additional limits, count and limits, limit, count, API calls

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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## System merge fields

* **Mostly relevant to:** Configuration admins, Super Admins, End-users, Developers / Integrators
* **Closely related concepts:** Merge fields, Document templates, Email templates, Admin Context, Client Context, Constants Context, Date and Time Context, Loop Item Context

**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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## system notifications

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Email templates, Merge fields, Document templates, ALX system

**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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## systemconf

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** authentication method, min length, min letters, min lower case, min numbers, min symbols, max repeating chars, Activation link valid period, any, password, sso, internal, external, full

**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.

* **Pages:**
  * [`catalyst/resources/security-rules.md`](/api/catalyst/resources/security-rules.html)

## tables columns

* **Mostly relevant to:** End-users, Developers / Integrators
* **Closely related concepts:** authenticated user preferences, filtering, frontend application layout settings, GET /api/users/preferences/{key}/, POST /api/users/preferences/{key}/, preferences key, sorting, User Preferences

**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.

* **Pages:**
  * [`catalyst/resources/users/user-preferences.md`](/api/catalyst/resources/users/user-preferences.html)

## Task assignee

* **Mostly relevant to:** End-users, Developers / Integrators, Configuration admins
* **Closely related concepts:** current assignees users, current assignees user groups, Tasks, Complex filtering, Next actions

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.

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## task assignee added

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/tasks/, real time update mechanism, task assignee removed, task created, task deleted, task owner added, task owner removed, task status changed

**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.

* **Pages:**
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## task assignee removed

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/tasks/, real time update mechanism, task assignee added, task deleted, task owner removed, task status changed

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.

* **Pages:**
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## Task assignment

* **Mostly relevant to:** Configuration admins, Super Admins, End-users
* **Closely related concepts:** membership, num of members, num of owners

**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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

## task created

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/tasks/, real time update mechanism, task assignee added, task assignee removed, task deleted, task id, task owner added, task owner removed, task status changed, event timestamp

**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.

* **Pages:**
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## task creation

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** task templates, complete by

**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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## task deleted

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/tasks/, real time update mechanism, task created, task status changed, task assignee added, task assignee removed, task owner added, task owner removed, task id, event timestamp, Object Class ID, query string parameter authentication

**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.

* **Pages:**
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## task group templates

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** task templates, object classes, Sequences, meta.permissions, autocomplete widgets

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)
  * [`catalyst/resources/tasks/task-group-templates.md`](/api/catalyst/resources/tasks/task-group-templates.html)
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## task id

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/tasks/, event timestamp, task created, task deleted, task status changed, task assignee added, task assignee removed, task owner added, task owner removed, real time update mechanism

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.

* **Pages:**
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## Task locking

* **Mostly relevant to:** End-users, Configuration admins, Super Admins
* **Closely related concepts:** Next actions, approval required, approval conditions
* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## Task owner

* **Mostly relevant to:** Developers / Integrators, End-users, Configuration admins
* **Closely related concepts:** current assignees users, current assignees user groups, Next actions, Object Record Ownership, Object Class Ownership, Object Class Permission Set permission

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.

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## task owner added

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/tasks/, real time update mechanism, task owner removed, task assignee added, task assignee removed, task created, task deleted, task status changed, task id, event timestamp, Object Class ID, query string parameter authentication

**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.

* **Pages:**
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## task owner removed

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/tasks/, real time update mechanism, task owner added, task assignee removed, task assignee added, task created, task deleted, task status changed, event timestamp, task id

**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.

* **Pages:**
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## Task response

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** ALX API standards, Next actions
* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## task response attachment

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** API calls, file permissions, specific file, compatible endpoint supporting uploaded files

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.

* **Pages:**
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)

## task stages

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** default assignees, default Task assignees, current assignees users, current assignees user groups, task group templates, approval conditions, approval required

**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.

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## Task status

* **Mostly relevant to:** Developers / Integrators, End-users, Configuration admins
* **Closely related concepts:** ALX API standards, Complex filtering, Next actions

**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.

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## task status changed

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/tasks/, real time update mechanism, task created, task deleted, task assignee added, task assignee removed, task owner added, task owner removed, event timestamp, task id

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.

* **Pages:**
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## task template form

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** custom components, object class create form, object class standalone form, object class summary form
* **Pages:**
  * [`catalyst/resources/custom-components.md`](/api/catalyst/resources/custom-components.html)

## Task Template permissions

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** meta.permissions, object class ID for Task Templates type, object classes, plugin config
* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## Task Template usage

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** API calls, num of tasks created, last task created, meta.permissions, object class ID for Task Templates type, object classes

**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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## task templates

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** task group templates, tasks, object classes, meta.permissions, autocomplete widgets, object class fields

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)
  * [`catalyst/resources/tasks/task-group-templates.md`](/api/catalyst/resources/tasks/task-group-templates.html)
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

::: details Show 1 more pages

* [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

:::

## Task Templates API

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** object class ID for Task Templates type, object classes, meta.permissions, plugin config, approval conditions, complete by, expiry, notice type, reminders, last task created, num of tasks created

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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## Task Templates autocomplete

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** autocomplete widgets, API calls, Task Templates

**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.

* **Pages:**
  * [`catalyst/resources/tasks/task-templates.md`](/api/catalyst/resources/tasks/task-templates.html)

## Task Templates JSON schema for OPTIONS request

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** nested schema, Autologyx API
* **Pages:**
  * [`standards/index.md`](/api/standards/)

## task type

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Complex filtering, ALX API standards, Next actions

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**.

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## task value changed

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/tasks/, real time update mechanism, task created, task deleted, task assignee added, task assignee removed, task owner added, task owner removed, task id, event timestamp, Object Class ID, query string parameter authentication

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.

* **Pages:**
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## TaskContext

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context types, Context scopes, Context Availability by Scope, Default Contexts, DefaultScope, Document Generation, DocumentContext, DocumentGenerationScope, AdminContext, ClientContext, ConstantContext, DateAndTimeContext

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## tasks

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** Object Records, actions, filter by, filtered count, ID based access

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## Tasks events

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** GET /ws/events/tasks/, real time update mechanism, query string parameter authentication, task created, task deleted, task assignee added, task assignee removed, task owner added, task owner removed, task id, event timestamp, Object Class ID

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.

* **Pages:**
  * [`websockets/resources/tasks.md`](/api/websockets/resources/tasks.html)

## tasks resource

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** object class permission sets, available resources, create edit view delete complete assign, object classes

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-sets.md`](/api/catalyst/resources/object-classes/object-class-permission-sets.html)

## temp upload id

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** multipart presigned URLs, presigned url, request presigned url, complete multipart upload, s3 key

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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## template file

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Document Template usage, document templates/download, document templates/verify, Object Class Document File, Jinja template syntax, Merge fields, merge tags, class fields

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)

## Templates panel

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Document templates, Custom filters, Merge Field Rendering, Document field alias, DOCX embedding, Image embedding, Doc Auto Actor

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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## temporary file

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** compatible endpoint supporting uploaded files, file token, specific 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.

* **Pages:**
  * [`catalyst/resources/files.md`](/api/catalyst/resources/files.html)

## tenant db

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** API History Event microservice, client history database, Client tenant entry exists, POST /api/initialize tenant, DELETE /api/delete tenant, client id, Authorization header, api key, database name, clickhouse default database, Autologyx main system, client secret

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.

* **Pages:**
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## tenant table

* **Mostly relevant to:** Developers / Integrators, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** client history database, Tenants, API History Event microservice, ClickHouse database, clickhouse default database, Autologyx main system

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.

* **Pages:**
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## Tenants

* **Mostly relevant to:** Developers / Integrators, Super Admins, Configuration admins
* **Closely related concepts:** API History Event microservice, client history database, tenant table, additional authorization headers, additional parameters, Microsoft Client Credentials, api key

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)
  * [`event-history/resources/events.md`](/api/event-history/resources/events.html)
  * [`event-history/resources/files.md`](/api/event-history/resources/files.html)
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## Test button

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

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.

* **Pages:**
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## token url

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** authentication objects, credentials, additional authorization headers, additional parameters, Adobe Client Credentials, Box Client Credentials, expiry applies to

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## top parents limit

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Object Models, object classes, children limit, relation depth limit, multiplicity, modifiable multiplicity

**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.

* **Pages:**
  * [`catalyst/resources/relational-model/object-models.md`](/api/catalyst/resources/relational-model/object-models.html)

## total count

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** filtered count, Object Record permission sets, Object Records Permission Sets, Object Records, actions

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-sets.md`](/api/catalyst/resources/object-records/object-record-permission-sets.html)

## transaction creator

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** complete multipart upload, multipart presigned URLs, presigned url, request presigned url

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## tt object record update

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** object classes, Object Record Ownership, class fields

**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.

* **Pages:**
  * [`catalyst/resources/tasks/tasks.md`](/api/catalyst/resources/tasks/tasks.html)

## UI component

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** UI Config, UI Config API, custom components, upload components, public theme

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.

* **Pages:**
  * [`catalyst/resources/landing-page/ui-config.md`](/api/catalyst/resources/landing-page/ui-config.html)

## UI Config

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** UI component, UI Config API, custom components, upload components, public theme, document type field, object class fields, object classes

**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.

* **Pages:**
  * [`catalyst/resources/landing-page/ui-config.md`](/api/catalyst/resources/landing-page/ui-config.html)

## UI Config API

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** UI Config, UI component, custom components, upload components, public theme

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.

* **Pages:**
  * [`catalyst/resources/landing-page/ui-config.md`](/api/catalyst/resources/landing-page/ui-config.html)

## UI configurations

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** limit, count and limits, additional limits, custom components

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## unassign roles

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** add roles, meta.permissions, is super admin, account type, API calls

**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.

* **Pages:**
  * [`catalyst/resources/users/users.md`](/api/catalyst/resources/users/users.html)

## Unauthorized API Key

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** API History Event Health Check, API History Event Version, GET /api/healthz/, GET /api/files/upload\_url, generic endpoints, API History Event microservice
* **Pages:**
  * [`event-history/resources/files.md`](/api/event-history/resources/files.html)

## Unauthorized Client

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** client id, Authorization header, api key, Tenants, API History Event microservice

**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**."

* **Pages:**
  * [`event-history/resources/files.md`](/api/event-history/resources/files.html)
  * [`event-history/resources/tenants.md`](/api/event-history/resources/tenants.html)

## upload complete

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** complete multipart upload, multipart presigned URLs, presigned url, request presigned url, progress update, s3 key

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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## upload components

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** custom components, object classes, object class fields, display configuration

**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.

* **Pages:**
  * [`catalyst/resources/landing-page/ui-config.md`](/api/catalyst/resources/landing-page/ui-config.html)
  * [`catalyst/resources/object-classes/object-classes.md`](/api/catalyst/resources/object-classes/object-classes.html)

## upload id

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** upload session, complete multipart upload, completed upload files

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## upload process

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** complete multipart upload, multipart presigned URLs, presigned url, request presigned url, progress update, s3 key

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.

* **Pages:**
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## upload session

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** upload id, complete multipart upload, completed upload files, error reason, failed count, extract files, document field name, document type, adding records

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)
  * [`websockets/resources/files.md`](/api/websockets/resources/files.html)

## upload summary

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Object Record Uploads, Object Records Uploads API, completed upload files, failed count, failed percent, error reason, ALX API standards, meta.permissions

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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-uploads.md`](/api/catalyst/resources/object-records/object-record-uploads.html)

## uploaded file token

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Object Class Document File, Document Template usage, document templates/verify, document templates/download

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-document-templates.md`](/api/catalyst/resources/object-classes/object-class-document-templates.html)

## url key

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** api key, authentication objects, credentials, additional authorization headers, additional parameters

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.

* **Pages:**
  * [`catalyst/resources/authentication/authentication-objects.md`](/api/catalyst/resources/authentication/authentication-objects.html)

## usage endpoint

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Sequences, ALX API standards, ALX API standards Developers guide, membership, num of members, num of owners, meta.permissions

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.

* **Pages:**
  * [`catalyst/resources/tasks/task-group-templates.md`](/api/catalyst/resources/tasks/task-group-templates.html)
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

## user assignees

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** assignees/users endpoint, Object Record Assignee, Object Record permission sets, Object Records, Permission Set Assignees limit

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-set-user-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-assignees.html)

## user group assignees

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** Object Classes Permission Set, Object Record and Permission Set assignee list, Object Class Assignees, assignees, group permission, object classes, Object Records, members perm set, everyone perm set, everyone or members perm set, Object Record ID

**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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.html)
  * [`catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.html)

## user group ids

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** user group assignees, Object Records Permission Sets, Permission Set ID, Object Record and Permission Set assignee list, assignees

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.html)

## user group members

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** limit, count and limits, additional limits, object class permission set assignees user groups, default Task assignees

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## User group objects

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Merge fields, Object based access, ID based access, Document Object Structure

**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.

* **Pages:**
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## user group owners

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** user group permission sets, Custom User Group Permission Set, MEMBERS Permission Set, EVERYONE Permission Set, limit, count and limits, ERR LIMIT EXCEEDED

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)

## user group permission sets

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** user groups, object class permission sets, user group owners, assignees/user groups endpoint, assignees/users endpoint, ALX API standards, ERR LIMIT EXCEEDED, additional limits

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/user-groups/user-group-permission-set-assignees.md`](/api/catalyst/resources/user-groups/user-group-permission-set-assignees.html)
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

## user groups

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** permissions, object classes, Autologyx API, nested schema, meta.permissions, authentication objects

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.html)
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)
  * [`catalyst/resources/roles.md`](/api/catalyst/resources/roles.html)

::: details Show 3 more pages

* [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)
* [`standards/index.md`](/api/standards/)
* [`terminology/index.md`](/api/terminology/)

:::

## User Groups API

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** membership, num of members, num of owners, ALX API standards, API calls

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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

## user groups resource

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Custom User Group Permission Set, EVERYONE Permission Set, MEMBERS Permission Set, permission dependencies, Permission Set type, permissions object, reserved permission set names, restricted system set, Special Permission Sets, user group owners, user group permission sets

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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)

## user groups.edit perm set

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** user group permission sets, Custom User Group Permission Set, user group owners, Permission Set type, permissions object, permission dependencies, Special Permission Sets, EVERYONE Permission Set, MEMBERS Permission Set, reserved permission set names, restricted system 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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)

## user groups.list permission

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** assignees/user groups endpoint, permission set assignees, user group permission sets, Users Group Assignees, Users Group ID

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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-group-permission-set-assignees.md`](/api/catalyst/resources/user-groups/user-group-permission-set-assignees.html)

## user groups.view

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** user group permission sets, Custom User Group Permission Set, permission dependencies, permissions object, user group owners

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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-group-permission-sets.md`](/api/catalyst/resources/user-groups/user-group-permission-sets.html)

## User Preferences

* **Mostly relevant to:** End-users, Developers / Integrators, Configuration admins
* **Closely related concepts:** frontend application layout settings, authenticated user preferences, GET /api/users/preferences/{key}/, limit, count and limits

**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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)
  * [`catalyst/resources/users/user-preferences.md`](/api/catalyst/resources/users/user-preferences.html)

## user type

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Autologyx API, nested schema, owners type, permission fields, permissions, user groups, non modifiable properties

**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.

* **Pages:**
  * [`standards/index.md`](/api/standards/)
  * [`terminology/index.md`](/api/terminology/)

## User type fields

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Object Records, user groups, assignees, assignees added, assignees removed, API Actor, API Call

**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.

* **Pages:**
  * [`catalyst/resources/object-records/object-record-history-events.md`](/api/catalyst/resources/object-records/object-record-history-events.html)
  * [`catalyst/resources/object-records/object-records.md`](/api/catalyst/resources/object-records/object-records.html)
  * [`merge-fields/resources/object-record-merge-fields.md`](/api/merge-fields/resources/object-record-merge-fields.html)

## UserContext

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** AdminContext, ClientContext, ConstantContext, Context Availability by Scope, Context scopes, Context types, DateAndTimeContext, Default Contexts, DefaultScope, Document Generation, DocumentContext, DocumentGenerationScope

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## UserFieldContext

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context types, Context scopes, Context Availability by Scope, Default Contexts, DefaultScope

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## UserFieldMetaContext

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context types, Context scopes, Context Availability by Scope, Default Contexts, DefaultScope

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## users combined autocomplete

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** autocomplete widgets, Task assignment, membership, ALX API standards

**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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

## Users Group Assignees

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** permission set assignees, user group permission sets, Users Group ID, Permission Set ID, assignees/user groups endpoint, ERR LIMIT EXCEEDED, everyone or members perm set, anonymized user assignee removal

**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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-group-permission-set-assignees.md`](/api/catalyst/resources/user-groups/user-group-permission-set-assignees.html)

## Users Group ID

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** assignees/user groups endpoint, permission set assignees, Permission Set ID, user group permission sets, Users Group Assignees, user groups.list permission

**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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-group-permission-set-assignees.md`](/api/catalyst/resources/user-groups/user-group-permission-set-assignees.html)

## users group permission set assignees user groups

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** limit, count and limits, additional limits, object class permission set assignees user groups, object class permission set assignees users, default Task assignees

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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## users group permission set assignees users

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** limit, count and limits, additional limits, object class permission set assignees users, object class permission set assignees user groups, default Task assignees

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.

* **Pages:**
  * [`catalyst/resources/limits.md`](/api/catalyst/resources/limits.html)

## users search in

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** autocomplete widgets, membership, Task assignment, ALX API standards

`**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.

* **Pages:**
  * [`catalyst/resources/user-groups/user-groups.md`](/api/catalyst/resources/user-groups/user-groups.html)

## users.list permission

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Object Record Owners, Object Class Assignees, Permission Set ID, Object Class ID, Object Record ID, owner id

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.

* **Pages:**
  * [`catalyst/resources/object-classes/object-class-owners.md`](/api/catalyst/resources/object-classes/object-class-owners.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-assignees.html)
  * [`catalyst/resources/object-classes/object-class-permission-set-user-assignees.md`](/api/catalyst/resources/object-classes/object-class-permission-set-user-assignees.html)
  * [`catalyst/resources/object-records/object-record-owners.md`](/api/catalyst/resources/object-records/object-record-owners.html)
  * [`catalyst/resources/object-records/object-record-permission-set-assignees.md`](/api/catalyst/resources/object-records/object-record-permission-set-assignees.html)

## UsersGroupContext

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context types, Context scopes, Context Availability by Scope, Default Contexts, AdminContext, ClientContext, DocumentContext

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## Variable Actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Custom filters, All AI Actors, API Call 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.

* **Pages:**
  * [`merge-fields/resources/custom-filters.md`](/api/merge-fields/resources/custom-filters.html)

## Variable source

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Loop actor, Array source, API Call actor, loop item

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.

* **Pages:**
  * [`merge-fields/resources/sequncer-merge-fields.md`](/api/merge-fields/resources/sequncer-merge-fields.html)

## VariableContext

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context types, Context scopes, Context Availability by Scope, Default Contexts, DefaultScope

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## VariableDocumentContext

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Context types, Context scopes, Context Availability by Scope, DocumentContext, Document Generation, DocumentGenerationScope, Default Contexts

**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.

* **Pages:**
  * [`merge-fields/resources/scopes.md`](/api/merge-fields/resources/scopes.html)

## Variables

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** AI Actors, API Call actor, Merge fields

**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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## WebSocket connection

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Catalyst Websockets API, GET /api/users/ws auth/, Catalyst API endpoint, buffered events, real time updates, WebSocket response

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.

* **Pages:**
  * [`websockets/index.md`](/api/websockets/)

## WebSocket response

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Catalyst Websockets API, WebSocket connection, buffered events, real time updates, GET /api/users/ws auth/

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.

* **Pages:**
  * [`websockets/index.md`](/api/websockets/)

## Word Add in plugin

* **Mostly relevant to:** End-users, Configuration admins
* **Closely related concepts:** Merge fields, Document templates, Email templates
* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## Word Addin

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Azure application SSO, is word addin enabled, logout url, Okta tenant (organization) domain, Azure tenant identifier

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.

* **Pages:**
  * [`catalyst/resources/authentication/sso-config.md`](/api/catalyst/resources/authentication/sso-config.html)

## Workflow notifications

* **Mostly relevant to:** Configuration admins, Developers / Integrators, End-users
* **Closely related concepts:** Merge fields, Document templates, Email templates, API Call actor

**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.

* **Pages:**
  * [`merge-fields/merge-fields.md`](/api/merge-fields/merge-fields.html)

## ws auth

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx API, Catalyst API Reference, Catalyst Websockets API

**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.

* **Pages:**
  * [`terminology/index.md`](/api/terminology/)

---

---
url: /knowledgebase/system-configuration/apis-and-variables.md
---
# Apis And Variables

**Browse the sections below:**

* [Api Call Actor](/knowledgebase/system-configuration/apis-and-variables/api-call-actor/)
* [Local Variable Actor](/knowledgebase/system-configuration/apis-and-variables/local-variable-actor/)
* [Understanding Namespace In Jinja2 For Local Variables](/knowledgebase/system-configuration/apis-and-variables/understanding-namespace-in-jinja2-for-local-variables/)

---

---
url: /knowledgebase/applied-ai.md
---

# Applied AI

**AppliedAI** in Autologyx brings AI into structured, governed workflows so teams can understand, summarise, extract, and act on information without losing control of the underlying process.

Rather than sitting outside the platform as a standalone tool, AppliedAI is designed to work inside Autologyx Catalyst, where it can support human decision-making, automate repetitive analysis, and help organisations process unstructured content at scale.

AppliedAI now includes several complementary patterns:

* **AppliedAI and the Sequencer** - where Catalyst workflow automation initiates outbound requests to AI services, orchestrates the work, and uses responses inside a controlled process.
* **MCP Work** - where approved AI assistants, co-pilots, or autonomous agents use defined tools to work with live Autologyx data and services.
* **MCP Success** - where approved AI assistants use Autologyx Knowledgebase and Customer Success guidance to help users plan, design, and build effective solutions.
* **Security and audit capabilities** - where permissions, auditability, and hard-stop access controls wrap around AppliedAI activity.

![Diagram showing the main AppliedAI capability areas in Autologyx, including AppliedAI and the Sequencer, MCP Work, MCP Success, and security and audit controls](/knowledgebase/images/appliedai-capability-map.png)

## What AppliedAI means in Autologyx

Autologyx combines deterministic workflow automation with AI capabilities that can be used safely, predictably, and at scale.

In practice, that means AI can be used within Sequences, Object records, Task templates, and related workflow steps to help users work faster and more effectively, while still keeping structured business logic, governance, and operational control at the centre of the process.

AppliedAI in Autologyx is designed to support:

* AI inside structured workflows, not outside them
* human-designed processes that are enhanced by AI, not replaced by it
* predictable and auditable outcomes
* model-agnostic implementation, so organisations can use the model that best fits their requirements
* governance, control, and transparency for AI-driven actions
* granular access control for users, co-pilots, autonomous agents, and connected services

## AppliedAI and the Sequencer

The Sequencer can be used to send structured requests to AI services, receive responses, and use those responses in later workflow steps.

This pattern is useful where Catalyst should remain the originator and orchestrator of the process. For example, a Sequence might collect record data, prepare a prompt, send it to an AI model, receive a response, store the result on a record, create a task, or route the work based on the response.

With this pattern, Autologyx acts as a model-agnostic orchestrator. Extraction, classification, summarisation, and similar tasks can be handed off as structured data from Autologyx's deterministic workflow to the most appropriate model or provider for the task.

Catalyst can support this pattern through native AI connectivity, dedicated actors, AI tooling, and outbound REST calls using API-based actors.

**Examples include:**

* sending prompts and record context to OpenAI models
* using Anthropic models where available through a supported integration
* using Azure OpenAI or Azure OpenAI deployments
* using AWS Bedrock to access supported model families
* connecting to privately hosted models or customer-specific AI gateways
* using the API Call actor to call an AI endpoint where there is no native actor
* using vectorisation, text processing, and document conversion to prepare content for AI-assisted processing
* using the Loop Actor and playbook-style Object Classes to run reusable prompt functions across repeated extraction or classification tasks

See [AppliedAI and the Sequencer](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/) for guidance on using AI services from Catalyst workflow automation.

## MCP services

MCP services provide a different AppliedAI pattern.

Instead of Catalyst starting the AI request from a Sequence, MCP allows an approved AI assistant or agent to initiate requests into Autologyx using defined tools. These tools can help the assistant work with Catalyst data, tasks, knowledge, or future configuration capabilities.

![Diagram comparing the Sequencer pattern, where Autologyx initiates outbound AI requests and orchestrates the workflow, with the MCP services pattern, where AI assistants and agents initiate requests into Autologyx](/knowledgebase/images/appliedai-sequencer-vs-mcp-patterns.png)

**Autologyx MCP services are grouped by purpose:**

* **Autologyx MCP Work** is for working with live Catalyst data and tasks. It supports co-pilot style agents, such as Claude Coworker, working alongside users. It can also support controlled autonomous or headless agents where that model is enabled. MCP Work can help agents access Autologyx data and services, read and write to records, assign, manage and complete tasks, generate documents, and work alongside users to maximise productivity.
* **Autologyx MCP Success** is for Knowledgebase, design, planning, and configuration guidance. It allows co-pilots to use Autologyx Knowledgebase and Customer Success experience to help Config Admins and configuration users plan, architect, design, and build powerful workflows and solutions using Autologyx technology.
* **Autologyx MCP Build** is a future capability area for AI-assisted Catalyst configuration, including Object Classes, forms, Task Templates, users, groups, permissions, sequences, and related build components.

See [MCP services](/knowledgebase/applied-ai/mcp-services/) for more information about the MCP service families.

## Working with AI assistants

AppliedAI can also involve direct interaction with AI assistants, such as a desktop AI assistant connected to Catalyst through approved services.

These assistants may help users ask questions, review information, understand tasks, explore records, or get configuration guidance. The exact capability depends on the enabled services, permissions, and customer configuration.

**A key distinction is where the interaction starts:**

* with **AppliedAI and the Sequencer**, Autologyx initiates the outbound request and orchestrates the workflow
* with **AI assistants and MCP services**, the assistant or agent initiates the request into Autologyx through approved tools or APIs

See [Working with AI assistants](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/) for setup guidance, example prompts, and troubleshooting.

## What AppliedAI can help with

AppliedAI capabilities are especially valuable where work is document-heavy, process-driven, and operationally important.

**Typical examples include:**

* understanding and triaging inbound content
* extracting key data points from documents and messages
* classifying records, requests, documents, clauses, or issues
* summarising long or complex content
* supporting allocation, prioritisation, and workflow routing
* improving speed and consistency in high-volume review processes
* helping teams turn unstructured content into structured, actionable information
* helping users understand records, related records, and tasks
* supporting configuration design, planning, and build decisions

Autologyx describes examples such as email intake, assisted triage and allocation, term extraction, content summarisation, and AI-assisted workflow design as part of its AppliedAI approach.

## Why AppliedAI matters

AppliedAI is useful because many operational processes involve large amounts of unstructured information that still need to be handled within a controlled workflow.

By combining AI with deterministic workflow logic, Autologyx helps organisations process work more quickly while still maintaining auditability, predictable handling, and appropriate human oversight. This is particularly important in environments where quality, consistency, and governance matter as much as speed.

AppliedAI is not a replacement for good process design. It is most effective when it is used to support a clear process, with appropriate controls around when AI is used, what information is provided, what action is taken, and when a human should review the result.

## Model-agnostic by design

AppliedAI in Autologyx is designed to be **model agnostic**.

This means organisations can choose the model that best matches their technical, commercial, or governance requirements, and can evolve that choice over time without having to redesign the surrounding workflow. In practical terms, the workflow remains stable while the underlying AI model can change as needs or technologies change.

Different customers may use different AI providers, hosted models, private endpoints, or agent platforms depending on their requirements. AppliedAI documentation explains the patterns that sit around those choices, not only the provider-specific setup.

## Built for security, audit, and control

AppliedAI in Autologyx is intended for serious operational use, particularly in environments where trust, governance, and compliance matter.

Security and audit capabilities should wrap around AppliedAI activity. That includes every tool call, every edit, and every action that reads from or writes to live Catalyst data.

**AppliedAI governance can include:**

* auditability of AI-assisted activity
* human-in-the-loop steps where needed
* guardrails around how AI is used
* deterministic usage policies
* enterprise-grade control and security expectations
* clear separation between read-only guidance and actions that change live data
* controlled access for co-pilot and autonomous agent patterns
* granular permissions that can be changed by agent, instance, client matter, or individual record
* hard-stop gated control over what agents and users can access at every level

See [Security, permissions, and governance](/knowledgebase/applied-ai/mcp-services/) for guidance on controlling AppliedAI access and activity.

## Agentic workflows

Agentic workflows describe patterns where an AI assistant or agent can reason across a goal, choose available tools, and carry out steps within defined boundaries.

In Autologyx, agentic workflows should still be designed around governance, permissions, auditability, and clear process ownership. Some use cases may keep a human in the loop at each important decision point. Others may use autonomous or headless agents for tightly controlled work where the risks and permissions are understood.

See [Co-pilot agents and autonomous agents](/knowledgebase/applied-ai/mcp-services/mcp-work/) for more information.

## What you will find in this section

Use this section to understand the main AppliedAI patterns available in Autologyx and where each one fits.

**Browse the sections below:**

* [AppliedAI and the Sequencer](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/) - use AI services from Catalyst workflow automation.
* [OpenAI: GPT Actor](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/) - configure and use the OpenAI GPT actor in Sequences.
* [MCP services](/knowledgebase/applied-ai/mcp-services/) - understand Autologyx MCP Work, MCP Success, and future MCP Build capabilities.
* [Working with AI assistants](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/) - connect and use approved AI assistants with Catalyst.
* [Security, permissions, and governance](/knowledgebase/applied-ai/mcp-services/) - understand access, permissions, attribution, and control.
* [Co-pilot agents and autonomous agents](/knowledgebase/applied-ai/mcp-services/mcp-work/) - understand different agent operating models.

## Things to remember

1. AppliedAI should enhance governed workflows, not bypass them.
2. The Sequencer pattern is best where Catalyst should start and control the AI interaction.
3. MCP services are best where an approved AI assistant or agent needs to use defined Autologyx tools.
4. MCP Work and MCP Success serve different purposes: one works with live data and tasks, while the other supports guidance, planning, and solution design.
5. Read-only guidance and live data actions carry different levels of risk and should be governed differently.
6. Model choice, prompt design, permissions, and auditability should be considered before AppliedAI is used in production workflows.

::: info
AppliedAI in Autologyx is intended to enhance workflows, not bypass them. The workflow remains the backbone of the process, with AI used where it adds the most value.
:::

::: tip
If you are exploring AppliedAI for the first time, start with the pattern that matches your use case: use **AppliedAI and the Sequencer** where Catalyst should call an AI service from a workflow, or use **MCP services** where an approved AI assistant or agent should work with Catalyst through defined tools.
:::

---

---
url: >-
  /api/catalyst/resources/object-classes/object-class-permission-set-assignees.md
---
# Assigning for Object Classes Permission Set

## POST /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/

Endpoint to create `ObjectClassAssignee` model object.
Batch operation - adds single or multiple users (members) as assignees to specific permission set.

### Permissions

Perm to check: `object_class.edit_perm_set` (for individual UObject Class).

### URL parameters

| Key                | Notes             |
|--------------------|-------------------|
| object\_class\_id    | Object Class ID   |
| permission\_set\_id  | Permission Set ID |

### Request Schema

* Headers

```
Request Method: POST
Location: /api/object-classes/{object_class_id}/permission-sets/{permission_set_id}/assignees/
Authorization: JWT access_token
```

* Body

```json
[<int>]
```

In body must be sent list of users ids to be assigned.

```json
[<user_id>, <user_id>]
```

> :warning: 1 Time Completion accounts cannot be assignee.

If some of users is already an assignee for given permission set, then request  should be silently accepted without an error or a warning.

> `created_at` and `created_by` fields are set automatically if relation does not exist.

### Request example

```json
[2734, 7231]
```

### Response example

| Key         | Type     | Notes                                               |
|-------------|----------|-----------------------------------------------------|
| user        | user     |                                                     |
| created\_at  | datetime |                                                     |
| created\_by  | user     |                                                     |

* Status `201 CREATED`
* Body

```json
[
  {
    "user": {
      "id": 100,
      "first_name": "John",
      "last_name": "Smith",
      "company_name": "Company1",
      "username": "john.smith@mail.com",
      "is_deleted": false
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false
    }
  },
  {
    "user": {
      "id": 30078,
      "first_name": "Jack",
      "last_name": "Lee",
      "company_name": "Company1",
      "username": "lee.jack@mail.com",
      "is_deleted": false,
      "account_type": "full"
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false,
      "account_type": "super_admin"
    }
  }
]
```

### Restriction

* Max `100` users ids in one request
* Max `100` items of Object Class Assignees (per Object Class and Permission Set)

### Errors

| Error                                                                                                                 | Response code      | Message                                                                                                             |
|-----------------------------------------------------------------------------------------------------------------------|--------------------|---------------------------------------------------------------------------------------------------------------------|
| Given empty list                                                                                                      | 400 Bad Request    | "detail": \["This list may not be empty."]                                                                           |
| Given different type than list                                                                                        | 400 Bad Request    | "detail": \["Expected a list of items but got type "{type}"."]                                                     |
| List contains item of wrong type                                                                                      | 400 Bad Request    | "detail": \["Incorrect type. Expected pk value, received {type}."]                                                   |
| User does not exist for given ID in list                                                                              | 400 Bad Request    | "detail": \["Invalid pk "{user\_id}" - object does not exist."]                                                     |
| Given ID is for 1 Time Completion account                                                                             | 400 Bad Request    | "detail": \["1 Time Completion account "{user\_id}" cannot be assignee."]                                           |
| Attempt to assign assignees to the everyone or members perm set                                                       | 400 Bad Request    | "detail": \["Assignees can not be set to this permission set type."]                                                 |
| More than 100 items on a list                                                                                         | 400 Bad Request    | "detail": \["Up to 100 items allowed."]                                                                              |
| Limit of Assignees for Object Class and Permission Set exceeded.                                                      | 400 Bad Request    | "detail": "Limit of 100 permission set assignees has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED"            |
| Request user does not have "users.list" permission for the user to be assigned to the Objects Class Permission Set    | 400 Bad Request    | "detail": \["You do not have permission to assign user "{user\_id}" to Object Class Permission Set "{perm\_set\_id}"."] |
| Wrong/not existing `permission_set_id`                                                                                | 404 Not Found      |                                                                                                                     |
| Wrong/not existing `object_class_id`                                                                                  | 404 Not Found      |                                                                                                                     |
| Insufficient permissions                                                                                              | 403 Forbidden      | "detail": "You do not have permission to perform this action."                                                      |

## OPTIONS /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/

Endpoint returns schema for POST and GET.

### Permissions

Requires authentication only.

### URL parameters

| Key                  | Notes             |
|----------------------|-------------------|
| object\_class\_id      | Object Class ID   |
| permission\_set\_id    | Permission Set ID |

### Request schema

* Headers

```
Request Method: OPTIONS
Location: /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/
```

### Response example

* Status `200 OK`
* Body

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "user",
                "type": "user",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [],
                "sort_ok": false
            }
        ]
    },
    "batch": {
        "type": "set",
        "required": true,
        "autocomplete": "/api/users/autocomplete/?account_type!=one_time_completion&text__icontains="
    },
    "restrictions": {
        "limit_items": 100,
        "limit_items_in_batch": 100
    }
}
```

## GET /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/

Endpoint to receive list of `ObjectClassAssignee` model objects for defined Object Class and Permission Set.

### Permissions

Perm to check: `object_class.view`.

### URL parameters

| Key                | Notes             |
|--------------------|-------------------|
| object\_class\_id    | Object Class ID   |
| permission\_set\_id  | Permission Set ID |

### Request schema

* Headers

```
Request Method: GET
Location: /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/
Authorization: JWT access_token
```

### Response

| Key             | Type       | Notes                                                                                    |
|-----------------|------------|------------------------------------------------------------------------------------------|
| limit           | int        |                                                                                          |
| offset          | int        | 	                                                                                        |
| total\_count     | int        | Total number of assignees for specific permission set related to specific object record. |
| filtered\_count  | int        | Number of assignees if some filters are applied.                                         |
| next            | URL / null | Next page URL (null if there is no next page)                                            |
| previous        | URL / null | Previous page URL (null if there is no previous page)                                    |
| results         | Array      | Described in the next table.                                                             |

### Response `results` array

| Key            | Type        | Notes                                                                            |
|----------------|-------------|----------------------------------------------------------------------------------|
| user           | user        | 	                                                                                |
| created\_at     | datetime    | 	                                                                                |
| created\_by     | user        | 	                                                                                |

### Response schema

* Status `200 OK`
* Body:

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str|null>,
  "previous": <str|null>,
  "results": [
    {
      "user": <user>,
      "created_at": <datetime>,
      "created_by": <user>
    }
  ]
} 
```

### Response example

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "user": {
        "id": 11,
        "first_name": "John",
        "last_name": "Smith",
        "company_name": "Company1",
        "username": "john.smith@mail.com",
        "is_deleted": false
      },
      "created_at": "2021-05-18T06:39:17.688341Z",
      "created_by": {
        "id": 5,
        "first_name": "Ann",
        "last_name": "Jackson",
        "company_name": "Company1",
        "username": "ann.jackson@mail.com",
        "is_deleted": false
      }
    }
  ]
}
```

### Sorting

Not available. Results are not sorted - order returned by database.

### Filtering

No filters.

### Errors

| Error                                                                           | Response code | Message                                                        |
|---------------------------------------------------------------------------------|---------------|----------------------------------------------------------------|
| Object Record for `object_class_id` not found.                                  | 403 Forbidden | 	                                                              |
| Permission set for `permission_set_id` not found (for given `object_class_id`). | 404 Not Found | 	                                                              |
| Insufficient permissions                                                        | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## DELETE /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/

Endpoint to remove `ObjectClassAssignee` model objects.
Batch operation - removes users (assignees) from a permission set.
User assigned to the permission set will be removed from assignees also if he is anonymized.

### Permissions

Perm to check: `object_class.edit_perm_sets` (for individual Object Class).

### URL parameters

| Key                 | Notes             |
|---------------------|-------------------|
| object\_class\_id     | Object Class ID   |
| permission\_set\_id   | Permission Set ID |

### Request schema

* Headers

```
Request Method: DELETE
Location: /api/object-classes/{object_class_id}/permission-sets/{permission_set_id}/assignees/
Authorization: JWT access_token
```

* Body

In body must be sent list of Object Class Assignees users ids.

```json
[<user_id>, <user_id>]
```

### Response example

* Status `204 No Content`

### Restrictions

* Max `100` users ids in one request

### Errors

| Error                                        | Response code   | Message                                                                   |
|----------------------------------------------|-----------------|---------------------------------------------------------------------------|
| Given empty list                             | 400 Bad Request | "detail": \["This list may not be empty."]                                 |
| Given different type than list               | 400 Bad Request | "detail": \["Expected a list of items but got type "{type}"."]           |
| List contains item of wrong type             | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]         |
| Assignee does not exist for given ID in list | 400 Bad Request | "detail": \["Invalid pk "{assignee\_id}" - object does not exist."]       |
| More than 100 items on a list                | 400 Bad Request | "detail": \["Up to 100 items allowed."]                                    |
| Wrong/not existing  `permission_set_id`      | 404 Not Found   |                                                                           |
| Wrong/not existing `object_class_id`         | 404 Not Found   |                                                                           |
| Insufficient permissions                     | 403 Forbidden   | "detail": "You do not have permission to perform this action."            |

# Not allowed endpoints

## GET /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/`id`/

### Response example

* Status `405 Method Not Allowed`

## PATCH /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/`id`/

### Response example

* Status `405 Method Not Allowed`

## PUT /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/`id`/

### Response example

* Status `405 Method Not Allowed`

## DELETE /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/`id`/

### Response example

* Status `405 Method Not Allowed`

---

---
url: >-
  /api/catalyst/resources/object-records/object-record-permission-set-assignees.md
---
# Assigning for Object Records Permission Set

This technical design describes API for managing Assigment user for Object Record Permission Set.

Endpoints for managing Permission Set are described in separated document.

Implementation details can be found in external document: [Object Record Permission Sets - Technical Design](https://autologyx.sharepoint.com/:w:/s/Dev/EQ6UwfqnkKdOnyAW0bLBtBABuXBqI3fPHM5JMB38gDBD2A?e=9iOf9s).

## GET /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/

Endpoint to receive list of `ObjectRecordAssignee` model objects for defined Object Record and Permission Set.

### Permissions

Perm to check: `object_record.view` (for individual Object Record). Permission can be checked for example by retrieving details from list of Object Classes (`GET /api/object-records/`): `_meta.permissions`

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| record\_id         | Object Record ID  |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: GET
Location: /api/object-records/{record_id}/permission-sets/{permission_set_id}/assignees/
Authorization: JWT access_token
```

### Response

| Key             | Type       | Notes                                                                                    |
|-----------------|------------|------------------------------------------------------------------------------------------|
| limit           | int        |                                                                                          |
| offset          | int        | 	                                                                                        |
| total\_count     | int        | Total number of assignees for specific permission set related to specific object record. |
| filtered\_count  | int        | Number of assignees if some filters are applied.                                         |
| next            | URL / null | Next page URL (null if there is no next page)                                            |
| previous        | URL / null | Previous page URL (null if there is no previous page)                                    |
| results         | Array      | Described in the next table.                                                             |

### Response `results` array

| Key            | Type        | Notes                                                                            |
|----------------|-------------|----------------------------------------------------------------------------------|
| id             | int         | 	                                                                                |
| user           | user        | 	                                                                                |
| created\_at     | datetime    | 	                                                                                |
| created\_by     | user        | 	                                                                                |

### Response schema

* Status `200 OK`
* Body:

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str|null>,
  "previous": <str|null>,
  "results": [
    {
      "id": <int>,
      "user": <user>,
      "created_at": <datetime>,
      "created_by": <user>
    }
  ]
} 
```

### Response example

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 6,
      "user": {
        "id": 11,
        "first_name": "John",
        "last_name": "Smith",
        "company_name": "Company1",
        "username": "john.smith@mail.com",
        "is_deleted": false
      },
      "created_at": "2021-05-18T06:39:17.688341Z",
      "created_by": {
        "id": 5,
        "first_name": "Ann",
        "last_name": "Jackson",
        "company_name": "Company1",
        "username": "ann.jackson@mail.com",
        "is_deleted": false
      }
    }
  ]
}
```

### Sorting

Not available. Results are not sorted - order returned by database.

### Filtering

No filters.

### Errors

| Error                                                                     | Response code | Message                                                        |
|---------------------------------------------------------------------------|---------------|----------------------------------------------------------------|
| Object Record for `record_id` not found.                                  | 403 Forbidden | 	                                                              |
| Permission set for `permission_set_id` not found (for given `record_id`). | 404 Not Found | 	                                                              |
| Insufficient permissions                                                  | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## POST /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/

Endpoint to create `ObjectRecordPermissionSet` model object.
Batch operation - adds single or multiple users (members) as assignees to specific permission set.

### Permissions

Perm to check: `object_records.edit_owners` (for individual Object Class). Permission can be checked for example by retrieving details of Object Classes (`GET /api/object-classes/`): `_meta.permissions`

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| record\_id         | Object Record ID  |
| permission\_set\_id | Permission Set ID |

### Request Schema

* Headers

```
Request Method: POST
Location: /api/object-records/{record_id}/permission-sets/{permission_set_id}/assignees/
Authorization: JWT access_token
```

* Body

```json
[<int>]
```

In body must be sent list of users ids to be assigned.

```json
[<user_id>, <user_id>]
```

> :warning: 1 Time Completion accounts cannot be assignee.

If some of users is already an assignee for given permission set, then request  should be silently accepted without an error or a warning.

> `created_at` and `created_by` fields are set automatically if relation does not exist.

### Request example

```json
[2734, 7231]
```

### Response example

| Key         | Type     | Notes                                                     |
|-------------|----------|-----------------------------------------------------------|
| id          | int      | Automatically generated by the backend.                   |
| user        | user     | 	                                                         |
| created\_at  | datetime | 	                                                         |
| created\_by  | user     | 	                                                         |

* Status `201 CREATED`
* Body

```json
[
  {
    "id": 987,
    "user": {
      "id": 100,
      "first_name": "John",
      "last_name": "Smith",
      "company_name": "Company1",
      "username": "john.smith@mail.com",
      "is_deleted": false
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false
    }
  },
  {
    "id": 988,
    "user": {
      "id": 30078,
      "first_name": "Jack",
      "last_name": "Lee",
      "company_name": "Company1",
      "username": "lee.jack@mail.com",
      "is_deleted": false,
      "account_type": "full"
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false,
      "account_type": "super_admin"
    }
  }
]
```

### Restriction

* Max `100` users ids in one request
* Max `100` items of Object Record Assignees (per Object Record and Permission Set)

### Errors

| Error                                                                                                              | Response code      | Message                                                                                                              |
|--------------------------------------------------------------------------------------------------------------------|--------------------|----------------------------------------------------------------------------------------------------------------------|
| Given empty list                                                                                                   | 400 Bad Request    | "detail": \["This list may not be empty."]                                                                            |
| Given different type than list                                                                                     | 400 Bad Request    | "detail": \["Expected a list of items but got type "{type}"."]                                                      |
| List contains item of wrong type                                                                                   | 400 Bad Request    | "detail": \["Incorrect type. Expected pk value, received {type}."]                                                    |
| User does not exist for given ID in list                                                                           | 400 Bad Request    | "detail": \["Invalid pk "{user\_id}" - object does not exist."]                                                      |
| Given ID is for 1 Time Completion account                                                                          | 400 Bad Request    | "detail": \["1 Time Completion account "{user\_id}" cannot be assignee."]                                            |
| More than 100 items on a list                                                                                      | 400 Bad Request    | "detail": \["Up to 100 items allowed."]                                                                               |
| Limit of Assignees for Object Record and Permission Set exceeded.                                                  | 400 Bad Request    | "detail": "Limit of 100 Permission Set Assignees has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED"             |
| Request user does not have "users.list" permission for the user to be assigned to the Object Record Permission Set | 400 Bad Request    | "detail": \["You do not have permission to assign user "{user\_id}" to Object Record Permission Se "{perm\_set\_id}"."]  |
| Wrong/not existing `permission_set_id`                                                                             | 404 Not Found      |                                                                                                                      |
| Wrong/not existing `record_id`                                                                                     | 403 Forbidden      |                                                                                                                      |
| Insufficient permissions                                                                                           | 403 Forbidden      | "detail": "You do not have permission to perform this action."                                                       |

## OPTIONS /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/

Endpoint returns schema for POST and GET.

### Permissions

Requires authentication only.

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| record\_id         | Object Record ID  |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: OPTIONS
Location: /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/
```

### Response example

* Status `200 OK`
* Body

```json
{
  "list": {
    "columns": [
      {
        "alias": "id",
        "type": "int",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "user",
        "type": "user",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_at",
        "type": "datetime",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_by",
        "type": "user",
        "predicates": [],
        "sort_ok": false
      }
    ]
  },
  "batch": {
    "type": "set",
    "required": true,
    "autocomplete": "/api/users/autocomplete/?account_type!=one_time_completion&text__icontains="
  },
  "restrictions": {
    "limit_items": 100,
    "limit_items_in_batch": 100
  }
} 
```

| Error                                                             | Response code   | Message  |
|-------------------------------------------------------------------|-----------------|----------|
| Wrong/not existing `record_id` or `permission_set_id`             | 404 Not Found   |          |

## DELETE /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/

Endpoint to remove `ObjectRecordPermissionSet` model objects.
Batch operation - removes users (assignees) from a permission set.

### Permissions

Perm to check: `object_records.edit_owners` (for individual Object Class). Permission can be checked for example by retrieving details from list of Object Classes (GET /api/object-classes/): \_meta.permissions.

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| record\_id         | Object Record ID  |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: DELETE
Location: /api/object-records/{record_id}/permission-sets/{permission_set_id}/assignees/
Authorization: JWT access_token
```

* Body

In body must be sent list of Object Record Assignees ids.

```json
[<assigne_id>, <assigne_id>]
```

### Response example

* Status `204 No Content`

### Restrictions

* Max `100` users ids in one request

### Errors

| Error                                        | Response code   | Message                                                                   |
|----------------------------------------------|-----------------|---------------------------------------------------------------------------|
| Given empty list                             | 400 Bad Request | "detail": \["This list may not be empty."]                                 |
| Given different type than list               | 400 Bad Request | "detail": \["Expected a list of items but got type "{type}"."]           |
| List contains item of wrong type             | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]         |
| Assignee does not exist for given ID in list | 400 Bad Request | "detail": \["Invalid pk "{assignee\_id}" - object does not exist."]       |
| More than 100 items on a list                | 400 Bad Request | "detail": \["Up to 100 items allowed."]                                    |
| Wrong/not existing  `permission_set_id`      | 404 Not Found   |                                                                           |
| Wrong/not existing `record_id`               | 403 Forbidden   |                                                                           |
| Insufficient permissions                     | 403 Forbidden   | "detail": "You do not have permission to perform this action."            |

## Not allowed endpoints

### GET /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/`id`/

### Response example

* Status `405 Method Not Allowed`

### PATCH /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/`id`/

### Response example

* Status `405 Method Not Allowed`

### PUT /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/`id`/

### Response example

* Status `405 Method Not Allowed`

### DELETE /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/`id`/

### Response example

* Status `405 Method Not Allowed`

### OPTIONS /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/`id`/

### Response example

* Status `405 Method Not Allowed`

---

---
url: /api/catalyst/resources/user-groups/user-group-permission-set-assignees.md
---
# Assigning for User Groups Permission Set

This technical design describes API for managing assignees for User Groups Permission Set.

Endpoints for managing Permission Set are described in separated document.

Implementation details can be found in external document: [User Groups Permission Sets - Technical Design](https://autologyx.sharepoint.com/:w:/s/Dev/EVXcrsoacx5Ek38G44xQJbkBqiUgbh5ZPJo1OiqUHl7knw).

## POST /api/user-groups/`group_id`/permission-sets/`permission_set_id`/assignees/users/

Endpoint to create `UsersGroupAssignee` model object.
Batch operation - adds single or multiple users (members) as assignees to specific permission set.

### Permissions

Perm to check: `user_groups.edit_perm_sets` (for individual Users Group).

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| group\_id          | Users Group ID    |
| permission\_set\_id | Permission Set ID |

### Request Schema

* Headers

```
Request Method: POST
Location: /api/user-groups/{group_id}/permission-sets/{permission_set_id}/assignees/users/
Authorization: JWT access_token
```

* Body

```json
[<int>]
```

In body must be sent list of users ids to be assigned.

```json
[<user_id>, <user_id>]
```

> :warning: 1 Time Completion accounts cannot be assignee.

If some of users is already an assignee for given permission set, then request  should be silently accepted without an error or a warning.

> `created_at` and `created_by` fields are set automatically if relation does not exist.

### Request example

```json
[2734, 7231]
```

### Response example

| Key         | Type     | Notes                                               |
|-------------|----------|-----------------------------------------------------|
| user        | user     |                                                     |
| created\_at  | datetime |                                                     |
| created\_by  | user     |                                                     |

* Status `201 CREATED`
* Body

```json
[
  {
    "user": {
      "id": 100,
      "first_name": "John",
      "last_name": "Smith",
      "company_name": "Company1",
      "username": "john.smith@mail.com",
      "is_deleted": false
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false
    }
  },
  {
    "user": {
      "id": 30078,
      "first_name": "Jack",
      "last_name": "Lee",
      "company_name": "Company1",
      "username": "lee.jack@mail.com",
      "is_deleted": false,
      "account_type": "full"
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false,
      "account_type": "super_admin"
    }
  }
]
```

### Restriction

* Max `100` users ids in one request
* Max `100` items of Users Group Assignees (per Users Group and Permission Set)

### Errors

| Error                                                             | Response code    | Message                                                                                                          |
|-------------------------------------------------------------------|------------------|------------------------------------------------------------------------------------------------------------------|
| Given empty list                                                  | 400 Bad Request  | "detail": \["This list may not be empty."]                                                                        |
| Given different type than list                                    | 400 Bad Request  | "detail": \["Expected a list of items but got type "{type}"."]                                                  |
| List contains item of wrong type                                  | 400 Bad Request  | "detail": \["Incorrect type. Expected pk value, received {type}."]                                                |
| User does not exist for given ID in list                          | 400 Bad Request  | "detail": \["Invalid pk "{user\_id}" - object does not exist."]                                                  |
| Insufficient permissions to user                                  | 400 Bad Request  | "detail": \["You do not have permission to assign user "user\_id" to User Group Permission Set "group\_id"."]   |
| Given ID is for 1 Time Completion account                         | 400 Bad Request  | "detail": \["1 Time Completion account "{user\_id}" cannot be assignee."]                                        |
| Attempt to assign assignees to the everyone or members perm set   | 400 Bad Request  | "detail": \["Assignees can not be set to this permission set type."]                                              |
| More than 100 items on a list                                     | 400 Bad Request  | "detail": \["Up to 100 items allowed."]                                                                           |
| Limit of Assignees for Object Record and Permission Set exceeded. | 400 Bad Request  | "detail": "Limit of 100 permission set assignees has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED"         |
| Wrong/not existing `permission_set_id`                            | 404 Not Found    |                                                                                                                  |
| Wrong/not existing `group_id`                                     | 404 Not Found    |                                                                                                                  |
| Insufficient permissions                                          | 403 Forbidden    | "detail": "You do not have permission to perform this action."                                                   |

## OPTIONS /api/user-groups/`group_id`/permission-sets/`permission_set_id`/assignees/users/

Endpoint returns schema for POST and GET.

### Permissions

Requires authentication only.

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| group\_id          | Users Group ID    |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: OPTIONS
Location: /api/user-groups/`group_id`/permission-sets/`permission_set_id`/assignees/users/
```

### Response example

* Status `200 OK`
* Body

```json
{
  "list": {
    "columns": [
      {
        "alias": "id",
        "type": "int",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "user",
        "type": "user",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_at",
        "type": "datetime",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_by",
        "type": "user",
        "predicates": [],
        "sort_ok": false
      }
    ]
  },
  "batch": {
    "type": "set",
    "required": true,
    "autocomplete": "/api/users/autocomplete/?account_type!=one_time_completion&text__icontains="
  },
  "restrictions": {
    "limit_items": 100,
    "limit_items_in_batch": 100
  }
} 
```

## GET /api/user-groups/`group_id`/permission-sets/`permission_set_id`/assignees/users/

Endpoint to receive list of `UsersGroupAssignee` model objects for defined Users Group and Permission Set.

### Permissions

Perm to check: `user_groups.view`.

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| group\_id          | Users Group ID    |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: GET
Location: /api/user-groups/`group_id`/permission-sets/`permission_set_id`/assignees/users/
Authorization: JWT access_token
```

### Response

| Key             | Type       | Notes                                                                                    |
|-----------------|------------|------------------------------------------------------------------------------------------|
| limit           | int        |                                                                                          |
| offset          | int        | 	                                                                                        |
| total\_count     | int        | Total number of assignees for specific permission set related to specific object record. |
| filtered\_count  | int        | Number of assignees if some filters are applied.                                         |
| next            | URL / null | Next page URL (null if there is no next page)                                            |
| previous        | URL / null | Previous page URL (null if there is no previous page)                                    |
| results         | Array      | Described in the next table.                                                             |

### Response `results` array

| Key            | Type        | Notes                                                                            |
|----------------|-------------|----------------------------------------------------------------------------------|
| user           | user        | 	                                                                                |
| created\_at     | datetime    | 	                                                                                |
| created\_by     | user        | 	                                                                                |

### Response schema

* Status `200 OK`
* Body:

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str|null>,
  "previous": <str|null>,
  "results": [
    {
      "user": <user>,
      "created_at": <datetime>,
      "created_by": <user>
    }
  ]
} 
```

### Response example

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "user": {
        "id": 11,
        "first_name": "John",
        "last_name": "Smith",
        "company_name": "Company1",
        "username": "john.smith@mail.com",
        "is_deleted": false
      },
      "created_at": "2021-05-18T06:39:17.688341Z",
      "created_by": {
        "id": 5,
        "first_name": "Ann",
        "last_name": "Jackson",
        "company_name": "Company1",
        "username": "ann.jackson@mail.com",
        "is_deleted": false
      }
    }
  ]
}
```

### Sorting

Not available. Results are not sorted - order returned by database.

### Filtering

No filters.

### Errors

| Error                                                                     | Response code | Message                                                        |
|---------------------------------------------------------------------------|---------------|----------------------------------------------------------------|
| Object Record for `group_id` not found.                                   | 403 Forbidden | 	                                                              |
| Permission set for `permission_set_id` not found (for given `record_id`). | 404 Not Found | 	                                                              |
| Insufficient permissions                                                  | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## DELETE /api/user-groups/`group_id`/permission-sets/`permission_set_id`/assignees/users/

Endpoint to remove `UsersGroupAssignee` model objects.
Batch operation - removes users (assignees) from a permission set.
User assigned to the permission set will be removed from assignees also if he is anonymized.

### Permissions

Perm to check: `user_groups.edit_perm_sets` (for individual Users Group).

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| group\_id          | Users Group ID    |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: DELETE
Location: /api/user-groups/{group_id}/permission-sets/{permission_set_id}/assignees/users/
Authorization: JWT access_token
```

* Body

In body must be sent list of Users Group Assignees users ids.

```json
[<user_id>, <user_id>]
```

### Response example

* Status `204 No Content`

### Restrictions

* Max `100` users ids in one request

### Errors

| Error                                        | Response code   | Message                                                                   |
|----------------------------------------------|-----------------|---------------------------------------------------------------------------|
| Given empty list                             | 400 Bad Request | "detail": \["This list may not be empty."]                                 |
| Given different type than list               | 400 Bad Request | "detail": \["Expected a list of items but got type "{type}"."]           |
| List contains item of wrong type             | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]         |
| Assignee does not exist for given ID in list | 400 Bad Request | "detail": \["Invalid pk "{assignee\_id}" - object does not exist."]       |
| More than 100 items on a list                | 400 Bad Request | "detail": \["Up to 100 items allowed."]                                    |
| Wrong/not existing  `permission_set_id`      | 404 Not Found   |                                                                           |
| Wrong/not existing `group_id`                | 404 Not Found   |                                                                           |
| Insufficient permissions                     | 403 Forbidden   | "detail": "You do not have permission to perform this action."            |

# Not allowed endpoints

## GET /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/`id`/

### Response example

* Status `405 Method Not Allowed`

## PATCH /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/`id`/

### Response example

* Status `405 Method Not Allowed`

## PUT /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/`id`/

### Response example

* Status `405 Method Not Allowed`

## DELETE /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/`id`/

### Response example

* Status `405 Method Not Allowed`

## POST /api/user-groups/`group_id`/permission-sets/`permission_set_id`/assignees/user-groups/

Endpoint to create `UsersGroupAssigneeUserGroups` model object.
Batch operation - adds single or multiple users\_group (members) as assignees to specific permission set.

### Permissions

Perm to check: `user_groups.edit_perm_sets` (for individual Users Group).

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| group\_id          | Users Group ID    |
| permission\_set\_id | Permission Set ID |

### Request Schema

* Headers

```
Request Method: POST
Location: /api/user-groups/{group_id}/permission-sets/{permission_set_id}/assignees/user-groups/
Authorization: JWT access_token
```

* Body

```json
[<int>]
```

In body must be sent list of users ids to be assigned.

```json
[<users_group_id>, <users_group_id>]
```

If some of user\_groups is already an assignee for given permission set, then request  should be silently accepted without an error or a warning.

> `created_at` and `created_by` fields are set automatically if relation does not exist.

### Request example

```json
[2734, 7231]
```

### Response example

| Key        | Type     | Notes            |
|------------|----------|------------------|
| id         | int      | Users Group ID   |
| name       | str      | Users Group Name |
| created\_at | datetime |                  |
| created\_by | user     |                  |

* Status `201 CREATED`
* Body

```json
[
  {
    
    "id": 2734,
    "name": "Group1",
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false
    }
  },
  {
    "id": 7231,
    "name": "Group2",
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false,
      "account_type": "super_admin"
    }
  }
]
```

### Restriction

* Max `10` user\_groups ids in one request
* Max `10` items of Users Group Assignees (per Users Group and Permission Set)

### Errors

| Error                                                                                                | Response code   | Message                                                                                                                        |
|------------------------------------------------------------------------------------------------------|-----------------|--------------------------------------------------------------------------------------------------------------------------------|
| Given empty list                                                                                     | 400 Bad Request | "detail": \["This list may not be empty."]                                                                                      |
| Given different type than list                                                                       | 400 Bad Request | "detail": \["Expected a list of items but got type "{type}"."]                                                                |
| List contains item of wrong type                                                                     | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]                                                              |
| Users Group does not exist for given ID in list                                                      | 400 Bad Request | "detail": \["Invalid pk "{id}" - object does not exist."]                                                                     |
| Request user does not have "user\_groups.list" permission for some User Groups passed in the payload  | 400 Bad Request | “detail”: \["You do not have permission to assign user group "{group\_id}" to User Group Permission Set "{perm\_set\_id}"."]   |
| Attempt to assign assignees to the everyone or members perm set                                      | 400 Bad Request | "detail": \["Assignees can not be set to this permission set type."]                                                            |
| More than 10 items on a list                                                                         | 400 Bad Request | "detail": \["Up to 10 items allowed."]                                                                                          |
| Limit of Assignees for Object Record and Permission Set exceeded.                                    | 400 Bad Request | "detail": "Limit of 10 permission set assignees has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED"                        |
| Wrong/not existing `permission_set_id`                                                               | 404 Not Found   |                                                                                                                                |
| Wrong/not existing `group_id`                                                                        | 404 Not Found   |                                                                                                                                |
| Insufficient permissions                                                                             | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                                                 |

## OPTIONS /api/user-groups/`group_id`/permission-sets/`permission_set_id`/assignees/user-groups/

Endpoint returns schema for POST and GET.

### Permissions

Requires authentication only.

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| group\_id          | Users Group ID    |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: OPTIONS
Location: /api/user-groups/`group_id`/permission-sets/`permission_set_id`/assignees/user-groups/
```

### Response example

* Status `200 OK`
* Body

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "name",
                "type": "string",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [],
                "sort_ok": false
            }
        ]
    },
    "batch": {
        "type": "set",
        "required": true,
        "autocomplete": "/api/user-groups/autocomplete/?text__icontains="
    },
    "restrictions": {
        "limit_items": 10,
        "limit_items_in_batch": 10
    }
}
```

## GET /api/user-groups/`group_id`/permission-sets/`permission_set_id`/assignees/user-groups/

Endpoint to receive list of `UsersGroupAssigneeUserGroups` model objects for defined Users Group and Permission Set.

### Permissions

Perm to check: `user_groups.view`.

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| group\_id          | Users Group ID    |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: GET
Location: /api/user-groups/`group_id`/permission-sets/`permission_set_id`/assignees/user-groups/
Authorization: JWT access_token
```

### Response

| Key             | Type       | Notes                                                                                    |
|-----------------|------------|------------------------------------------------------------------------------------------|
| limit           | int        |                                                                                          |
| offset          | int        | 	                                                                                        |
| total\_count     | int        | Total number of assignees for specific permission set related to specific object record. |
| filtered\_count  | int        | Number of assignees if some filters are applied.                                         |
| next            | URL / null | Next page URL (null if there is no next page)                                            |
| previous        | URL / null | Previous page URL (null if there is no previous page)                                    |
| results         | Array      | Described in the next table.                                                             |

### Response `results` array

| Key        | Type     | Notes            |
|------------|----------|------------------|
| id         | int      | Users Group ID   |
| name       | str      | Users Group Name |
| created\_at | datetime |                  |
| created\_by | user     |                  |

### Response schema

* Status `200 OK`
* Body:

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str|null>,
  "previous": <str|null>,
  "results": [
    {
      "id": <int>,
      "name": <str>,
      "created_at": <datetime>,
      "created_by": <user>
    }
  ]
} 
```

### Response example

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 11,
      "name": "Group1",
      "created_at": "2021-05-18T06:39:17.688341Z",
      "created_by": {
        "id": 5,
        "first_name": "Ann",
        "last_name": "Jackson",
        "company_name": "Company1",
        "username": "ann.jackson@mail.com",
        "is_deleted": false
      }
    }
  ]
}
```

### Sorting

Not available. Results are not sorted - order returned by database.

### Filtering

No filters.

### Errors

| Error                                                                     | Response code | Message                                                        |
|---------------------------------------------------------------------------|---------------|----------------------------------------------------------------|
| Object Record for `group_id` not found.                                   | 403 Forbidden | 	                                                              |
| Permission set for `permission_set_id` not found (for given `record_id`). | 404 Not Found | 	                                                              |
| Insufficient permissions                                                  | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## DELETE /api/user-groups/`group_id`/permission-sets/`permission_set_id`/assignees/user-groups/

Endpoint to remove `UsersGroupAssigneeUserGroups` model objects.
Batch operation - removes user\_groups (assignees) from a permission set.

### Permissions

Perm to check: `user_groups.edit_perm_sets` (for individual Users Group).

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| group\_id          | Users Group ID    |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: DELETE
Location: /api/user-groups/{group_id}/permission-sets/{permission_set_id}/assignees/user-groups/
Authorization: JWT access_token
```

* Body

In body must be sent list of Users Group Assignees users ids.

```json
[<users_group_id>, <users_group_id>]
```

### Response example

* Status `204 No Content`

### Restrictions

* Max `10` users ids in one request

### Errors

| Error                                        | Response code   | Message                                                             |
|----------------------------------------------|-----------------|---------------------------------------------------------------------|
| Given empty list                             | 400 Bad Request | "detail": \["This list may not be empty."]                           |
| Given different type than list               | 400 Bad Request | "detail": \["Expected a list of items but got type "{type}"."]     |
| List contains item of wrong type             | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]   |
| Assignee does not exist for given ID in list | 400 Bad Request | "detail": \["Invalid pk "{assignee\_id}" - object does not exist."] |
| More than 10 items on a list                 | 400 Bad Request | "detail": \["Up to 10 items allowed."]                               |
| Wrong/not existing  `permission_set_id`      | 404 Not Found   |                                                                     |
| Wrong/not existing `group_id`                | 404 Not Found   |                                                                     |
| Insufficient permissions                     | 403 Forbidden   | "detail": "You do not have permission to perform this action."      |

# Not allowed endpoints

## GET /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/user-groups/`id`/

### Response example

* Status `405 Method Not Allowed`

## PATCH /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/user-groups/`id`/

### Response example

* Status `405 Method Not Allowed`

## PUT /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/user-groups/`id`/

### Response example

* Status `405 Method Not Allowed`

## DELETE /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/user-groups/`id`/

### Response example

* Status `405 Method Not Allowed`

---

---
url: >-
  /knowledgebase/administration/all-about-users/assigning-tasks-to-1-time-completion-users.md
---

# Assigning tasks to 1-time completion Users

1-time completion users can be assigned both manual and automated Tasks.

Unlike other users, they do not sign in to Catalyst. Instead, they receive an email containing a secure link that allows them to complete the assigned task.

## Assigning a manual task

Manual tasks are created from the **Tasks** tab in the side panel of an Object record.

Open the required record and click **+ Create task**.

![Tasks tab showing the Create task button](../../../images2/zendesk_10640070061469_001_8bf07c167e38.png)

## Select a Task Template

Choose the appropriate **Task type** and **Task Template**.

Only Task Templates configured with a **Task creation mechanism** of **Manual** are available for selection.

This applies to both:

* **Complete standalone form**
* **Update object records**

![Task type selection when creating a manual task](../../../images2/zendesk_10640070061469_002_b3b655534550.png)

![Manual Task Templates available for selection](../../../images2/zendesk_10640070061469_003_7680d82281a5.png)

## Assign the task

Search for and select the 1-time completion user.

In the example below, the task is assigned to **Harry Bennett**.

Users with a 1-time completion account are identified by the **dotted circle** around their avatar.

![Selecting a 1-time completion user as the task assignee](../../../images2/zendesk_10640070061469_004_b2860e3157a0.png)

### Important

Once a 1-time completion user has been selected, no additional assignees can be added.

This ensures that the task is completed only by that individual.

When the task is created, the user automatically receives an email notification containing a secure link to complete it.

For more information, see [How does a 1-time completion user interact with Catalyst?](/knowledgebase/administration/all-about-users/how-does-a-1-time-completion-user-interact-with-catalyst/).

![1-time completion user selected with additional assignees disabled](../../../images2/zendesk_10640070061469_005_970ecec8d6df.png)

## Add additional instructions

You can optionally provide instructions that are specific to the task being assigned.

This is particularly useful for 1-time completion users because they typically have little or no experience of using your Catalyst system.

![Instructions field when creating a manual task](../../../images2/zendesk_10640070061469_006_8356b8886fc7.png)

Any instructions you enter are displayed at the top of the task when the recipient opens it.

![Additional instructions displayed to the 1-time completion user](../../../images2/zendesk_10640070061469_007_f0d03c49c944.png)

## Assigning tasks from a Sequence

You cannot currently select a 1-time completion user as the **default task assignee** in a Sequence.

However, a Sequence can assign one or more tasks to a 1-time completion user as part of the workflow using the available task assignment configuration.

## Things to remember

1. 1-time completion users do not sign in to Catalyst.
2. They receive a secure email link whenever a task is assigned to them.
3. A task assigned to a 1-time completion user can have only one assignee.
4. Additional task instructions are displayed prominently when the task is opened.
5. Both manual and automated tasks can be assigned to 1-time completion users.

---

---
url: >-
  /api/catalyst/resources/object-classes/object-class-permission-set-user-group-assignees.md
---
# Assigning User Groups for Object Classes Permission Set

## POST /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/user-groups/

Endpoint to create `ObjectClassAssigneeUserGroups` model object.
Batch operation - adds single or multiple user groups as assignees to specific permission set.

### Permissions

Perm to check: `object_class.edit_perm_set` (for individual Object Class).

### URL parameters

| Key                | Notes             |
|--------------------|-------------------|
| object\_class\_id    | Object Class ID   |
| permission\_set\_id  | Permission Set ID |

### Request Schema

* Headers

```
Request Method: POST
Location: /api/object-classes/{object_class_id}/permission-sets/{permission_set_id}/assignees/user-groups/
Authorization: JWT access_token
```

* Body

```json
[<int>]
```

Request body must contain a list of user group ids to be assigned.

```json
[<group_id1>, <group_id2>]
```

If some of user group is already an assignee for given permission set, then request  should be silently accepted without an error or a warning.

> `created_at` and `created_by` fields are set automatically if relation does not exist.

### Request example

```json
[2734, 7231]
```

### Response example

| Key                 | Type        | Notes                                         |
|---------------------|-------------|-----------------------------------------------|
| id                  | pk          | Automatically generated by the backend.       |
| user\_group          | user\_group  |                                               |
| created\_at          | datetime    |                                               |
| created\_by          | user        |                                               |

* Status `201 CREATED`
* Body

```json
[
  {
    "id": 1,
    "user_group": {
      "id": 100,
      "name": "User Group 1"
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false
    }
  },
  {
    "id": 2,
    "user_group": {
      "id": 101,
      "name": "User Group 2"
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false,
      "account_type": "super_admin"
    }
  }
]
```

### Restriction

* Max `10` user groups ids in one request
* Max `10` items of Object Class Assignees (per Object Class and Permission Set)

### Errors

| Error                                                               | Response code   | Message                                                                                                 |
|---------------------------------------------------------------------|-----------------|---------------------------------------------------------------------------------------------------------|
| Given empty list                                                    | 400 Bad Request | "detail": \["This list may not be empty."]                                                               |
| Given different type than list                                      | 400 Bad Request | "detail": \["Expected a list of items but got type "{type}"."]                                         |
| List contains item of wrong type                                    | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]                                       |
| Users Group does not exist for given ID in list                     | 400 Bad Request | "detail": \["Invalid pk "{group\_id}" - object does not exist."]                                        |
| Attempt to assign assignees to the everyone or members perm set     | 400 Bad Request | "detail": \["Assignees can not be set to this permission set type."]                                     |
| More than 10 items in a list                                       | 400 Bad Request | "detail": \["Up to 10 items allowed."]                                                                   |
| User has no `list` group permission for the group that was passed.  | 400 Bad Request | "detail": \["Invalid pk "{group\_id}" - You do not have permission for this Group."]                    |
| Limit of Assignees for Object Class and Permission Set exceeded.    | 400 Bad Request | "detail": "Limit of 10 permission set assignees has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED" |
| Wrong/not existing `permission_set_id`                              | 404 Not Found   |                                                                                                         |
| Wrong/not existing `object_class_id`                                | 404 Not Found   |                                                                                                         |
| Insufficient permissions                                            | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                          |

## OPTIONS /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/user-groups/

Endpoint returns schema for POST and GET.

### Permissions

Requires authentication only.

### URL parameters

| Key                  | Notes             |
|----------------------|-------------------|
| object\_class\_id      | Object Class ID   |
| permission\_set\_id    | Permission Set ID |

### Request schema

* Headers

```
Request Method: OPTIONS
Location: /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/user-groups/
```

### Response example

* Status `200 OK`
* Body

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "user_group",
                "type": "user_group",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [],
                "sort_ok": false
            }
        ]
    },
    "batch": {
        "type": "set",
        "required": true,
        "autocomplete": "/api/user-groups/autocomplete/?text__icontains="
    },
    "restrictions": {
        "limit_items": 10,
        "limit_items_in_batch": 10
    }
}
```

## GET /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/user-groups/

Endpoint to receive list of `ObjectClassAssigneeUserGroups` model objects for defined Object Class and Permission Set.

### Permissions

Perm to check: `object_class.view`.

### URL parameters

| Key                | Notes             |
|--------------------|-------------------|
| object\_class\_id    | Object Class ID   |
| permission\_set\_id  | Permission Set ID |

### Request schema

* Headers

```
Request Method: GET
Location: /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/user-groups/
Authorization: JWT access_token
```

### Response

| Key             | Type       | Notes                                                                                    |
|-----------------|------------|------------------------------------------------------------------------------------------|
| limit           | int        |                                                                                          |
| offset          | int        | 	                                                                                        |
| total\_count     | int        | Total number of assignees for specific permission set related to specific object record. |
| filtered\_count  | int        | Number of assignees if some filters are applied.                                         |
| next            | URL / null | Next page URL (null if there is no next page)                                            |
| previous        | URL / null | Previous page URL (null if there is no previous page)                                    |
| results         | Array      | Described in the next table.                                                             |

### Response `results` array

| Key        | Type       | Notes                                        |
|------------|------------|----------------------------------------------|
| id         | pk         | Automatically generated by the backend.      |
| user\_group | user\_group | 	                                            |
| created\_at | datetime   | 	                                            |
| created\_by | user       | 	                                            |

### Response schema

* Status `200 OK`
* Body:

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str|null>,
  "previous": <str|null>,
  "results": [
    {
      "id": <int>,
      "user_group": <user_group>,
      "created_at": <datetime>,
      "created_by": <user>
    }
  ]
} 
```

### Response example

```json
[
  {
    "id": 1,
    "user_group": {
      "id": 100,
      "name": "User Group 1"
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false
    }
  }
]
```

### Sorting

Not available. Results are not sorted - order returned by database.

### Filtering

No filters.

### Errors

| Error                                                                           | Response code | Message                                                        |
|---------------------------------------------------------------------------------|---------------|----------------------------------------------------------------|
| Object Class for `object_class_id` not found.                                   | 404 Not Found | 	                                                              |
| Permission set for `permission_set_id` not found (for given `object_class_id`). | 404 Not Found | 	                                                              |
| Insufficient permissions                                                        | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## DELETE /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/user-groups/

Endpoint to remove `ObjectClassAssigneeUserGroups` model objects.
Batch operation - removes user groups (assignees) from a permission set.

### Permissions

Perm to check: `object_class.edit_perm_sets` (for individual Object Class).

### URL parameters

| Key                 | Notes             |
|---------------------|-------------------|
| object\_class\_id     | Object Class ID   |
| permission\_set\_id   | Permission Set ID |

### Request schema

* Headers

```
Request Method: DELETE
Location: /api/object-classes/{object_class_id}/permission-sets/{permission_set_id}/assignees/user-groups/
Authorization: JWT access_token
```

* Body

In body must be sent list of Object Class Assignees users ids.

```json
[<group_id1>, <group_id2>]
```

### Response example

* Status `204 No Content`

### Restrictions

* Max `10` user groups ids in one request

### Errors

| Error                                        | Response code   | Message                                                                  |
|----------------------------------------------|-----------------|--------------------------------------------------------------------------|
| Given empty list                             | 400 Bad Request | "detail": \["This list may not be empty."]                                |
| Given different type than list               | 400 Bad Request | "detail": \["Expected a list of items but got type "{type}"."]          |
| List contains item of wrong type             | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]        |
| Assignee does not exist for given ID in list | 400 Bad Request | "detail": \["Invalid pk "{assignee\_id}" - object does not exist."]      |
| More than 10 items on a list                 | 400 Bad Request | "detail": \["Up to 10 items allowed."]                                    |
| Wrong/not existing  `permission_set_id`      | 404 Not Found   |                                                                          |
| Wrong/not existing `object_class_id`         | 404 Not Found   |                                                                          |
| Insufficient permissions                     | 403 Forbidden   | "detail": "You do not have permission to perform this action."           |

---

---
url: >-
  /api/catalyst/resources/object-records/object-record-permission-set-user-group-assignees.md
---
# Assigning User Groups for Object Records Permission Set

## POST /api/object-records/`object_record_id`/permission-sets/`permission_set_id`/assignees/user-groups/

Endpoint to create `ObjectRecordAssigneeUserGroups` model object.
Batch operation - adds single or multiple user groups as assignees to specific permission set.

### Permissions

Perm to check: `object_records.edit_owners` (for individual Object Record).

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| object\_record\_id  | Object Record ID  |
| permission\_set\_id | Permission Set ID |

### Request Schema

* Headers

```
Request Method: POST
Location: /api/object-records/{object_record_id}/permission-sets/{permission_set_id}/assignees/user-groups/
Authorization: JWT access_token
```

* Body

```json
[<int>]
```

Request body must contain a list of user group ids to be assigned.

```json
[<group_id1>, <group_id2>]
```

If some of user group is already an assignee for given permission set, then request  should be silently accepted without an error or a warning.

> `created_at` and `created_by` fields are set automatically if relation does not exist.

### Request example

```json
[2734, 7231]
```

### Response example

| Key                 | Type        | Notes                                         |
|---------------------|-------------|-----------------------------------------------|
| id                  | pk          | Automatically generated by the backend.       |
| user\_group          | user\_group  |                                               |
| created\_at          | datetime    |                                               |
| created\_by          | user        |                                               |

* Status `201 CREATED`
* Body

```json
[
  {
    "id": 1,
    "user_group": {
      "id": 100,
      "name": "User Group 1"
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false
    }
  },
  {
    "id": 2,
    "user_group": {
      "id": 101,
      "name": "User Group 2"
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false,
      "account_type": "super_admin"
    }
  }
]
```

### Restriction

* Max `10` user groups ids in one request
* Max `10` items of Object Class Assignees (per Object Class and Permission Set)

### Errors

| Error                                                              | Response code   | Message                                                                                                 |
|--------------------------------------------------------------------|-----------------|---------------------------------------------------------------------------------------------------------|
| Given empty list                                                   | 400 Bad Request | "detail": \["This list may not be empty."]                                                               |
| Given different type than list                                     | 400 Bad Request | "detail": \["Expected a list of items but got type "{type}"."]                                         |
| List contains item of wrong type                                   | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]                                       |
| Users Group does not exist for given ID in list                    | 400 Bad Request | "detail": \["Invalid pk "{group\_id}" - object does not exist."]                                        |
| Attempt to assign assignees to the everyone or members perm set    | 400 Bad Request | "detail": \["Assignees can not be set to this permission set type."]                                     |
| More than 10 items in a list                                       | 400 Bad Request | "detail": \["Up to 10 items allowed."]                                                                   |
| User has no `list` group permission for the group that was passed. | 400 Bad Request | "detail": \["Invalid pk "{group\_id}" - You do not have permission for this Group."]                    |
| Limit of Assignees for Object Class and Permission Set exceeded.   | 400 Bad Request | "detail": "Limit of 10 permission set assignees has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED" |
| Wrong/not existing `permission_set_id`                             | 404 Not Found   |                                                                                                         |
| Wrong/not existing `object_record_id`                              | 404 Not Found   |                                                                                                         |
| Insufficient permissions                                           | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                          |

## OPTIONS /api/object-records/`object_record_id`/permission-sets/`permission_set_id`/assignees/user-groups/

Endpoint returns schema for POST and GET.

### Permissions

Requires authentication only.

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| object\_record\_id  | Object Record ID  |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: OPTIONS
Location: /api/object-records/`object_record_id`/permission-sets/`permission_set_id`/assignees/user-groups/
```

### Response example

* Status `200 OK`
* Body

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "user_group",
                "type": "user_group",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [],
                "sort_ok": false
            }
        ]
    },
    "batch": {
        "type": "set",
        "required": true,
        "autocomplete": "/api/user-groups/autocomplete/?text__icontains=" 
    },
    "restrictions": {
        "limit_items": 10,
        "limit_items_in_batch": 10
    }
}
```

## GET /api/object-records/`object_record_id`/permission-sets/`permission_set_id`/assignees/user-groups/

Endpoint to receive list of `ObjectRecordAssigneeUserGroups` model objects for defined Object Record and Permission Set.

### Permissions

Perm to check: `object_record.view`.

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| object\_record\_id  | Object Record ID  |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: GET
Location: /api/object-records/`object_record_id`/permission-sets/`permission_set_id`/assignees/user-groups/
Authorization: JWT access_token
```

### Response

| Key             | Type       | Notes                                                                                    |
|-----------------|------------|------------------------------------------------------------------------------------------|
| limit           | int        |                                                                                          |
| offset          | int        | 	                                                                                        |
| total\_count     | int        | Total number of assignees for specific permission set related to specific object record. |
| filtered\_count  | int        | Number of assignees if some filters are applied.                                         |
| next            | URL / null | Next page URL (null if there is no next page)                                            |
| previous        | URL / null | Previous page URL (null if there is no previous page)                                    |
| results         | Array      | Described in the next table.                                                             |

### Response `results` array

| Key        | Type       | Notes                                        |
|------------|------------|----------------------------------------------|
| id         | pk         | Automatically generated by the backend.      |
| user\_group | user\_group | 	                                            |
| created\_at | datetime   | 	                                            |
| created\_by | user       | 	                                            |

### Response schema

* Status `200 OK`
* Body:

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str|null>,
  "previous": <str|null>,
  "results": [
    {
      "id": <int>,
      "user_group": <user_group>,
      "created_at": <datetime>,
      "created_by": <user>
    }
  ]
} 
```

### Response example

```json
[
  {
    "id": 1,
    "user_group": {
      "id": 100,
      "name": "User Group 1"
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false
    }
  }
]
```

### Sorting

Not available. Results are not sorted - order returned by database.

### Filtering

No filters.

### Errors

| Error                                                                            | Response code | Message                                                        |
|----------------------------------------------------------------------------------|---------------|----------------------------------------------------------------|
| Object Class for `object_record_id` not found.                                   | 404 Not Found | 	                                                              |
| Permission set for `permission_set_id` not found (for given `object_record_id`). | 404 Not Found | 	                                                              |
| Insufficient permissions                                                         | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## DELETE /api/object-records/`object_record_id`/permission-sets/`permission_set_id`/assignees/user-groups/

Endpoint to remove `ObjectRecordAssigneeUserGroups` model objects.
Batch operation - removes user groups (assignees) from a permission set.

### Permissions

Perm to check: `object_records.edit_owners` (for individual Object Record).

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| object\_record\_id  | Object Record ID  |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: DELETE
Location: /api/object-records/{object_record_id}/permission-sets/{permission_set_id}/assignees/user-groups/
Authorization: JWT access_token
```

* Body

In body must be sent list of Object CRecord Assignees user groups ids.

```json
[<group_id1>, <group_id2>]
```

### Response example

* Status `204 No Content`

### Restrictions

* Max `10` user groups ids in one request

### Errors

| Error                                        | Response code   | Message                                                                  |
|----------------------------------------------|-----------------|--------------------------------------------------------------------------|
| Given empty list                             | 400 Bad Request | "detail": \["This list may not be empty."]                                |
| Given different type than list               | 400 Bad Request | "detail": \["Expected a list of items but got type "{type}"."]          |
| List contains item of wrong type             | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]        |
| Assignee does not exist for given ID in list | 400 Bad Request | "detail": \["Invalid pk "{assignee\_id}" - object does not exist."]      |
| More than 10 items on a list                 | 400 Bad Request | "detail": \["Up to 10 items allowed."]                                    |
| Wrong/not existing  `permission_set_id`      | 404 Not Found   |                                                                          |
| Wrong/not existing `object_record_id`        | 404 Not Found   |                                                                          |
| Insufficient permissions                     | 403 Forbidden   | "detail": "You do not have permission to perform this action."           |

---

---
url: >-
  /api/catalyst/resources/object-classes/object-class-permission-set-user-assignees.md
---
# Assigning Users for Object Classes Permission Set

## POST /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/users/

Endpoint to create `ObjectClassAssignee` model object.
Batch operation - adds single or multiple users (members) as assignees to specific permission set.

### Permissions

Perm to check: `object_class.edit_perm_set` (for individual UObject Class).

### URL parameters

| Key                | Notes             |
|--------------------|-------------------|
| object\_class\_id    | Object Class ID   |
| permission\_set\_id  | Permission Set ID |

### Request Schema

* Headers

```
Request Method: POST
Location: /api/object-classes/{object_class_id}/permission-sets/{permission_set_id}/assignees/
Authorization: JWT access_token
```

* Body

```json
[<int>]
```

In body must be sent list of users ids to be assigned.

```json
[<user_id>, <user_id>]
```

> :warning: 1 Time Completion accounts cannot be assignee.

If some of users is already an assignee for given permission set, then request  should be silently accepted without an error or a warning.

> `created_at` and `created_by` fields are set automatically if relation does not exist.

### Request example

```json
[2734, 7231]
```

### Response example

| Key         | Type     | Notes                                               |
|-------------|----------|-----------------------------------------------------|
| user        | user     |                                                     |
| created\_at  | datetime |                                                     |
| created\_by  | user     |                                                     |

* Status `201 CREATED`
* Body

```json
[
  {
    "user": {
      "id": 100,
      "first_name": "John",
      "last_name": "Smith",
      "company_name": "Company1",
      "username": "john.smith@mail.com",
      "is_deleted": false
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false
    }
  },
  {
    "user": {
      "id": 30078,
      "first_name": "Jack",
      "last_name": "Lee",
      "company_name": "Company1",
      "username": "lee.jack@mail.com",
      "is_deleted": false,
      "account_type": "full"
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false,
      "account_type": "super_admin"
    }
  }
]
```

### Restriction

* Max `100` users ids in one request
* Max `100` items of Object Class Assignees (per Object Class and Permission Set)

### Errors

| Error                                                                                                               | Response code     | Message                                                                                                                |
|---------------------------------------------------------------------------------------------------------------------|-------------------|------------------------------------------------------------------------------------------------------------------------|
| Given empty list                                                                                                    | 400 Bad Request   | "detail": \["This list may not be empty."]                                                                              |
| Given different type than list                                                                                      | 400 Bad Request   | "detail": \["Expected a list of items but got type "{type}"."]                                                        |
| List contains item of wrong type                                                                                    | 400 Bad Request   | "detail": \["Incorrect type. Expected pk value, received {type}."]                                                      |
| User does not exist for given ID in list                                                                            | 400 Bad Request   | "detail": \["Invalid pk "{user\_id}" - object does not exist."]                                                        |
| Given ID is for 1 Time Completion account                                                                           | 400 Bad Request   | "detail": \["1 Time Completion account "{user\_id}" cannot be assignee."]                                              |
| Attempt to assign assignees to the everyone or members perm set                                                     | 400 Bad Request   | "detail": \["Assignees can not be set to this permission set type."]                                                    |
| More than 100 items on a list                                                                                       | 400 Bad Request   | "detail": \["Up to 100 items allowed."]                                                                                 |
| Limit of Assignees for Object Class and Permission Set exceeded.                                                    | 400 Bad Request   | "detail": "Limit of 100 permission set assignees has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED"               |
| Request user does not have "users.list" permission for the user to be assigned to the Objects Class Permission Set  | 400 Bad Request   | "detail": \["You do not have permission to assign user "{user\_id}" to Object Class Permission Set "{perm\_set\_id}"."]    |
| Wrong/not existing `permission_set_id`                                                                              | 404 Not Found     |                                                                                                                        |
| Wrong/not existing `object_class_id`                                                                                | 404 Not Found     |                                                                                                                        |
| Insufficient permissions                                                                                            | 403 Forbidden     | "detail": "You do not have permission to perform this action."                                                         |

## OPTIONS /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/users/

Endpoint returns schema for POST and GET.

### Permissions

Requires authentication only.

### URL parameters

| Key                  | Notes             |
|----------------------|-------------------|
| object\_class\_id      | Object Class ID   |
| permission\_set\_id    | Permission Set ID |

### Request schema

* Headers

```
Request Method: OPTIONS
Location: /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/users/
```

### Response example

* Status `200 OK`
* Body

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "user",
                "type": "user",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [],
                "sort_ok": false
            }
        ]
    },
    "batch": {
        "type": "set",
        "required": true,
        "autocomplete": "/api/users/autocomplete/?account_type!=one_time_completion&text__icontains="
    },
    "restrictions": {
        "limit_items": 100,
        "limit_items_in_batch": 100
    }
}
```

## GET /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/users/

Endpoint to receive list of `ObjectClassAssignee` model objects for defined Object Class and Permission Set.

### Permissions

Perm to check: `object_class.view`.

### URL parameters

| Key                | Notes             |
|--------------------|-------------------|
| object\_class\_id    | Object Class ID   |
| permission\_set\_id  | Permission Set ID |

### Request schema

* Headers

```
Request Method: GET
Location: /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/users/
Authorization: JWT access_token
```

### Response

| Key             | Type       | Notes                                                                                    |
|-----------------|------------|------------------------------------------------------------------------------------------|
| limit           | int        |                                                                                          |
| offset          | int        | 	                                                                                        |
| total\_count     | int        | Total number of assignees for specific permission set related to specific object record. |
| filtered\_count  | int        | Number of assignees if some filters are applied.                                         |
| next            | URL / null | Next page URL (null if there is no next page)                                            |
| previous        | URL / null | Previous page URL (null if there is no previous page)                                    |
| results         | Array      | Described in the next table.                                                             |

### Response `results` array

| Key            | Type        | Notes                                                                            |
|----------------|-------------|----------------------------------------------------------------------------------|
| user           | user        | 	                                                                                |
| created\_at     | datetime    | 	                                                                                |
| created\_by     | user        | 	                                                                                |

### Response schema

* Status `200 OK`
* Body:

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str|null>,
  "previous": <str|null>,
  "results": [
    {
      "user": <user>,
      "created_at": <datetime>,
      "created_by": <user>
    }
  ]
} 
```

### Response example

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "user": {
        "id": 11,
        "first_name": "John",
        "last_name": "Smith",
        "company_name": "Company1",
        "username": "john.smith@mail.com",
        "is_deleted": false
      },
      "created_at": "2021-05-18T06:39:17.688341Z",
      "created_by": {
        "id": 5,
        "first_name": "Ann",
        "last_name": "Jackson",
        "company_name": "Company1",
        "username": "ann.jackson@mail.com",
        "is_deleted": false
      }
    }
  ]
}
```

### Sorting

Not available. Results are not sorted - order returned by database.

### Filtering

No filters.

### Errors

| Error                                                                           | Response code | Message                                                        |
|---------------------------------------------------------------------------------|---------------|----------------------------------------------------------------|
| Object Record for `object_class_id` not found.                                  | 403 Forbidden | 	                                                              |
| Permission set for `permission_set_id` not found (for given `object_class_id`). | 404 Not Found | 	                                                              |
| Insufficient permissions                                                        | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## DELETE /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/users/

Endpoint to remove `ObjectClassAssignee` model objects.
Batch operation - removes users (assignees) from a permission set.
User assigned to the permission set will be removed from assignees also if he is anonymized.

### Permissions

Perm to check: `object_class.edit_perm_sets` (for individual Object Class).

### URL parameters

| Key                 | Notes             |
|---------------------|-------------------|
| object\_class\_id     | Object Class ID   |
| permission\_set\_id   | Permission Set ID |

### Request schema

* Headers

```
Request Method: DELETE
Location: /api/object-classes/{object_class_id}/permission-sets/{permission_set_id}/assignees/users/
Authorization: JWT access_token
```

* Body

In body must be sent list of Object Class Assignees users ids.

```json
[<user_id>, <user_id>]
```

### Response example

* Status `204 No Content`

### Restrictions

* Max `100` users ids in one request

### Errors

| Error                                        | Response code   | Message                                                                   |
|----------------------------------------------|-----------------|---------------------------------------------------------------------------|
| Given empty list                             | 400 Bad Request | "detail": \["This list may not be empty."]                                 |
| Given different type than list               | 400 Bad Request | "detail": \["Expected a list of items but got type "{type}"."]           |
| List contains item of wrong type             | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]         |
| Assignee does not exist for given ID in list | 400 Bad Request | "detail": \["Invalid pk "{assignee\_id}" - object does not exist."]       |
| More than 100 items on a list                | 400 Bad Request | "detail": \["Up to 100 items allowed."]                                    |
| Wrong/not existing  `permission_set_id`      | 404 Not Found   |                                                                           |
| Wrong/not existing `object_class_id`         | 404 Not Found   |                                                                           |
| Insufficient permissions                     | 403 Forbidden   | "detail": "You do not have permission to perform this action."            |

# Not allowed endpoints

## GET /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/users/`id`/

### Response example

* Status `405 Method Not Allowed`

## PATCH /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/users/`id`/

### Response example

* Status `405 Method Not Allowed`

## PUT /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/users/`id`/

### Response example

* Status `405 Method Not Allowed`

## DELETE /api/object-classes/`object_class_id`/permission-sets/`permission_set_id`/assignees/users/`id`/

### Response example

* Status `405 Method Not Allowed`

---

---
url: >-
  /api/catalyst/resources/object-records/object-record-permission-set-user-assignees.md
---
# Assigning Users for Object Records Permission Set

This technical design describes API for managing Assigment user for Object Record Permission Set.

Endpoints for managing Permission Set are described in separated document.

Implementation details can be found in external document: [Object Record Permission Sets - Technical Design](https://autologyx.sharepoint.com/:w:/s/Dev/EQ6UwfqnkKdOnyAW0bLBtBABuXBqI3fPHM5JMB38gDBD2A?e=9iOf9s).

## GET /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/

Endpoint to receive list of `ObjectRecordAssignee` model objects for defined Object Record and Permission Set.

### Permissions

Perm to check: `object_record.view` (for individual Object Record). Permission can be checked for example by retrieving details from list of Object Classes (`GET /api/object-records/`): `_meta.permissions`

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| record\_id         | Object Record ID  |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: GET
Location: /api/object-records/{record_id}/permission-sets/{permission_set_id}/assignees/users/
Authorization: JWT access_token
```

### Response

| Key             | Type       | Notes                                                                                    |
|-----------------|------------|------------------------------------------------------------------------------------------|
| limit           | int        |                                                                                          |
| offset          | int        | 	                                                                                        |
| total\_count     | int        | Total number of assignees for specific permission set related to specific object record. |
| filtered\_count  | int        | Number of assignees if some filters are applied.                                         |
| next            | URL / null | Next page URL (null if there is no next page)                                            |
| previous        | URL / null | Previous page URL (null if there is no previous page)                                    |
| results         | Array      | Described in the next table.                                                             |

### Response `results` array

| Key            | Type        | Notes                                                                            |
|----------------|-------------|----------------------------------------------------------------------------------|
| id             | int         | 	                                                                                |
| user           | user        | 	                                                                                |
| created\_at     | datetime    | 	                                                                                |
| created\_by     | user        | 	                                                                                |

### Response schema

* Status `200 OK`
* Body:

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str|null>,
  "previous": <str|null>,
  "results": [
    {
      "id": <int>,
      "user": <user>,
      "created_at": <datetime>,
      "created_by": <user>
    }
  ]
} 
```

### Response example

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 6,
      "user": {
        "id": 11,
        "first_name": "John",
        "last_name": "Smith",
        "company_name": "Company1",
        "username": "john.smith@mail.com",
        "is_deleted": false
      },
      "created_at": "2021-05-18T06:39:17.688341Z",
      "created_by": {
        "id": 5,
        "first_name": "Ann",
        "last_name": "Jackson",
        "company_name": "Company1",
        "username": "ann.jackson@mail.com",
        "is_deleted": false
      }
    }
  ]
}
```

### Sorting

Not available. Results are not sorted - order returned by database.

### Filtering

No filters.

### Errors

| Error                                                                     | Response code | Message                                                        |
|---------------------------------------------------------------------------|---------------|----------------------------------------------------------------|
| Object Record for `record_id` not found.                                  | 403 Forbidden | 	                                                              |
| Permission set for `permission_set_id` not found (for given `record_id`). | 404 Not Found | 	                                                              |
| Insufficient permissions                                                  | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## POST /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/

Endpoint to create `ObjectRecordPermissionSet` model object.
Batch operation - adds single or multiple users (members) as assignees to specific permission set.

### Permissions

Perm to check: `object_records.edit_owners` (for individual Object Class). Permission can be checked for example by retrieving details of Object Classes (`GET /api/object-classes/`): `_meta.permissions`

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| record\_id         | Object Record ID  |
| permission\_set\_id | Permission Set ID |

### Request Schema

* Headers

```
Request Method: POST
Location: /api/object-records/{record_id}/permission-sets/{permission_set_id}/assignees/users/
Authorization: JWT access_token
```

* Body

```json
[<int>]
```

In body must be sent list of users ids to be assigned.

```json
[<user_id>, <user_id>]
```

> :warning: 1 Time Completion accounts cannot be assignee.

If some of users is already an assignee for given permission set, then request  should be silently accepted without an error or a warning.

> `created_at` and `created_by` fields are set automatically if relation does not exist.

### Request example

```json
[2734, 7231]
```

### Response example

| Key         | Type     | Notes                                                     |
|-------------|----------|-----------------------------------------------------------|
| id          | int      | Automatically generated by the backend.                   |
| user        | user     | 	                                                         |
| created\_at  | datetime | 	                                                         |
| created\_by  | user     | 	                                                         |

* Status `201 CREATED`
* Body

```json
[
  {
    "id": 987,
    "user": {
      "id": 100,
      "first_name": "John",
      "last_name": "Smith",
      "company_name": "Company1",
      "username": "john.smith@mail.com",
      "is_deleted": false
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false
    }
  },
  {
    "id": 988,
    "user": {
      "id": 30078,
      "first_name": "Jack",
      "last_name": "Lee",
      "company_name": "Company1",
      "username": "lee.jack@mail.com",
      "is_deleted": false,
      "account_type": "full"
    },
    "created_at": "2021-07-05T06:49:30.688714Z",
    "created_by": {
      "id": 5,
      "first_name": "Ann",
      "last_name": "Jackson",
      "company_name": "Company2",
      "username": "ann.jackson@mail.com",
      "is_deleted": false,
      "account_type": "super_admin"
    }
  }
]
```

### Restriction

* Max `100` users ids in one request
* Max `100` items of Object Record Assignees (per Object Record and Permission Set)

### Errors

| Error                                                             | Response code   | Message                                                                                                  |
|-------------------------------------------------------------------|-----------------|----------------------------------------------------------------------------------------------------------|
| Given empty list                                                  | 400 Bad Request | "detail": \["This list may not be empty."]                                                                |
| Given different type than list                                    | 400 Bad Request | "detail": \["Expected a list of items but got type "{type}"."]                                          |
| List contains item of wrong type                                  | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]                                        |
| User does not exist for given ID in list                          | 400 Bad Request | "detail": \["Invalid pk "{user\_id}" - object does not exist."]                                          |
| Given ID is for 1 Time Completion account                         | 400 Bad Request | "detail": \["1 Time Completion account "{user\_id}" cannot be assignee."]                                |
| More than 100 items on a list                                     | 400 Bad Request | "detail": \["Up to 100 items allowed."]                                                                   |
| Limit of Assignees for Object Record and Permission Set exceeded. | 400 Bad Request | "detail": "Limit of 100 Permission Set Assignees has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED" |
| Wrong/not existing `permission_set_id`                            | 404 Not Found   |                                                                                                          |
| Wrong/not existing `record_id`                                    | 403 Forbidden   |                                                                                                          |
| Insufficient permissions                                          | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                           |

## OPTIONS /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/

Endpoint returns schema for POST and GET.

### Permissions

Requires authentication only.

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| record\_id         | Object Record ID  |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: OPTIONS
Location: /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/
```

### Response example

* Status `200 OK`
* Body

```json
{
  "list": {
    "columns": [
      {
        "alias": "id",
        "type": "int",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "user",
        "type": "user",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_at",
        "type": "datetime",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_by",
        "type": "user",
        "predicates": [],
        "sort_ok": false
      }
    ]
  },
  "batch": {
    "type": "set",
    "required": true,
    "autocomplete": "/api/users/autocomplete/?account_type!=one_time_completion&text__icontains="
  },
  "restrictions": {
    "limit_items": 100,
    "limit_items_in_batch": 100
  }
} 
```

| Error                                                             | Response code   | Message  |
|-------------------------------------------------------------------|-----------------|----------|
| Wrong/not existing `record_id` or `permission_set_id`             | 404 Not Found   |          |

## DELETE /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/

Batch operation - removes users (assignees) from a permission set.

### Permissions

Perm to check: `object_records.edit_owners` (for individual Object Class). Permission can be checked for example by retrieving details from list of Object Classes (GET /api/object-classes/): \_meta.permissions.

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| record\_id         | Object Record ID  |
| permission\_set\_id | Permission Set ID |

### Request schema

* Headers

```
Request Method: DELETE
Location: /api/object-records/{record_id}/permission-sets/{permission_set_id}/assignees/users/
Authorization: JWT access_token
```

* Body

In body must be sent list of Object Record Users Assignees ids.

```json
[<user_id>, <user_id>]
```

### Response example

* Status `204 No Content`

### Restrictions

* Max `100` users ids in one request

### Errors

| Error                                        | Response code   | Message                                                                   |
|----------------------------------------------|-----------------|---------------------------------------------------------------------------|
| Given empty list                             | 400 Bad Request | "detail": \["This list may not be empty."]                                 |
| Given different type than list               | 400 Bad Request | "detail": \["Expected a list of items but got type "{type}"."]           |
| List contains item of wrong type             | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]         |
| Assignee does not exist for given ID in list | 400 Bad Request | "detail": \["Invalid pk "{assignee\_id}" - object does not exist."]       |
| More than 100 items on a list                | 400 Bad Request | "detail": \["Up to 100 items allowed."]                                    |
| Wrong/not existing  `permission_set_id`      | 404 Not Found   |                                                                           |
| Wrong/not existing `record_id`               | 403 Forbidden   |                                                                           |
| Insufficient permissions                     | 403 Forbidden   | "detail": "You do not have permission to perform this action."            |

## Not allowed endpoints

### GET /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/`id`/

### Response example

* Status `405 Method Not Allowed`

### PATCH /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/`id`/

### Response example

* Status `405 Method Not Allowed`

### PUT /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/`id`/

### Response example

* Status `405 Method Not Allowed`

### DELETE /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/`id`/

### Response example

* Status `405 Method Not Allowed`

### OPTIONS /api/object-records/`record_id`/permission-sets/`permission_set_id`/assignees/users/`id`/

### Response example

* Status `405 Method Not Allowed`

---

---
url: >-
  /knowledgebase/applied-ai/mcp-services/mcp-work/mcp-work-configuration/associate-mcp-connectors-with-object-classes.md
---
# Associate MCP connectors with Object Classes

You can control which Object Classes an MCP connector can be associated with by selecting classes when you create the connector or by changing its Object Class selections later.

## When to use this

Use Object Class associations when an MCP connector should be available for selected areas of your Object Model rather than for every Object Class.

## Before you start

You need permission to create or edit MCP connectors and access to the Object Classes that are available in the connector's **Object classes** tab.

## Select Object Classes when creating a connector

1. Go to **System configuration** > **Integrations** and start creating an MCP connector.
2. Open the **Object classes** tab.
3. Expand the Object Class tree to find the classes you want the connector to access.
4. Select each required Object Class using its checkbox.
5. Save the connector.

The tree includes nested Object Classes. Parent and child selections are independent: selecting a child does not automatically select its parent, and selecting a parent does not automatically select its children.

A parent can display an indeterminate state when the parent itself is not selected but one or more descendants are selected.

![Object classes tab showing a nested Object Class tree with selection checkboxes](../../../../../images/TODO-mcp-object-class-tree.png)

## Change Object Class associations for an existing connector

1. Open the MCP connector's edit page.
2. Open the **Object classes** tab.
3. Existing associations are shown as selected.
4. Select additional Object Classes to associate them with the connector.
5. Clear selected Object Classes to remove those associations.
6. Click **Save** to apply the changes.

If you click **Cancel**, changes to the Object Class selections are not applied.

## Things to remember

* Object Class selections are independent at every level of the tree.
* An indeterminate parent indicates that one or more descendants are selected; it does not mean the parent itself is selected.
* Only checked Object Classes are associated when you save.
* Removing an association means that connector should no longer be offered for that Object Class in the relevant permissions UI.

## Useful info

1. Associated connectors are used by the **Applied AI** selector in Object Class permissions.
2. You can update associations later without recreating the connector.

---

---
url: /knowledgebase/release-notes/release-notes-1.14/authentication-security.md
---

# Authentication & Security

## Enhanced `/api/security/` OPTIONS for authentication method management

We’ve enhanced the `/api/security/` OPTIONS response to provide greater visibility and control over authentication configuration.

With this update, the response now includes detailed information about the `authentication_method` field, enabling you to **programmatically understand and configure allowed login methods** for different user types.

This improvement makes it easier to build more flexible and secure authentication workflows, while reducing the need for manual configuration or guesswork when integrating with the API.

**Example response structure**

```
{
  "details": {
    "schema": [
      {
        "alias": "password_complexity",
        "schema": [
          {
            "alias": "max_repeating_chars",
            "type": "int",
            "required": false,
            "validators": [
              { "type": "min_value", "value": 0 }
            ]
          },
          {
            "alias": "min_letters",
            "type": "int",
            "required": false,
            "validators": [
              { "type": "min_value", "value": 0 }
            ]
          },
          {
            "alias": "min_numbers",
            "type": "int",
            "required": false,
            "validators": [
              { "type": "min_value", "value": 0 }
            ]
          },
          {
            "alias": "min_symbols",
            "type": "int",
            "required": false,
            "validators": [
              { "type": "min_value", "value": 0 }
            ]
          },
          {
            "alias": "min_lower_case",
            "type": "int",
            "required": false,
            "validators": [
              { "type": "min_value", "value": 0 }
            ]
          },
          {
            "alias": "min_upper_case",
            "type": "int",
            "required": false,
            "validators": [
              { "type": "min_value", "value": 0 }
            ]
          },
          {
            "alias": "min_length",
            "type": "int",
            "required": false,
            "validators": [
              { "type": "min_value", "value": 0 }
            ]
          }
        ]
      },
      {
        "alias": "systemconf",
        "schema": [
          {
            "alias": "password_prevent_reuse",
            "type": "bool",
            "required": false
          },
          {
            "alias": "password_rotation_interval",
            "type": "int",
            "required": false,
            "validators": [
              { "type": "min_value", "value": 0 },
              { "type": "max_value", "value": 32767 }
            ]
          },
          {
            "alias": "activation_link_valid_period",
            "type": "int",
            "required": false,
            "validators": [
              { "type": "min_value", "value": 0 }
            ]
          }
        ]
      },
      {
        "alias": "authentication_method",
        "schema": [
          {
            "alias": "internal",
            "type": "enum",
            "required": false,
            "values": [
              { "value": "any", "text": "Any" },
              { "value": "password", "text": "Password" },
              { "value": "sso", "text": "Single Sign-On" }
            ]
          },
          {
            "alias": "external",
            "type": "enum",
            "required": false,
            "values": [
              { "value": "any", "text": "Any" },
              { "value": "password", "text": "Password" },
              { "value": "sso", "text": "Single Sign-On" }
            ]
          },
          {
            "alias": "full",
            "type": "enum",
            "required": false,
            "values": [
              { "value": "any", "text": "Any" },
              { "value": "password", "text": "Password" },
              { "value": "sso", "text": "Single Sign-On" }
            ]
          },
          {
            "alias": "super_admin",
            "type": "enum",
            "required": false,
            "values": [
              { "value": "any", "text": "Any" },
              { "value": "password", "text": "Password" },
              { "value": "sso", "text": "Single Sign-On" }
            ]
          }
        ]
      }
    ]
  }
}
```

## Updated authentication expiry notifications

We’ve refreshed the Authentication Object expiry notification emails to make them clearer, more consistent, and easier to act on.

The updated template now applies to both **upcoming expiries** and **already expired Authentication Objects**, providing a more unified and streamlined experience.

**Updated email content**

```
Title: Action needed: status update for your Authentication Object

Dear <name>,

We’re contacting you regarding the status of one of your Authentication Objects. Our system indicates that it is either approaching its expiry date or has already expired. 

Details :

•	Authentication Object : <name>
•	Provider : <provider>
•	ID : <id>
•	Link: <link>
•	Expiry Date : <datedime>
•	Applies To : <parameter>

To ensure uninterrupted access and workflow continuity, please review this Authentication Object and update it if it is still required.

If the Authentication Object is no longer in use, you may safely ignore this message.

<email admin signature>
```

As part of this update, we’ve also simplified the expiry date format by removing the time element - making key information clearer and easier to understand at a glance.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.13/authentication-object-changes.md
---

# Authentication object changes

Authentication credentials power your most critical integrations—email delivery, API connections, and ML services. When they expire or disappear unexpectedly, entire workflows can fail without warning. This release transforms how you manage these essential components.

## Automatic expiry notifications

Authentication objects now monitor their own lifecycle. **Fourteen days before** any credential expires, the system automatically emails the person who created it. The notification includes the object's name and precise expiry timestamp, giving you proper lead time to refresh tokens or update passwords.

If the original creator no longer has an account, no notification is sent, preventing emails to inactive addresses whilst maintaining security boundaries.

## Complete usage visibility

Each authentication object now displays a comprehensive usage panel showing exactly where it's deployed across your platform. When you're reviewing credentials, you'll see:

* **Sequencer integrations**: Every sequence using the object, listed by name for immediate identification of dependencies.
* **System email configuration**: Clear indication when the object powers your outbound mail setup.

This visibility eliminates guesswork when managing credentials and helps you understand the true impact of any changes.

![Auth object 1.gif](/knowledgebase/images/img_4916202355359_1776895584.png)

## Deletion protection

Authentication objects currently in use cannot be deleted. The system prevents the removal of any credential that would break active sequences or system functions. **This safeguard** stops accidental deletion of SMTP credentials that handle system emails, API tokens powering live integrations, or any other authentication that keeps your workflows running.

## Summary

Your authentication infrastructure now operates with built-in intelligence. Credentials announce their approaching expiry, reveal their dependencies clearly, and protect themselves from destructive changes.

These improvements reduce the maintenance overhead of complex automation while preventing the silent failures that can disrupt business operations. Your integrations stay stable, your team stays informed, and your workflows keep running.

---

---
url: /knowledgebase/release-notes/release-notes-1.9/authentication-objects.md
---

# Authentication objects

**Exciting news!** We're thrilled to announce that our Authentication Objects feature is levelling up, and bringing along top-tier providers like Salesforce, Adobe, and Box.

We've reimagined the integration experience from the ground up. Gone are the days of deciphering cryptic documentation. We've built pre-configured fields for integrating with leading providers. Simply fill in the blanks, and watch your integrations seamlessly click into place. With a unique set of fields tailored to each provider, crafting your integration has never been easier.

![AuthObject1\_article.gif](../../../images2/zendesk_17868342594461_001_3379088c8f74.gif)

**Built-in testing** gives you the chance to put your configuration to the test before committing. With this feature, you can ensure that your integration is rock-solid and ready to roll before going live.

![AuthObject4\_article.gif](../../../images2/zendesk_17868342594461_002_ae04a0210efb.gif)

## Generic OAuth 2.0 template

Now, let's talk about the Generic OAuth 2.0 template — a game-changer in the integration landscape. This versatile template opens doors to limitless integration possibilities, allowing you to connect with any provider supporting standard OAuth 2.0 in client credentials flow.

**The Generic OAuth 2.0 template includes:**

* **Token URL:** the URL that the request would be sent to acquire the token.
* **Refresh URL:** URL that the system would send the request to gain the refresh token.
* **Client ID:** application's unique identifier.
* **Client Secret:** application's confidential key.
* **Additional Parameters:** these optional parameters, saved as a JSON object in the configuration, can vary for each setup and would be injected into the authentication request.
* **Additional Authorization Headers:** additional parameters saved as multiple keys with values will be added as parameters to the headers of an API Call using the given Authentication Object.

![AuthObject3\_article.gif](../../../images2/zendesk_17868342594461_003_72ebd43f9cb5.gif)

## What this means for you

It means unlocking a world of integration opportunities tailored to your exact needs. Whether you're syncing data between systems, managing documents from various sources, or orchestrating complex workflows, our enhanced Authentication Objects feature puts the power in your hands.

Let's simplify your workflows and drive efficiency with Catalyst!

---

---
url: /api/catalyst/resources/authentication/authentication-objects.md
---
# Authentication Objects

This technical design describes implementation and API for Authentication Objects.

## POST  /api/authentication-objects/

### Permissions

Requires `authentication` and `authentication_objects.create` permission.

### Request example

#### Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

#### Body

| Key               | Type    | Notes                                                                                                                                                                                  |
|-------------------|---------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| name              | string  |                                                                                                                                                                                        |
| provider          | enum    | Values: imanage, docusign, api\_key, autologyx, microsoft\_client\_credentials, box\_client\_credentials, adobe\_client\_credentials, salesforce\_client\_credentials, oauth\_client\_credentials |
| description       | string  |                                                                                                                                                                                        |
| expiry\_at         | date    | Optional                                                                                                                                                                               |
| expiry\_applies\_to | string  | Optional                                                                                                                                                                               |\
| credentials       | object  | Each provider has different set of credentials                                                                                                                                         |

##### Provider `iManage`

| Key           | Type    | Notes |
|---------------|---------|-------|
| username      | string  |       |
| password      | string  |       |
| client\_id     | string  |       |
| client\_secret | string  |       |
| host          | string  |       |

##### Provider `DocuSign`

| Key             | Type    | Notes |
|-----------------|---------|-------|
| user\_id         | string  |       |
| client\_id       | string  |       |
| private\_rsa\_key | string  |       |
| host            | string  |       |

##### Provider `Autologyx`

| Key             | Type    | Notes |
|-----------------|---------|-------|
| username        | string  |       |
| password        | string  |       |

##### Provider `ApiKey`

| Key        | Type    | Notes |
|------------|---------|-------|
| header\_key | string  |       |
| url\_key    | string  |       |
| api\_Key    | string  |       |

##### Provider `Microsoft Client Credentials`

| Key           | Type    | Notes |
|---------------|---------|-------|
| tenant        | string  |       |
| client\_id     | string  |       |
| client\_secret | string  |       |
| scope         | string  |       |

##### Provider `Box Client Credentials`

| Key              | Type   | Notes |
|------------------|--------|-------|
| client\_id        | string |       |
| client\_secret    | string |       |
| scope            | string |       |
| box\_subject\_type | enum   |       |
| box\_subject\_id   | string |       |

##### Provider `Adobe Client Credentials`

| Key              | Type   | Notes |
|------------------|--------|-------|
| client\_id        | string |       |
| client\_secret    | string |       |
| scope            | string |       |

##### Provider `Salesforce Client Credentials`

| Key           | Type   | Notes |
|---------------|--------|-------|
| client\_id     | string |       |
| client\_secret | string |       |
| domain\_name   | string |       |

##### Provider `Generic Client Credentials`

| Key                              | Type        | Notes |
|----------------------------------|-------------|-------|
| client\_id                        | string      |       |
| client\_secret                    | string      |       |
| scope                            | string      |       |
| token\_url                        | url         |       |
| refresh\_url                      | url         |       |
| additional\_parameters            | json\_object |       |
| additional\_authorization\_headers | json\_object |       |

##### Provider `ROPC Generic oAuth`

| Key              | Type    | Notes |
|------------------|---------|-------|
| token\_url        | url     |       |
| refresh\_url      | url     |       |
| username         | string  |       |
| password         | string  |       |
| client\_id        | string  |       |
| client\_secret    | string  |       |
| scope            | string  |       |

### Response

* Successful status `201 Created`
* Response body:

```json
{
  "id": 5,
  "name": "My iManage credentials",
  "provider": "imanage",
  "description": "The credentials to iManage provider",
  "expiry_at": "2025-02-05",
  "expiry_applies_to": "client_secret",
  "created_at": "2021-05-18T06:39:17.688341Z",
  "created_by": { 
    "id ": 256, 
    "first_name": "John", 
    "last_name": "Smith", 
    "username": "j.smith@autologyx.com", 
    "company_name": "Autologyx", 
    "is_deleted": false
},
  "modified_at": "2021-05-18T06:39:17.688394Z"
  "modified_by": {
    "id ": 256,
    "first_name": "John",
    "last_name": "Smith",
    "username": "j.smith@autologyx.com",
    "company_name": "Autologyx",
    "is_deleted": false
  },
  "_meta": {
    "permissions":{
      "list": true,
      "view": true,
      "create": true,
      "edit": true,
      "delete": true
    } 
  },
  "credentials": <credentials>
}

```

### Errors

| Error                                                            | Response code    | Message                                                                                               |
|------------------------------------------------------------------|------------------|-------------------------------------------------------------------------------------------------------|
| "name" is missing                                                | 400 Bad Request  | "name": \[ "This field is required." ]                                                                 |
| "name" is null                                                   | 400 Bad Request  | "name": \[ "This field may not be null." ]                                                             |
| "name" has > 100 chars                                           | 400 Bad Request  | "name": \[ "Ensure this field has no more than 100 characters." ]                                      |
| "name" is not unique                                             | 400 Bad Request  | "name": \[ "This field must be unique." ]                                                              |
| "expiry\_at" is not a valid date                                  | 400 Bad Request  | "expiry\_at": \["Date has wrong format. Use one of these formats instead: YYYY-MM-DD."]                 |
| "expiry\_at" is not a future date                                 | 400 Bad Request  | "expiry\_at": \[ "Date must be in the future." ]                                                        |
| "expiry\_applies\_to" not provided when "expiry\_at" is provided    | 400 Bad Request  | "expiry\_applies\_to": \[ "This field is required when expiry\_at is provided." ]                         |
| "expiry\_at\_to" not provided when "expiry\_applies\_to" is provided | 400 Bad Request  | expiry\_at": \[ "This field is required when expiry\_applies\_to is provided." ]                          |
| "expiry\_applies\_to" has > 255 chars                              | 400 Bad Request  | "expiry\_applies\_to ": \[ "Ensure this field has no more than 255 characters." ]                        |
| "expiry\_applies\_to" is null when the "expiry\_at" is provided     | 400 Bad Request  | "expiry\_applies\_to ": \[ "This field may not be null when expiry\_at is provided" ]                     |
| "expiry\_at\_to" is null when the "expiry\_applies\_to" is provided  | 400 Bad Request  | "expiry\_at ": \[ "This field may not be null when expiry\_applies\_to is provided" ]                     |
| "expiry\_applies\_to" is blank                                     | 400 Bad Request  | expiry\_applies\_to ": \[ "This field may not be blank." ]                                               |
| "provider" is missing                                            | 400 Bad Request  | "provider": \[ "This field is required." ]                                                             |
| "provider" is null                                               | 400 Bad Request  | "provider": \[ "This field may not be null." ]                                                         |
| "provider" is not a choice                                       | 400 Bad Request  | "provider": \[ "{ provider } is not a valid choice" ]                                                  |
| "description" has > 500  chars                                   | 400 Bad Request  | "description": \[ "Ensure this field has no more than 500 characters." ]                               |
| "description" is null                                            | 400 Bad Request  | "description": \[ "This field may not be null." ]                                                      |
| "credentials" is missing                                         | 400 Bad Request  | "credentials": \[ "This field is required." ]                                                          |
| "credentials" is null                                            | 400 Bad Request  | "credentials": \[ "This field may not be null." ]                                                      |
| Limit of Authentication exceeded                                 | 400 Bad Request  | "type": \[ "Limit of 100 Authentication Objects has been exceeded" ]                                   |
| Provider integration is both inactive and disabled               | 400 Bad Request  | "details": \["\<provider\_name> integration requires activation and enablement to perform this action."] |
| Provider integration is inactive                                 | 400 Bad Request  | "details": \["\<provider\_name> integration requires activation to perform this action."]                |
| Provider integration is disabled                                 | 400 Bad Request  | "details": \["\<provider\_name> integration requires enablement to perform this action."]                |
| Insufficient permissions                                         | 403 Forbidden    | "detail": "You do not have permission to perform this action."                                        |

#### Provider "IManage"

| Error                           | Response code    | Message                                                                   |
|---------------------------------|------------------|---------------------------------------------------------------------------|
| "username" is missing           | 400 Bad Request  | "username": \[ "This field is required." ]                                 |
| "username" is null              | 400 Bad Request  | "username": \[ "This field may not be null." ]                             |
| "username" has > 255 chars      | 400 Bad Request  | "username": \[ "Ensure this field has no more than 255 characters." ]      |
| "password" is missing           | 400 Bad Request  | "password": \[ "This field is required." ]                                 |
| "password" is null              | 400 Bad Request  | "password": \[ "This field may not be null." ]                             |
| "password" has > 255 chars      | 400 Bad Request  | "password": \[ "Ensure this field has no more than 255 characters." ]      |
| "client\_id" is missing          | 400 Bad Request  | "client\_id": \[ "This field is required." ]                                |
| "client\_id" is null             | 400 Bad Request  | "client\_id": \[ "This field may not be null." ]                            |
| "client\_id" has > 255 chars     | 400 Bad Request  | "client\_id": \[ "Ensure this field has no more than 255 characters." ]     |
| "client\_secret" has > 255 chars | 400 Bad Request  | "client\_secret": \[ "Ensure this field has no more than 200 characters." ] |
| "host" is missing               | 400 Bad Request  | "host": \[ "This field is required." ]                                     |
| "host" is null                  | 400 Bad Request  | "host": \[ "This field may not be null." ]                                 |
| "host" has > 200  chars         | 400 Bad Request  | "host": \[ "Ensure this field has no more than 200 characters." ]          |
| "host" is not valid             | 400 Bad Request  | "host": \[ "Enter a valid URL" ]                                           |

#### Provider "DocuSign"

| Error                              | Response code    | Message                                                                      |
|------------------------------------|------------------|------------------------------------------------------------------------------|
| "user\_id" is missing               | 400 Bad Request  | "user\_id": \[ "This field is required." ]                                     |
| "user\_id" is null                  | 400 Bad Request  | "user\_id": \[ "This field may not be null." ]                                 |
| "user\_id" has > 255 chars          | 400 Bad Request  | "user\_id": \[ "Ensure this field has no more than 255 characters." ]          |
| "client\_id" is missing             | 400 Bad Request  | "client\_id": \[ "This field is required." ]                                   |
| "client\_id" is null                | 400 Bad Request  | "client\_id": \[ "This field may not be null." ]                               |
| "client\_id" has > 255 chars        | 400 Bad Request  | "client\_id": \[ "Ensure this field has no more than 255 characters." ]        |
| "private\_rsa\_key" is missing       | 400 Bad Request  | "private\_rsa\_key": \[ "This field is required." ]                             |
| "private\_rsa\_key" is null          | 400 Bad Request  | "private\_rsa\_key": \[ "This field may not be null." ]                         |
| "private\_rsa\_key" has > 2000 chars | 400 Bad Request  | "private\_rsa\_key": \[ "Ensure this field has no more than 2000 characters." ] |
| "host" is missing                  | 400 Bad Request  | "host": \[ "This field is required." ]                                        |
| "host" is null                     | 400 Bad Request  | "host": \[ "This field may not be null." ]                                    |
| "host" has > 200  chars            | 400 Bad Request  | "host": \[ "Ensure this field has no more than 200 characters." ]             |
| "host" is not valid                | 400 Bad Request  | "host": \[ " \fake\_host\ is not a valid choice." ]                            |

#### Provider "Autologyx"

| Error                              | Response code    | Message                                                                     |
|------------------------------------|------------------|-----------------------------------------------------------------------------|
| "username" is missing              | 400 Bad Request  | "username": \[ "This field is required." ]                                   |
| "username" is null                 | 400 Bad Request  | "username": \[ "This field may not be null." ]                               |
| "username" has > 255 chars         | 400 Bad Request  | "username": \[ "Ensure this field has no more than 255 characters." ]        |
| "username" is not valid            | 400 Bad Request  | "username": \[ "Enter a valid email address" ]                               |
| "password" is missing              | 400 Bad Request  | "password": \[ "This field is required." ]                                   |
| "password" is null                 | 400 Bad Request  | "password": \[ "This field may not be null." ]                               |
| "password" has > 255 chars         | 400 Bad Request  | "password": \[ "Ensure this field has no more than 255 characters." ]        |

#### Provider "Microsoft Client Credentials"

| Error                           | Response code    | Message                                                                   |
|---------------------------------|------------------|---------------------------------------------------------------------------|
| "tenant" is missing             | 400 Bad Request  | "tenant": \[ "This field is required." ]                                   |
| "tenant" is null                | 400 Bad Request  | "tenant": \[ "This field may not be null." ]                               |
| "tenant" has > 255 chars        | 400 Bad Request  | "tenant": \[ "Ensure this field has no more than 255 characters." ]        |
| "client\_id" is missing          | 400 Bad Request  | "client\_id": \[ "This field is required." ]                                |
| "client\_id" is null             | 400 Bad Request  | "client\_id": \[ "This field may not be null." ]                            |
| "client\_id" has > 120 chars     | 400 Bad Request  | "client\_id": \[ "Ensure this field has no more than 120 characters." ]     |
| "client\_secret" is missing      | 400 Bad Request  | "client\_secret": \[ "This field is required." ]                            |
| "client\_secret" is null         | 400 Bad Request  | "client\_secret": \[ "This field may not be null." ]                        |
| "client\_secret" has > 120 chars | 400 Bad Request  | "client\_secret": \[ "Ensure this field has no more than 120 characters." ] |
| "scope" is missing              | 400 Bad Request  | "scope": \[ "This field is required." ]                                    |
| "scope" is null                 | 400 Bad Request  | "scope": \[ "This field may not be null." ]                                |
| "scope" has > 255  chars        | 400 Bad Request  | "scope": \[ "Ensure this field has no more than 255 characters." ]         |

#### Provider "Box Client Credentials"

| Error                                      | Response code    | Message                                                                    |
|--------------------------------------------|------------------|----------------------------------------------------------------------------|
| "client\_id" is missing                     | 400 Bad Request  | "client\_id": \[ "This field is required." ]                                 |
| "client\_id" is null                        | 400 Bad Request  | "client\_id": \[ "This field may not be null." ]                             |
| "client\_id" has > 120 chars                | 400 Bad Request  | "client\_id": \[ "Ensure this field has no more than 120 characters." ]      |
| "client\_secret" is missing                 | 400 Bad Request  | "client\_secret": \[ "This field is required." ]                             |
| "client\_secret" is null                    | 400 Bad Request  | "client\_secret": \[ "This field may not be null." ]                         |
| "client\_secret" has > 120 chars            | 400 Bad Request  | "client\_secret": \[ "Ensure this field has no more than 120 characters." ]  |
| "scope" has > 255  chars                   | 400 Bad Request  | "scope": \[ "Ensure this field has no more than 255 characters." ]          |
| "box\_subject\_id" is missing                | 400 Bad Request  | "box\_subject\_id": \[ "This field is required." ]                            |
| "box\_subject\_id" is null                   | 400 Bad Request  | "box\_subject\_id": \[ "This field may not be null." ]                        |
| "box\_subject\_id" has > 255 chars           | 400 Bad Request  | "box\_subject\_id": \[ "Ensure this field has no more than 255 characters." ] |
| "box\_subject\_type" is missing              | 400 Bad Request  | "box\_subject\_type": \[ "This field is required." ]                          |
| "box\_subject\_type" is null                 | 400 Bad Request  | "box\_subject\_type": \[ "This field may not be null." ]                      |
| "box\_subject\_type" not a valid enum value  | 400 Bad Request  | "box\_subject\_type": \[ " ""value" is not a valid choice."]                |

#### Provider "Adobe Client Credentials"

| Error                           | Response code    | Message                                                                   |
|---------------------------------|------------------|---------------------------------------------------------------------------|
| "client\_id" is missing          | 400 Bad Request  | "client\_id": \[ "This field is required." ]                                |
| "client\_id" is null             | 400 Bad Request  | "client\_id": \[ "This field may not be null." ]                            |
| "client\_id" has > 120 chars     | 400 Bad Request  | "client\_id": \[ "Ensure this field has no more than 120 characters." ]     |
| "client\_secret" is missing      | 400 Bad Request  | "client\_secret": \[ "This field is required." ]                            |
| "client\_secret" is null         | 400 Bad Request  | "client\_secret": \[ "This field may not be null." ]                        |
| "client\_secret" has > 120 chars | 400 Bad Request  | "client\_secret": \[ "Ensure this field has no more than 120 characters." ] |
| "scope" is missing              | 400 Bad Request  | "scope": \[ "This field is required." ]                                    |
| "scope" is null                 | 400 Bad Request  | "scope": \[ "This field may not be null." ]                                |
| "scope" has > 255  chars        | 400 Bad Request  | "scope": \[ "Ensure this field has no more than 255 characters." ]         |

#### Provider "Generic Client Credentials"

| Error                                               | Response code    | Message                                                                                                      |
|-----------------------------------------------------|------------------|--------------------------------------------------------------------------------------------------------------|
| "client\_id" is missing                              | 400 Bad Request  | "client\_id": \[ "This field is required." ]                                                                   |
| "client\_id" is null                                 | 400 Bad Request  | "client\_id": \[ "This field may not be null." ]                                                               |
| "client\_id" has > 120 chars                         | 400 Bad Request  | "client\_id": \[ "Ensure this field has no more than 120 characters." ]                                        |
| "client\_secret" is missing                          | 400 Bad Request  | "client\_secret": \[ "This field is required." ]                                                               |
| "client\_secret" is null                             | 400 Bad Request  | "client\_secret": \[ "This field may not be null." ]                                                           |
| "client\_secret" has > 120 chars                     | 400 Bad Request  | "client\_secret": \[ "Ensure this field has no more than 120 characters." ]                                    |
| "scope" is null                                     | 400 Bad Request  | "scope": \[ "This field may not be null." ]                                                                   |
| "scope" has > 255  chars                            | 400 Bad Request  | "scope": \[ "Ensure this field has no more than 255 characters." ]                                            |
| "token\_url" is missing                              | 400 Bad Request  | "token\_url": \[ "This field is required." ]                                                                   |
| "token\_url" is null                                 | 400 Bad Request  | "token\_url": \[ "This field may not be null." ]                                                               |
| "token\_url" has > 255 chars                         | 400 Bad Request  | "token\_url": \[ "Ensure this field has no more than 255 characters." ]                                        |
| "token\_url" not valid URL                           | 400 Bad Request  | "token\_url": \[ "Enter a valid URL." ]                                                                        |
| "refresh\_url" is null                               | 400 Bad Request  | "refresh\_url": \[ "This field may not be null." ]                                                             |
| "refresh\_url" has > 255 chars                       | 400 Bad Request  | "refresh\_url": \[ "Ensure this field has no more than 255 characters." ]                                      |
| "refresh\_url" not valid URL                         | 400 Bad Request  | "refresh\_url": \[ "Enter a valid URL." ]                                                                      |
| "additional\_parameters" is null                     | 400 Bad Request  | "additional\_parameters": \[ "This field may not be null." ]                                                   |
| "additional\_parameters" has > 5000 chars            | 400 Bad Request  | "additional\_parameters": \[ "Ensure this field has no more than 255 characters (it has {value}." ]            |
| "additional\_parameters" is not Object               | 400 Bad Request  | "additional\_parameters": \[ "Value must be valid JSON object." ]                                              |
| "additional\_authorization\_headers" is null          | 400 Bad Request  | "additional\_authorization\_headers": \[ "This field may not be null." ]                                        |
| "additional\_authorization\_headers" has > 5000 chars | 400 Bad Request  | "additional\_authorization\_headers": \[ "Ensure this field has no more than 255 characters (it has {value}." ] |
| "additional\_authorization\_headers" is not Object    | 400 Bad Request  | "additional\_authorization\_headers": \[ "Value must be valid JSON object." ]                                   |

#### Provider "ROPC Generic oAuth"

| Error                           | Response code    | Message                                                                   |
|---------------------------------|------------------|---------------------------------------------------------------------------|
| "token\_url" is missing          | 400 Bad Request  | "token\_url": \[ "This field is required." ]                                |
| "token\_url" is null             | 400 Bad Request  | "token\_url": \[ "This field may not be null." ]                            |
| "token\_url" has > 255 chars     | 400 Bad Request  | "token\_url": \[ "Ensure this field has no more than 255 characters." ]     |
| "token\_url" not valid URL       | 400 Bad Request  | "token\_url": \[ "Enter a valid URL." ]                                     |
| "refresh\_url" is null           | 400 Bad Request  | "refresh\_url": \[ "This field may not be null." ]                          |
| "refresh\_url" has > 255 chars   | 400 Bad Request  | "refresh\_url": \[ "Ensure this field has no more than 255 characters." ]   |
| "refresh\_url" not valid URL     | 400 Bad Request  | "refresh\_url": \[ "Enter a valid URL." ]                                   |
| "username" is missing           | 400 Bad Request  | "username": \[ "This field is required." ]                                 |
| "username" is null              | 400 Bad Request  | "username": \[ "This field may not be null." ]                             |
| "username" has > 255 chars      | 400 Bad Request  | "username": \[ "Ensure this field has no more than 255 characters." ]      |
| "password" is missing           | 400 Bad Request  | "password": \[ "This field is required." ]                                 |
| "password" is null              | 400 Bad Request  | "password": \[ "This field may not be null." ]                             |
| "password" has > 255 chars      | 400 Bad Request  | "password": \[ "Ensure this field has no more than 255 characters." ]      |
| "client\_id" is missing          | 400 Bad Request  | "client\_id": \[ "This field is required." ]                                |
| "client\_id" is null             | 400 Bad Request  | "client\_id": \[ "This field may not be null." ]                            |
| "client\_id" has > 255 chars     | 400 Bad Request  | "client\_id": \[ "Ensure this field has no more than 255 characters." ]     |
| "client\_secret" is missing      | 400 Bad Request  | "client\_secret": \[ "This field is required." ]                            |
| "client\_secret" is null         | 400 Bad Request  | "client\_secret": \[ "This field may not be null." ]                        |
| "client\_secret" has > 255 chars | 400 Bad Request  | "client\_secret": \[ "Ensure this field has no more than 255 characters." ] |
| "scope" is null                 | 400 Bad Request  | "scope": \[ "This field may not be null." ]                                |
| "scope" has > 255  chars        | 400 Bad Request  | "scope": \[ "Ensure this field has no more than 255 characters." ]         |

## GET  /api/authentication-objects/

Returns list of Authentication Objects.

### Permissions

Requires `authentication` and `authentication_objects.list` permission.

### Request example

#### Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

#### Response `results` array

| Key               | Type     | Notes                                                                                                                                                                                  |
|-------------------|----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| id                | int      |                                                                                                                                                                                        |
| name              | string   |                                                                                                                                                                                        |
| description       | string   |                                                                                                                                                                                        |
| provider          | enum     | Values: imanage, docusign, api\_key, autologyx, microsoft\_client\_credentials, box\_client\_credentials, adobe\_client\_credentials, salesforce\_client\_credentials, oauth\_client\_credentials |
| expiry\_at         | date     |                                                                                                                                                                                        |
| created\_at        | datetime |                                                                                                                                                                                        |
| created\_by        | user     |                                                                                                                                                                                        |
| modified\_at       | datetime |                                                                                                                                                                                        |
| modified\_by       | user     |                                                                                                                                                                                        |
| \_meta.permissions | Object   | Dict describing permissions.                                                                                                                                                           |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 20,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 5,
      "name": "My iManage credentials",
      "description": "The credentials to iManage provider"
      "provider": "imanage",
      "expiry_at": "2021-08-22",
      "created_at": "2021-08-12T11:21:51.877690+02:00",
      "created_by": <user>,
      "modified_at": "2021-09-14T11:11:31.127734+02:00",
      "modified_by": <user>,
      "_meta": {
        "permissions": {
            "list": true,
            "view": true,
            "edit": true,
            "create": true,
            "delete": true,
        }
      }
    }
  ]
}
```

### Sorting

| Parameter   | Example                                               | Notes          |
|-------------|-------------------------------------------------------|----------------|
| id          | {build}/api/object-class-forms/?ordering=id           | Ascending      |
| id          | {build}/api/object-class-forms/?ordering=-id          | Descending (-) |
| name        | {build}/api/object-class-forms/?ordering=name         | Ascending      |
| name        | {build}/api/object-class-forms/?ordering=-name        | Descending (-) |
| expiry\_at   | {build}/api/object-class-forms/?ordering=expiry\_at    | Ascending      |
| expiry\_at   | {build}/api/object-class-forms/?ordering=-expiry\_at   | Descending (-) |
| created\_at  | {build}/api/object-class-forms/?ordering=created\_at   | Ascending      |
| created\_at  | {build}/api/object-class-forms/?ordering=-created\_at  | Descending (-) |
| modified\_at | {build}/api/object-class-forms/?ordering=modified\_at  | Ascending      |
| modified\_at | {build}/api/object-class-forms/?ordering=-modified\_at | Descending (-) |

### Filtering

| Parameter    | Predicates          | Example                                                                  |
|--------------|---------------------|--------------------------------------------------------------------------|
| id           | =                   | {build}/api/object-class-forms/?id=9                                     |
| name         | standard string     | {build}/api/object-class-forms/?name\_\_icontains=foobar                   |
| provider     | standard enum       | {build}/api/object-class-forms/?provider\_in=provider                     |
| expiry\_at    | standard date       | {build}/api/object-class-forms/?expiry\_at=2022-01-01                     |\
| created\_at   | standard datetime   | {build}/api/object-class-forms/?created\_at\_\_gte=2022-01-01               |
| created\_by   | standard set        | {build}/api/object-class-forms/?created\_by\_\_in=123,234,345               |
| modified\_at  | standard datetime   | {build}/api/object-class-forms/?modified\_at\_\_range=2022-01-01,2022-01-31 |
| modified\_by  | standard set        | {build}/api/object-class-forms/?modified\_by=123                          |

### Errors

| Error                                            | Response code    | Message                                                                        |
|--------------------------------------------------|------------------|--------------------------------------------------------------------------------|
| Insufficient permissions                         | 403 Forbidden    | "detail": "You do not have permission to perform this action."                 |

## GET  /api/authentication-objects/`id`/

Returns details of Authentication Objects.

### Permissions

Requires `authentication` and `authentication_objects.view` permission.

### Request example

#### Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response example

* Status `200 OK`
* Body

```json
{
  "id": 5,
  "name": "My iManage credentials",
  "description": "The credentials to iManage provider",
  "expiry_at": "2025-02-05",
  "expiry_applies_to": "client_secret",
  "provider": "imanage",
  "created_at": "2021-08-12T11:21:51.877690+02:00",
  "created_by": <user>,
  "modified_at": "2021-09-14T11:11:31.127734+02:00",
  "modified_by": <user>,
  "_meta": {
    "permissions": {
        "list": true,
        "view": true,
        "edit": true,
        "create": true,
        "delete": true,
    }
  },
  "credentials": <credentials>
}
```

##### Autologyx

```json
{
    ...
    "credentials": {
        "username": "user@example.com"
    }
}
```

##### DocuSign

```json
{
    ...
    "credentials": {
        "user_id": "some-user-id",
        "client_id": "some-client-id",
        "host": "https://...."
    }
}
```

##### API Key

```json
{
    ...
    "credentials": {
        "method": "send_in_header",
        "key": "MyHeader"
    }
}
```

##### Adobe Client Credentials

```json
{
    ...
    "credentials": {
        "client_id": "some-client-id",
        "scope": "scope"
    }
}
```

##### Box

```json
{
    ...
    "credentials": {
        "client_id": "some-client-id",
        "scope": "read, write",
        "box_subject_type": "user"
        "box_subject_type": "user-id"
    }
}
```

##### Generic Client Credentials

```json
{
    ...
    "credentials": {
        "token_url": "https://oauth-client-credentials.com",
        "refresh_url": "https://oauth-client-credentials.com",  # included only if not empty
        "client_id": "some-client-id",  # included only if not empty
        "scope": "scope",  # included only if not empty
        "additional_parameters": {"key": "val"},
        "additional_authorization_headers": {"key": "val"},
    }
}
```

##### ROPC Generic oAuth

```json
{
    ...
    "credentials": {
        "token_url": "https://example.com/oauth/refresh",
        "refresh_url": "https://example.com/oauth/token",  # included only if not empty
        "username": "user@example.com",
        "client_id": "some-client-id",  # included only if not empty
        "scope": "read, write",  # included only if not empty
    }
}
```

##### iManage

```json
{
    ...
    "credentials": {
        "username": "user@example.com",
        "client_id": "some-client-id",
        "host": "https://...."
    }
}
```

##### Microsoft Client Credentials

```json
{
    ...
    "credentials": {
        "tenant": "common",
        "client_id": "some-client-id",
        "scope": "https://graph.microsoft.com/.default"
    }
}
```

##### Salesforce Client Credentials

```json
{
    ...
    "credentials": {
        "client_id": "some-client-id",
        "domain_name": "common"
    }
}
```

### Errors

| Error                                          | Response code | Message                                                         |
|------------------------------------------------|---------------|-----------------------------------------------------------------|
| Authentication object with "id" does not exist | 404 Not Found | "detail": "Not found."                                          |
| Insufficient permissions                       | 403 Forbidden | "detail": "You do not have permission to perform this action."  |

## PATCH  /api/authentication-objects/`id`/

Updates the Authentication Object.

### Permissions

Requires `authentication` and `authentication_objects.edit` permission.

### Request example

#### Headers

```
Request Method: PATCH
Content-Type: application/json
Authorization: JWT access_token
```

#### Body

```json
{
  "name": "My updated iManage credentials",
  "description": "The updated credentials to iManage provider"
  "credentials": {
    ...
}
```

##### iManage

```json
{
    ...
    "credentials": {
        "username": "username",
        "password": "notObvious",
        "client_id": "some-client-id",
        "client_secret": "client-secret",
        "host": "https://...."
    }
}
```

##### DocuSign

```json
{
    ...
    "credentials": {
        "user_id": "some-user-id",
        "client_id": "some-client-id",
        "private_rsa_key": "some-private-rsa-key",
        "host": "https://...."
    }
}
```

##### Autologyx

```json
{
    ...
    "credentials": {
        "username": "user@example.com",
        "password": "notObvious",
    }
}
```

##### Microsoft Client Credentials

```json
{
    ...
    "credentials": {
        "tenant": "common",
        "client_id": "some-client-id",
        "client_secret": "some-client-secret",
        "scope": "https://graph.microsoft.com/.default"
    }
}
```

##### Box Client Credentials

```json
{
    ...
    "credentials": {
        "client_id": "some-client-id",
        "client_secret": "some-client-secret",
        "scope": "scope",
        "box_subject_type": "user",
        "box_subject_id": "8949874",
    }
}
```

##### Adobe Client Credentials

```json
{
    ...
    "credentials": {
        "client_id": "some-client-id",
        "client_secret": "some-client-secret",
        "scope": "scope"
    }
}
```

##### Salesforce Client Credentials

```json
{
    ...
    "credentials": {
        "client_id": "some-client-id",
        "client_secret": "some-client-secret",
        "domain_name": "common"
    }
}
```

##### Generic Client Credentials

```json
{
    ...
    "credentials": {
        "client_id": "some-client-id",
        "client_secret": "some-client-secret",
        "scope": "https://graph.microsoft.com/.default",
        "token_url": "https://graph.microsoft.com/token",
        "refresh_url": "https://graph.microsoft.com/token",
        "additional_parameters": {},
        "additional_authorization_headers": {},
    }
}
```

##### ROPC Generic oAuth

```json
{
    ...
    "credentials": {
        "token_url": "https://example.com/oauth/refresh",
        "refresh_url": "https://example.com/oauth/token",
        "username": "user@example.com",
        "password": "notObvious",
        "client_id": "some-client-id",
        "client_secret": "some-client-secret",
        "scope": "read",
    }
}
```

### Response

| Key               | Type      | Notes                                                                                                                                                                                  |
|-------------------|-----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| id                | int       | 	                                                                                                                                                                                      |
| name              | string    | 	                                                                                                                                                                                      |
| description       | string    | 	                                                                                                                                                                                      |
| provider          | enum      | Values: imanage, docusign, api\_key, autologyx, microsoft\_client\_credentials, box\_client\_credentials, adobe\_client\_credentials, salesforce\_client\_credentials, oauth\_client\_credentials |
| expiry\_at         | date      | Optional                                                                                                                                                                               |
| expiry\_applies\_to | string    | Optional                                                                                                                                                                               |
| created\_at        | datetime  | 	                                                                                                                                                                                      |
| created\_by        | user      | 	                                                                                                                                                                                      |
| modified\_at       | datetime  | 	                                                                                                                                                                                      |
| modified\_by       | user      | 	                                                                                                                                                                                      |
| \_meta.permissions | Object    | Dict describing permissions.                                                                                                                                                           |
| credentials       | Object    | A dict with publicly visible credentials.                                                                                                                                              |

### Response example

* Status `200 OK`
* Body

```json
{
  "id": 5,
  "name": "My updated iManage credentials",
  "description": "The updated credentials to iManage provider",
  "expiry_at": "2025-02-05",
  "expiry_applies_to": "client_secret",
  "provider": "imanage",
  "created_at": "2021-08-12T11:21:51.877690+02:00",
  "created_by": <user>,
  "modified_at": "2021-09-14T11:11:31.127734+02:00",
  "modified_by": <user>,
  "_meta": {
    "permissions": {
        "list": true,
        "view": true,
        "edit": true,
        "create": true,
        "delete": true,
    }
  },
  "credentials": <credentials>
}
```

### Restrictions

* The provider cannot be changed once the Authentication Object has been created. Any attempt to change it will be silently ignored.

### Errors

| Error                                                            | Response code    | Message                                                                                      |
|------------------------------------------------------------------|------------------|----------------------------------------------------------------------------------------------|
| Authentication object with "id" does not exist                   | 404 Not Found    | "detail": "Not found."                                                                       |
| Insufficient permissions                                         | 403 Forbidden    | "detail": "You do not have permission to perform this action."                               |
| "expiry\_at" is not a valid date                                  | 400 Bad Request  | "expiry\_at": \["Date has wrong format. Use one of these formats instead: YYYY-MM-DD."]        |
| "expiry\_at" is not a future date                                 | 400 Bad Request  | "expiry\_at": \[ "Date must be in the future." ]                                               |
| "expiry\_applies\_to" not provided when "expiry\_at" is provided    | 400 Bad Request  | "expiry\_applies\_to": \[ "This field is required when expiry\_at is provided." ]                |
| "expiry\_at\_to" not provided when "expiry\_applies\_to" is provided | 400 Bad Request  | expiry\_at": \[ "This field is required when expiry\_applies\_to is provided." ]                 |
| "expiry\_applies\_to" has > 255 chars                              | 400 Bad Request  | "expiry\_applies\_to ": \[ "Ensure this field has no more than 255 characters." ]               |
| "expiry\_applies\_to" is null when the "expiry\_at" is provided     | 400 Bad Request  | "expiry\_applies\_to ": \[ "This field may not be null when expiry\_at is provided" ]            |
| "expiry\_at\_to" is null when the "expiry\_applies\_to" is provided  | 400 Bad Request  | "expiry\_at ": \[ "This field may not be null when expiry\_applies\_to is provided" ]            |
| "expiry\_applies\_to" is blank                                     | 400 Bad Request  | expiry\_applies\_to ": \[ "This field may not be blank." ]                                      |
| Provider integration is inactive                                 | 400 Bad Request  | "details": \["\<provider\_name> integration requires activation to perform this action."]       |

## DELETE /api/authentication-objects/`id`/

Deletes the Authentication object.

### Permissions

Requires `authentication` and `authentication_objects.delete` permission.

### Request example

* Headers

```
Request Method: DELETE
Location: /api/authentication-objects/9/
Authorization: JWT access_token
```

### Response example

* Status `204 No Content`
* Body

### Errors

| Error                                                   | Response code    | Message                                                                                     |
|---------------------------------------------------------|------------------|---------------------------------------------------------------------------------------------|
| Authentication Object in use - Sequences                | 400 Forbidden    | "detail": "Authentication Object is in use by Sequences."                                   |
| Authentication Object in use - Outbound e-mail settings | 400 Forbidden    | "detail": "Authentication Object is in use by Outbound Mail Setup."                         |
| Insufficient permissions                                | 403 Forbidden    | "detail": "You do not have permission to perform this action."                              |
| Authentication object with "id" does not exist          | 404 Not Found    | "detail": "Not found."                                                                      |
| Provider integration is inactive                        | 400 Bad Request  | "details": \["\<provider\_name> integration requires activation to perform this action."]      |

## OPTIONS  /api/authentication-objects/

### Permissions

Requires `authentication` only.

### Request example

* Headers

```
Request Method: OPTIONS
Location: /api/authentication-objects/
```

### Response example

* Status `200 OK`
* Body

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "name",
                "type": "string",
                "predicates": [
                    "exact",
                    "iexact",
                    "contains",
                    "icontains",
                    "startswith",
                    "istartswith",
                    "endswith",
                    "iendswith"
                ],
                "sort_ok": true
            },
            {
                "alias": "provider",
                "type": "enum",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "values": [
                    {
                        "value": "autologyx",
                        "text": "Autologyx"
                    },
                    {
                        "value": "docu_sign",
                        "text": "DocuSign"
                    },
                    {
                        "value": "api_key",
                        "text": "Api Key"
                    },
                    {
                        "value": "adobe_client_credentials",
                        "text": "Adobe Client Credentials"
                    },
                    {
                        "value": "box_client_credentials",
                        "text": "Box Client Credentials"
                    },
                    {
                        "value": "oauth_client_credentials",
                        "text": "Generic Client Credentials"
                    },
                    {
                        "value": "oauth_ropc",
                        "text": "ROPC Generic oAuth"
                    },
                    {
                        "value": "imanage",
                        "text": "iManage"
                    },
                    {
                        "value": "microsoft_client_credentials",
                        "text": "Microsoft Client Credentials"
                    },
                    {
                        "value": "salesforce_client_credentials",
                        "text": "Salesforce Client Credentials"
                    }
                ]
            },
            {
                "alias": "description",
                "type": "string",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "expiry_at",
                "type": "date",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range",
                    "isnull"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "modified_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "modified_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            }
        ]
    },
    "details": {
        "schema": [
            {
                "alias": "name",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "description",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 500
                    }
                ]
            },
            {
                "alias": "expiry_at",
                "type": "date",
                "required": false,
                "validators": [
                    {
                        "type": "date_in_future"
                    }
                ]
            },
            {
                "alias": "expiry_applies_to",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 255
                    }
                ]
            },
            {
                "alias": "provider",
                "type": "enum",
                "values": [
                    {
                        "value": "autologyx",
                        "text": "Autologyx"
                    },
                    {
                        "value": "docu_sign",
                        "text": "DocuSign"
                    },
                    {
                        "value": "api_key",
                        "text": "Api Key"
                    },
                    {
                        "value": "adobe_client_credentials",
                        "text": "Adobe Client Credentials"
                    },
                    {
                        "value": "box_client_credentials",
                        "text": "Box Client Credentials"
                    },
                    {
                        "value": "oauth_client_credentials",
                        "text": "Generic Client Credentials"
                    },
                    {
                        "value": "oauth_ropc",
                        "text": "ROPC Generic oAuth"
                    },
                    {
                        "value": "imanage",
                        "text": "iManage"
                    },
                    {
                        "value": "microsoft_client_credentials",
                        "text": "Microsoft Client Credentials"
                    },
                    {
                        "value": "salesforce_client_credentials",
                        "text": "Salesforce Client Credentials"
                    }
                ],
                "required": true
            },
            {
                "alias": "credentials",
                "schema": [],
                "schema_by_provider": [
                    {
                        "provider": "autologyx",
                        "schema": [
                            {
                                "alias": "username",
                                "type": "email",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "password",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "provider": "docu_sign",
                        "schema": [
                            {
                                "alias": "user_id",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "client_id",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "private_rsa_key",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 2000
                                    }
                                ]
                            },
                            {
                                "alias": "host",
                                "type": "enum",
                                "required": true,
                                "values": [
                                    {
                                        "value": "account.docusign.com",
                                        "text": "account.docusign.com"
                                    },
                                    {
                                        "value": "account-d.docusign.com",
                                        "text": "account-d.docusign.com"
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "provider": "api_key",
                        "schema": [
                            {
                                "alias": "api_key",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 8000
                                    }
                                ]
                            },
                            {
                                "alias": "method",
                                "type": "enum",
                                "required": true,
                                "values": [
                                    {
                                        "value": "send_in_header",
                                        "text": "Send in header"
                                    },
                                    {
                                        "value": "send_in_query_string",
                                        "text": "Send in query string"
                                    }
                                ]
                            },
                            {
                                "alias": "key",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "provider": "adobe_client_credentials",
                        "schema": [
                            {
                                "alias": "client_id",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 120
                                    }
                                ]
                            },
                            {
                                "alias": "client_secret",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 120
                                    }
                                ]
                            },
                            {
                                "alias": "scope",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "provider": "box_client_credentials",
                        "schema": [
                            {
                                "alias": "client_id",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 120
                                    }
                                ]
                            },
                            {
                                "alias": "client_secret",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 120
                                    }
                                ]
                            },
                            {
                                "alias": "scope",
                                "type": "string",
                                "required": false,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "box_subject_type",
                                "type": "enum",
                                "required": true,
                                "values": [
                                    {
                                        "value": "user",
                                        "text": "user"
                                    },
                                    {
                                        "value": "enterprise",
                                        "text": "enterprise"
                                    }
                                ]
                            },
                            {
                                "alias": "box_subject_id",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "provider": "oauth_client_credentials",
                        "schema": [
                            {
                                "alias": "client_id",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 120
                                    }
                                ]
                            },
                            {
                                "alias": "client_secret",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 120
                                    }
                                ]
                            },
                            {
                                "alias": "scope",
                                "type": "string",
                                "required": false,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "token_url",
                                "type": "url",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "refresh_url",
                                "type": "url",
                                "required": false,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "additional_parameters",
                                "type": "json_object",
                                "required": false,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 5000
                                    }
                                ]
                            },
                            {
                                "alias": "additional_authorization_headers",
                                "type": "json_object",
                                "required": false,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 5000
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "provider": "oauth_ropc",
                        "schema": [
                            {
                                "alias": "token_url",
                                "type": "url",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "refresh_url",
                                "type": "url",
                                "required": false,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "username",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "password",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "client_id",
                                "type": "string",
                                "required": false,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "client_secret",
                                "type": "string",
                                "required": false,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "scope",
                                "type": "string",
                                "required": false,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "provider": "imanage",
                        "schema": [
                            {
                                "alias": "username",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "password",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "client_id",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "client_secret",
                                "type": "string",
                                "required": false,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "host",
                                "type": "url",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "provider": "microsoft_client_credentials",
                        "schema": [
                            {
                                "alias": "tenant",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            },
                            {
                                "alias": "client_id",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 120
                                    }
                                ]
                            },
                            {
                                "alias": "client_secret",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 120
                                    }
                                ]
                            },
                            {
                                "alias": "scope",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "provider": "salesforce_client_credentials",
                        "schema": [
                            {
                                "alias": "client_id",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 120
                                    }
                                ]
                            },
                            {
                                "alias": "client_secret",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 120
                                    }
                                ]
                            },
                            {
                                "alias": "domain_name",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            }
                        ]
                    }
                ]
            }
        ]
    },
    "restrictions": {
        "limit_items": 100
    }
}
```

## GET /api/authentication-objects/`id`/usage/

### Permissions

Requires `authentication` and `authentication_objects.view` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/authentication-objects/1/usage/
Authorization: JWT access_token
```

### Response

| Key                               | Type       | Notes                           |
|-----------------------------------|------------|---------------------------------|
| num\_of\_outbound\_mail\_setup        | int        |                                 |
| sequences                         | array      |                                 |
| num\_of\_sequences                  | int        |                                 |

### Response `sequences` array

| Key          | Type       | Notes                                          |
|--------------|------------|------------------------------------------------|
| id           | int        | Sequence id                                    |
| name         | str        | Name of sequence                               |

### Response example

* Status `200 OK`
* Body

```json
{
    "num_of_outbound_mail_setup": 0,
    "sequences": [
        {
            "id": 1,
            "name": "sequence1"
        },
        {
            "id": 7,
            "name": "sequence_test"
        }
    ],
    "num_of_sequences": 2,
}
```

### Errors

| Error                         | Response code   | Message                                                            |
|-------------------------------|-----------------|--------------------------------------------------------------------|
| `id` is invalid               | 404 Bad Request | 'detail': "Not found."                                             |
| Unauthorized API call         | 403 Bad Request | 'detail': "You do not have permission to perform this action."     |

## POST  /api/authentication-objects/test/

Returns a status for given credentials:

* True – if credentials are correct
* False – if there was authentication error

### Permissions

Requires `authentication` and `authentication_objects.edit` permission.

### Request example

#### Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

#### Body

For provider specific credentials, see [#POST  /api/authentication-objects/](#post-api-authentication-objects)

```json
{
  "name": "Authentication object",
  "description": "Description",
  "provider": "autologyx",
  "credentials": {
        "username": "some_username@example.test",
        "password": "password"
    }
}
```

### Response

```json
{
    "status": true
}
```

### Errors

| Error                                                     | Response code     | Message                                                                                               |
|-----------------------------------------------------------|-------------------|-------------------------------------------------------------------------------------------------------|
| Provider integration is both inactive and disabled        | 400 Bad Request   | "details": \["\<provider\_name> integration requires activation and enablement to perform this action."] |
| Provider integration is inactive                          | 400 Bad Request   | "details": \["\<provider\_name> integration requires activation to perform this action."]                |
| Provider integration is disabled                          | 400 Bad Request   | "details": \["\<provider\_name> integration requires enablement to perform this action."]                |

## POST  /api/authentication-objects/`id`/test/

Returns a status for credentials stored for an existing authentication object:

* True – if credentials are correct
* False – if there was authentication error

### Permissions

Requires `authentication` and `authentication_objects.edit` permission.

### Request example

#### Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

#### Body

For provider specific credentials, see [#POST /api/authentication-objects/](#post-api-authentication-objects)

```json
{
  "name": "Authentication object",
  "description": "Description",
  "provider": "autologyx",
  "credentials": {
        "username": "some_username@example.test",
        "password": "password"
    }
}
```

### Response

```json
{
    "status": true
}
```

### Errors

| Error                                  | Response code     | Message                                                                                            |
|----------------------------------------|-------------------|----------------------------------------------------------------------------------------------------|
| Provider integration is inactive       | 400 Bad Request   | "details": \["\<provider\_name> integration requires activation to perform this action."]             |

# Personal Authentication  - PAO

Personal Authentication Objects are user-specific credentials that allow individual users to authenticate
and access external systems. Unlike system-wide Authentication Objects, they are created and managed by Users
without requiring special permissions.

Each Personal Authentication Object is private to the User who created it, ensuring that only they can view
or modify it. However, Super Admin Users are an exception; they have the ability to edit them but cannot use them
to authenticate in external systems.

PAO related to any [Integration](#integrations-api) are excluded.

## POST  /api/authentication-objects/personal/

### Permissions

Requires `authentication` only.

### Request example

#### Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

#### Body

| Key         | Type   | Notes                                                                                                                                                                                  |
|-------------|--------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| name        | string |                                                                                                                                                                                        |
| description | string |\
| provider    | enum   | Values: imanage, docusign, api\_key, autologyx, microsoft\_client\_credentials, box\_client\_credentials, adobe\_client\_credentials, salesforce\_client\_credentials, oauth\_client\_credentials |
| credentials | object | Each provider has different set of credentials                                                                                                                                         |

For provider specific credentials, see [#POST /api/authentication-objects/](#post-api-authentication-objects)

### Response

* Successful status `201 Created`
* Response body:

```json
{
  "id": 5,
  "name": "My iManage credentials",
  "description": "The credentials to iManage provider"
  "provider": "imanage",
  "created_at": "2021-05-18T06:39:17.688341Z",
  "created_by": { 
    "id ": 256, 
    "first_name": "John", 
    "last_name": "Smith", 
    "username": "j.smith@autologyx.com", 
    "company_name": "Autologyx", 
    "is_deleted": false
},
  "modified_at": "2021-05-18T06:39:17.688394Z"
  "modified_by": {
    "id ": 256,
    "first_name": "John",
    "last_name": "Smith",
    "username": "j.smith@autologyx.com",
    "company_name": "Autologyx",
    "is_deleted": false
  },
  "_meta": {
    "permissions":{
      "list": true,
      "view": true,
      "create": true,
      "edit": true,
      "delete": true
    } 
  }
}

```

### Restrictions

* Each User may have only 1 Personal Authentication Object created for each provider.

### Errors

Generally, the same errors as for [#POST /api/authentication-objects/](#post-api-authentication-objects) are handled.

Additional errors are listed below.

| Error                                                                         | Response code    | Message                                                                                  |
|-------------------------------------------------------------------------------|------------------|------------------------------------------------------------------------------------------|
| Limit of PAOs per provider exceeded                                           | 400 Bad Request  | "type": \[ "Personal Authentication Object for this provider has already been created." ] |
| "method": "send\_in\_query\_string" is passed in credentials of api\_key provider | 400 Bad Request  | "method": \[ '"send\_in\_query\_string" is not a valid choice.' ]                            |

## GET  /api/authentication-objects/personal/

Returns list of Personal Authentication Objects.

### Permissions

Requires `authentication` and the User must be a Super Admin.

### Request example

#### Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

#### Response `results` array

| Key               | Type     | Notes                                                                                                                                                                                   |
|-------------------|----------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| id                | int      | 	                                                                                                                                                                                       |
| name              | string   | 	                                                                                                                                                                                       |
| description       | string   | 	                                                                                                                                                                                       |
| provider          | enum     | Values: imanage, docusign, api\_key, autologyx, microsoft\_client\_credentials, box\_client\_credentials, adobe\_client\_credentials, salesforce\_client\_credentials, oauth\_client\_credentials  |
| created\_at        | datetime | 	                                                                                                                                                                                       |
| created\_by        | user     | 	                                                                                                                                                                                       |
| modified\_at       | datetime | 	                                                                                                                                                                                       |
| modified\_by       | user     | 	                                                                                                                                                                                       |
| \_meta.permissions | Object   | Dict describing permissions.                                                                                                                                                            |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 20,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 5,
      "name": "My iManage credentials",
      "description": "The credentials to iManage provider"
      "provider": "imanage",
      "created_at": "2021-08-12T11:21:51.877690+02:00",
      "created_by": <user>,
      "modified_at": "2021-09-14T11:11:31.127734+02:00",
      "modified_by": <user>,
      "_meta": {
        "permissions": {
            "list": true,
            "view": true,
            "edit": true,
            "create": true,
            "delete": true,
        }
      }
    }
  ]
}
```

### Sorting

| Parameter      | Example                                               | Notes          |
|----------------|-------------------------------------------------------|----------------|
| id             | {build}/api/object-class-forms/?ordering=id           | Ascending      |
| id             | {build}/api/object-class-forms/?ordering=-id          | Descending (-) |
| name           | {build}/api/object-class-forms/?ordering=name         | Ascending      |
| name           | {build}/api/object-class-forms/?ordering=-name        | Descending (-) |
| created\_at     | {build}/api/object-class-forms/?ordering=created\_at   | Ascending      |
| created\_at     | {build}/api/object-class-forms/?ordering=-created\_at  | Descending (-) |
| modified\_at    | {build}/api/object-class-forms/?ordering=modified\_at  | Ascending      |
| modified\_at    | {build}/api/object-class-forms/?ordering=-modified\_at | Descending (-) |

### Filtering

| Parameter   | Predicates        | Example                                                                  |
|-------------|-------------------|--------------------------------------------------------------------------|
| id          | =                 | {build}/api/object-class-forms/?id=9                                     |
| name        | standard string   | {build}/api/object-class-forms/?name\_\_icontains=foobar                   |
| provider    | standard enum     | {build}/api/object-class-forms/?provider\_in=provider                     |
| created\_at  | standard datetime | {build}/api/object-class-forms/?created\_at\_\_gte=2022-01-01               |
| created\_by  | standard set      | {build}/api/object-class-forms/?created\_by\_\_in=123,234,345               |
| modified\_at | standard datetime | {build}/api/object-class-forms/?modified\_at\_\_range=2022-01-01,2022-01-31 |
| modified\_by | standard set      | {build}/api/object-class-forms/?modified\_by=123                          |

### Errors

| Error                                            | Response code    | Message                                                                        |
|--------------------------------------------------|------------------|--------------------------------------------------------------------------------|
| Insufficient permissions                         | 403 Forbidden    | "detail": "You do not have permission to perform this action."                 |

## GET  /api/authentication-objects/personal/me/

Returns a list of the caller's Personal Authentication Objects.

### Permissions

Requires `authentication` only.

### Request example

#### Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

The same errors as for [#GET  /api/authentication-objects/personal/](#get-api-authentication-objects-personal).

### Sorting

The same errors as for [#GET  /api/authentication-objects/personal/](#get-api-authentication-objects-personal).

### Filtering

| Parameter   | Predicates        | Example                                                                  |
|-------------|-------------------|--------------------------------------------------------------------------|
| id          | =                 | {build}/api/object-class-forms/?id=9                                     |
| name        | standard string   | {build}/api/object-class-forms/?name\_\_icontains=foobar                   |
| provider    | standard enum     | {build}/api/object-class-forms/?provider\_in=provider                     |
| created\_at  | standard datetime | {build}/api/object-class-forms/?created\_at\_\_gte=2022-01-01               |
| modified\_at | standard datetime | {build}/api/object-class-forms/?modified\_at\_\_range=2022-01-01,2022-01-31 |

### Errors

| Error                                 | Response code    | Message                                                    |
|---------------------------------------|------------------|------------------------------------------------------------|
| Requesting user is not authenticated  | 401 Unauthorized | "detail": "Authentication credentials were not provided."  |

## GET  /api/personal-authentication-objects/`id`/

Returns details of the Personal Authentication Object.

### Permissions

Requires `authentication` and the User must be either the creator of the Personal Authentication Object or a Super Admin.

### Request example

#### Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response example

* Status `200 OK`
* Body

```json
{
  "id": 5,
  "name": "My iManage credentials",
  "description": "The credentials to iManage provider"
  "provider": "imanage",
  "created_at": "2021-08-12T11:21:51.877690+02:00",
  "created_by": <user>,
  "modified_at": "2021-09-14T11:11:31.127734+02:00",
  "modified_by": <user>,
  "_meta": {
    "permissions": {
        "list": true,
        "view": true,
        "edit": true,
        "create": true,
        "delete": true,
    }
  }
}
```

For provider specific credentials, see [#GET /api/authentication-objects/`id`/](#get-api-authentication-objects-id)

### Errors

| Error                        | Response code | Message                                                         |
|------------------------------|---------------|-----------------------------------------------------------------|
| PAO with "id" does not exist | 404 Not Found | "detail": "Not found."                                          |
| Insufficient permissions     | 403 Forbidden | "detail": "You do not have permission to perform this action."  |

## PATCH  /api/authentication-objects/personal/`id`/

Updates the Personal Authentication Object.

### Permissions

Requires `authentication` and the User must be either the creator of the Personal Authentication Object or a Super Admin.

### Request example

#### Headers

```
Request Method: PATCH
Content-Type: application/json
Authorization: JWT access_token
```

#### Body

```json
{
  "name": "My updated iManage credentials",
  "description": "The updated credentials to iManage provider",
  "credentials": {
    ...
  }
}
```

For provider specific credentials, see [#GET /api/authentication-objects/`id`/](#get-api-authentication-objects-id)

### Response

| Key               | Type     | Notes                                                                                                                                                                                  |
|-------------------|----------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| id                | int      | 	                                                                                                                                                                                      |
| name              | string   | 	                                                                                                                                                                                      |
| description       | string   | 	                                                                                                                                                                                      |
| provider          | enum     | Values: imanage, docusign, api\_key, autologyx, microsoft\_client\_credentials, box\_client\_credentials, adobe\_client\_credentials, salesforce\_client\_credentials, oauth\_client\_credentials |
| created\_at        | datetime | 	                                                                                                                                                                                      |
| created\_by        | user     | 	                                                                                                                                                                                      |
| modified\_at       | datetime | 	                                                                                                                                                                                      |
| modified\_by       | user     | 	                                                                                                                                                                                      |
| \_meta.permissions | Object   | Dict describing permissions.                                                                                                                                                           |

### Response example

* Status `200 OK`
* Body

```json
{
  "id": 5,
  "name": "My updated iManage credentials",
  "description": "The updated credentials to iManage provider"
  "provider": "imanage",
  "created_at": "2021-08-12T11:21:51.877690+02:00",
  "created_by": <user>,
  "modified_at": "2021-09-14T11:11:31.127734+02:00",
  "modified_by": <user>,
  "_meta": {
    "permissions": {
        "list": true,
        "view": true,
        "edit": true,
        "create": true,
        "delete": true,
    }
  }
}
```

### Errors

The same errors as for [#PATCH  /api/authentication-objects/`id`/](#patch-api-authentication-objects-id) are handled.

| Error                                                                         | Response code    | Message                                                                                  |
|-------------------------------------------------------------------------------|------------------|------------------------------------------------------------------------------------------|
| "method": "send\_in\_query\_string" is passed in credentials of api\_key provider | 400 Bad Request  | "method": \[ '"send\_in\_query\_string" is not a valid choice.' ]                            |

## DELETE /api/authentication-objects/personal/`id`/

Deletes the Personal Authentication object.

### Permissions

Requires `authentication` and the User must be either the creator of the Personal Authentication Object or a Super Admin.

### Request example

* Headers

```
Request Method: DELETE
Location: /api/authentication-objects/personal/9/
Authorization: JWT access_token
```

### Response example

* Status `204 No Content`
* Body

### Errors

| Error                                | Response code     | Message                                                        |
|--------------------------------------|-------------------|----------------------------------------------------------------|
| Requesting user is not authenticated | 401 Unauthorized  | "detail": "Authentication credentials were not provided."      |
| PAO with "id" does not exist         | 404 Not Found     | "detail": "Not found."                                         |
| Insufficient permissions             | 403 Forbidden     | "detail": "You do not have permission to perform this action." |

## GET  /api/authentication-objects/personal/`id`/authentication-headers/

This endpoint provides the authentication data of a specified Personal Authentication Object (PAO) in a format to be directly used in request’s headers to external system.

### Permissions

Requires `authentication` and the User must be the creator of the Personal Authentication Object.

### Request example

#### Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

Response contains the authentication headers for the Personal Authentication Object of different providers.

1. Generally `access_token` is obtained from the Personal Authentication Object and used in the authentication header with the "Bearer" prefix to authorize subsequent requests to the server.
2. A Personal Authentication Object with `client_credentials` provider is used to obtain the `access_token` and `token_type` which are used in the header.
3. Every time `access_token` is used, it is checked for expiry. If it is expired, a new `access_token` is obtained using the `refresh_token` and the new `access_token` is used in the header.
4. Header key might be different for different providers. For example, for `imanage` provider, the key is `X-Auth-Token` and its value is `Bearer <access_token>`.
5. `token_type` is used to specify the type of token used in the header it might be different for different providers. For example, for `client_credentials` provider, the `token_type` is `Bearer`.
6. For `api_key` provider, the `api_key` and its saved value is used in the header. Personal Authentication Object is used to store the API key and its value.

### Response example

* Status `200 OK`
* Body

### Provider

##### iManage

```json
{
    "X-Auth-Token": "<token_type> <access_token>"
}
```

##### Autologyx

```json
{
    "Authorization": "<token_type> <access_token>"
}
```

##### Api Key

```json
{
    "Some-api-key": "api key"
}
```

##### Docu Sign

```json
{
    "Authorization": "<token_type> <access_token>"
}
```

##### Adobe

```json
{
    "Authorization": "<token_type> <access_token>"
}
```

##### Box

```json
{
    "Authorization": "<token_type> <access_token>"
}
```

##### Generic Client Credentials

```json
{
    "Authorization": "<token_type> <access_token>"
}
```

##### Microsoft

```json
{
    "Authorization": "<token_type> <access_token>"
}
```

##### Salesforce

```json
{
    "Authorization": "<token_type> <access_token>"
}
```

### Errors

| Error                                | Response code    | Message                                                                                       |
|--------------------------------------|------------------|-----------------------------------------------------------------------------------------------|
| Requesting user is not authenticated | 401 Unauthorized | "detail": "Authentication credentials were not provided."                                     |
| PAO with "id" does not exist         | 404 Not Found    | "detail": "Not found."                                                                        |
| Insufficient permissions             | 403 Forbidden    | "detail": "You do not have permission to perform this action."                                |
| Authentication failed                | 200 OK           | "detail": "Unable to authenticate your credentials.", "error\_code": "ERR\_INVALID\_CREDENTIALS" |

## POST  /api/authentication-objects/personal/test/

Returns a status for given credentials:

* True – if credentials are correct
* False – if there was authentication error

### Permissions

Requires `authentication` only.

### Request example

#### Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

#### Body

For provider specific credentials, see [#POST  /api/authentication-objects/personal/](#post-api-authentication-objects-personal)

```json
{
  "name": "Authentication object",
  "description": "Description",
  "provider": "autologyx",
  "credentials": {
        "username": "some_username@example.test",
        "password": "password"
    }
}
```

### Response

```json
{
    "status": true
}
```

## POST  /api/authentication-objects/personal/`id`/test/

Returns a status for credentials stored for an existing authentication object:

* True – if credentials are correct
* False – if there was authentication error

### Permissions

Requires `authentication` and the User must be either the creator of the Personal Authentication Object or a Super Admin.

### Request example

#### Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

#### Body

For provider specific credentials, see [#POST  /api/authentication-objects/personal/](#post-api-authentication-objects-personal)

```json
{
  "name": "Authentication object",
  "description": "Description",
  "provider": "autologyx",
  "credentials": {
        "username": "some_username@example.test",
        "password": "password"
    }
}
```

### Response

```json
{
    "status": true
}
```

---

---
url: /knowledgebase/administration/authentication-objects.md
---

# Authentication Objects

Authentication Objects provide a secure, centralised way to store and manage the credentials used by API integrations.

Instead of storing usernames, passwords, API keys or OAuth credentials within individual API calls, you create an Authentication Object once and reference it wherever it is needed. This simplifies administration, improves security, and makes credential updates much easier.

Use the guides below to learn how to create, manage and use Authentication Objects.

## Getting started

### Create an Authentication Object

Learn how to configure Authentication Objects for supported providers, validate the connection, and securely store credentials.

* [What is an Authentication Object and how do I configure it?](/knowledgebase/administration/authentication-objects/what-is-an-authentication-object-and-how-do-i-configure-it/)

### View Authentication Objects

Learn about the Authentication Objects list, available columns, actions, and how to monitor Authentication Objects across your system.

* [Authentication Objects List](/knowledgebase/administration/authentication-objects/authentication-objects-list/)

## Using Authentication Objects

### Configure API calls

Learn how to reference an Authentication Object from an API Call actor so that integrations can authenticate securely.

* [Using an Authentication Object in an API Call](/knowledgebase/administration/authentication-objects/using-an-authentication-object-in-an-api-call/)

## Managing Authentication Objects

### Update credentials

Learn what happens when you edit an Authentication Object, how updates affect existing integrations, and what to expect when changing credentials.

* [What happens if I edit an Authentication Object?](/knowledgebase/administration/authentication-objects/what-happens-if-i-edit-an-authentication-object/)

## Things to remember

1. Authentication Objects allow credentials to be stored securely in one central location.
2. A single Authentication Object can be reused by multiple API Call actors.
3. Updating an Authentication Object automatically updates every integration that references it.
4. Authentication Objects support a range of built-in providers, including OAuth, API Key, DocuSign and Autologyx Internal authentication.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.5/authentication-objects---api-keys.md
---

# Authentication Objects - API Keys

In the realm of data security and access control, staying one step ahead is paramount. Autologyx Catalyst's latest release introduces **Authorization Objects - API Keys** - your new dashboard for managing and generating API keys securely. With the power of API Keys, you can ensure that only authorized entities have access to your valuable resources, providing peace of mind and safeguarding your sensitive information.

The Authorisation Object API Key is designed to grant secure access to your application programming interfaces (APIs) by generating unique and encrypted keys. These keys act as digital credentials, allowing authorized users or systems to interact with your APIs while keeping unauthorized entities at bay. With this level of control, you can confidently manage and monitor API access, mitigating the risk of data breaches and unauthorized usage.

**Getting started is simple.** With just a few simple steps, you can generate your unique API Key and start using it in no time. The user-friendly interface allows you to customize your API Key name and provide a brief description, ensuring clarity and organization in your authentication process.

## Authentication methods

**API Keys offer two authentication methods** - "Send in header" and "Send in query string." Select the method that best suits your needs and enjoy the benefits of secure access to your data. Depending on your choice, you will be presented with additional fields to further customize your authentication experience.

![APIKeys\_main.gif](/knowledgebase/images/img_12574180104733_1776895685.png)

## Security

**Security is at the heart of our API Key implementation.** Your API Keys are stored in Vault, ensuring maximum protection against unauthorized access. Rest assured that your data is safeguarded by industry-leading security measures, allowing you to focus on your core tasks without any worries.

## Editing API Keys

**Editing your API Key is a breeze** with our seamless editing capabilities. Make changes to your API Key, method preferences, and additional fields effortlessly, and watch as the updates are instantly applied across all your authentication sequences.

With Authorization Objects API Keys, Autologyx Catalyst is taking business automation to a whole new level - it's about connecting systems, streamlining operations, and unlocking new levels of efficiency.

---

---
url: >-
  /knowledgebase/administration/authentication-objects/authentication-objects-list.md
---

# Authentication Objects List

The **Authentication Objects** list shows all authentication objects configured in your Autologyx system. These objects store the credentials used by integrations and API calls, allowing them to authenticate securely without embedding usernames and passwords throughout your configuration.

Like all lists in Autologyx, this page supports filtering, sorting, column configuration and bulk list features. For an overview of these common functions, see [List Pages](/knowledgebase/finding-your-way-around/ui-and-navigation/list-pages/).

## Default columns

By default, the list displays the following columns:

* **ID** - the unique identifier for the Authentication Object.
* **Name** - the name given to the Authentication Object.
* **Provider** - the authentication provider associated with the object.
* **Description** - an optional description to help identify its purpose.
* **Actions** - available actions for the Authentication Object, depending on your permissions.

![Authentication Objects list showing the default columns and available actions](/knowledgebase/images/administration/auth-objects-1.png)

## Additional columns

Using the **Column configuration** option, you can add additional information to the list.

Available columns include:

* **Created** - the date and time the Authentication Object was created.
* **Created By** - the user who created the Authentication Object.
* **Expiry Date** - an optional expiry date configured for the Authentication Object. This column can be sorted to help identify credentials that may require renewal.
* **Last Edited** - the date and time of the most recent update.
* **Last Edited By** - the user who last edited the Authentication Object.
* **Usage** - the number of API Call actors currently using the Authentication Object.

These additional columns are particularly useful when auditing integrations or reviewing credentials that may need updating.

## Actions

Users with a Super Admin account type, or users whose Role includes the appropriate Authentication Object permissions, can access the following actions.

![Role permissions required for Authentication Objects](/knowledgebase/images/administration/auth-objects-2.png)

### Edit

The **Edit** action allows you to update an existing Authentication Object.

For example, if the username, password or authentication credentials change, you can update them in one place without having to edit every API Call actor that references the Authentication Object.

### Delete

Authentication Objects can only be deleted when they are no longer being used.

The **Delete** option is available only when:

* the **Usage** column displays **0**
* no API Call actors reference the Authentication Object

If the Authentication Object is still in use, the **Delete** option is hidden to prevent integrations from being broken accidentally.

> **Note:** Users with Role-based Administration permissions can edit Authentication Objects but cannot delete them. Deleting Authentication Objects is restricted to Super Admin users.

## Related articles

To learn more about Authentication Objects, see:

* [What is an Authentication Object and how do I configure it?](/knowledgebase/administration/authentication-objects/what-is-an-authentication-object-and-how-do-i-configure-it/)
* [What happens if I edit an Authentication Object?](/knowledgebase/administration/authentication-objects/what-happens-if-i-edit-an-authentication-object/)
* [Using an Authentication Object in an API call](/knowledgebase/administration/authentication-objects/using-an-authentication-object-in-an-api-call/)

## Things to remember

1. Updating an Authentication Object automatically updates every API Call actor that uses it.
2. Authentication Objects cannot be deleted while they are in use.
3. The **Usage** column helps identify where an Authentication Object is referenced.
4. Additional columns can be enabled to help monitor credential ownership, expiry dates and usage.

---

---
url: /knowledgebase/release-notes/release-notes-1.16.md
---

# Release Notes 1.16

3 June 2026

Catalyst 1.16 gives Super Admins and Config Admins more control over access, task wording, automation behaviour, and troubleshooting information.

The main changes are:

* new Service Account options for integration and automation users,
* IP restrictions for user access,
* configurable task action labels,
* clearer Sequencer behaviour for emails, loops, API calls, and task templates,
* improvements to formatting, help content, browser compatibility, and general platform reliability.

## Access and integration control

### Service Accounts

This release adds Service Account user types for integrations and automated processes.

Service Accounts are useful when an integration, sequence, or automated process needs to authenticate to Catalyst without relying on a named person. This helps configuration teams separate human user access from system-to-system access.

You can now create and manage Service Accounts from the user administration area, alongside other users.

There are two Service Account types:

* **Service Internal** - for internal API integrations and automated Catalyst processes.
* **Service External** - for external API integrations and automated processes.

Service Accounts can use username and password authentication even where this option has been disabled for other user types in favour of SSO. This helps integrations continue to run without changing the normal login policy for human users.

You can:

* view Service Account details
* create Service Accounts
* edit usernames and personal information
* delete Service Accounts
* reset passwords
* view account-type limits

Service Accounts are automatically activated when created. They do not use the delayed activation flow that applies to some other user accounts.

![Service Account user type tiles in the Create User page](/knowledgebase/images/release-notes-1.16-service-account-user-types.png)

#### Things to remember

Once an account has been created as a Service Account, its account type cannot be changed to a standard user account. Standard user accounts also cannot be changed into Service Accounts.

Create a new Service Account when you need a dedicated account for an integration or automated process.

Internal Service Accounts are granted Super Admin permissions. External Service Accounts have no permissions unless permissions are explicitly assigned, so they may need User Groups and Permission Sets on Object Classes.

### IP restrictions for users

Users with a Super Admin account type can now restrict user access by IP address.

This gives configuration and administration teams more control over where a user account can be used from. It is helpful where access should be limited to an organisation network, approved office locations, VPN ranges, or other controlled environments.

A new **IP Restrictions** section is available when creating or editing a user. From this section, you can:

* turn IP restrictions on or off for the user
* add one or more allowed IP ranges
* edit existing IP ranges
* remove IP ranges
* see validation when an entered IP range is not valid

![IP Restrictions section on the user form](/knowledgebase/images/release-notes-1.16-user-ip-restrictions-section-full.png)

When IP restrictions are enabled, the user can only access Catalyst from one of the allowed ranges.

If a user tries to log in from outside the allowed range, access is blocked and the login page shows a message explaining that the current IP address is not authorised.

If an administrator changes a user's allowed IP ranges, the change takes effect immediately.

The restriction is enforced the next time the user performs an action in Catalyst.

#### Things to remember

IP restriction changes take effect immediately after the User record is saved.

Use this feature carefully when changing access for active users. If a user's current IP address is no longer allowed, they may be returned to the login page and unsaved work could be lost.

The **Enable IP restrictions** toggle is not available unless at least one allowed IP range has been added.

## Task experience and wording

### Configurable task action labels

Configuration users can now change the labels used for task action buttons.

This is useful where the default **Complete** label is not the best wording for your process. For example, some users may read **Complete** as a task status rather than an action they need to take. You can now choose wording that better fits your workflow.

Go to:

**Theme** > **Text Overrides**

Use the new **Task buttons** section to configure:

* **Actionable tasks label** - shown for tasks that are outstanding and need action. The default is **Complete**.
* **View-only tasks label** - shown where a task has already been completed or where the user does not have permission to complete it. The default is **View**.

![Task button label settings in Theme Text Overrides](/knowledgebase/images/release-notes-1.16-task-button-label-overrides.png)

When the theme is enabled, the configured labels are used across the task list, task action menus, and task panel. The change applies to both new and existing tasks.

If the theme is disabled, Catalyst uses the default labels.

#### Things to remember

These settings change action labels only. They do not change task status chips, task list column names, or task list filters.

## Sequencer and communication improvements

### Send Message emails are clearer and easier to manage

The Send Message actor now sends one email to the intended recipient group instead of sending a separate email per recipient.

This is especially useful where a message has multiple recipients and someone is copied in. Previously, a copied recipient could receive duplicate emails. In 1.16, recipients and copied recipients receive the expected single message.

Formatting has also been improved for Send Message emails. Highlighted text and background colours are now retained when emails are generated, helping important instructions or warnings stand out as intended.

### Better loop testing in Send Message actors

When a Send Message actor is used after a Loop actor, test emails now resolve loop-based merge fields such as {{ loop\_item }} and {{ loop\_counter }} more reliably.

This makes it easier to test loop-driven communications before activating a sequence.

### More helpful API Call notification emails

API Call notification emails now include more information to help configuration users investigate failed integrations.

The notification can include details such as:

* the Catalyst domain
* the sequence name or identifier
* a link back to the sequence
* the API Call name
* the affected record
* the error response returned by the external system

This should make it easier to understand whether an issue relates to configuration, data, permissions, or the external service being called.

### API Calls that return files are easier to configure

Some external systems return files, such as PDFs or images, in ways that are difficult to detect automatically.

The API Call actor now includes a **Force Download** option for these cases. Enable this when an API Call is expected to return a file and the tested response is not being handled correctly as a download.

![Force Download option in the API Call actor configuration](/knowledgebase/images/release-notes-1.16-api-call-force-download.png)

This is useful for document and integration workflows where a sequence needs to work with a file returned by an external service.

### Loop actors are more reliable

Several Loop actor behaviours have been improved.

Loop actors can now work more reliably with nested arrays. This helps when you are looping over structured JSON data from an API response or local variable.

Error messages are also clearer when a Loop actor depends on an untested API Call or Local Variable. Instead of showing a more general invalid-output message, Catalyst now indicates that the connected item needs to be tested first.

Loop actor configuration is also more reliable when connected to a Document Picker.

### Sequence design is more forgiving

Copying triggers in Sequence Designer now handles unsupported conditions more gracefully.

If a trigger is copied to a place where one of its conditions is not supported, Catalyst can still copy the supported parts and show a message explaining that some conditions could not be copied.

This helps configuration users reuse trigger setup without causing the trigger configuration to get stuck.

### Task Template and Task Group Template improvements

Long Task Template names are now handled more cleanly in Set Task actor configuration, reducing layout issues when selecting a template.

Deletion checks for Task Group Templates have also been improved, so templates are less likely to be blocked by incorrect usage information.

## Usability, formatting, and help improvements

### Instruction text colour formatting

Instruction text formatting has been restored where colour was previously lost.

This helps configuration users keep important guidance visible in forms and tasks. For example, if you use red text to draw attention to a key instruction, that formatting can now be preserved again.

### Knowledgebase help panel styling

Styling in the right-hand Knowledgebase help panel has been improved. Background colours and text sizing are more consistent, making embedded help easier to read while working in Catalyst.

### Custom components in Safari

Custom components are more reliable in Safari on macOS and iOS, especially where the component needs to receive user, token, or page context from Catalyst.

This improves compatibility for pages that use embedded custom components.

### Version visibility and platform maintenance

The Admin Portal can now check the frontend application version, making it easier to confirm which Catalyst build is running.

This release also includes general maintenance and security updates to keep the platform stable and up to date. No configuration change is required for these maintenance updates.

## Things to remember

1. Review any Service Account limits before creating new accounts for integrations.
2. Test IP restrictions with care, especially where users work across VPNs, office networks, or remote locations.
3. Keep task labels short enough to fit comfortably in the task panel and task action menu.
4. Re-test sequences that use Loop actors, Send Message actors, API Calls, or file downloads before relying on them in a live process.
5. Use the improved API Call notification emails to troubleshoot integration issues before escalating to support.

---

---
url: /knowledgebase/release-notes/release-notes-1.20.md
---
# Autologyx Catalyst 1.20 release notes

AI agents become far more valuable when they can work with live business data - but connection without control is not enough.

As AI becomes more deeply embedded in legal work, governance increasingly needs to operate at the point of execution: controlling what agents can access, what they can do and creating a clear record of their activity.

This release introduces the foundations for governed MCP connectivity in Autologyx Catalyst, giving organisations a clearer way to connect approved AI tools while maintaining visibility, permissions and control.

[Watch the video](https://vimeo.com/1223656275)

## Manage MCP Connectors in one place

![MCP Connector management in Catalyst](media/mcp-connectors.png)

You can now create, configure and manage MCP Connectors directly in Catalyst. From one place, you can:

* Create and manage MCP Connectors linked to the right AI integration
* Choose what data AI agents can access by controlling which Object Classes each connector can access
* Generate a unique MCP Server URL for every connector
* Control who can manage MCP Connectors through permissions
* See every MCP Connector at a glance, with filtering and sorting

![MCP Connector configuration](media/mcp-provider-restrictions.png)

## MCP Connector provider restrictions

Each MCP Connector is tied to the AI integration it was created for, preventing it from being reused with a different provider and helping configurations remain deliberate and predictable.

## Choose which MCP tools are available

New backend API functionality lets you list the MCP tools available, see which tools are configured for a connector and update its allowed toolset. This lays the groundwork for precise control over what each connected AI service can do.

**Note:** Tool restrictions are not yet enforced. This release introduces the backend configuration needed to support that control.

## Bring MCP into the Catalyst permission model

MCP Connectors can be configured within Class and Record Permission Sets, so access to Object Classes, records and tasks can be governed using the same permission model already familiar to Catalyst administrators.

![Configuring MCP Connector permissions](media/mcp-permissions.gif)

Authorised users can manage permissions and assignees, with **Enable All** and **Disable All** actions making broader configuration changes faster.

**Important:** Users cannot grant an MCP Connector permissions beyond those they hold themselves.

## See MCP Connector permissions side by side

![Comparing MCP Connector permissions](media/mcp-permission-comparison.png)

Compare Permission Sets for each MCP Connector in one view. It is now easier to spot differences, review access and understand exactly what an individual connector has been allowed to reach.

## See exactly when AI is at work

Catalyst's Activity Log now clearly identifies record events triggered by AI agents, showing which agent was involved alongside the user and timestamp. This gives teams a transparent, chronological view of human, system and AI activity - strengthening oversight, accountability and auditability without adding another layer of reporting.

![AI agent attribution in the Activity Log](media/ai-agent-activity-log.png)

## A clearer home for every integration

We have introduced clearer integration categories, separating Business integrations from AI and Sequencer integrations so administrators can find and manage the right connection faster.

![Business, AI and Sequencer integration categories](media/integration-categories.png)

Catalyst also supports a wider choice of integrations, including Claude, Copilot, Slack, xAI, Perplexity, Gemini, Harvey and Legora - giving teams more freedom to connect the tools that fit their way of working. *(To review.)*

### Further reading: governance and the next phase of legal AI

These developments reflect a wider shift we're seeing across legal technology. Legal IT Insider's latest *Gen AI and the Practice of Law* report explores the growing importance of governance as AI becomes embedded in real legal work, including the role of orchestration and a cross-system "governance spine".

[Read our take on the report →](https://autologyx.com/blog/what-legal-it-insiders-gen-ai-report-tells-us-about-ai-governance)

## Smaller changes, smoother building

### Find the right child record, faster

Child record tables on parent Object Record forms can now be sorted and filtered, helping users get to the right related record with less scrolling. Administrators can also set the number of records shown per page, keeping larger lists manageable.

### Build smarter, more responsive forms

Conditional visibility in Object Record and Task forms now supports OR logic and multiple conditions against the same field. Form designers can create more nuanced behaviour and show the right fields or sections across a wider range of scenarios - without awkward workarounds.

Taken together, these improvements make Catalyst easier to connect, safer to govern and smoother to configure - laying the foundations for AI agents to take part in real work without losing the control that enterprise teams need.

### Further fixes and enhancements

Alongside these headline features, this release includes more than 40 additional fixes and enhancements across Catalyst, together with the latest security patches and dependency updates. These changes improve the platform’s overall stability, performance and security.

---

---
url: /knowledgebase/applied-ai/mcp-services/mcp-customer-success.md
---

# Autologyx MCP Customer Success

Autologyx MCP Customer Success is an MCP service that gives approved AI assistants and agents access to Autologyx product knowledge, implementation guidance, terminology, configuration patterns, API documentation, and best-practice advice.

In simple terms, it allows an AI assistant to reason with the Autologyx knowledge base instead of relying only on the model's general training data. That makes the assistant much more useful when a user wants help understanding how Autologyx works, planning a configuration change, designing a new process, preparing an implementation, or analysing a potential client requirement.

Unlike Autologyx MCP Work, which can interact with live operational records and tasks, Autologyx MCP Customer Success is focused on knowledge, analysis, design, and planning. It helps the agent understand the Autologyx platform so that it can support better decisions before work is configured or changed.

## **Why this matters**

Autologyx is a powerful configuration platform. That power means there are often several ways to solve the same business problem.

A user might ask:

* Should this be modelled as an Object Class, a field, a task, or a related record?
* Should this process be driven by a Sequence, manual user action, an API integration, or an MCP-enabled agent?
* Which roles, user groups, task templates, document templates, and record relationships might be needed?
* What are the risks in the proposed design?
* What would an implementation plan look like?
* What should be migrated from an existing Autologyx environment into a new one?

Autologyx MCP Customer Success helps an AI assistant answer those questions using Autologyx-specific context. The result is not just a generic AI response. It can be a practical Autologyx-aware analysis that reflects the language, concepts, constraints, and patterns used across the platform.

## **What the service can help with**

Autologyx MCP Customer Success can support a wide range of planning and analysis activities.

It can help with small configuration questions, such as how to structure a task, when to use a related record, or where a field should live.

It can also help with larger design exercises, such as planning a new intake process, reviewing an existing workflow, preparing a migration, or breaking down a complex requirements document into an Autologyx implementation plan.

The service is especially powerful when used with an agent that can accept uploaded documents, screenshots, spreadsheets, or pasted requirements. In that scenario, the user can provide source material and ask the agent to analyse it in the context of Autologyx.

For example, a user might upload a client requirements document and ask the agent to produce:

* a proposed Autologyx solution design
* a list of candidate Object Classes
* suggested parent and child record relationships
* recommended fields and field types
* proposed task templates and task ownership
* candidate Sequences and automation points
* document generation requirements
* integration and API considerations
* permissions and governance considerations
* risks, assumptions, and open questions
* a phased implementation plan
* a cut list of configuration items to build

That is where the service becomes much more than a documentation lookup. It becomes a design companion for Autologyx implementation work.

## **Getting started**

There is very little setup required from a user perspective.

**Connect an MCP-capable AI assistant or agent to the Autologyx MCP endpoint:**

```text
https://docs.autologyx.com/mcp
```

The exact connection steps depend on the AI assistant or MCP client being used. For general connection guidance, see [Getting started with MCP](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/).

Once connected, start asking Autologyx-specific questions. The agent can use the MCP service to discover relevant knowledge and respond with more context than it would have from the prompt alone.

## **Example prompts**

The value of Autologyx MCP Customer Success depends on the quality of the question. Broad questions can be useful, but the service becomes more powerful when the user provides clear context and asks for a specific output.

### Understanding a concept

```text
Explain how Object Classes, Object Records, Tasks, and Sequences work together in Autologyx. Use an example based on legal intake.
```

```text
What is the difference between a Manual Task and an Automatic Task, and when should I use each one?
```

```text
I am new to Autologyx configuration. Explain the key building blocks I need to understand before designing a matter intake process.
```

### Planning a configuration change

```text
We need to add a new approval step to an existing onboarding process. What Autologyx configuration areas should I review, and what questions should I ask before changing anything?
```

```text
A client wants to capture additional risk data during triage. Help me decide whether this should be added as fields on the main intake record, a related child record, or a task response.
```

```text
Prepare a configuration checklist for adding a new document generation step to an existing workflow.
```

### Analysing requirements

```text
I have uploaded a client requirements document. Analyse it and produce an Autologyx implementation cut list covering Object Classes, fields, relationships, tasks, Sequences, document templates, permissions, integrations, assumptions, and open questions.
```

```text
Review this requirements document and identify which parts look like data model design, workflow automation, permissions, reporting, document automation, and integration work.
```

```text
Turn this statement of work into an Autologyx implementation plan with phases, dependencies, risks, and configuration workstreams.
```

### Designing a new process

```text
Design a high-level Autologyx architecture for a legal intake and triage process. Include the likely Object Classes, record relationships, task templates, user groups, Sequences, and reporting considerations.
```

```text
Suggest three possible Autologyx designs for this process: a simple version, a scalable version, and a highly automated version. Explain the trade-offs.
```

```text
Create a solution design note for implementing a contract review workflow in Autologyx. Include assumptions and questions I should validate with the client.
```

### Migration and environment comparison

```text
We are moving a process from one Autologyx environment to another. What should we inventory before migration?
```

```text
Help me prepare a migration checklist covering Object Classes, fields, forms, task templates, Sequences, roles, user groups, document templates, integrations, test data, and validation steps.
```

```text
Given this exported configuration summary, identify likely migration risks and questions for the implementation team.
```

## **Using uploaded requirements documents**

One of the most powerful uses of Autologyx MCP Customer Success is requirements analysis.

A user can upload a request for proposal, statement of work, discovery notes, process map, client requirements document, or legacy system description, then ask the agent to analyse it through an Autologyx lens.

**A good output might include:**

| Area | What the agent can help identify |
|---|---|
| Data model | Candidate Object Classes, Object Records, fields, relationships, ownership, and record lifecycle |
| Workflow | Manual steps, automation opportunities, Sequence triggers, task creation, approvals, and exception handling |
| Tasks | Manual Tasks, Automatic Tasks, task templates, assignment rules, due dates, and completion criteria |
| Documents | Document templates, merge fields, generation points, review steps, and storage requirements |
| Permissions | Roles, user groups, access boundaries, service accounts, and governance considerations |
| Integrations | API calls, external systems, authentication objects, data exchange, and error handling |
| Reporting | Status fields, metrics, dashboards, audit needs, and operational reporting requirements |
| Migration | Existing data, mapping questions, validation steps, cutover considerations, and test approach |
| Risks | Ambiguities, dependencies, sensitive data, decision points, and areas requiring human confirmation |

This does not remove the need for an experienced implementer. It helps the implementer work faster by turning unstructured requirements into a structured starting point.

## **From requirements to implementation cut list**

A useful pattern is to ask the agent for a cut list.

A cut list is a structured breakdown of configuration and implementation items that may need to be created, updated, or reviewed. It should be specific enough that a solution designer, configuration user, or implementation team can use it as a starting backlog.

For an Autologyx implementation, a cut list might include:

* Object Classes to create or review
* fields to add to each Object Class
* parent and child record relationships
* form sections and field placement
* task templates and task instructions
* role and user group changes
* Sequence triggers, conditions, and actors
* document templates and merge field requirements
* integration endpoints and authentication requirements
* reporting fields and operational metrics
* test scenarios and acceptance checks
* migration mappings and data validation steps
* questions to confirm with the client

The agent can also group the cut list by phase, priority, dependency, or workstream.

## **Example: client requirements to Autologyx architecture**

A strong prompt for a large requirements document might look like this:

```text
I have uploaded a potential client requirements document.

Please analyse it as an Autologyx solution designer.

Produce:
1. A concise summary of the client need.
2. A proposed Autologyx architecture.
3. Candidate Object Classes and their purpose.
4. Key fields for each Object Class.
5. Parent-child record relationships.
6. Task templates and likely assignees.
7. Sequences and automation points.
8. Document generation requirements.
9. Integration requirements.
10. Roles, user groups, and access considerations.
11. Reporting and audit requirements.
12. Migration considerations, if any.
13. Implementation phases.
14. Risks, assumptions, and open questions.
15. A cut list of configuration items.

Use Autologyx terminology and explain why each design choice might be appropriate.
```

**The response can then be refined through follow-up prompts:**

```text
Turn the cut list into a build plan ordered by dependency.
```

```text
Highlight anything that should be clarified with the client before build starts.
```

```text
Suggest a simpler version of this design for a first phase implementation.
```

```text
Identify which requirements could be handled by configuration and which might require integration or custom work.
```

## **Working alongside** Autologyx MCP Work

Autologyx MCP Customer Success and Autologyx MCP Work serve different purposes, but they are complementary.

Autologyx MCP Customer Success helps the agent understand Autologyx concepts, design patterns, implementation options, and documentation. It is useful when the user is asking what something means, how something should be designed, or what should be considered before making a change.

Autologyx MCP Work allows an approved agent to interact with live operational work in Autologyx, subject to permissions and governance. It is useful when the user wants the agent to find records, read record data, create tasks, update records, or generate documents.

A sophisticated agentic workflow may use both services. For example:

1. Use Autologyx MCP Customer Success to understand the relevant configuration concept.
2. Ask the user to confirm the intended approach.
3. Use Autologyx MCP Work to inspect live records or tasks where permitted.
4. Produce a recommendation, checklist, or proposed action.
5. Ask for human review before any important change or externally visible output.

## **Good questions produce better designs**

Autologyx MCP Customer Success is most effective when the user asks for a clear deliverable.

**Instead of asking:**

```text
What should we do with this process?
```

**Ask:**

```text
Analyse this process and produce an Autologyx solution design with Object Classes, fields, relationships, task templates, Sequences, permissions, risks, assumptions, and a phased implementation plan.
```

**Instead of asking:**

```text
Can this be built in Autologyx?
```

**Ask:**

```text
Assess whether this requirement can be met using standard Autologyx configuration. Separate your answer into likely configuration, likely integration, possible custom work, risks, and questions for the client.
```

The more specific the requested output, the more useful the result.

## **Governance and review**

Autologyx MCP Customer Success can help with analysis and planning, but it should not be treated as a substitute for professional judgement.

Users should review outputs carefully, especially where the result will influence architecture, security, permissions, migration, client commitments, contractual scope, or production configuration.

When using the service for client requirements, it is good practice to treat the output as a structured draft. The implementation team should validate:

* whether the requirements have been understood correctly
* whether the proposed data model is appropriate
* whether any assumptions need client confirmation
* whether any proposed automation is safe
* whether access and permissions are correctly designed
* whether migration and integration risks have been captured
* whether the plan is realistic for the delivery timeline

::: warning Important reminder
Autologyx MCP Customer Success can make an AI assistant much more useful for Autologyx analysis, planning, and design, but it does not guarantee that every recommendation is correct.

Always review AI-generated architecture, implementation plans, migration advice, and configuration recommendations before relying on them for client commitments or production changes.
:::

## **Things to remember**

1. Autologyx MCP Customer Success gives an AI assistant Autologyx-specific knowledge and implementation context.
2. It is designed for analysis, design, planning, discovery, and configuration guidance.
3. It is different from Autologyx MCP Work, which can interact with live operational records and tasks.
4. The service is especially powerful when combined with uploaded requirements documents or process notes.
5. It can help turn unstructured client requirements into structured Autologyx design options and implementation cut lists.
6. Users should ask for specific outputs such as solution designs, cut lists, migration plans, risks, assumptions, and open questions.
7. AI-generated recommendations should always be reviewed by an experienced Autologyx user or implementation team before being used for production change.

---

---
url: /knowledgebase/applied-ai/mcp-services.md
---

# Autologyx MCP Work

Autologyx MCP Work is the tool collection that allows approved AI assistants and agents to help perform operational work in Autologyx.

It is called **Work** because it is intended for the people and teams who normally perform work through Autologyx: lawyers, attorneys, associates, legal operations teams, back office teams, external third parties, and in some scenarios clients. MCP Work gives those users a way to augment the work they already do in Autologyx by allowing approved agents to act alongside them, or in controlled autonomous workflows.

MCP Work is not for configuring the Autologyx product. It does not create Object Classes, design forms, build Sequences, configure permissions, or change administration settings. Instead, it focuses on live operational activity: finding records, reading and updating data, managing tasks, using document automation, navigating record relationships, and helping work move through an existing process.

## What MCP Work is for

MCP Work is for agentic interaction with live Autologyx work.

Depending on the enabled tools, permissions, and customer configuration, an approved agent can help with activities such as:

* finding records that match a user request
* reading the details of a record
* updating structured fields on a record
* creating a new record
* creating related record structures
* navigating parent and child record relationships
* finding relevant task templates
* creating manual or automatic tasks
* assigning and unassigning tasks
* reading task details
* saving task data
* generating documents from configured templates
* checking document generation status
* downloading generated document payloads where permitted

This means an agent can do more than answer a question. It can help complete the operational steps that a user would otherwise perform directly in Autologyx.

## Who benefits from MCP Work

MCP Work is designed for users and teams who interact with Autologyx as part of a live process.

This can include:

* lawyers and attorneys managing legal work
* associates preparing documents, triaging matters, or reviewing tasks
* legal operations teams managing intake, allocation, reporting, and process flow
* back office teams handling repeatable operational steps
* external third parties contributing to a controlled process
* clients or business users interacting with defined records and tasks
* autonomous service agents operating within tightly controlled permissions

The agent does not replace the Autologyx process. It works through that process using the tools it has been granted.

## Why MCP Work matters

Many AI tools can summarise text or answer questions. MCP Work is different because it allows an approved agent to participate in the operational system of record.

For example, an agent might:

1. review a new intake record,
2. identify missing information,
3. update structured fields,
4. create a follow-up task,
5. generate a first draft document,
6. assign a review task to the correct team.

This can be useful in high-volume areas such as claims processing, client onboarding, remediation, contract management, legal intake, matter triage, and document-heavy workflows.

The value comes from combining agent reasoning with Autologyx control: structured data, record relationships, task management, document automation, permissions, and auditability.

## What MCP Work is not

MCP Work is not a configuration toolkit.

It should not be used to:

* create or redesign Object Classes
* configure forms
* build or change Sequences
* create Sequence Actors
* configure roles or permissions
* change administration settings
* redesign the data model

Those activities belong to Autologyx configuration and administration workflows. MCP Work is for interacting with work that already exists inside a configured Autologyx environment.

For configuration guidance and platform knowledge, use [Autologyx MCP Customer Success](/knowledgebase/applied-ai/mcp-services/mcp-customer-success/).

## Co-pilot and autonomous patterns

MCP Work can support both co-pilot and autonomous patterns.

In a co-pilot pattern, the agent works alongside a named user. The user asks the agent to find information, prepare an update, draft a document, or create a task. The user remains closely involved and can review the output.

Some co-pilot style agents may occasionally ask the user to confirm an action before continuing. This can happen where the requested action is sensitive, affects multiple records, or results in bulk operations. This confirmation behaviour is not triggered or controlled by the MCP tools or by Autologyx. It is part of the safeguarding and guardrail controls implemented by the AI assistant or agent client.

In an autonomous pattern, the agent may perform a defined set of actions without a user prompting each step. For example, it might monitor a queue of intake records, identify records missing key information, and create follow-up tasks.

Autonomous patterns require careful design. The agent should have narrow permissions, clear tool boundaries, and human review gates for important decisions or externally visible outputs.

## Permissions and audit

MCP Work should be enabled with governance in mind.

Agent access can be controlled by the tools exposed to the agent, the account the agent uses, the user context, and the underlying Autologyx role-based access model. Customers can decide which agents can read data, update records, create tasks, generate documents, or perform other permitted actions.

Audit logging is especially important because MCP Work can include write actions. Customers should be able to review which tools were called, what action was requested, what data was affected, when the action happened, and whether the action succeeded.

## Record tool endpoints

Record tools allow an approved agent to find, read, create, update, relate, and work with Object Records and record-related documents.

For more detail, see [Working with records through MCP Work](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/#record-tool-endpoints#record-tool-endpoints).

| Endpoint | What it does | Example use case |
|---|---|---|
| `search_object_classes` | Searches available Object Classes. This supports discovery of the data model without changing configuration. | An agent finds the correct Object Class before searching for matter records. |
| `get_object_class` | Retrieves details for a specific Object Class. | An agent checks the structure of a matter type before explaining what record data is available. |
| `list_object_class_fields` | Lists valid fields and aliases for a specific Object Class. | An agent identifies the correct field aliases before creating or updating a record. |
| `list_object_class_children` | Lists direct child Object Classes for a parent Object Class. | An agent confirms which related child records can be created under a parent matter. |
| `list_object_class_parents` | Lists direct parent Object Classes for a child Object Class. | An agent works out which parent records a child record can be related to. |
| `search_object_records` | Searches Object Records using filters, pagination, ordering, and selected fields. | An agent finds all open intake records for a client or process. |
| `get_object_record` | Retrieves details for a specific Object Record. | An agent reviews the current state of a matter before suggesting next steps. |
| `create_object_record` | Creates a new Object Record with supplied field values. | An agent creates a new intake record from information provided by a user. |
| `update_object_record` | Updates fields on an existing Object Record. | An agent fills missing triage fields after reviewing source information. |
| `create_object_records_hierarchy` | Creates a parent Object Record and nested child Object Records as an asynchronous operation. | An agent creates a matter structure with related parties, requests, or child items in one operation. |
| `check_object_records_hierarchy_creation` | Checks the status of an asynchronous record hierarchy creation process. | An agent confirms whether a complex matter structure has finished creating. |
| `search_object_record_children` | Finds child records linked to a parent Object Record. | An agent lists all related contract documents or subsidiary requests under a matter. |
| `search_object_record_parents` | Finds parent records linked to a child Object Record. | An agent identifies the matter or client record linked to a document record. |
| `remove_object_record_child` | Removes the relationship between a parent record and a child record. | An agent disconnects a record that was linked to the wrong parent, where permitted. |
| `search_document_templates` | Searches document templates for a specific Object Class. | An agent finds the correct template for an engagement letter or approval document. |
| `get_document_template` | Retrieves details for a specific document template. | An agent checks template details before generating a document. |
| `generate_object_record_document` | Starts document generation for an Object Record and document template. | An agent generates a first draft document from record data. |
| `get_object_record_document` | Retrieves document generation metadata, processing status, and download information. | An agent checks whether a generated document is ready. |
| `download_object_record_document` | Downloads a generated Object Record document payload and metadata where permitted. | An agent retrieves a completed document for review or onward processing. |
| `search_object_record_documents` | Searches documents linked to an Object Record. | An agent finds documents already generated or attached to a matter. |

## Task tool endpoints

Task tools allow an approved agent to find, create, read, update, assign, unassign, and manage Tasks.

For more detail, see [Working with tasks through MCP Work](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/#task-tool-endpoints#task-tool-endpoints).

| Endpoint | What it does | Example use case |
|---|---|---|
| `search_task_templates` | Searches available Task Templates. | An agent finds the right template before creating a follow-up task. |
| `get_task_template` | Retrieves details for a specific Task Template. | An agent checks what task type should be used for legal review. |
| `search_tasks` | Searches Tasks using filters, pagination, ordering, and assignment criteria. | An agent finds overdue tasks assigned to a team or user. |
| `get_task` | Retrieves current details, schema, and response data for a Task. | An agent reviews what information is needed before updating or saving a task. |
| `create_manual_task` | Creates a new Manual Task against an Object Record. | An agent creates a lawyer review task with instructions and a due date. |
| `create_automatic_task` | Creates a new Automatic Task from a Task Template and Object Record. | An agent starts a configured task as part of a repeatable process. |
| `save_task` | Saves or updates Task data while keeping the task outstanding. | An agent records partial progress on a task that still requires human action. |
| `assign_task_to_users` | Assigns a Task to one or more users. | An agent assigns a contract review task to the responsible lawyer. |
| `assign_task_to_user_groups` | Assigns a Task to one or more user groups. | An agent assigns an intake task to the legal operations team. |
| `unassign_task_from_users` | Removes one or more user assignments from a Task. | An agent removes a user assignment when work is reallocated. |
| `unassign_task_from_user_groups` | Removes one or more user group assignments from a Task. | An agent removes a team assignment after the task is reassigned to a named user. |

## How the tools work together

The real value of MCP Work comes from combining tools.

For example, an agent might:

1. search for the right intake record,
2. retrieve the record details,
3. inspect related child records,
4. update missing structured fields,
5. search for a task template,
6. create a manual task,
7. assign the task to a user group,
8. generate a document from a configured template.

Each step is performed through a tool that can be permissioned, controlled, and audited.

For more information, see [How MCP Work tools are used together](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/).

## Designing safe MCP Work patterns

MCP Work gives agents operational capability, so design matters.

Before enabling an agent, consider:

* which users or service accounts the agent will act with
* which Object Classes the agent can access
* which records the agent can read or update
* which task templates the agent can use
* whether the agent can create or complete tasks
* whether the agent can generate or download documents
* which actions require human review
* how tool calls will be audited
* how quickly access can be removed if needed

Start narrow. Give the agent the smallest set of tools and permissions needed for the use case, then expand only where there is a clear benefit.

## Important reminder about agentic work

::: warning Important reminder
MCP Work can allow agents to perform real actions in Autologyx.

Even where permissions, tools, prompts, and workflows have been carefully designed, an agent may misunderstand a request, choose the wrong tool, rely on incomplete context, or produce an unexpected result.

Permissions, audit logging, validation, deterministic checks, and human review can reduce risk, but they cannot remove it entirely.

Use human review where an agent action affects important decisions, external communications, sensitive data, record updates, document generation, or task completion.
:::

## Things to remember

1. MCP Work is for operational work in Autologyx, not product configuration.
2. It is designed for the people and teams who already work through Autologyx processes.
3. MCP Work can support both co-pilot and autonomous agent patterns.
4. Record tools allow agents to search, read, create, update, relate, and work with Object Records and documents.
5. Task tools allow agents to search, create, assign, unassign, save, and manage Tasks.
6. Tool access should be limited to the tools and data the agent genuinely needs.
7. Write access should be granted carefully and tested before production use.
8. Audit logging and human review are essential for higher-risk workflows.

---

---
url: /knowledgebase/applied-ai/mcp-services/mcp-work.md
---

# Autologyx MCP Work

Autologyx MCP Work is the tool collection that allows approved AI assistants and agents to help perform operational work in Autologyx.

It is called **Work** because it is intended for the people and teams who normally perform work through Autologyx: lawyers, attorneys, associates, legal operations teams, back office teams, external third parties, and in some scenarios clients. MCP Work gives those users a way to augment the work they already do in Autologyx by allowing approved agents to act alongside them, or in controlled autonomous workflows.

MCP Work is not for configuring the Autologyx product. It does not create Object Classes, design forms, build Sequences, configure permissions, or change administration settings. Instead, it focuses on live operational activity: finding records, reading and updating data, managing tasks, using document automation, navigating record relationships, and helping work move through an existing process.

Most users do not need to learn the MCP Work tool catalogue in detail before using an MCP-enabled agent. In normal use, the agent can read the available MCP tools, understand what each tool is for, and select the most appropriate tool for the user’s request. If you mainly want to understand how to begin using agents with Autologyx, start with [Getting started with MCP](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/).

Architects, administrators, solution designers, and advanced agentic workflow designers may want to understand the available tools in more detail. That is useful when planning permissions, designing autonomous patterns, assessing risk, or deciding which tools an agent should be allowed to use. The tool reference pages in this section explain the MCP Work tools in more technical detail.

## What MCP Work is for

MCP Work is for agentic interaction with live Autologyx work.

Depending on the enabled tools, permissions, and customer configuration, an approved agent can help with activities such as:

* finding records that match a user request
* reading the details of a record
* updating structured fields on a record
* creating a new record
* creating related record structures
* navigating parent and child record relationships
* finding relevant task templates
* creating manual or automatic tasks
* assigning and unassigning tasks
* reading task details
* saving task data
* generating documents from configured templates
* checking document generation status
* downloading generated document payloads where permitted

This means an agent can do more than answer a question. It can help complete the operational steps that a user would otherwise perform directly in Autologyx.

## Who benefits from MCP Work

MCP Work is designed for users and teams who interact with Autologyx as part of a live process.

This can include:

* lawyers and attorneys managing legal work
* associates preparing documents, triaging matters, or reviewing tasks
* legal operations teams managing intake, allocation, reporting, and process flow
* back office teams handling repeatable operational steps
* external third parties contributing to a controlled process
* clients or business users interacting with defined records and tasks
* autonomous service agents operating within tightly controlled permissions

The agent does not replace the Autologyx process. It works through that process using the tools it has been granted.

## Why MCP Work matters

Many AI tools can summarise text or answer questions. MCP Work is different because it allows an approved agent to participate in the operational system of record.

For example, an agent might:

1. review a new intake record,
2. identify missing information,
3. update structured fields,
4. create a follow-up task,
5. generate a first draft document,
6. assign a review task to the correct team.

This can be useful in high-volume areas such as claims processing, client onboarding, remediation, contract management, legal intake, matter triage, and document-heavy workflows.

The value comes from combining agent reasoning with Autologyx control: structured data, record relationships, task management, document automation, permissions, and auditability.

## What MCP Work is not

MCP Work is not a configuration toolkit.

It should not be used to:

* create or redesign Object Classes
* configure forms
* build or change Sequences
* create Sequence Actors
* configure roles or permissions
* change administration settings
* redesign the data model

Those activities belong to Autologyx configuration and administration workflows. MCP Work is for interacting with work that already exists inside a configured Autologyx environment.

For configuration guidance and platform knowledge, use [Autologyx MCP Customer Success](/knowledgebase/applied-ai/mcp-services/mcp-customer-success/).

## Co-pilot and autonomous patterns

MCP Work can support both co-pilot and autonomous patterns.

In a co-pilot pattern, the agent works alongside a named user. The user asks the agent to find information, prepare an update, draft a document, or create a task. The user remains closely involved and can review the output.

Some co-pilot style agents may occasionally ask the user to confirm an action before continuing. This is often seen where a request could result in a bulk operation or another higher-impact change. That confirmation behaviour is not triggered or controlled by Autologyx MCP Work tools. It is part of the safeguarding and guardrail behaviour implemented by the agent or AI client.

In an autonomous pattern, the agent may perform a defined set of actions without a user prompting each step. For example, it might monitor a queue of intake records, identify records missing key information, and create follow-up tasks.

Autonomous patterns require careful design. The agent should have narrow permissions, clear tool boundaries, and human review gates for important decisions or externally visible outputs.

## Permissions and audit

MCP Work should be enabled with governance in mind.

Agent access can be controlled by the tools exposed to the agent, the account the agent uses, the user context, and the underlying Autologyx role-based access model. Customers can decide which agents can read data, update records, create tasks, generate documents, or perform other permitted actions.

Audit logging is especially important because MCP Work can include write actions. Customers should be able to review which tools were called, what action was requested, what data was affected, when the action happened, and whether the action succeeded.

## Record tool endpoints

Record tools allow an approved agent to find, read, create, update, relate, and work with Object Records and record-related documents.

For more detail, see [Available MCP Work tools](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/#record-tool-endpoints) and [Available MCP Work tools](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/#record-tool-endpoints).

| Endpoint | What it does | Example use case |
|---|---|---|
| `check_object_records_hierarchy_creation` | Checks the status of an asynchronous record hierarchy creation process. | An agent confirms whether a complex matter structure has finished creating. |
| `create_object_record` | Creates a new Object Record with supplied field values. | An agent creates a new intake record from information provided by a user. |
| `create_object_records_hierarchy` | Creates a parent Object Record and nested child Object Records as an asynchronous operation. | An agent creates a matter structure with related parties, requests, or child items in one operation. |
| `download_object_record_document` | Downloads a generated Object Record document payload and metadata where permitted. | An agent retrieves a completed document for review or onward processing. |
| `generate_object_record_document` | Starts document generation for an Object Record and document template. | An agent generates a first draft document from record data. |
| `get_document_template` | Retrieves details for a specific document template. | An agent checks template details before generating a document. |
| `get_object_class` | Retrieves details for a specific Object Class. | An agent checks the structure of a matter type before explaining what record data is available. |
| `get_object_record` | Retrieves details for a specific Object Record. | An agent reviews the current state of a matter before suggesting next steps. |
| `get_object_record_document` | Retrieves document generation metadata, processing status, and download information. | An agent checks whether a generated document is ready. |
| `list_object_class_children` | Lists direct child Object Classes for a parent Object Class. | An agent confirms which related child records can be created under a parent matter. |
| `list_object_class_fields` | Lists valid fields and aliases for a specific Object Class. | An agent identifies the correct field aliases before creating or updating a record. |
| `list_object_class_parents` | Lists direct parent Object Classes for a child Object Class. | An agent works out which parent records a child record can be related to. |
| `remove_object_record_child` | Removes the relationship between a parent record and a child record. | An agent disconnects a record that was linked to the wrong parent, where permitted. |
| `search_document_templates` | Searches document templates for a specific Object Class. | An agent finds the correct template for an engagement letter or approval document. |
| `search_object_classes` | Searches available Object Classes. This supports discovery of the data model without changing configuration. | An agent finds the correct Object Class before searching for matter records. |
| `search_object_record_children` | Finds child records linked to a parent Object Record. | An agent lists all related contract documents or subsidiary requests under a matter. |
| `search_object_record_documents` | Searches documents linked to an Object Record. | An agent finds documents already generated or attached to a matter. |
| `search_object_record_parents` | Finds parent records linked to a child Object Record. | An agent identifies the matter or client record linked to a document record. |
| `search_object_records` | Searches Object Records using filters, pagination, ordering, and selected fields. | An agent finds all open intake records for a client or process. |
| `update_object_record` | Updates fields on an existing Object Record. | An agent fills missing triage fields after reviewing source information. |

## Task tool endpoints

Task tools allow an approved agent to find, create, read, update, assign, unassign, and manage Tasks.

For more detail, see [Available MCP Work tools](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/#task-tool-endpoints) and [Available MCP Work tools](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/#task-tool-endpoints).

| Endpoint | What it does | Example use case |
|---|---|---|
| `assign_task_to_user_groups` | Assigns a Task to one or more user groups. | An agent assigns an intake task to the legal operations team. |
| `assign_task_to_users` | Assigns a Task to one or more users. | An agent assigns a contract review task to the responsible lawyer. |
| `create_automatic_task` | Creates a new Automatic Task from a Task Template and Object Record. | An agent starts a configured task as part of a repeatable process. |
| `create_manual_task` | Creates a new Manual Task against an Object Record. | An agent creates a lawyer review task with instructions and a due date. |
| `get_task` | Retrieves current details, schema, and response data for a Task. | An agent reviews what information is needed before updating or saving a task. |
| `get_task_template` | Retrieves details for a specific Task Template. | An agent checks what task type should be used for legal review. |
| `save_task` | Saves or updates Task data while keeping the task outstanding. | An agent records partial progress on a task that still requires human action. |
| `search_task_templates` | Searches available Task Templates. | An agent finds the right template before creating a follow-up task. |
| `search_tasks` | Searches Tasks using filters, pagination, ordering, and assignment criteria. | An agent finds overdue tasks assigned to a team or user. |
| `unassign_task_from_user_groups` | Removes one or more user group assignments from a Task. | An agent removes a team assignment after the task is reassigned to a named user. |
| `unassign_task_from_users` | Removes one or more user assignments from a Task. | An agent removes a user assignment when work is reallocated. |

## How the tools work together

The real value of MCP Work comes from combining tools.

For example, an agent might:

1. search for the right intake record,
2. retrieve the record details,
3. inspect related child records,
4. update missing structured fields,
5. search for a task template,
6. create a manual task,
7. assign the task to a user group,
8. generate a document from a configured template.

Each step is performed through a tool that can be permissioned, controlled, and audited.

For more information, see [Available MCP Work tools](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/).

## Designing safe MCP Work patterns

MCP Work gives agents operational capability, so design matters.

Before enabling an agent, consider:

* which users or service accounts the agent will act with
* which Object Classes the agent can access
* which records the agent can read or update
* which task templates the agent can use
* whether the agent can create or complete tasks
* whether the agent can generate or download documents
* which actions require human review
* how tool calls will be audited
* how quickly access can be removed if needed

Start narrow. Give the agent the smallest set of tools and permissions needed for the use case, then expand only where there is a clear benefit.

## Important reminder about agentic work

::: warning Important reminder
MCP Work can allow agents to perform real actions in Autologyx.

Even where permissions, tools, prompts, and workflows have been carefully designed, an agent may misunderstand a request, choose the wrong tool, rely on incomplete context, or produce an unexpected result.

Permissions, audit logging, validation, deterministic checks, and human review can reduce risk, but they cannot remove it entirely.

Use human review where an agent action affects important decisions, external communications, sensitive data, record updates, document generation, or task completion.
:::

## Things to remember

1. MCP Work is for operational work in Autologyx, not product configuration.
2. It is designed for the people and teams who already work through Autologyx processes.
3. MCP Work can support both co-pilot and autonomous agent patterns.
4. Most users do not need to learn each MCP tool in detail because agents can navigate the available tool catalogue.
5. Advanced designers should understand the tool catalogue when planning permissions, autonomous workflows, and risk controls.
6. Record tools allow agents to search, read, create, update, relate, and work with Object Records and documents.
7. Task tools allow agents to search, create, assign, unassign, save, and manage Tasks.
8. Tool access should be limited to the tools and data the agent genuinely needs.
9. Write access should be granted carefully and tested before production use.
10. Audit logging and human review are essential for higher-risk workflows.

---

---
url: >-
  /knowledgebase/system-configuration/working-with-document-templates/automatic-generation-of-documents-via-the-sequencer.md
---

# Automatic generation of documents via the Sequencer

Having created a document template for an object class, it can be used to generate documents automatically as part of the workflow in a sequence.

[Click here](/knowledgebase/system-configuration/working-with-document-templates/create-a-document-template/) for information on how to create a document template.

The document generation can follow any other operation in a sequence, eg completion of task, sending of a message, or an Update Record actor being used to change a status or other record field value.

If you wish to store the document on a record once it has been generated, you will need to add an appropriately named Document type field on the same object class as the template.

**For the actual document generation, you will need three actors:**

|  |  |
| --- | --- |
| DocAuto | Screenshot 2024-01-29 at 15.05.17.png |
| Document Picker | Screenshot 2024-01-29 at 14.59.06.png |
| Update Record | Screenshot 2024-01-29 at 15.20.52.png |

## Steps for sequencing the document generation

1. Drag the DocAuto actor on the sequence workspace. Connect a trigger to it from the actor which precedes it in the workflow. Add the required trigger configuration and save this.
2. Right click on the DocAuto actor and select Configure![Screenshot 2024-01-29 at 17.30.27.png](/knowledgebase/images/img_16404937615389_1776895847.png)
3. Click into the Template field and select the required template. These are listed alphabetically by name. Click Save. This actor is responsible for getting the template and generating the document for the specific record.
4. Drag a Document Picker onto the sequence workspace and position it so that you can connect it with a trigger from the DocAuto actor. Set the trigger conditions and save these.
5. Right click on the Document Picker actor and select Configure.

![Screenshot 2024-01-29 at 18.19.00.png](/knowledgebase/images/img_16404937615389_1776895848.png)

6. Click into the Source field. There are two options. In this case select "DocAuto Actor" as you want to take the newly generated document from the DocAuto actor. Click Save.

|  |  |
| --- | --- |
| The other option, "Document Field", would be selected when a Document Picker is used, without a Document Generation actor, to "take" an existing document from a field.  This option requires you to select the field from which the document is referenced. | Screenshot 2024-02-06 at 17.42.13.png |

7. **Optional: send the generated document by email.** At this stage, if you connect a Send Message Actor to the Document Picker actor the generated document will appear as an Attachment option. Simply tick the box to ensure that the generated document is attached to the outgoing email.

![Screenshot 2024-01-29 at 18.47.11.png](/knowledgebase/images/img_16404937615389_1776895848.png)

8. **To store the generated document on the record:** connect an Update Record Actor from the Document Picker Actor for other uses of the generated document; configure the trigger conditions and save these.
9. Right click on the Update Record Actor and select Configure. In the left hand "Set" field, select "Field from Document Picker".

**![Screenshot 2024-01-29 at 18.27.04.png](/knowledgebase/images/img_16404937615389_1776895849.png)**

10. In the next field, select the document field you created as the file storage for the generated document.

**![Screenshot 2024-01-29 at 18.33.15.png](/knowledgebase/images/img_16404937615389_1776895849.png)**

11. In the final field select "Add" if you wish to add the newly generated document to the field or "Replace" if you wish to remove the existing document from the field and replace it with this new one.

![Screenshot 2024-01-29 at 18.36.41.png](/knowledgebase/images/img_16404937615389_1776895849.png)

**Important:** Consider how your field has been configured. If your field has a maximum of one file allowed, you should select Replace. This is important if the process might cycle around more than once.

![Screenshot 2024-02-05 at 19.46.31.png](/knowledgebase/images/img_16404937615389_1776895849.png)

12. Having saved the generated document to a field on the object record, it can be referenced in an API call as below. Documents sent via API are always taken from a field on the object record and sent in base64 format.

![Screenshot 2024-01-29 at 20.18.59.png](/knowledgebase/images/img_16404937615389_1776895850.png)

13. If the document field is to be included in a task, the task template must be configured in the workflow after the Document Generation, Document Picker and Update Record actors. However, this does not have to be immediately after as is shown in the below screenshot. Once the document has been saved to a field on the object record it can be used at any stage.

![Screenshot 2024-01-29 at 21.36.33.png](/knowledgebase/images/img_16404937615389_1776895850.png)

The document will appear as a downloadable link in the task, as shown below.

![Screenshot 2024-02-06 at 11.11.38.png](/knowledgebase/images/img_16404937615389_1776895850.png)

## Useful info

1. In order to create workflow in sequences you will require either a Super admin account type or a Role with permission to create sequences.

---

---
url: /knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools.md
---

# Available MCP Work tools

This page provides a more detailed reference for the tools available through Autologyx MCP Work.

MCP Work tools allow approved AI assistants and agents to interact with live Autologyx work. The tools are focused on operational activity, such as finding records, reading and updating record data, creating tasks, assigning work, and generating documents from configured templates.

MCP Work does not expose Autologyx configuration tools. It is not intended to create Object Classes, build forms, configure Sequences, manage roles, or change administration settings. Configuration and administration remain controlled through the normal Autologyx configuration experience.

## How to read this page

Each tool is described using the same general structure:

| Section | Meaning |
|---|---|
| Purpose | What the tool is used for |
| Typical use | When an agent might use the tool |
| Required inputs | Inputs the tool needs before it can run |
| Optional inputs | Inputs that refine the request |
| Important requirements | Constraints, dependencies, or safe-use notes |
| Typical output | The kind of result the agent should expect |

The exact response body may vary by environment, permissions, Object Class configuration, Task Template configuration, and product version.

## Common concepts

### Tool permissions

Agents can only use the MCP Work tools they have been granted. Tool access should be combined with the normal Autologyx role-based access model so that an agent can only see and do what is appropriate for the user, service account, process, or use case.

### Object Class and Object Record IDs

Many record tools require an Object Class ID, an Object Record ID, or both.

An agent will often need to search for an Object Class first, then inspect its fields, then search or update records within that class.

### Field aliases

When creating or updating Object Records, field values are passed using field aliases.

For create and update tools, the alias is normally the field slug value without the `field_` prefix. For example, use `first_name`, not `field_first_name`.

For search filters and `show_fields`, custom Object Class fields normally use the `field_` prefix. For example, use `field_first_name`.

### Filters

Search tools support filters. A filter contains a field name and a value. Some filters can use lookup suffixes such as `__icontains`, `__in`, `__gt`, `__gte`, `__lt`, `__lte`, `__range`, `__containsall`, or `__containssome`, depending on the field type.

For example:

```json
{
  "filters": [
    {
      "name": "field_status",
      "value": "Open"
    },
    {
      "name": "field_client_name__icontains",
      "value": "example"
    }
  ]
}
```

### Pagination and ordering

Many search tools support `limit`, `offset`, and `ordering`.

Use these where an agent may retrieve many results. This helps avoid overly broad requests and makes tool use easier to review.

### Write actions

Tools that create, update, assign, unassign, save, generate, download, or remove relationships should be treated as write or action tools.

Give agents access to write tools only where the use case requires it. Use human review gates where the action is sensitive, high impact, externally visible, or difficult to reverse.

## Record tool endpoints

Record tools allow agents to inspect the data model, find and work with Object Records, manage record relationships, and use document automation.

### check\_object\_records\_hierarchy\_creation

Checks the status of an asynchronous Object Record hierarchy creation process.

#### Purpose

Use this tool after `create_object_records_hierarchy` to confirm whether the hierarchy creation has completed.

#### Typical use

An agent starts a hierarchy creation request and then checks the transaction status before telling the user the matter structure has been created.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `id` | string | Transaction ID returned by `create_object_records_hierarchy` |

#### Important requirements

Only use this tool for transactions initiated by `create_object_records_hierarchy`.

Interpret the returned status carefully:

| Status | Meaning |
|---|---|
| `queued` | The operation has not completed yet |
| `processing` | The operation is still running |
| `completed` | The hierarchy was created successfully |
| `failed` | The hierarchy creation failed |

If the status is `queued` or `processing`, the agent should check again later. The user should not be told that the hierarchy has been created until the status is `completed`.

#### Typical output

A transaction status object.

### create\_object\_record

Creates a new Object Record.

#### Purpose

Use this tool when an agent needs to create a new record in an existing Object Class.

#### Typical use

An agent creates a new legal request record from information provided by a user in a co-pilot conversation.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_class` | integer | Object Class ID for the new record |

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `fields` | array | Field values to set on creation |

Each item in `fields` contains:

| Key | Type | Notes |
|---|---|---|
| `alias` | string | Field alias without the `field_` prefix |
| `value` | string | Field value. For set fields, pass a JSON-encoded array |

#### Example body

```json
{
  "object_class": 12,
  "fields": [
    {
      "alias": "client_name",
      "value": "Example Client"
    },
    {
      "alias": "request_type",
      "value": "Contract review"
    }
  ]
}
```

#### Important requirements

The agent must know the correct Object Class and field aliases. Use `list_object_class_fields` first where needed.

This is a write action. Use appropriate permissions and review patterns.

#### Typical output

The created Object Record or a confirmation of the created record.

### create\_object\_records\_hierarchy

Creates a parent Object Record and nested child Object Records as an asynchronous operation.

#### Purpose

Use this tool when an agent needs to create a structured record hierarchy in one operation.

#### Typical use

An agent creates a new matter with related child records for parties, documents, and initial work items.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_class` | integer | Object Class ID for the parent record |

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `fields` | array | Field values for the parent record |
| `children` | array | Nested child records. Children can contain their own `children` arrays |

#### Important requirements

Before using this tool, the agent must discover allowed child classes with `list_object_class_children`. This should be repeated recursively for each child class level the agent intends to create.

This tool initiates an asynchronous process. It does not mean the hierarchy has been created immediately.

After starting the operation, the agent must use the transaction ID returned by this tool and call `check_object_records_hierarchy_creation` until the status is `completed` or `failed`.

This is a write action and can create multiple records. Some co-pilot style agents may ask the user for confirmation before running a bulk or multi-record operation.

#### Typical output

A transaction object with an ID and status, such as `queued`.

### download\_object\_record\_document

Downloads a generated Object Record document payload and metadata.

#### Purpose

Use this tool when an agent needs to retrieve the generated document file after confirming that it is available.

#### Typical use

An agent retrieves a generated document so it can be reviewed, summarised, or provided to a user where permitted.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_record` | integer | Object Record ID |
| `document_template` | integer | Document Template ID |
| `uuid` | string | Document UUID extracted from `get_object_record_document` metadata |

#### Important requirements

Call `get_object_record_document` first and extract the UUID from the document URL.

The response contains metadata and base64-encoded file content, not a plain binary file.

This tool may expose document content, so permissions and audit are important.

#### Typical output

A JSON object containing file metadata and base64-encoded content.

### generate\_object\_record\_document

Starts document generation for an Object Record and Document Template.

#### Purpose

Use this tool when an agent needs to generate a document using an existing Autologyx document template.

#### Typical use

An agent generates a first draft engagement letter using data from a matter record.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_record` | integer | Object Record ID |
| `document_template` | integer | Document Template ID |

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `object_record_field` | string | Field where the generated document should be added. Prefix the alias with `field_` |

#### Important requirements

This starts the generation process. The generated document may not be immediately ready.

Use `get_object_record_document` to check status and retrieve metadata.

This is an action tool and may create or attach a document. Use human review where the document will be externally visible or legally significant.

#### Typical output

A generation response or reference that can be followed using document status tools.

### get\_document\_template

Retrieves details for a single Document Template.

#### Purpose

Use this tool when an agent needs to inspect a known template before document generation.

#### Typical use

An agent checks a document template before generating a draft document from record data.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_class` | integer | Object Class ID |
| `pk` | string | Document Template ID |

#### Important requirements

Use this where the agent needs to confirm template details before calling `generate_object_record_document`.

#### Typical output

Details of the Document Template visible to the agent.

### get\_object\_class

Retrieves details for a single Object Class.

#### Purpose

Use this tool when an agent already has an Object Class ID and needs to inspect the class before working with its records.

#### Typical use

An agent retrieves details for a matter Object Class before explaining what type of records it contains.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `pk` | string | Object Class ID |

#### Important requirements

The Object Class must exist and be visible to the agent.

#### Typical output

Details of the Object Class, including identifiers, metadata, and available permissions.

### get\_object\_record

Retrieves details for a single Object Record.

#### Purpose

Use this tool when an agent needs to inspect a known record before taking action or answering a question.

#### Typical use

An agent reviews the current details of an intake record before suggesting next steps or creating a follow-up task.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `pk` | string | Object Record ID |

#### Important requirements

The record must exist and be visible to the agent.

Use this tool before update actions where the current record state matters.

#### Typical output

The Object Record details visible to the agent.

### get\_object\_record\_document

Retrieves metadata, status, and download information for a generated Object Record document.

#### Purpose

Use this tool to check whether document generation is still processing, completed, or failed.

#### Typical use

An agent checks whether a document generated from a template is ready to download or review.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_record` | integer | Object Record ID |
| `document_template` | integer | Document Template ID |

#### Important requirements

If the document is completed and a file download is needed, the agent must extract the document UUID from the document URL returned in the metadata and then call `download_object_record_document`.

Do not guess the UUID.

#### Typical output

Document metadata, processing status, error details if generation failed, and a document URL where available.

### list\_object\_class\_children

Retrieves direct child Object Classes for a parent Object Class.

#### Purpose

Use this tool when an agent needs to understand which child record types can sit under a parent record type.

#### Typical use

An agent checks which child Object Classes can be created under a matter before preparing a matter hierarchy.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_class` | integer | Parent Object Class ID |

#### Important requirements

This tool is required before using `create_object_records_hierarchy` to create child records. If the hierarchy has multiple levels, the agent should check allowed child classes at each level.

#### Typical output

A list of direct child Object Classes related to the parent Object Class.

### list\_object\_class\_fields

Retrieves valid fields and aliases for a specific Object Class.

#### Purpose

Use this tool before creating, updating, or filtering Object Records where the agent needs to know which field aliases are valid.

#### Typical use

An agent checks the field aliases for an intake record before updating `priority`, `client_name`, or `matter_type`.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_class` | integer | Object Class ID |

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `limit` | integer | Maximum number of fields to return |
| `offset` | integer | Number of fields to skip |

#### Important requirements

Use this tool before passing field aliases into `create_object_record` or `update_object_record` where the agent is not already certain of the schema.

#### Typical output

A list of fields for the Object Class, including aliases and field metadata.

### list\_object\_class\_parents

Retrieves direct parent Object Classes for a child Object Class.

#### Purpose

Use this tool when an agent needs to understand where a child record type can sit in the data model.

#### Typical use

An agent checks which parent record types can contain a document review record.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_class` | integer | Child Object Class ID |

#### Important requirements

This is a relationship discovery tool. It does not create or remove any relationship.

#### Typical output

A list of direct parent Object Classes related to the child Object Class.

### remove\_object\_record\_child

Removes the relationship between a parent Object Record and a child Object Record.

#### Purpose

Use this tool when an agent needs to disconnect a child record from a parent record.

#### Typical use

An agent removes a child record that was linked to the wrong parent, after user confirmation.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_record_parent` | integer | Parent Object Record ID |
| `object_record_child` | integer | Child Object Record ID |

#### Important requirements

This is a write action that changes record relationships.

Use this tool carefully. The agent should normally confirm the intended parent and child records before removing a relationship.

#### Typical output

A success status or confirmation that the relationship has been removed.

### search\_document\_templates

Searches Document Templates for a specific Object Class.

#### Purpose

Use this tool when an agent needs to find a document template before generating a document.

#### Typical use

An agent searches for the correct engagement letter template for a matter type.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_class` | integer | Object Class ID |

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `limit` | integer | Maximum number of results to return |
| `offset` | integer | Number of results to skip |
| `ordering` | string | Sort field, with `-` for descending order |
| `filters` | array | Filter objects with `name` and `value` |

#### Important requirements

The agent must have permission to see the relevant templates.

This tool only searches templates. It does not generate a document.

#### Typical output

A paginated list of matching Document Templates.

### search\_object\_classes

Searches Object Classes matching the supplied criteria.

#### Purpose

Use this tool when an agent needs to discover which Object Classes are available before searching for records or explaining a data model.

#### Typical use

An agent is asked to find open legal intake records. It first searches Object Classes to identify the correct intake Object Class.

#### Required inputs

This tool can be called without a body. Filters are optional.

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `limit` | integer | Maximum number of results to return |
| `offset` | integer | Number of results to skip |
| `ordering` | string | Sort field, with `-` for descending order |
| `filters` | array | Filter objects with `name` and `value` |

#### Important requirements

The agent must have permission to list Object Classes.

This is a discovery tool. It does not create or change configuration.

#### Typical output

A paginated list of Object Classes visible to the agent.

### search\_object\_record\_children

Finds child records linked to a specific parent Object Record.

#### Purpose

Use this tool when an agent needs to navigate downward from a parent record to related child records.

#### Typical use

An agent lists all document review records under a matter.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_record` | integer | Parent Object Record ID |

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `child_object_class` | integer | Restrict results to a specific child Object Class |
| `limit` | integer | Maximum number of results to return |
| `offset` | integer | Number of results to skip |

#### Important requirements

Use `child_object_class` where possible to avoid returning unrelated child records.

#### Typical output

A paginated list of direct child Object Records.

### search\_object\_record\_documents

Searches documents linked to an Object Record.

#### Purpose

Use this tool when an agent needs to find documents associated with a record.

#### Typical use

An agent lists documents already generated or attached to a matter before generating a new one.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_record` | integer | Object Record ID |

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `limit` | integer | Maximum number of results to return |
| `offset` | integer | Number of results to skip |
| `ordering` | string | Sort field, with `-` for descending order |
| `filters` | array | Filter objects with `name` and `value` |

#### Important requirements

Search results depend on the agent’s permissions and the documents associated with the record.

#### Typical output

A paginated list of documents linked to the Object Record.

### search\_object\_record\_parents

Finds parent records linked to a specific child Object Record.

#### Purpose

Use this tool when an agent needs to navigate upward from a child record to its parent records.

#### Typical use

An agent identifies the matter or client record associated with a document review record.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_record` | integer | Child Object Record ID |

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `limit` | integer | Maximum number of results to return |
| `offset` | integer | Number of results to skip |

#### Important requirements

The returned parents depend on the relationships visible to the agent.

#### Typical output

A paginated list of direct parent Object Records.

### search\_object\_records

Searches Object Records matching the supplied criteria.

#### Purpose

Use this tool when an agent needs to find records within a specific Object Class.

#### Typical use

An agent finds all open onboarding records assigned to a team, or all matters for a particular client.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_class` | integer | Object Class ID to search within |

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `limit` | integer | Maximum number of results to return |
| `offset` | integer | Number of results to skip |
| `ordering` | string | Sort field, with `-` for descending order |
| `filters` | array | Filter objects with `name` and `value` |
| `show_fields` | array | Field aliases to include in the response, normally prefixed with `field_` |

#### Important requirements

Search as narrowly as possible. Use filters and `show_fields` to avoid returning more data than the agent needs.

Custom Object Class fields in filters normally require the `field_` prefix.

#### Typical output

A paginated list of matching Object Records.

### update\_object\_record

Updates fields on an existing Object Record.

#### Purpose

Use this tool when an agent needs to update structured data on a known record.

#### Typical use

An agent updates an intake record with a classification, priority, missing-information flag, or reviewer recommendation.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `pk` | string | Object Record ID |

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `fields` | array | Field values to update |

Each item in `fields` contains:

| Key | Type | Notes |
|---|---|---|
| `alias` | string | Field alias without the `field_` prefix |
| `value` | string | Field value. For set fields, pass a JSON-encoded array |

#### Example body

```json
{
  "fields": [
    {
      "alias": "triage_status",
      "value": "Needs review"
    }
  ]
}
```

#### Important requirements

This is a write action. The agent should usually retrieve the record first and update only the fields required for the task.

Use human review where the update affects important decisions, record status, or external communications.

#### Typical output

The updated Object Record or a confirmation of the update.

## Task tool endpoints

Task tools allow agents to find, create, read, update, assign, unassign, and manage Tasks.

### assign\_task\_to\_user\_groups

Assigns a Task to one or more user groups.

#### Purpose

Use this tool when an agent needs to assign a task to a team or group rather than a named user.

#### Typical use

An agent assigns a new intake task to the legal operations user group.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `task` | integer | Task ID |
| `user_groups` | array | Array of user group IDs |

#### Important requirements

This is a write action that changes task assignment.

Use group assignment where work should be picked up by a team queue rather than a specific individual.

#### Typical output

Confirmation that the task assignment has been updated.

### assign\_task\_to\_users

Assigns a Task to one or more users.

#### Purpose

Use this tool when an agent needs to assign a task to named users.

#### Typical use

An agent assigns a review task to the responsible lawyer.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `task` | integer | Task ID |
| `users` | array | Array of user IDs |

#### Important requirements

This is a write action that changes task assignment.

The agent should normally confirm the intended assignee before assigning important work.

#### Typical output

Confirmation that the task assignment has been updated.

### create\_automatic\_task

Creates a new Automatic Task against an Object Record from a Task Template.

#### Purpose

Use this tool where a configured automatic task should be created as part of a repeatable process.

#### Typical use

An agent starts a configured task based on an existing Task Template after a record reaches a certain condition.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_record` | integer | Object Record ID |
| `task_template` | integer | Task Template ID |

#### Important requirements

The selected Task Template determines the task behaviour. Use `search_task_templates` and `get_task_template` where the agent needs to identify or confirm the correct template.

This is a write action.

#### Typical output

The created Task or confirmation that the Task has been created.

### create\_manual\_task

Creates a new Manual Task against an Object Record.

#### Purpose

Use this tool when an agent needs to create a human-facing task with a name, instructions, and optional due date.

#### Typical use

An agent creates a review task for a lawyer after identifying a contract that needs human approval.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `object_record` | integer | Object Record ID |
| `task_template` | integer | Task Template ID |
| `name` | string | Task name, maximum 100 characters |

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `instructions` | string | Task instructions, maximum 5000 characters |
| `due_date` | string | Due date in ISO-8601 date format |

#### Example body

```json
{
  "object_record": 1001,
  "task_template": 25,
  "name": "Review supplier contract",
  "instructions": "Please review the non-standard liability provisions and confirm whether escalation is required.",
  "due_date": "2026-07-31"
}
```

#### Important requirements

This is a write action that creates work for a user or team.

The agent should use the correct Task Template and provide clear instructions.

#### Typical output

The created Task or confirmation that the Task has been created.

### get\_task

Retrieves current details, configuration, schema, and response data for a Task.

#### Purpose

Use this tool when an agent needs to inspect a task before saving or updating task data.

#### Typical use

An agent reviews the schema of a task form before saving a partial response.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `pk` | string | Task ID |

#### Important requirements

Use this tool before `save_task`.

The response contains important sections:

| Section | Meaning |
|---|---|
| `configuration.plugin_config.configuration.data_schema` | Defines allowed keys and value types for task data |
| `response` | Contains current task response values |

#### Typical output

Task details, form schema, current response data, and configuration information.

### get\_task\_template

Retrieves details for a single Task Template.

#### Purpose

Use this tool when an agent needs to inspect a known Task Template before creating a task.

#### Typical use

An agent checks the review task template before creating a manual task for a lawyer.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `pk` | string | Task Template ID |

#### Important requirements

The Task Template must exist and be visible to the agent.

#### Typical output

Details of the Task Template.

### save\_task

Saves or updates Task data while keeping the Task outstanding.

#### Purpose

Use this tool when an agent needs to store task form data without completing the task.

#### Typical use

An agent fills in part of a review task based on extracted information, leaving the task outstanding for a lawyer to check.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `task` | integer | Task ID |
| `data` | object | Flat, single-level dictionary containing task data |

#### Important requirements

The agent must call `get_task` first for the specific task ID.

The agent must inspect the task schema at `configuration.plugin_config.configuration.data_schema` to identify allowed keys and value types.

The agent must preserve existing data from `response` unless the user has explicitly asked to overwrite a specific field.

The submitted `data` object should be a complete merged dictionary, not just the changed fields.

#### Example pattern

1. Call `get_task`.
2. Read the schema.
3. Read the existing `response` data.
4. Modify only the requested values.
5. Submit the complete merged `data` object to `save_task`.

#### Important note

This tool saves task data. It does not complete the task.

#### Typical output

The updated task data or confirmation that the task has been saved.

### search\_task\_templates

Searches Task Templates matching the supplied criteria.

#### Purpose

Use this tool when an agent needs to find the right Task Template before creating a task.

#### Typical use

An agent searches for a legal review task template before creating a review task on a matter.

#### Required inputs

This tool can be called without a body. Filters are optional.

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `limit` | integer | Maximum number of results to return |
| `offset` | integer | Number of results to skip |
| `ordering` | string | Sort field, with `-` for descending order |
| `filters` | array | Filter objects with `name` and `value` |

#### Important requirements

This is a discovery tool. It does not create a task.

#### Typical output

A paginated list of Task Templates visible to the agent.

### search\_tasks

Searches Tasks matching the supplied criteria.

#### Purpose

Use this tool when an agent needs to find tasks by status, assignee, date, or other available filters.

#### Typical use

An agent finds overdue tasks assigned to a legal operations team.

#### Required inputs

This tool can be called without a body. Filters are optional.

#### Optional inputs

| Input | Type | Notes |
|---|---|---|
| `limit` | integer | Maximum number of results to return |
| `offset` | integer | Number of results to skip |
| `ordering` | string | Sort field, with `-` for descending order |
| `filters` | array | Filter objects with `name` and `value` |

#### Current assignee filters

The `current_assignees` field has a custom structure with `users` and `user_groups` sets.

Examples:

```json
{
  "filters": [
    {
      "name": "current_assignees__users__containssome",
      "value": "2,3"
    }
  ]
}
```

```json
{
  "filters": [
    {
      "name": "current_assignees__user_groups__containsall",
      "value": "5"
    }
  ]
}
```

#### Important requirements

Use filters to avoid broad task searches. Assignment, due date, status, and process-specific filters should be used where available.

#### Typical output

A paginated list of Tasks visible to the agent.

### unassign\_task\_from\_user\_groups

Removes one or more user group assignments from a Task.

#### Purpose

Use this tool when an agent needs to remove group assignment from a task.

#### Typical use

An agent removes the legal operations group from a task after assigning the task to a specific lawyer.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `task` | integer | Task ID |
| `user_groups` | array | Array of user group IDs |

#### Important requirements

This is a write action that changes task assignment.

The agent should verify that the correct task and groups have been identified before unassigning.

#### Typical output

Confirmation that the user groups have been unassigned.

### unassign\_task\_from\_users

Removes one or more user assignments from a Task.

#### Purpose

Use this tool when an agent needs to remove named users from a task assignment.

#### Typical use

An agent removes a user assignment after the task has been reassigned to a different lawyer or team.

#### Required inputs

| Input | Type | Notes |
|---|---|---|
| `task` | integer | Task ID |
| `users` | array | Array of user IDs |

#### Important requirements

This is a write action that changes task assignment.

The agent should verify that the correct task and users have been identified before unassigning.

#### Typical output

Confirmation that the users have been unassigned.

## Tool chaining examples

### Create a legal review task from a record

A typical agent flow might be:

1. Use `search_object_records` to find the relevant matter or intake record.
2. Use `get_object_record` to review the record.
3. Use `search_task_templates` to find the legal review Task Template.
4. Use `create_manual_task` to create the review task.
5. Use `assign_task_to_users` or `assign_task_to_user_groups` to assign the task.

### Generate and retrieve a document

A typical agent flow might be:

1. Use `get_object_record` to review the record.
2. Use `search_document_templates` to find the appropriate template.
3. Use `get_document_template` to confirm the template.
4. Use `generate_object_record_document` to start document generation.
5. Use `get_object_record_document` to check generation status.
6. Use `download_object_record_document` if the completed file needs to be retrieved.

### Create a record hierarchy

A typical agent flow might be:

1. Use `list_object_class_children` to discover allowed child classes.
2. Repeat child-class discovery for nested levels where needed.
3. Use `create_object_records_hierarchy` to start hierarchy creation.
4. Use `check_object_records_hierarchy_creation` until the transaction is `completed` or `failed`.

## Designing safe tool access

MCP Work tools can perform real actions. Access should be designed around the intended use case.

For each agent, decide:

* which tools the agent can use
* which Object Classes it can access
* whether it can read only or also write
* whether it can create records
* whether it can create or assign tasks
* whether it can generate or download documents
* whether relationship changes are permitted
* which actions need user confirmation
* which actions need human review after completion

Start with the smallest toolset that solves the problem. Add additional tools only where there is a clear operational need.

## Important reminder about agentic tool use

::: warning Important reminder
MCP Work tools can allow an agent to perform real actions in Autologyx.

Even where permissions, tool descriptions, prompts, and workflows have been carefully designed, an agent may misunderstand a request, select the wrong record, choose the wrong tool, or submit unexpected data.

Permissions, audit logging, validation, deterministic checks, user confirmations, and human review can reduce risk, but they cannot remove it entirely.

Use human review where an action affects important decisions, external communications, sensitive data, record updates, document generation, task assignment, or task completion.
:::

## Related pages

* [Autologyx MCP Work](/knowledgebase/applied-ai/mcp-services/mcp-work/)
* [Working with records through MCP Work](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/#record-tool-endpoints)
* [Working with tasks through MCP Work](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/#task-tool-endpoints)
* [How MCP Work tools are used together](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

---

---
url: >-
  /knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock.md
---

# AWS Bedrock

AWS Bedrock can be used in Autologyx workflows where a Sequence needs to call a foundation model through Amazon Web Services.

Bedrock is useful where customers want to use AI models through their AWS environment, apply their AWS governance and access controls, and choose from a range of model providers and model families. This can include Amazon models, Anthropic Claude models, Meta models, Mistral models, OpenAI models, and other models made available through Bedrock.

This article explains how AWS Bedrock fits into AI and the Sequencer, what the Bedrock actor is used for, and what customers need to consider when preparing their AWS environment.

## When to use AWS Bedrock

Use AWS Bedrock where you want a Sequence to call a model through AWS rather than through a direct public provider integration.

This is often useful where:

* the customer already uses AWS for AI governance or cloud services
* the organisation wants model access to be managed through AWS
* the workflow needs to use a model available through Bedrock
* Claude models are required through AWS Bedrock rather than a native Anthropic actor
* model choice needs to remain flexible across several providers
* the customer wants to align AI access with AWS account, region, and security controls
* the workflow needs a private-cloud or enterprise-controlled AI route

Bedrock can be a flexible option because the same general actor pattern can support different providers and models, depending on what has been enabled in AWS and in the Autologyx environment.

## Before you start

Before configuring AWS Bedrock in Autologyx, check that:

1. the AWS Bedrock integration is enabled in the Autologyx environment,
2. the customer has an AWS account with access to Amazon Bedrock,
3. the required model provider and model are available in the relevant AWS region,
4. model access has been enabled in AWS where required,
5. the required AWS authentication details are available through an Authentication Object,
6. you have permission to edit the relevant Sequence.

Model availability changes over time. Not every model is available in every AWS region, and some models require explicit access or setup in AWS before they can be used. Always check the latest AWS Bedrock documentation and the customer’s AWS console before finalising a workflow.

## How AWS Bedrock works with the Sequencer

With the Bedrock actor, Autologyx initiates the request as part of a controlled workflow.

A typical Sequence might:

1. collect data from an Object Record,
2. prepare the input text or prompt,
3. call a selected model through AWS Bedrock,
4. receive the model response,
5. store or parse the response,
6. update a record, create a task, generate a draft output, or route the workflow.

The Sequencer still controls when the request is made, what information is sent, and what happens when the response is returned. Bedrock provides the model access route.

## Bedrock model providers

The Bedrock actor groups available models by provider.

Provider options may include:

* **Amazon**
* **Anthropic**
* **Meta**
* **Mistral**
* **OpenAI**

The exact providers and models shown in the actor depend on the Autologyx integration, the AWS Bedrock configuration, the AWS region, and the models enabled for the customer. Customers should confirm current provider and model availability in AWS before designing or publishing a workflow.

AWS Bedrock itself supports a changing range of foundation models from different providers. Refer to AWS documentation and the customer’s AWS account for the current list of available models, regions, modalities, and model-specific configuration options.

## Where to find current AWS Bedrock information

AWS Bedrock model availability changes over time. New models may be added, existing models may change, and availability can vary by AWS region.

For the most up-to-date information, refer to AWS documentation before finalising a workflow design:

* [Amazon Bedrock product page](https://aws.amazon.com/bedrock/) - for a general overview of Bedrock, its capabilities, and AWS positioning
* [Amazon Bedrock overview](https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html) - for the AWS user guide overview and links to core Bedrock concepts
* [Supported foundation models in Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html) - for the current route into model details, model IDs, supported regions, modalities, and inference parameters
* [Request access to models](https://docs.aws.amazon.com/bedrock/latest/userguide/model-access.html) - for model access requirements, AWS Marketplace permissions, and provider-specific access steps

AWS describes Amazon Bedrock as a fully managed service that provides secure, enterprise-grade access to foundation models from leading AI companies. AWS also maintains current Bedrock model details outside static Autologyx documentation.

Autologyx documentation explains how Bedrock fits into AI and the Sequencer. AWS documentation should be treated as the source of truth for current Bedrock model availability, supported regions, model IDs, pricing, AWS-side setup, and provider-specific access requirements.

## Using Anthropic Claude through AWS Bedrock

Autologyx does not currently require a separate native Anthropic actor for the Sequencer pattern.

Where a customer wants to use Anthropic Claude models, the supported route is through AWS Bedrock, provided the customer’s AWS Bedrock environment has the relevant Anthropic model access enabled.

This means Claude can still be used in AI and the Sequencer workflows, but it is configured as an AWS Bedrock provider and model combination rather than as a separate Anthropic actor.

For example, the Bedrock actor may allow you to select:

* **Provider**: Anthropic
* **Model**: Claude 3.7 Sonnet or another available Claude model

![AWS Bedrock configuration modal showing Anthropic as the provider, Claude 3.7 Sonnet as the model, authentication object, message, system prompt, configurations, record ID, test integration, and save settings](/knowledgebase/images/aws-bedrock-anthropic-configuration-modal.png)

## Using Amazon models through AWS Bedrock

The Bedrock actor can also be used with Amazon model families where they are available in the customer’s AWS environment.

For example, the actor may allow you to select:

* **Provider**: Amazon
* **Model**: Nova Pro or another available Amazon model

![AWS Bedrock configuration modal showing Amazon as the provider, Nova Pro as the model, authentication object, input text, configurations, record ID, test integration, and save settings](/knowledgebase/images/aws-bedrock-amazon-configuration-modal.png)

Amazon models may be useful where a customer wants to use AWS-native model options for summarisation, classification, drafting, extraction, multimodal processing, or other AI-supported workflow steps.

## Bedrock Actor settings

The exact settings shown in the Bedrock actor can vary depending on the provider and model selected.

**Common settings include:**

### Provider

Select the model provider.

The provider determines which group of models is available in the **Model** field. Different providers may expose different configuration options.

### Model

Select the model that should process the request.

The model list depends on the selected provider, the customer’s AWS region, and the model access configured in AWS Bedrock.

Where available, the actor may display a description of the selected model to help explain what that model is commonly suited for. Use this as guidance, but choose the model based on the workflow goal, input type, expected output, performance requirements, cost profile, and customer AI policy.

### Auth Object

Select the Authentication Object used to authenticate the request to AWS Bedrock.

The Authentication Object should be configured to use the customer’s approved AWS authentication approach. The exact setup depends on the customer’s AWS security model and the Autologyx integration configuration.

### Message or input text

Use **Message** or **Input text** to provide the content that the model should process.

This can include static instructions, record data, extracted document text, email content, or a combination of text and Merge fields.

For example, a workflow might send a contract extract, matter description, inbound request, or document summary to the selected Bedrock model.

### System prompt

Some provider and model combinations include a **System prompt** field.

Use the system prompt to guide the model’s behaviour, role, tone, constraints, or output format. This is usually where you describe the model’s task at a higher level.

For example, the system prompt might tell the model to:

* act as a legal intake triage assistant
* return only valid JSON
* classify the request using a fixed list of categories
* flag uncertain results for human review
* avoid making assumptions where the source text is unclear

Not every provider or model combination exposes the same prompt structure. Always check the modal for the model you are configuring.

### Configurations

The **Configurations** section contains additional model-specific settings.

These settings may vary depending on the provider and model selected. Refer to the relevant AWS Bedrock documentation and the customer’s model configuration guidance before changing advanced settings.

### Record ID and Test Integration

Where the message, input text, or system prompt includes merge fields, enter a **Record ID** before testing.

Use **Test Integration** to confirm that the actor can resolve the record data, call the selected Bedrock model, and return a usable response.

Testing is especially important where the actor is expected to return structured data for later workflow processing.

## Preparing AWS Bedrock for use with Autologyx

Autologyx configuration teams do not usually configure the customer’s AWS account directly. However, it is useful to understand the general preparation steps that need to happen in AWS.

In principle, the customer or AWS administrator will need to:

1. choose the AWS account and region where Bedrock will be used,
2. confirm that Amazon Bedrock is available in that region,
3. enable access to the required model providers and models,
4. configure AWS identity and access controls for Bedrock use,
5. create or approve the credentials or access method that Autologyx will use,
6. confirm any customer policies for prompts, data sharing, logging, retention, and model use,
7. provide the required authentication details for configuration in Autologyx,
8. test the connection from the Bedrock actor before using it in production workflows.

Customers should refer to AWS documentation for the detailed Bedrock setup steps, including model access, supported regions, inference options, provider-specific configuration, and AWS security controls.

## Choosing a Bedrock model

Different Bedrock models are suited to different tasks.

When choosing a model, consider:

* the type of input being sent
* the expected output format
* whether the task is summarisation, classification, extraction, drafting, reasoning, coding, or multimodal processing
* the size of the input
* the required response quality
* latency and cost
* regional availability
* customer policy requirements
* whether the output will be reviewed by a human

The model selected for a workflow should reflect the business task, not just the provider preference. For example, one model may be more appropriate for summarising long text, while another may be better suited to classification, structured extraction, or multimodal analysis.

## Structured outputs and deterministic processing

Bedrock model responses are most useful in Autologyx when they can be brought back into the workflow as structured data.

Where possible, design prompts so the model returns a predictable structure. For example:

```json
{
  "classification": "human_review",
  "summary": "The request appears to relate to a supplier contract review.",
  "recommended_next_step": "Create a legal review task",
  "confidence": "medium"
}
```

A structured response makes it easier for the Sequencer to apply deterministic checks.

For example, a Sequence can check whether `classification` matches an expected value before deciding which route to follow. If the response is missing, unexpected, or uncertain, the workflow can create a task for human review.

This pattern is particularly useful where Bedrock is being used to support triage, intake, contract review, document analysis, or other workflow decisions.

## Important reminder about model outputs

::: warning Important reminder
Bedrock provides access to foundation models, but model responses are not deterministic in the same way as conventional workflow logic.

Prompt design, model choice, structured JSON, low-temperature or equivalent settings, validation rules, and deterministic Sequence logic can reduce risk, but they cannot absolutely guarantee that a model will always return a perfect, complete, or accurate response.

Where the model returns a specific structured value, the Sequencer can often apply deterministic checks to decide whether the value is acceptable. Where the model produces semantic output, such as a narrative summary, interpretation, or recommendation, customers should strongly consider human review before the output is used for important decisions, external communications, or final record updates.
:::

## Things to remember

1. AWS Bedrock is the main route for using Anthropic Claude models in AI and the Sequencer.
2. The Bedrock actor can support several provider and model combinations, depending on the customer’s AWS and Autologyx configuration.
3. Provider and model availability varies by AWS region and changes over time.
4. Customers should check AWS documentation and their AWS console for the latest model availability and setup requirements.
5. Different providers and models may expose different configuration options.
6. Use **Test Integration** with a representative record before relying on the actor in a live workflow.
7. Prefer structured outputs where the response will drive routing, record updates, or task creation.
8. Use human review where outputs are semantic, high impact, externally visible, or difficult to validate automatically.

---

---
url: /knowledgebase/system-configuration/integrations/aws-bedrock-integration.md
---

# AWS Bedrock integration

The AWS Bedrock integration allows Catalyst workflows to use multiple AI providers through Amazon Bedrock.

Supported providers may include:

* Amazon Nova
* Anthropic Claude
* Meta Llama
* Mistral AI

![Sequence showing Bedrock actor](/knowledgebase/images/sys-config/int-bedrock.gif)

This allows organisations to choose different AI models for different workflow requirements.

## Typical use cases

AWS Bedrock models can be used for:

* contract analysis
* document summarisation
* legal research
* AI-assisted review
* compliance analysis
* document categorisation
* workflow automation
* risk assessment

## Configurable AI parameters

The AWS Bedrock actor supports configuration of:

* temperature
* Top P
* Top K
* maximum length
* stop sequences

These settings help control:

* creativity
* predictability
* response length
* formatting consistency
* output structure

## Choosing the right model

Different models may be better suited to different tasks.

Examples include:

* Claude for factual consistency
* Nova for contract analysis
* Llama for reasoning tasks
* Mistral for high-speed document processing

## Things to remember

* Available models depend on your AWS Bedrock configuration.
* Different models may produce different outputs for the same prompt.
* Lower temperature settings typically produce more predictable responses.
* AI outputs should be reviewed before operational use.

---

---
url: /knowledgebase/release-notes/release-notes-1.11/aws-bedrock-integration.md
---

# AWS: Bedrock integration

**AI choice matters** — and now you have it all. Our AWS Bedrock actor brings Amazon, Anthropic, Meta, and Mistral AI models together in one powerful actor, ending the 'one-size-fits-all' approach to AI-powered automation. No longer restricted to a single provider's capabilities, you can now select the perfect AI model for each specific task, whether you need Amazon's Nova for contract analysis, Claude's factual consistency for legal research, Llama 3's reasoning prowess, or Mistral's lightning-fast document processing.

![Bedrock\_article.gif](/knowledgebase/images/img_4701868046239_1776895608.png)

## Available models

**Amazon’s Nova models** are among the most advanced, designed for legal text analysis, contract automation, and compliance monitoring. With strong reasoning capabilities and efficient processing, they’re ideal for:

* Extracting key clauses from long contracts
* Summarising regulatory documents
* Automating legal risk assessments

**Claude models** are known for factual consistency and deep understanding, making them a great choice for:

* Drafting contracts with minimal human input
* Legal research, where accuracy is crucial
* Redlining documents, catching ambiguous clauses before they become a liability

**Meta’s Llama 3 models** are built for complex reasoning and structured text generation, making them well-suited for:

* Generating detailed legal summaries
* Supporting legal chatbots and contract automation
* Enhancing document review processes with AI-assisted insights

**Mistral AI** delivers cutting-edge, open-weight models designed for efficiency and performance, making them a strong choice for AI-powered contract analysis and legal automation. Known for their speed and adaptability, these models excel in:

* Automating legal document categorisation, quickly classifying contracts and compliance records
* Generating precise risk assessments, flagging potential issues in agreements with minimal manual intervention
* Enhancing workflow automation, ensuring that contract reviews and compliance processes remain fast and accurate

![Bedrock2\_article.gif](/knowledgebase/images/img_4701868046239_1776895609.png)

## Model configuration

**Fine-tune model behaviour** with key parameters to ensure the right output for your use case.

### Temperature

Controls randomness in responses.

* **Lower values (e.g., 0.2)** make AI more deterministic - great for legal and compliance workflows where accuracy is key.
* **Higher values (e.g., 0.8)** make AI more creative, useful for brainstorming contract clauses or summarising content in different styles.

### Top P & Top K

Fine-tunes response diversity.

* **Top P (nucleus sampling)** defines how diverse the AI’s response can be by considering only the most probable words. When drafting formal documents, keeping Top P low ensures responses remain formal and structured.
* **Top K** sets a limit on the number of top words the AI can pick from - lower values make outputs more predictable.

### Maximum Length

Prevents overly long outputs. Essential for controlling response size, especially when summarising contracts or generating reports.

### Stop Sequences

Defines where the AI should stop generating text. Helps in workflows where responses need a **specific format**, such as structured contract clauses or predefined summaries.

## Summary

This AWS Bedrock integration fundamentally changes how you'll approach AI in your business processes. The days of compromising or building complex workarounds to accommodate a single model's limitations are over. Now you can match each workflow to its ideal AI partner, fine-tune every parameter to your exact requirements, and build truly intelligent automation that adapts to your needs rather than forcing you to adapt to it. Your AI toolkit just expanded dramatically - the only question is which model you'll put to work first.

---

---
url: >-
  /knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai.md
---

# Azure OpenAI

Azure OpenAI can be used in Autologyx workflows where a Sequence needs to call an OpenAI model that is hosted through a customer’s Azure environment.

This is similar in purpose to the OpenAI actor, but the model call is made through an Azure OpenAI endpoint rather than directly through the public OpenAI API. This can be useful where a customer wants to use OpenAI models while applying Azure-based resource management, authentication, monitoring, networking, governance, and enterprise controls.

This article explains how Azure OpenAI fits into AI and the Sequencer, what the Azure OpenAI actor is used for, and what customers need to consider when preparing their Azure environment.

## When to use Azure OpenAI

Use Azure OpenAI where you want a Sequence to use OpenAI models through Azure.

This is often useful where:

* the customer already uses Microsoft Azure for cloud services or AI governance
* the organisation wants OpenAI model access to be managed through Azure resources
* Azure networking, identity, monitoring, policy, or regional controls are required
* the customer has an approved Azure OpenAI deployment
* the workflow needs to use a GPT-style chat model hosted through Azure OpenAI
* the customer wants an enterprise-approved route to OpenAI models
* the workflow needs a private-cloud or Azure-controlled AI access route

Azure OpenAI can be a good fit where the customer wants the capabilities of OpenAI models, but wants the operational and governance model to sit inside Azure.

## Before you start

Before configuring Azure OpenAI in Autologyx, check that:

1. the Azure OpenAI integration is enabled in the Autologyx environment,
2. the customer has an Azure subscription with access to Azure OpenAI,
3. the relevant Azure OpenAI resource and model deployment have been created,
4. the Azure OpenAI endpoint is available,
5. the required authentication details are available through an Authentication Object,
6. you have permission to edit the relevant Sequence.

Model availability, deployment options, quotas, and regional availability can change over time. Always check Microsoft documentation and the customer’s Azure configuration before finalising a workflow.

## How Azure OpenAI works with the Sequencer

With the Azure OpenAI actor, Autologyx initiates the request as part of a controlled workflow.

A typical Sequence might:

1. collect data from an Object Record,
2. prepare the prompt or input text,
3. call a selected Azure OpenAI model deployment,
4. receive the model response,
5. store or parse the response,
6. update a record, create a task, generate a draft output, or route the workflow.

The Sequencer still controls when the request is made, what information is sent, and what happens when the response is returned. Azure OpenAI provides the Azure-hosted model access route.

## Azure OpenAI is not the same as Azure AI Foundry model hosting

This page covers the Azure OpenAI actor in the Sequencer.

The Azure OpenAI actor is designed for OpenAI models that are exposed through an Azure OpenAI endpoint. It is not a general-purpose actor for every model or service that may be available through Azure AI Foundry.

For other private or customer-hosted models, use the guidance for privately hosted models or generic API-based integration patterns.

## Why customers may choose Azure OpenAI

Customers may choose Azure OpenAI instead of calling OpenAI APIs directly where their organisation prefers to manage AI access through Azure.

**Common reasons include:**

* existing Azure cloud strategy
* Azure identity and access management patterns
* Azure networking or private connectivity requirements
* Azure monitoring and logging expectations
* regional or resource-level control
* enterprise governance and policy alignment
* procurement, billing, or operational preference for Azure services
* approved internal patterns for using OpenAI models through Azure

The right choice depends on the customer’s cloud strategy, security model, AI governance requirements, data handling policies, and the models available in the target Azure environment.

## Where to find current Azure OpenAI information

Azure OpenAI model availability and setup requirements change over time. New models may be added, deployment types may change, and availability can vary by region, subscription, quota, and cloud.

For the most up-to-date information, refer to Microsoft documentation before finalising a workflow design:

* [Azure OpenAI in Microsoft Foundry Models](https://learn.microsoft.com/en-us/azure/ai-services/openai/overview) - for the Microsoft overview and current product documentation route
* [Azure OpenAI models](https://learn.microsoft.com/en-us/azure/ai-services/openai/concepts/models) - for model capabilities, model IDs, deployment types, and region availability
* [Azure OpenAI quotas and limits](https://learn.microsoft.com/en-us/azure/ai-services/openai/quotas-limits) - for current quota and rate-limit guidance
* [Data, privacy, and security for Azure OpenAI](https://learn.microsoft.com/en-us/legal/cognitive-services/openai/data-privacy) - for Microsoft’s current data privacy and security information

Autologyx documentation explains how Azure OpenAI fits into AI and the Sequencer. Microsoft documentation should be treated as the source of truth for current model availability, supported regions, model IDs, quotas, pricing, Azure-side setup, and Microsoft data handling details.

## Configure the Azure OpenAI actor

Add the actor to a Sequence in the same way as other Sequence actors.

1. Go to **System Configuration** > **Sequences**.
2. Open the Sequence you want to update.
3. Find the Azure OpenAI actor in the relevant actor category.
4. Drag the actor onto the Sequence canvas.
5. Connect it to the appropriate trigger or workflow step.
6. Open the actor configuration.

The exact labels available in your environment may depend on the integration version and enabled actors.

## Azure OpenAI actor settings

The Azure OpenAI configuration modal allows you to define the endpoint, model type, model, authentication, prompt, context, temperature, and test record.

![Azure OpenAI configuration modal showing endpoint, model type, model, authentication object, prompt, context, temperature, record ID, test Azure OpenAI, and save settings](/knowledgebase/images/azure-openai-configuration-modal.png)

### Endpoint

Enter the Azure OpenAI endpoint for the customer’s Azure OpenAI resource.

The endpoint normally follows the customer’s Azure OpenAI resource name and Azure domain pattern. Use the endpoint provided by the customer’s Azure administrator or implementation team.

### Model Type

Select the type of model interaction required.

For example, **Chat** is used where the workflow needs to send a prompt to a chat model and use the model response inside the Sequence.

The available model types depend on the integration and customer configuration.

### Model

Select the Azure OpenAI model that the actor should use.

The available model list depends on the models enabled for the customer’s Azure environment and the deployments configured for the Azure OpenAI resource.

Where available, the modal may show a short description of the selected model to help explain what that model is commonly suited for. Use this as guidance, but choose the model based on the workflow goal, expected input size, response type, cost profile, Azure availability, and customer AI policy.

### Auth Object

Select the Authentication Object used to authenticate the request to Azure OpenAI.

This allows the Sequence to make the request without exposing credentials inside the actor configuration.

### Prompt

The prompt is the main instruction that will be sent to the model.

A prompt can contain static text and Merge fields from the record being processed. This allows each request to be tailored to the specific Object Record in the workflow.

For example, a prompt could include the body of an inbound email, such as {{ record.field\_email\_body }}, so that the model can summarise or classify the content in the context of the current record.

### Context

Context can be used to give the model additional guidance about how to respond.

Context is optional. Use it where the model needs additional instructions that should sit alongside the prompt. If the workflow does not need separate context, keep the prompt focused.

For example, the context might explain:

* the role the model should perform
* the type of work being processed
* the categories the model can choose from
* the expected output format
* when the model should flag something for human review

For workflow use cases, context is often where you define guardrails for the response.

### Temperature

Temperature controls how varied or creative the model response can be.

Lower values are usually better for workflow automation because they make the output more focused and consistent. Higher values may be useful for creative drafting tasks, but they are usually less suitable where the response needs to be parsed or used by later deterministic workflow logic.

The modal guidance explains that lower values, such as `0.2`, make responses more focused and more consistent, while higher values, such as `0.8`, make responses more creative and varied.

### Record ID and Test Azure OpenAI

Where the prompt or context includes merge fields, enter a **Record ID** before testing. This allows the actor to resolve record-specific values during the test.

Use **Test Azure OpenAI** to test the request before saving. This helps you check the request and response using real record data before relying on the actor in a live workflow.

Click **Save** to save the actor configuration. Remember to save the Sequence itself after updating the actor.

## Use Azure OpenAI responses in the Sequence

The Azure OpenAI actor response is most useful when it is stored or transformed into data that later Sequence steps can use.

**Common patterns include:**

* storing the response in a variable
* extracting part of a JSON response
* updating fields on the source record
* creating a task for human review
* sending the result into a document or message
* using the response to decide the next workflow route

For JSON responses, a Local Variable actor can be used to store or extract the content returned by the Azure OpenAI actor.

The exact response path depends on the actor, endpoint, model type, and response structure being used.

## JSON outputs and deterministic processing

Azure OpenAI calls are often most useful in Autologyx when the response can be turned into structured data.

For example, a model might be asked to return JSON with fields such as:

```json
{
  "classification": "human_review",
  "summary": "The email appears to request review of a supplier contract.",
  "recommended_next_step": "Create a legal review task",
  "confidence": "medium"
}
```

This can make it easier for the Sequence to apply deterministic checks after the model has responded.

For example, the Sequence can check whether `classification` is one of a known set of values before deciding what happens next. It can also send uncertain, incomplete, or unexpected responses to a human review task.

**This approach is especially useful when combined with:**

* clear prompt instructions
* constrained output schemas
* validation logic
* known allowed values
* Local Variable actors
* API response parsing
* human review gates

## Important reminder about model outputs

::: warning Important reminder
Azure OpenAI model responses are not deterministic in the same way as conventional workflow logic.

Prompt design, structured JSON, low temperature settings, validation rules, and deterministic Sequence logic can reduce risk, but they cannot absolutely guarantee that a model will always return a perfect, complete, or accurate response.

Where the model returns a specific structured value, the Sequencer can often apply deterministic checks to decide whether the value is acceptable. Where the model produces semantic output, such as a narrative summary, interpretation, or recommendation, customers should strongly consider human review before the output is used for important decisions, external communications, or final record updates.
:::

## Things to remember

1. Azure OpenAI is for OpenAI models exposed through a customer’s Azure OpenAI endpoint.
2. The Azure OpenAI actor is not a general-purpose actor for every model hosted through Azure AI Foundry.
3. Customers may choose Azure OpenAI where Azure-based governance, identity, networking, monitoring, or regional controls are important.
4. Model availability, deployment types, quotas, and regions can change over time.
5. Microsoft documentation should be treated as the source of truth for Azure-side setup and current model availability.
6. Use **Test Azure OpenAI** with a representative record before relying on the actor in a live workflow.
7. Prefer structured outputs where the response will drive routing, record updates, or task creation.
8. Use human review where outputs are semantic, high impact, externally visible, or difficult to validate automatically.

---

---
url: /knowledgebase/release-notes/release-notes-1.11/azure-openai-integration.md
---

# Azure OpenAI integration

The power of OpenAI's latest models is now at your fingertips with Azure OpenAI actor in Catalyst - this integration provides a simple, scalable, and enterprise-ready solution.

With support for OpenAI’s most advanced models, you can leverage cutting-edge AI capabilities directly within your business processes. Plus, full compatibility with Azure OpenAI Service means you can use both standard models and your own custom deployments, giving you maximum flexibility.

![AzureOpenAI1\_article.gif](../../../images2/zendesk_4702059841567_001_8cdc924bb484.gif)

## Chat models

**OpenAI’s latest chat models** are designed to handle complex reasoning, generate high-quality responses, and support real-time interactions.

**Ideal for:**

* Customer service automation – AI-powered virtual assistants and chatbots for instant query resolution.
* Document drafting & summarisation – automate contract generation, policy explanations, and legal document reviews.
* Knowledge retrieval – seamless integration with databases for AI-powered insights and internal knowledge management.

**Supported models:** GPT-4o, GPT-4o mini, GPT-4, GPT-3.5 Turbo, o1, o1-mini

## Instruct models

For businesses requiring precise, instruction-following AI, **Instruct models** excel in structured input-output tasks.

**Ideal for:**

* Process automation – AI-driven workflows for compliance checks, policy analysis, and regulatory document processing.
* Decision support – AI-powered data interpretation, risk analysis, and financial forecasting.
* Content generation – generating reports, summaries, and structured responses tailored to business needs.

**Supported models:** GPT-3.5 Turbo Instruct

![AzureOpenAI2\_article.gif](../../../images2/zendesk_4702059841567_002_c6c145b54078.gif)

## Embedding models

**Embedding models** convert text into numerical vectors.

**This enables:**

* AI-driven search – more relevant and intelligent search results based on contextual meaning rather than keywords.
* Recommendation engines – personalising customer experiences by understanding user behaviour and preferences.
* Data classification & clustering – automatically organising large volumes of unstructured data for deeper insights.

**Supported models:** text-embedding-3-large, text-embedding-3-small, text-embedding-ada-002

![AzureOpenAI3\_article.gif](../../../images2/zendesk_4702059841567_003_4e655242b01b.gif)

## Configuration

Setting up Azure OpenAI Actor in Catalyst is straightforward, allowing businesses to tailor AI capabilities to their specific needs.

**Endpoint:** The endpoint field defines where requests are sent, ensuring seamless communication with Azure’s API.

**Model type:** Choosing the model type - Chat, Instruct, or Embeddings - determines how AI will process the input, whether it’s generating conversational responses, executing task-specific instructions, or transforming text into vector representations.

**Specific model:** Once the model type is set, a specific model needs to be specified - either from the supported list or a custom model deployed in the Azure OpenAI Service.

**Authentication:** Authentication is handled through the Authentication Object, ensuring secure access to the selected model.

**Prompt and context:** For **Chat and Instruct models**, the **prompt** and **context** fields shape the AI’s responses, allowing users to provide relevant details or set constraints.

**Additional parameters:** Additional parameters, like **temperature**, help fine-tune outputs - higher values generate more diverse responses, while lower values keep them precise and predictable.

**Embeddings-specific fields:** With **Embeddings models**, instead of a prompt, users enter the text input to be converted into numerical vectors. The configuration also includes **encoding format**, which dictates how text is processed, and **vector dimensions**, allowing businesses to optimise search accuracy and similarity matching.

**User parameter:** A user parameter can be specified for tracking or personalisation, ensuring that AI outputs are contextually relevant.

## Availability and outcome

**Availability:** This integration is available for customers with this feature enabled. If your organisation is leveraging Azure OpenAI Service, you can now unlock the full potential of AI in your business operations with minimal setup.

**Outcome:** The Azure OpenAI actor marks a turning point in how businesses can apply AI to their operations. With a straightforward setup, flexible model options, and enterprise-grade security through Azure, you're now equipped to transform customer interactions, automate document processing, and extract insights from mountains of data - all while keeping your information within your secure environment. The AI revolution is here in Catalyst, ready for you to put it to work.

---

---
url: /knowledgebase/system-configuration/integrations/azure-openai-integration.md
---

# Azure OpenAI integration

The Azure OpenAI integration allows organisations to use Azure-hosted OpenAI models directly inside Catalyst workflows.

This integration supports enterprise AI workflows while allowing organisations to use their own Azure OpenAI Service deployments.

![Sequence showing Azure OpenAI actor](/knowledgebase/images/sys-config/int-azureopenai.gif)

## Supported model types

Supported model categories include:

* Chat models
* Instruct models
* Embedding models

Supported models may include:

* GPT-4o
* GPT-4o mini
* GPT-4
* GPT-3.5 Turbo
* GPT-3.5 Turbo Instruct
* text-embedding-3-large
* text-embedding-3-small

## Configure the Azure OpenAI actor

Configuration options include:

* endpoint
* model type
* model selection
* custom deployments
* Authentication Objects
* prompts
* context
* temperature
* encoding format
* vector dimensions

![Azure OpenAI actor configuration page](/knowledgebase/images/sys-config-int-azure-open-ai-1.gif)

## Typical use cases

Azure OpenAI can be used for:

* AI-powered customer service
* document drafting
* document summarisation
* semantic search
* workflow automation
* policy analysis
* risk analysis
* recommendation systems

## Things to remember

* Azure OpenAI Service access is required.
* Supported models depend on your Azure deployment.
* Temperature settings affect response predictability.
* Embedding models use vector representations instead of conversational responses.

---

---
url: /knowledgebase/release-notes/release-notes-1.10/bug-fixes-and-improvements.md
---

# Bug fixes and improvements

Quality and reliability sit at the heart of every great platform. In our latest release, we've tackled over 100 issues head-on, delivering significant improvements across every aspect of the platform. From enhanced debugging capabilities to powerful new API endpoints, this update reinforces our commitment to excellence.

## 🛠️ Core Platform Enhancements

### **Enhanced Error Visibility**

The days of mysterious "Something went wrong" messages are behind us. Users can now click "Show details" to access comprehensive error information, including:

* App version
* Exact error location
* URL and error code
* Detailed backend message
* One-click copy feature for all error details

This granular insight helps users quickly diagnose issues or share precise information with our Client Value team for faster resolution.

### **Database Performance Boost**

We've upgraded our PostgreSQL RDS to version 16, bringing:

* Improved query performance
* Enhanced data security
* Better resource utilisation
* Increased stability for large-scale operations

## 🔌 API Updates

### **Personal Authentication Objects**

Our new Personal Authentication Object API enables developers to create user-specific authentication tokens for each integrated service. This game-changing feature opens up possibilities for:

* Building personalised multi-service workflows
* Creating secure user-specific integrations
* Implementing granular access control across services
* Developing custom authentication flows for different user roles

### **New API Capabilities**

* **Detailed error information:** when document generation fails (via the GET `/api/object-records/object_record_id/documents/document_template_id/` endpoint), detailed error or warning messages are displayed, providing clear guidance on resolving issues.
* **Sorting enhancement:** results from the GET `/api/object-models/1/object-records/${recordId}/children/` endpoint can now be ordered using the `show_fields` parameter.
* **Listing parent records:** the list of parent records using the new endpoint GET `/api/object-models/id/object-records/{child_record_id}/parents/` can now be retrieved.
* **Search in User Groups API:** introducing search capability in GET `/api/user-groups/id/users/`, making it easier to locate users within groups.

## 🎯 Sequencer Improvements

We've significantly enhanced the Sequencer's reliability and usability:

* Ensured trigger conditions load all available options and function correctly
* Disabled Sequencer actors from being moved when not in Edit Mode
* Standardised the display of checkbox static values in Sequencer configurations
* Added detailed formatting requirements information for all value types in the Local Variable Actor
* Removed non-functional trigger condition combinations to simplify configurations
* Made sure API call tests use updated Authentication Objects
* Improved Document type field configuration — the "Update Record" actor now supports clearing document type fields, offering more flexibility in managing records

## 💻 UI Refinements

The user interface received numerous stability improvements, including:

* Displaying identifier values in side panels when set
* Ensuring child components always display accurate information
* Correctly filtering after returning to a listing page with applied filters
* Handling object record lists when the `object.classes_list` permission is revoked
* Automatic updates to the summary panel after uploading a document
* Correctly displaying videos on the Landing Page
* Handling filtering with non-existent options for Single and Multi-select fields

Each of these 100+ fixes and improvements may seem like a small step, but together they represent a giant leap in platform reliability and user experience. From developers crafting complex integrations with our enhanced API suite to business users benefiting from crystal-clear error messages, every enhancement was purpose-built to make your daily operations smoother. We've turned your feedback into actionable improvements, transforming common frustrations into powerful solutions. The platform you trust just got more robust, more intuitive, and more capable of supporting your automation journey.

---

---
url: /knowledgebase/release-notes/release-notes-1.11/bug-fixes-and-improvements.md
---

# Bug fixes and improvements

In this release, our primary focus has been on **performance enhancements** and **security improvements**, knowing that these are top priorities for our customers. Additionally, to reduce manual configuration efforts and automate workflows even further, we are introducing Constants.

## Constants

Managing environment-specific values can be cumbersome and error-prone, especially when dealing with configuration migrations. Consider the case of API Calls in a Sequencer - each request refers to an environment-specific URL. In the development environment, the API call points to a test server. Traditionally, when moving to production, each reference had to be manually updated.

**With Constants, you can:**

* Define a **constant** in the **Resource Database** (e.g., `TEST_API_URL` = `https://test.example.com`).
* Reference the constant in the Sequencer’s API call.
* After migrating to production, update only the constant (`TEST_API_URL` → `https://api.example.com`).
* No need to manually modify every API request.

### Create a constant

A new constant can be created directly in the **Resource Database** using the following schema:

* `name` (string, required, max: 255 characters)
  * Must be **unique**.
  * Used to reference the constant in sequences.
* `description` (string, optional, max: 500 characters)
  * For internal documentation purposes.
* `data_type` (enum, required)
  * Currently supports: `string`.
* `value` (string, required, max: 255 characters)
  * The actual value that will be stored.

### Naming rules

To ensure consistency and proper migration, constants must follow strict naming rules:

* Allowed characters:
  * **Uppercase ASCII letters** (`A-Z`)
  * **Digits** (`0-9`)
  * **Underscores** (`_`)
* Must **contain at least one letter** (`A-Z`).
* Cannot **start with a digit**.

### Migration behavior

Constants are migrated based on their name. Existing constants in the target environment are **not overwritten** - if a constant already exists, its value remains unchanged. Deleted constants in development are **not removed** from the target environment.

### Referencing constants

Constants can be referenced in the Sequence Designer using:

```
{{constants.<CONSTANT_NAME>}}
```

We support using constants in the API Call Actor fields:

* URL
* Parameters

## Additional improvements

We’ve addressed multiple security vulnerabilities to enhance system protection and ensure a more resilient infrastructure. Alongside these security fixes, significant performance optimisations have been implemented to improve system responsiveness and scalability, particularly in operations involving user and group management. These improvements contribute to a faster, more efficient, and more secure platform for all users.

---

---
url: /knowledgebase/release-notes/release-notes-1.13/bug-fixes-and-improvements.md
---

# Bug fixes and improvements

Behind every smooth workflow lies a collection of thoughtful improvements you might never notice, until they save you time, protect your data, or simply make everything work better. This update focuses on those essential refinements that strengthen the Catalyst platform from the ground up.

### Trivy issues cleanup

We’ve completed a major sweep of security flags detected by Trivy, our vulnerability scanner, and resolved every actionable issue. From package-level risks to container image flags, we’ve tightened the hatches to ensure your data and infrastructure stay secure.

You won’t see it in the UI, but you’ll definitely feel the safety net.

### Antivirus scanning for every upload

Now, every document uploaded into the system, by users or via integrations, goes through automated antivirus scanning. If it looks suspicious, it’s blocked. That applies across API uploads, UI interactions, and background processes.

There’s no manual step required. Just seamless protection, built in.

### Constants available in Sequencer

Your constants - the small, reusable values stored directly in the database - are now fully usable inside the Sequencer via context menus. No more guesswork or manual typing.

**Use constants in:**

* **API Call**: URL, Parameters
* **Local Variable**: Value
* **Send Message**: Recipients, Subject, Message
* **OpenAI GPT**: Prompt, Context
* **OpenAI Embeddings**: Input

On execution, each constant’s value is injected automatically wherever it’s referenced. Clean, predictable, and incredibly useful for versioned endpoints, shared tokens, and consistent messaging.

### Activity log hidden from External users

External-type users no longer have access to the Activity Log. Why? Because that log exposes the entire record history, including system-level and sensitive user actions.

Restricting this view helps protect workflows from overexposure and keeps sensitive interactions internal-only. Internal teams still see everything. External collaborators see only what they need.

### Field IDs in the Class fields list

We now show the Field ID directly in the Class field list view. No need to open each field or go hunting in developer tools - just glance and grab.

It’s a small detail, but it means less clicking and more clarity when building dynamic workflows.

### No limit in Document Picker

Previously, the Document Picker actor would only pass through the first five files - whether pulled from a field or via API response. That limit has now been removed.

You can now process as many documents as the field or source allows, opening the door to more powerful automation.

#### A word of caution

Catalyst still has built-in limits for the maximum number of documents in a field, and external services (like DocuSign, iManage, etc.) may also enforce file upload limits. Always test complex flows with large document sets before going live.

### Testing improvements for Local Variables and API Calls

We’ve also extended our testing tools to cover two long-requested capabilities.

**First:** **Local Variables** are now fully testable inside the Sequencer, meaning you can finally preview their runtime values without running an entire flow.

**Second:** **API Calls** that rely on files can now be tested with real document inputs. In the testing section, you can select any *document field* from the object class and use one of its files as a sample upload. This lets you see exactly how your request will behave with real data - headers, payload, multipart structures, and all - before the sequence ever goes live.

![variable test .gif](../../../images2/zendesk_4916231661727_001_45fa693787c4.gif)

### Smarter error handling for Sequences

And finally, one of our favourite quality-of-life upgrades to date.

When a configured actor refers to a deleted or invalid resource (user, user group, permission set, etc.), the system now:

* **Flags** the actor in the Sequencer with a warning icon
* **Highlights** the broken field(s) in red when you open the configuration modal
* **Clearly shows** which option is missing or invalid
* **Prevents saving** until the issue is fixed

No more digging or silent failures. Especially useful for long, complex sequences with dozens of actors. Broken configs now jump out at you, right where they should.

![Step-by-step instruction](../../../images2/zendesk_4916231661727_002_31477610dda6.gif)

Please read about [Invalid Actors and Best Practice.](/knowledgebase/system-configuration/sequence-actors/invalid-actors-and-best-practice/)

These updates represent our commitment to building a platform that grows more reliable and intuitive with each release. Your workflows now run on stronger foundations, with better security, clearer visibility, and fewer friction points standing between you and the automation you need.

Keep building, keep experimenting, and let us know how these improvements serve your projects.

---

---
url: /knowledgebase/release-notes/release-notes-1.2/bug-fixes-and-improvements.md
---

# Bug fixes and improvements

We've been working hard to make Autologyx smoother and faster than ever before, so you can get more done and save tons of time.

## **Performance improvements**

We have focused on performance improvements, so you can keep working at lightning speed.

## **Form builder enhancements**

Our Form builder got some upgrades too, with several new enhancements that make it even easier to create forms exactly how you want them.

## **Data integrity and security**

We understand how important it is to keep your information secure, which is why we've taken extra steps to ensure that your valuable data is always protected. You can rest assured that your information is safe and sound with our new and improved data integrity measures.

## **New features**

We've also added some new features to make your life easier. For example, you can now trigger a Sequence by another Sequence, and you can even trigger Sequences when a related Record is updated.

## **Bug fixes**

And of course, we've fixed a bunch of bugs that were causing headaches for our users. We know how frustrating bugs can be, so we made sure to tackle them head-on and squash them for good.

We're always working to improve Autologyx, so you can focus on what really matters: getting stuff done!

So go ahead and dive into the Autologyx platform to see the difference for yourself!

---

---
url: /knowledgebase/release-notes/release-notes-1.3/bug-fixes-and-improvements.md
---

# Bug fixes and improvements

With this release, we are bringing you another round of updates that are set to take your experience with our platform to new heights. We've tackled a series of bugs and made key improvements to ensure your Autologyx journey is even more seamless and efficient.

## Updates in this release

### **Object model permissions**

We've addressed an issue that was hindering users with "edit object model" permission from viewing Object Classes. Now, you can navigate and modify with absolute ease.

### **Tasks list performance**

We've also improved our tasks list requests for standard users. Say goodbye to waiting over a second for your tasks list to populate.

### **File downloads**

Encountered issues downloading files with the U+2014 character in the filename? This bug has been fixed, ensuring smooth downloads for all your files.

### **Sequencer improvements**

We've fine-tuned the Sequencer triggers by eliminating the redundant predicates and conditions.

### **Set task actor configuration**

Long task template names causing a stir in your set task actor configuration? We've ironed out this wrinkle.

### **Additional enhancements**

We've rolled out a range of other enhancements, including:

* refining user preferences
* correcting role permissions for the Relational modeller
* improving the display of child record control in Create/Edit record view
* resolving several quirks with the Records list, including column configuration resets and selection changes on the Record access panel

We're confident these updates will elevate your Autologyx experience. Dive in and explore the improvements.

---

---
url: /knowledgebase/release-notes/release-notes-1.8/bug-fixes-and-improvements.md
---

# Bug fixes and improvements

In our latest release, we've fine-tuned the Catalyst experience with a series of enhancements and bug fixes. Below is a snapshot of the key improvements and resolutions.

## Key improvements and resolutions

* 👥 **User Groups usage panel**: Explore a new, intuitive usage display for User Groups used in Send Message Actors, and enjoy the added assurance of preventing their accidental deletion.

* 🔗 **Optimising sequence connections**: The Document Picker actor features the "Combine" option, providing you with the flexibility to gather all files on a specified path within the sequence. If left unchecked, each subsequent actor will grab only the most recently connected file.

* 📝 **Comprehensive API call logs**: Our API Call logs are now enriched with the response body in the API Call test log.

* 🖱️ **UI refinement for API test call history**: Experience an enhanced user interface for API test call history, making it even more intuitive and user-friendly.

* 🔒 **Enhanced AWS backup**: Witness a smoother transition to an enhanced AWS backup system, fortified by an improved implementation using advanced Vault Variables.

* 🛡️ **Object class permissions**: We've separated list and view permissions within Object classes, empowering you to create workspaces where users can view or edit records from specific classes solely from the parent record form.

* 🌐 **Standalone forms changes**: With the ability to now use Elements on Standalone forms and dynamic submit button control, you can now design immersive and dynamic forms that go beyond the ordinary.

These improvements are a glimpse of the strides we've taken to make Catalyst even more robust, user-centric, and secure.

---

---
url: /knowledgebase/release-notes/release-notes-1.9/bug-fixes-and-improvements.md
---

# Bug fixes and improvements

We've been busy behind the scenes making some exciting changes to Catalyst, focusing on the things that matter most to our clients: **stability, user experience, and data security**.

## Django 4.2 LTS upgrade

**The cornerstone of this release** is the upgrade to Django 4.2 LTS, a strategic move aimed at fortifying Catalyst with a host of benefits, including:

* **Enhanced security:** Django 4.2 LTS incorporates the latest security patches and enhancements, bolstering Catalyst's defences against potential threats and vulnerabilities, thus ensuring a safer environment for our users.
* **Improved performance:** The latest Django version brings optimisations and performance improvements, resulting in snappier response times and smoother navigation.

## Bug fixes across Sequencer and UI

**Alongside the Django upgrade,** we have diligently addressed bugs across both the Sequencer and the UI. These fixes aim to enhance functionality, streamline processes, and eliminate any impediments to a seamless user experience.

## Backup and monitoring improvements

**We have also implemented** a history database-enhanced backup solution and monitoring. This ensures that all data is securely saved and monitored, providing peace of mind to our users regarding data integrity and retrieval.

## Outcome

**The result?** A more robust, secure, and user-friendly experience.

All implemented improvements combine to deliver a significantly more stable and secure application. Enjoy faster performance, smoother sequence execution, and intuitive user experience enhancements.

---

---
url: /api/catalyst/resources/platform-administration/build-limits.md
---
# Build Limits

This documentation describes the Platform Administration API endpoint for retrieving system limits for a specific build (tenant).

## Authentication

All Platform Administration API endpoints require a valid API key sent in the `X-API-Key` HTTP header over HTTPS.

```
X-API-Key: <key>
```

| Condition                     | Response           |
|-------------------------------|--------------------|
| Header missing                | `401 Unauthorized` |
| Header present, key incorrect | `403 Forbidden`    |

## GET /api/builds/\<build\_domain>/limits/

Returns the current system resource limits for a specific build, identified by its domain name.

This endpoint is accessible via the global cluster domain (e.g. `catalyst-vnext-be.iac-eu-west-1-0.autologyx.com`). The tenant is resolved from the `<build_domain>` path parameter, not the request domain.

For the list of deployed builds, see [clientvalue.autologyx.com](https://clientvalue.autologyx.com).

### Permissions

Requires a valid Platform Administration API Key.

### Request

* Headers

```
Content-Type: application/json
X-API-Key: <key>
```

* Schema

```
GET /api/builds/<build_domain>/limits/
```

#### Path parameters

| Parameter    | Type   | Notes                                                                      |
|--------------|--------|----------------------------------------------------------------------------|
| build\_domain | string | The domain name identifying the build (e.g. `acme.catalyst.autologyx.com`) |

### Response

The response contains two categories of fields:

* **Count/limit objects** — resources where both current usage and the configured maximum are returned.
* **Flat integer fields** — limits for which only the maximum value is returned (no usage counter).

#### Count/limit response objects

| Key                     | Type   | Notes                                        |
|-------------------------|--------|----------------------------------------------|
| authentication\_object   | object | Count and limit of authentication objects.   |
| custom\_components       | object | Count and limit of custom components.        |
| object\_classes          | object | Count and limit of object classes.           |
| public\_files            | object | Count and limit of public files.             |
| roles                   | object | Count and limit of roles.                    |
| sequences               | object | Count and limit of sequences.                |
| single\_sign\_on          | object | Count and limit of SSO configurations.       |
| task\_group\_templates    | object | Count and limit of task group templates.     |
| task\_templates          | object | Count and limit of task templates.           |
| ui\_config               | object | Count and limit of UI configurations.        |
| user\_groups             | object | Count and limit of user groups.              |

Each of these objects has the following structure:

| Key   | Type | Notes                                        |
|-------|------|----------------------------------------------|
| count | int  | The current number of objects in this build. |
| limit | int  | The maximum permitted number of objects.     |

#### Flat limit fields

::: info
The fields listed below reflect the limits available at the time of writing. New limit fields may be added in future platform releases as additional resource types are introduced. The response structure (count/limit objects and flat integers) is not expected to change.
:::

| Key                                                   | Type | Notes                                                           |
|-------------------------------------------------------|------|-----------------------------------------------------------------|
| api\_filters\_on\_object\_models\_object\_records\_list      | int  | Limit of API filters on object records list.                    |
| assignees\_standard                                    | int  | Limit of standard assignees.                                    |
| object\_class\_document\_templates                       | int  | Limit of document templates per object class.                   |
| object\_class\_fields                                   | int  | Limit of fields per object class.                               |
| object\_class\_forms                                    | int  | Limit of standalone forms per object class.                     |
| object\_class\_owners                                   | int  | Limit of owners per object class.                               |
| object\_class\_permission\_set                           | int  | Limit of permission sets per object class.                      |
| object\_class\_permission\_set\_assignees                 | int  | Limit of user assignees per object class permission set.        |
| object\_class\_permission\_set\_users\_groups\_assignees    | int  | Limit of user group assignees per object class permission set.  |
| object\_record\_owners                                  | int  | Limit of owners per object record.                              |
| object\_record\_permission\_set\_assignees                | int  | Limit of user assignees per object record permission set.       |
| object\_record\_permission\_set\_users\_groups\_assignees   | int  | Limit of user group assignees per object record permission set. |
| object\_records\_per\_object\_class                       | int  | Limit of records per object class.                              |
| object\_relations\_children                             | int  | Limit of children in object relations.                          |
| object\_relations\_depth                                | int  | Limit of depth in object relations.                             |
| object\_relations\_top\_parent                           | int  | Limit of top-level parents in object relations.                 |
| personal\_authentication\_objects\_per\_user\_per\_provider | int  | Limit of personal authentication objects per user per provider. |
| record\_relations\_transaction                          | int  | Limit of record relations per transaction.                      |
| records\_permission\_set                                | int  | Limit of record permission sets per object class.               |
| task\_assignees\_user\_groups                            | int  | Limit of user groups as default task assignees.                 |
| user\_group\_members                                    | int  | Limit of members per user group.                                |
| user\_group\_owners                                     | int  | Limit of owners per user group.                                 |
| user\_group\_permission\_set                             | int  | Limit of permission sets per user group.                        |
| user\_preferences                                      | int  | Limit of user preferences.                                      |
| users\_external                                        | int  | Limit of external users.                                        |
| users\_full                                            | int  | Limit of full users.                                            |
| users\_group\_permission\_set\_assignees\_user\_groups      | int  | Limit of user group assignees per user group permission set.    |
| users\_group\_permission\_set\_assignees\_users            | int  | Limit of user assignees per user group permission set.          |
| users\_internal                                        | int  | Limit of internal users.                                        |
| users\_ip\_restrictions                                 | int  | Limit of IP restriction rules per user.                         |
| users\_one\_time\_completion                             | int  | Limit of one-time completion users.                             |
| users\_service\_external                                | int  | Limit of external service users.                                |
| users\_service\_internal                                | int  | Limit of internal service users.                                |
| users\_super\_admin                                     | int  | Limit of super admin users.                                     |
| api\_object\_field\_string\_type\_length\_limit             | int  | String field character limit.                                   |
| api\_object\_field\_enum\_options\_max\_count               | int  | Limit of enum field options.                                    |
| api\_task\_string\_type\_length\_limit                     | int  | Task response string field character limit.                     |
| api\_object\_field\_set\_options\_max\_count                | int  | Limit of set field options.                                     |
| api\_document\_max\_num\_of\_files                         | int  | Limit of document field files.                                  |
| allowed\_file\_extensions                               | list | List of allowed file extensions.                                |

* Successful status `200 OK`
* Response body schema:

```json
{
  "authentication_object": { "count": "<int>", "limit": "<int>" },
  "custom_components": { "count": "<int>", "limit": "<int>" },
  "object_classes": { "count": "<int>", "limit": "<int>" },
  "public_files": { "count": "<int>", "limit": "<int>" },
  "roles": { "count": "<int>", "limit": "<int>" },
  "sequences": { "count": "<int>", "limit": "<int>" },
  "single_sign_on": { "count": "<int>", "limit": "<int>" },
  "task_group_templates": { "count": "<int>", "limit": "<int>" },
  "task_templates": { "count": "<int>", "limit": "<int>" },
  "ui_config": { "count": "<int>", "limit": "<int>" },
  "user_groups": { "count": "<int>", "limit": "<int>" },

  "api_filters_on_object_models_object_records_list": "<int>",
  "assignees_standard": "<int>",
  "object_class_document_templates": "<int>",
  "object_class_fields": "<int>",
  "object_class_forms": "<int>",
  "object_class_owners": "<int>",
  "object_class_permission_set": "<int>",
  "object_class_permission_set_assignees": "<int>",
  "object_class_permission_set_users_groups_assignees": "<int>",
  "object_record_owners": "<int>",
  "object_record_permission_set_assignees": "<int>",
  "object_record_permission_set_users_groups_assignees": "<int>",
  "object_records_per_object_class": "<int>",
  "object_relations_children": "<int>",
  "object_relations_depth": "<int>",
  "object_relations_top_parent": "<int>",
  "personal_authentication_objects_per_user_per_provider": "<int>",
  "record_relations_transaction": "<int>",
  "records_permission_set": "<int>",
  "task_assignees_user_groups": "<int>",
  "user_group_members": "<int>",
  "user_group_owners": "<int>",
  "user_group_permission_set": "<int>",
  "user_preferences": "<int>",
  "users_external": "<int>",
  "users_full": "<int>",
  "users_group_permission_set_assignees_user_groups": "<int>",
  "users_group_permission_set_assignees_users": "<int>",
  "users_internal": "<int>",
  "users_ip_restrictions": "<int>",
  "users_one_time_completion": "<int>",
  "users_service_external": "<int>",
  "users_service_internal": "<int>",
  "users_super_admin": "<int>",
  "api_object_field_string_type_length_limit": "<int>",
  "api_object_field_enum_options_max_count": "<int>",
  "api_task_string_type_length_limit": "<int>",
  "api_object_field_set_options_max_count": "<int>",
  "api_document_max_num_of_files": "<int>",
  "allowed_file_extensions": "<list>"
}
```

### Errors

| Error             | Status code      | Notes                                                        |
|-------------------|------------------|--------------------------------------------------------------|
| Unauthorized      | 401 Unauthorized | Standard message                                             |
| Incorrect API Key | 403 Forbidden    | Standard message                                             |
| Build not found   | 404 Not Found    | The specified `build_domain` does not match any active build |

## PATCH /api/builds/\<build\_domain>/limits/

Updates system limits for a specific build, identified by its domain name.

This endpoint is accessible via the global cluster domain (e.g. `catalyst-vnext-be.iac-eu-west-1-0.autologyx.com`). The tenant is resolved from the `<build_domain>` path parameter, not the request domain.

For the list of deployed builds, see [clientvalue.autologyx.com](https://clientvalue.autologyx.com).

### Permissions

Requires a valid Platform Administration API Key.

### Request

* Headers

```
Content-Type: application/json
X-API-Key: <key>
```

* Sample request body

```json
{
  "object_classes": 600,
  "object_class_fields": 6500,
  "object_records_per_object_class": 200000
}
```

#### Path parameters

| Parameter     | Type     | Notes                                                                       |
|---------------|----------|-----------------------------------------------------------------------------|
| build\_domain  | string   | The domain name identifying the build (e.g. `acme.catalyst.autologyx.com`)  |

### Response

Response is the same as in [GET /api/builds/\<build\_domain>/limits/](#get-build-limits)

### Errors

| Error               | Status code           | Notes                                                                           |
|---------------------|-----------------------|---------------------------------------------------------------------------------|
| Unauthorized        | 401 Unauthorized      | Standard message                                                                |
| Incorrect API Key   | 403 Forbidden         | Standard message                                                                |
| Build not found     | 404 Not Found         | The specified `build_domain` does not match any active build                    |
| Invalid value type  | 400 Bad Request       | "{limit\_key}": \["A valid integer is required."]                               |
| Value to large      | 400 Bad Request       | "{limit\_key}": \["Ensure this value is less than or equal to 32767."]          |
| Value to small      | 400 Bad Request       | "{limit\_key}": \["Ensure this value is greater than or equal to 1."]           |
| Value is not list   | 400 Bad Request       | "allowed\_file\_extensions": \["Expected a list of items but got type "str"."] |
| Extension not valid | 400 Bad Request       | "allowed\_file\_extensions": \["Invalid extension format."]                      |

---

---
url: /knowledgebase/getting-started/building-applications-analysts.md
---
# Building Applications Analysts

## Browse the sections below

* [Checklist of things to set up which are common across all applications of the system](/knowledgebase/getting-started/building-applications-analysts/checklist-of-things-to-set-up-which-are-common-across-all-applications-of-the-system/)
* [What goes into a typical application](/knowledgebase/getting-started/building-applications-analysts/what-goes-into-a-typical-application/)

---

---
url: /api/capacity-and-system-limits/capacity_and_system_limits.md
---

# 📏 Capacity and System Limits

Autologyx is designed for enterprise-scale workloads, but like every well-engineered platform, it operates within defined limits.

That is not unusual — in fact, limits are a healthy part of system design. Databases, APIs, storage engines, browsers, operating systems, and even office buildings all have limits. The important question is not whether limits exist, but whether they are practical, well understood, and appropriate for real-world use. In Autologyx, many limits are set at levels that support large-scale operational use, and some can be increased on request where there is a justified need.

This page summarises the standard platform limits currently documented for Autologyx. These limits are useful for:

* understanding the default operating boundaries of the platform
* planning solution design and data architecture
* sizing test data for performance and scale testing
* identifying areas where a higher threshold may be needed for a specific implementation

::: info
A `*` next to a limit indicates that it is system-imposed by default and may be possible to increase on request, subject to technical review and suitability.
:::

## Why limits matter

System limits are not just technical constraints — they are also design signals.

They help solution designers, implementation teams, and testers understand the scale assumptions under which the platform is expected to operate. In practical terms, this means they give you useful parameters for:

* designing object models
* structuring forms and permissions
* planning operational scale
* testing realistic data volumes
* understanding when a solution is moving beyond standard operating assumptions

Just as importantly, published limits help customers and internal teams distinguish between:

* what is supported as standard
* what is configurable or extendable
* what may require architectural review before scaling further

## What “enterprise scale” looks like in practice

The standard Autologyx limits are already large enough to support substantial enterprise workloads.

For example, a transaction review or claims-handling solution might include:

* hundreds of [Object Classes](/knowledgebase/terminology/#object-classes) covering customers, matters, transactions, claims, documents, audit events, exceptions, and decisions
* thousands of [Object class fields](/knowledgebase/terminology/#object-class-fields) across those classes to model operational, financial, regulatory, and workflow data
* millions of [Object Records](/knowledgebase/terminology/#object-records) in active use
* hundreds of users working across teams, [Roles](/knowledgebase/terminology/#roles), and permission models
* large numbers of [Task Templates](/knowledgebase/terminology/#task-templates), [Task Group Templates](/knowledgebase/terminology/#task-group-templates), and [sequences](/knowledgebase/terminology/#sequences) supporting operational automation
* high-volume document generation and structured [JSON fields](/knowledgebase/terminology/#json-fields) for integration payloads or case metadata

A banking transaction review solution, for example, could realistically operate with millions of transaction records, thousands of fields across related object models, large review teams, extensive automation, and fine-grained permission control — all within the normal design intent of the platform.

Similarly, a claims or settlement platform might maintain very large case volumes, many [Document Templates](/knowledgebase/terminology/#document-templates), multiple [User Groups](/knowledgebase/terminology/#user-groups) and [Roles](/knowledgebase/terminology/#roles), and complex process automation while still remaining within standard platform boundaries.

The key point is that these limits are not “small application” limits. They are intended to support enterprise use. Where an implementation expects to push beyond a standard threshold, that should usually be treated as a solution design and scaling conversation rather than a sign that the platform is unsuitable.

## Standard limits

| Resource | Limit |
|---|---:|
| Number of [Object Classes](/knowledgebase/terminology/#object-classes) | 10,000 |
| Number of [Object class fields](/knowledgebase/terminology/#object-class-fields) in an [Object Class](/knowledgebase/terminology/#object-classes) | 2,000 |
| Number of [Object Records](/knowledgebase/terminology/#object-records) in an [Object Class](/knowledgebase/terminology/#object-classes)\* | 5,000,000 |
| Total number of [Object Records](/knowledgebase/terminology/#object-records) | 5,000,000,000 |
| Number of owners of an individual [Object Class](/knowledgebase/terminology/#object-classes)\* | 100 |
| Number of owners of an individual [Object Record](/knowledgebase/terminology/#object-records)\* | 100 |
| Number of class permission sets defined for an individual [Object Class](/knowledgebase/terminology/#object-classes)\* | 10 |
| Number of assignees for an individual class permission set\* | 100 |
| Number of record permission sets defined for an individual [Object Class](/knowledgebase/terminology/#object-classes)\* | 10 |
| Number of assignees for an individual record permission set\* | 100 |
| Number of [Task Group Templates](/knowledgebase/terminology/#task-group-templates) | 10,000 |
| Number of [Task Templates](/knowledgebase/terminology/#task-templates) | 10,000 |
| Number of [Task Templates](/knowledgebase/terminology/#task-templates) in a [Task Group Template](/knowledgebase/terminology/#task-group-templates) | TBC |
| Number of fields in a task form | 2,000 |
| Number of [Sequences](/knowledgebase/terminology/#sequences) | 1,000 |
| Number of Users (1TC / System users)\* | 1,000,000 |
| Number of [User Groups](/knowledgebase/terminology/#user-groups) | 1,000 |
| Number of members in a single [User Group](/knowledgebase/terminology/#user-groups) | 1,000,000 |
| Number of owners of an individual [User Group](/knowledgebase/terminology/#user-groups)\* | 10 |
| Number of [Roles](/knowledgebase/terminology/#roles) | 5,000 |
| Number of [Roles](/knowledgebase/terminology/#roles) per User\* | 25 |
| Number of SSO configurations | 25 |
| Number of [Authentication Objects](/knowledgebase/terminology/#authentication-objects)\* | 100 |
| Number of characters in an [Object class field](/knowledgebase/terminology/#object-class-fields) label | 100 |
| Number of characters in an [Object class field](/knowledgebase/terminology/#object-class-fields) alias | 50 |
| Number of options in an [Object class field](/knowledgebase/terminology/#object-class-fields) of type single/multi select\* | 100 |
| Number of [standalone forms](/knowledgebase/terminology/#standalone-forms) in an [Object Class](/knowledgebase/terminology/#object-classes) | 100 |
| Number of components (fields, properties, instructions) in a [standalone form](/knowledgebase/terminology/#standalone-forms) | 200 |
| Number of fields in an [Object Class](/knowledgebase/terminology/#object-classes) create/edit record form | 200 |
| Number of sections in an [Object Class](/knowledgebase/terminology/#object-classes) create/edit record form | 100 |
| Number of [Document Templates](/knowledgebase/terminology/#document-templates) within an [Object Class](/knowledgebase/terminology/#object-classes) | 1,000 |
| Maximum characters in a [JSON field](/knowledgebase/terminology/#json-fields) | 250,000 |

## Interpreting these limits

A limit is not always a target.

In many solutions, it is good practice to stay comfortably below a maximum where possible, especially in areas such as:

* form complexity
* very large select-option sets
* very large numbers of permissions or roles assigned to one user
* extremely large record counts concentrated in a single class

This does not mean those upper limits are not valid. It simply means that good solution design still matters. The best implementations combine platform capacity with sensible modelling, clean automation, and appropriate operational partitioning.

## When to ask for more

Some limits are marked with `*` because they are imposed as standard platform thresholds and may be adjustable on request.

Where a project expects to exceed one of those limits, the right next step is usually to review:

* the use case and business need
* expected data growth and user growth
* performance implications
* operational and support considerations
* whether an increase is the right answer, or whether a different design approach would be better

## Notes

::: tip
When performance or scale testing a solution, it is usually more useful to model realistic operational behaviour than to test only theoretical maxima. A well-designed test with millions of representative records, realistic user concurrency, and production-like workflow behaviour will tell you more than a synthetic test that only tries to hit a numeric ceiling.
:::

::: warning
The values on this page describe currently documented standard limits. They should be treated as implementation guidance, not as a substitute for architecture review where unusually high scale, unusual data shapes, or non-standard usage patterns are expected.
:::

---

---
url: /api/catalyst.md
---

# 🔌 Catalyst API

Welcome to the Autologyx Catalyst API documentation.

This section provides the technical reference material needed to integrate with Catalyst services, understand the structure and conventions of the platform APIs, and work effectively with related features such as merge fields, event history, and WebSockets.

## 📚 What this section covers

The API documentation is organised into a small number of focused areas:

### 🔗 API service documentation

* [Catalyst Platform API](/api/catalyst/)\
  Core API reference for working with platform resources and operations.

* [Event History API](/api/event-history/)\
  Reference material for accessing and understanding historical event data.

* [WebSockets](/api/websockets/)\
  Documentation for real-time updates and event-driven interactions.

* [Monitoring and infrastructure (restricted)](/api/monitoring-and-infrastructure/)\
  Reference material for restricted, internal-facing, and operational API surfaces.

### 🛠️ Technical documentation

* [API Standards](/api/standards/)\
  Shared conventions, structures, and behaviours used across the API surface.

* [Understanding Merge Fields](/api/merge-fields/merge-fields)\
  Reference documentation for merge field syntax, usage patterns, and supported structures.

## 👥 Who this documentation is for

This section is primarily intended for:

* Developers and integrators building against the Catalyst APIs
* Configuration admins working with advanced platform integrations
* Technical users who need to understand payload structure, merge field syntax, and API conventions
* Teams implementing real-time or event-driven workflows

## 🧭 How to use this documentation

If you are new to the API documentation, a good place to start is:

1. [API Standards](/api/standards/) to understand common patterns and conventions
2. [Catalyst Platform API](/api/catalyst/) for the core service reference
3. [Understanding Merge Fields](/api/merge-fields/merge-fields) if your use case involves dynamic values in templates, messages, or automation
4. [Event History API](/api/event-history/) or [WebSockets](/api/websockets/) if you are working with history, monitoring, or real-time updates

## 🎯 Common use cases

Teams typically use this documentation when they need to:

* integrate external systems with Catalyst
* retrieve or update platform data programmatically
* understand API request and response conventions
* work with merge fields in documents, messages, or workflow configuration
* consume event history for reporting, monitoring, or audit-related scenarios
* build real-time integrations using WebSockets

## 🕒 Last updated

API Version 14.0.0 / 25-04-2026

This API documentation is maintained as part of the wider Autologyx Docs project and should be treated as the technical entry point for working with Catalyst services and related platform conventions.

::: warning
For the most accurate and current implementation detail, always check the specific service or standards page you are working from, especially when dealing with request and response structures, merge field syntax, event data, or real-time integration behaviour.
:::

## ℹ️ Notes

::: info
This API documentation is intended to complement the [Catalyst Knowledgebase](/knowledgebase/).\
Use the Knowledgebase for broader platform guidance and configuration workflows, and use this section when you need technical reference material for implementation.
:::

::: tip
If you already know which area you need, use the navigation to jump directly to the relevant API or technical reference section.
:::

---

---
url: /knowledgebase.md
---
# Catalyst Knowledgebase

Practical help and guidance for using, configuring, and getting more from Autologyx Catalyst.

Use the sections below to find the right starting point for your role, whether you are carrying out work in the platform, configuring a solution, or administering the wider environment.

## Browse by section

* **[Welcome & Introduction to Catalyst](/knowledgebase/welcome-introduction-to-catalyst/)**
* **[Getting Started](/knowledgebase/getting-started/)**
* **[Finding your way around](/knowledgebase/finding-your-way-around/)**
* **[Record and Task Forms](/knowledgebase/record-and-task-forms/)**
* **[Workspace](/knowledgebase/workspace/)**
* **[System Configuration](/knowledgebase/system-configuration/)**
* **[Administration](/knowledgebase/administration/)**
* **[Using Help and Support](/knowledgebase/using-help-and-support/)**
* **[Autologyx Terminology](/knowledgebase/terminology/)**
* **[Release Notes](/knowledgebase/release-notes/)**

## Notes

::: tip
**How links work in this Knowledgebase**

* A normal link like [Workspace](/knowledgebase/workspace/) takes you to another page or section.
* An **important concept** may be emphasised in **bold** to help you scan the page quickly.
* A highlighted term like Autologyx Catalyst links to the Terminology section, where you can find a definition or explanation of that concept.
  :::

::: info
A good place to start is **Getting Started** if you are new to Catalyst, **Workspace** if you are carrying out day-to-day work, or **System Configuration** if you are building or maintaining a solution.
:::

---

---
url: /knowledgebase/release-notes/release-notes-1.3/catalyst-word-add-in.md
---

# Catalyst Word Add-in

At Autologyx, we understand the challenges of working with complex documents and manually merging data from records. That's why we're announcing our latest innovation, the Catalyst Word Add in, which eliminates tedious manual processes and errors.

**Generate documents more easily** using merge fields populated with data from your records. Simply configure and make the Catalyst Word Add-in available in your admin-managed add-ins, courtesy of your System Administrator. Once set up, all users with appropriate permissions within your organisation can leverage the add-in's capabilities.

**Access your data source** by entering the domain and selecting the desired object class, the foundation for your merged data. This grants you access to all the class fields, which can be easily inserted into your document. We’ve also added user-friendly functions to the add-in, ensuring a smoother document creation experience.

![Addin\_articles.gif](/knowledgebase/images/img_11640461751197_1776895692.png)

**Use functions with confidence** by referring to the clear explanations provided for each one. Even those that may seem complex at first glance will quickly become second nature, revolutionising your document creation process.

With every document created using merge fields, you'll experience newfound efficiency and accuracy. Don't miss out on the Catalyst Word Add in and redefine how you create documents.

![Addin2\_articles.gif](/knowledgebase/images/img_11640461751197_1776895693.png)

---

---
url: >-
  /knowledgebase/getting-started/building-applications-analysts/checklist-of-things-to-set-up-which-are-common-across-all-applications-of-the-system.md
---

# Checklist of things to set up which are common across all applications of the system

You may be responsible for setting up just some of the components below, but it is useful to have this checklist all in one place so that you can liaise with the other people involved to ensure that everything is ready and working.

Your role will inevitably involve testing of the processes you build, so it is also useful to check, for instance, that the [Outbound mail setup](/knowledgebase/administration/communication/outbound-mail-setup/) has been correctly configured.

Some things will be set up only once and others will be built upon as you increase the number of users and number of processes which the platform is used to run.

Your user account type and role will determine whether you have access to all areas mentioned.

## Components which are set up once only

The following items are found under **Administration**.

* [**Company details**](/knowledgebase/administration/communication/company-details/) - details entered here are available as merge fields and will be used in message templates.
* [**Standard authentication**](/knowledgebase/administration/communication/how-do-i-configure-user-activation-rules/) - this area allows you to set the user login password rules for the system. This article will show you what the users see when they activate their account and how you set the password rules.
* [**Single sign-on**](/knowledgebase/administration/communication/how-do-i-configure-single-sign-on-for-users/) - if you use this feature it will allow you to configure a single sign-on provider such as Microsoft or Google. Users can select this method of authentication on the login page instead of entering their email address and password.
* [**Outbound mail setup**](https://autologyx.zendesk.com/knowledge/articles/4402900566033/en-us?brand_id=360001824097\&return_to=%2Fhc%2Fen-us%2Farticles%2F4402900566033) - this is where you will define and configure the mail service used for all outgoing notifications.

## Components which are needed for your first process and will be added to for subsequent applications

* **Data Model** - this centres around groups of records called Object classes. Fields are added to object classes where data and documents can be stored. Some fields will be used when creating records in an Object class while others will be presented at various stages and under different circumstances in a process so that the record can be updated. Object class fields can be used in task templates to review, amend and add data.

  You may start a simple process with only one Object class. However, as you see the benefits of automation and use the system further, you will want to take advantage of the **[Relational modeller](https://ng-autologyx.zendesk.com/hc/en-us/sections/10381782694301-Relational-Modeller)**. This allows you to associate a number of Object classes with each other, creating parent/child relationships meaning that data can be shared across some Object classes.

* **Documents** - invariably your process will involve the provision and signing of documents. One thing you will want to do straightaway is to upload any frequently used documents to the Template areas on appropriate Object classes. You'll find a number of useful articles in our **[Document Automation](/knowledgebase/system-configuration/document-automation/)** section.

* **User Roles and Groups** - it is likely that most users of the system will have accounts where they are required to log in. This means that they will activate their account via a unique link sent in an email. They will undoubtedly be added to a Permission set and/or User group - these groups can be assigned tasks and sent email notifications from the Sequencer. They may also require a Role where their permissions will determine what they can see and do in areas of the system other than Workspace. **[Find out more about Users, Roles and User Groups](/knowledgebase/administration/users-roles-and-user-groups/)**.

* **Tasks templates and Task group templates** - Tasks are created from task templates either automatically in a Sequence or manually from a Record. Tasks can be grouped so that there are two or more created at the same time. Tasks which are of the type, "Complete self contained form" can be shared by several Object classes whereas those which are of the type, "Update object record" are specific to an Object class. **[Find out more about Task Management](/knowledgebase/system-configuration/task-management/)**.

---

---
url: >-
  /knowledgebase/record-and-task-forms/formbuilder-components/child-object-classes.md
---

# Child Object Classes

The Child Object Class component will be available in the side panel of the Object class Create and edit view if the Object class is a parent in the relational model [Relational model](/knowledgebase/system-configuration/relational-modeller/what-is-the-relational-modeller/). Only Object classes which are direct children will be available for selection.

|  |  |
| --- | --- |
| In the relational model shown:   - Employee Management (HR) is at the top - we call this the root parent - Employee Management (HR) has one direct child - Employees. Note that object class Employees is not only a child. It is a parent to object class Employment Contracts - Employment Contracts is a direct child of Employees | Screenshot 2024-06-17 at ![11.34.52.png](../../../images2/zendesk_19545994438429_001_a6b368224b13.png) |

The Child Object Class component "Employees" is available in the side panel of the Create and edit view for Object class "Employee Management".

![1706a.png](../../../images2/zendesk_19545994438429_002_05d00e7672a2.png)

Similarly, "Employee Contracts" will be available in the side panel of the Create and edit view for Object class "Employees".

However, Object class "Employee Contracts" has no children, so the Child Object Class component does not appear.

![1706b.png](../../../images2/zendesk_19545994438429_003_edf777280a9a.png)

## Add the component to a form

Drag the Child object class component onto the form into a section. It will be greyed out in the side panel and appear as below on the canvas.

![1706c.png](../../../images2/zendesk_19545994438429_004_fe7b1f56844f.png)

Click on the grey header adjacent to "ID". A plus sign will be displayed, the same as those in the column configuration component on the Records list.

![Screenshot 2024-06-17 at 12.33.18.png](../../../images2/zendesk_19545994438429_005_cbe1a7030d69.png)

Click on the cross to display **Record properties** and **Class fields**. Select those that you wish to display on the Child component in the form.

![1706d.png](../../../images2/zendesk_19545994438429_006_89253a9807c1.png)

Click **+ Add columns**; the configuration will be saved.

Preview the form to check how the component is displayed. Return to the form to re-space and/or re-order the fields on the header if required, again by clicking on the header itself.

![1706e.png](../../../images2/zendesk_19545994438429_007_fbd5a1d64f0c.png)

![1706f.png](../../../images2/zendesk_19545994438429_008_80056fc41953.png)

Simply click off the component to save your changes.

Finish configuring the rest of the form and Save.

## Using the Child Object Class component in a form

The URL of the Create and edit view can be provided to Users as a link on their Landing page or can be accessed by clicking the + Create record button on the Records list.

The child object component will be displayed as **"Related records: Name of child object class"** (in this case, Employees). It will have holding text, **"No child records added. Search for existing records to add them, or create a new record."**

Clearly, you must have permissions to view or create records in the child class in order to carry out these actions.

### Search

Click into the search field. Records will appear listed by ALX ID number if no other field has been marked as the Identifier. In the below screenshot, records are listed by Personal email address (the chosen Identifier) followed by the ALX ID. You can scroll down the list or start typing - the list will filter accordingly.

![1706g.png](../../../images2/zendesk_19545994438429_009_2bd3a60585e3.png)

The selected record will appear in the child component as below.

![1706h.png](../../../images2/zendesk_19545994438429_010_ac78ae69a330.png)

The **Actions** menu on the child component has two options. **Open** will open the child record while, if you have selected in error, **Remove** will take it out of the child component.

![1706i.png](../../../images2/zendesk_19545994438429_011_bf292ad6631b.png)

### Create

If the record you wish to add to the relationship does not exist, click **+ Create** on the Related records child component.

The child Create and edit view form will open so that you can enter the details of the new record. Note that this form includes a Related records child component for Employee Contracts.

![1706j.png](../../../images2/zendesk_19545994438429_012_403b01c2a760.png)

When you save this form, the child record will be created. Note below that their ALX ID has been applied on creation.

The side panel displays the summary for the child record.

![1706k.png](../../../images2/zendesk_19545994438429_013_7f0a7bb78a80.png)

Additional child records can be added if the ratio to the parent is N. If the parent:child ratio is 1:1, the **+ Create** and **Search** functions will be disabled and clicking either will display a modal telling you that the maximum number of related records has been reached.

![1706l.png](../../../images2/zendesk_19545994438429_014_237228263db9.png)

Complete the rest of the form for the parent record and save.

---

---
url: /knowledgebase/release-notes/release-notes-1.2/click-to-call-on-autologyx.md
---

# Click-to-Call on Autologyx

We are pleased to introduce our latest feature — Click-to-Call!

With Click-to-Call, you can now call the numbers saved on your records directly from your browser, making it easier than ever to stay connected with saved contacts. No more switching between different devices or applications to make a simple phone call.

**How it works:** Simply click on the phone number within your Autologyx record, and the Click-to-Call feature will initiate a call to that number. It's that easy!

**Browser and device support:** You can use Click-to-Call with any web browser, on any device — whether you're on your desktop, laptop, or mobile phone. You don't need to take any additional steps, as the browser will automatically handle the call. Depending on your browser and device, you may be brought to FaceTime, a phone call app, or prompted with a dialog box to confirm the use of another app.

![Clicktocall\_article.gif](/knowledgebase/images/img_10872477553053_1776895710.png)

We believe that Click-to-Call will help streamline your communication and improve your productivity, allowing you to focus on what matters most. So why wait? Start using Click-to-Call today and experience convenience for yourself!

---

---
url: >-
  /knowledgebase/finding-your-way-around/ui-and-navigation/column-configuration-on-list-pages.md
---

# Column Configuration on List Pages

You can use **Column configuration** to customise which columns appear on a list page and control the order in which they are displayed.

This allows you to tailor list pages to the information you use most often.

In the screenshot below, the **Column configuration** control is highlighted.

![List page showing the Column configuration control](/knowledgebase/images/fywa-ui-column-config-1.png)

## Configure columns

Each list page has its own default column setup. You can change this by clicking the **Column configuration** control.

When you do this, three buttons appear above the column headers:

* **Save changes**
* **Reset to default**
* **Cancel**

A circular **+** insertion icon also appears to the right of each visible column, except the **Actions** column. Click the **+** icon where you want to insert extra columns.

![Column configuration mode showing Save changes, Reset to default, and Cancel controls](/knowledgebase/images/fywa-ui-column-config-2.png)

The column selection list shows any available columns that are not currently visible in the table.

![Column selection list showing available columns that can be added](/knowledgebase/images/fywa-ui-column-config-3.png)

Select the columns you want to add, then click **+ Add columns**.

The selected columns appear at the insertion point. Click **Save changes** to keep the updated column layout.

![List page showing newly added columns in the selected position](/knowledgebase/images/fywa-ui-column-config-4.png)

## Other actions in column configuration mode

While in column configuration mode, you can also:

* use the **X** control on a column header to remove it from the list
* reposition columns by dragging and dropping them into the required position
* cancel changes by clicking **Cancel**
* reset the list view to the default setting by clicking **Reset to default**

The **Actions** column cannot be removed or repositioned.

![Warning modal shown when cancelling unsaved column configuration changes](/knowledgebase/images/fywa-ui-column-config-5.png)

![Warning modal shown when resetting column configuration to the default layout](/knowledgebase/images/fywa-ui-column-config-6.png)

These actions display a warning modal where you can confirm the action or return to column configuration mode.

## Things to remember

* Column configuration changes apply only to the current list page.
* The **Actions** column cannot be removed or repositioned.
* Unsaved changes will be lost if you click **Cancel** and confirm the warning.
* Use **Reset to default** if you want to return the list page to its original column layout.

---

---
url: /knowledgebase/administration/communication.md
---

# Communication

The **Communication** section contains the configuration used to manage user authentication, email delivery, and system communications.

These settings determine how users sign in to Autologyx, how accounts are activated, and how the platform sends emails such as task notifications, password resets, and other automated messages.

Use the guides below to configure and manage these features.

## Company settings

### Company details

Configure your organisation's contact information. These details are used throughout the platform, including in system-generated emails.

* [Company Details](/knowledgebase/administration/communication/company-details/)

## Single Sign-on (SSO)

### Configure Single Sign-on

Learn how to configure Single Sign-on (SSO) so users can authenticate using an external identity provider.

* [How Do I Configure Single Sign On For Users](/knowledgebase/administration/communication/how-do-i-configure-single-sign-on-for-users/)

### Edit a Single Sign-on configuration

Learn how to update an existing Single Sign-on configuration, including automatic user creation and assigned Roles.

* [Editing A Single Sign On Setting](/knowledgebase/administration/communication/editing-a-single-sign-on-setting/)

### Configure Okta

Learn how to configure Okta as your Single Sign-on provider.

* [Okta Sso In Catalyst](/knowledgebase/administration/communication/okta-sso-in-catalyst/)

## User activation

### Configure activation rules

Control how new user accounts are activated and how activation emails are managed.

* [How Do I Configure User Activation Rules](/knowledgebase/administration/communication/how-do-i-configure-user-activation-rules/)

## Outbound email

### Configure outbound mail

Configure the email service used by Autologyx to send password reset emails, task notifications, and other system communications.

* [Outbound Mail Setup](/knowledgebase/administration/communication/outbound-mail-setup/)

### Microsoft Client Credentials

Learn how to configure Outbound Mail using Microsoft Client Credentials authentication.

* [Configuring Outbound Mail Setup With Microsoft Client Credentials](./configuring-outbound-mail-setup-with-microsoft-client-credentials/index.md)

## Things to remember

1. Access to Communication settings depends on your account type and Role permissions.
2. Company Details are used in system-generated emails and other communications.
3. You can configure one or more Single Sign-on providers for user authentication.
4. Outbound Mail must be configured before the platform can send email notifications.

---

---
url: /api/catalyst/resources/company-details.md
---
# Company details

Company details store the details of a **nominated system administrator** or a generic contact.

These details are available as **merge fields** within the system and are used in **standard message templates**.

Company Details is a **single instance** endpoint which means **only one database record** with Company Details exists.

## Permissions

| Permission | Manageable via Roles | Description                               |
| ---------- | -------------------- | ----------------------------------------- |
| `edit`     | true                 | Allow for **editing** the Company details |
| `view`     | true                 | Allow for **viewing** the Company details |

Permissions for Company details can be checked by:

| Context      | Endpoint                      | Location            | Available perms |
| ------------ | ----------------------------- | ------------------- | --------------- |
| Global scope | `GET /api/users/permissions/` | `"company_details"` | `edit`, `view`  |

## GET /api/administration/company-details/

Retrieves the Company details.

### Permissions

Requires `authentication` and `company_details.view` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/administration/company-details/
```

### Response

| Key                   | Type   | Notes                          |
| --------------------- | ------ | ------------------------------ |
| admin\_first\_name      | string |                                |
| admin\_last\_name       | string |                                |
| admin\_email\_address   | email  |                                |
| admin\_phone\_number    | string |                                |
| admin\_job\_title       | string |                                |
| admin\_email\_signature | string |                                |
| \_meta.permissions    | Object | Object describing permissions. |

* Successful status `200 OK`
* Response body schema:

```json
{
  "admin_first_name": <string>,
  "admin_last_name": <string>,
  "admin_email_address": <email>,
  "admin_phone_number": <string>,
  "admin_job_title": <string>,
  "admin_email_signature": <string>,
  "_meta": {
    "permissions": {
        "edit": <bool>,
        "view": <bool>
    }
  }
}
```

### Errors

| Error                    | Response code | Message                                                        |
| ------------------------ | ------------- | -------------------------------------------------------------- |
| Insufficient permissions | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## PATCH /api/administration/company-details/

Updates Company details.

### Permissions

Requires `authentication` and `company_details.edit` permission.

### Request

* Body parameters

| Key                   | Type   | Notes                                       |
| --------------------- | ------ | ------------------------------------------- |
| admin\_first\_name      | string | Optional, with max length of 25 characters  |
| admin\_last\_name       | string | Optional, with max length of 25 characters  |
| admin\_email\_address   | email  | Optional, with max length of 100 characters |
| admin\_phone\_number    | string | Optional, with max length of 20 characters  |
| admin\_job\_title       | string | Optional, with max length of 100 characters |
| admin\_email\_signature | string | Optional, with max length of 255 characters |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
PATCH /api/administration/company-details/

{
  "admin_first_name": <string>,
  "admin_email_address": <email>
  ...
}
```

### Response

| Key                   | Type   | Notes                          |
| --------------------- | ------ | ------------------------------ |
| admin\_first\_name      | string |                                |
| admin\_last\_name       | string |                                |
| admin\_email\_address   | email  |                                |
| admin\_phone\_number    | string |                                |
| admin\_job\_title       | string |                                |
| admin\_email\_signature | string |                                |
| \_meta.permissions    | Object | Object describing permissions. |

* Successful status `200 OK`
* Response body schema:

```json
{
  "admin_first_name": <string>,
  "admin_last_name": <string>,
  "admin_email_address": <email>,
  "admin_phone_number": <string>,
  "admin_job_title": <string>,
  "admin_email_signature": <string>,
  "_meta": {
    "permissions": {
        "edit": <bool>,
        "view": <bool>
    }
  }
}
```

### Errors

| Error                                      | Response code   | Message                                                                         |
| ------------------------------------------ | --------------- | ------------------------------------------------------------------------------- |
| "admin\_first\_name" is too long             | 400 Bad Request | "admin\_first\_name": \["Ensure this field has no more than 25 characters."]       |
| "admin\_first\_name" is null                 | 400 Bad Request | "admin\_first\_name": \["This field may not be null."]                             |
| "admin\_first\_name" is not a string         | 400 Bad Request | "admin\_first\_name": \["Not a valid string."]                                     |
| "admin\_last\_name" is too long              | 400 Bad Request | "admin\_last\_name": \["Ensure this field has no more than 25 characters."]        |
| "admin\_last\_name" is null                  | 400 Bad Request | "admin\_last\_name": \["This field may not be null."]                              |
| "admin\_last\_name" is not a string          | 400 Bad Request | "admin\_last\_name": \["Not a valid string."]                                      |
| "admin\_email\_address" is too long          | 400 Bad Request | "admin\_email\_address": \["Ensure this field has no more than 100 characters."]   |
| "admin\_email\_address" is null              | 400 Bad Request | "admin\_email\_address": \["This field may not be null."]                          |
| "admin\_email\_address" is not a valid email | 400 Bad Request | "admin\_email\_address": \["Enter a valid email address."]                         |
| "admin\_phone\_number" is too long           | 400 Bad Request | "admin\_phone\_number": \["Ensure this field has no more than 20 characters."]     |
| "admin\_phone\_number" is null               | 400 Bad Request | "admin\_phone\_number": \["This field may not be null."]                           |
| "admin\_phone\_number" is not a string       | 400 Bad Request | "admin\_phone\_number": \["Not a valid string."]                                   |
| "admin\_job\_title" is too long              | 400 Bad Request | "admin\_job\_title": \["Ensure this field has no more than 100 characters."]       |
| "admin\_job\_title" is null                  | 400 Bad Request | "admin\_job\_title": \["This field may not be null."]                              |
| "admin\_job\_title" is not a string          | 400 Bad Request | "admin\_job\_title": \["Not a valid string."]                                      |
| "admin\_email\_signature" is too long        | 400 Bad Request | "admin\_email\_signature": \["Ensure this field has no more than 255 characters."] |
| "admin\_email\_signature" is null            | 400 Bad Request | "admin\_email\_signature": \["This field may not be null."]                        |
| "admin\_email\_signature" is not a string    | 400 Bad Request | "admin\_email\_signature": \["Not a valid string."]                                |
| Insufficient permissions                   | 403 Forbidden   | "detail": "You do not have permission to perform this action."                  |

## OPTIONS /api/administration/company-details/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/administration/company-details/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
  "details": {
    "schema": [
      {
        "alias": "admin_first_name",
        "type": "string",
        "required": false,
        "validators": [
          {
            "type": "max_length",
            "length": 25
          }
        ]
      },
      {
        "alias": "admin_last_name",
        "type": "string",
        "required": false,
        "validators": [
          {
            "type": "max_length",
            "length": 25
          }
        ]
      },
      {
        "alias": "admin_email_address",
        "type": "email",
        "required": false,
        "validators": [
          {
            "type": "max_length",
            "length": 100
          }
        ]
      },
      {
        "alias": "admin_phone_number",
        "type": "string",
        "required": false,
        "validators": [
          {
            "type": "max_length",
            "length": 20
          }
        ]
      },
      {
        "alias": "admin_job_title",
        "type": "string",
        "required": false,
        "validators": [
          {
            "type": "max_length",
            "length": 100
          }
        ]
      },
      {
        "alias": "admin_email_signature",
        "type": "string",
        "required": false,
        "validators": [
          {
            "type": "max_length",
            "length": 255
          }
        ]
      }
    ]
  }
}
```

---

---
url: /knowledgebase/administration/communication/company-details.md
---

# Company details

The Company details page is found in the left-hand menu under Administration.

## Access

**Only the following users** have access to this page:

* Users with a Super admin account type
* Users with a Role where the Edit Permission for Company Details has been enabled on the Administration tab

## Details

**Use this page** to enter the details of a nominated user or a generic contact.

![mceclip0.png](/knowledgebase/images/img_4402900569873_1776896064.png)

## Merge fields

The information on this page is available as merge fields within the system and will be used in standard message templates, such as to notify a User that they have a Task to complete.

**Note:** None of these fields are mandatory. This means that you can choose to use only the Admin email signature, for example, and apply this as a merge field to outgoing messages.

---

---
url: /knowledgebase/system-configuration/merge-fields/conditional-logic.md
---

# Conditional Logic

Our Word Add-In will help you to build comprehensive document templates. These can be generated in a sequence or manually in the Templates tab on a Record.

Please see this article to help you configure the [Word Add-in.](/knowledgebase/system-configuration/working-with-document-templates/ms-word-add-in---configuration/)

You can use **`if` statements** to show or hide parts of the document template or email body based on field values.

## Basic condition

```
{% if record.field_status == 'active' %}
  Status: Active
{% endif %}
```

## If / Else

```
{% if record.field_price > 0 %}
  Paid: {{ record.field_price }} €
{% else %}
  Free
{% endif %}
```

## Nested conditions

```
{% if record.field_status %}
  {% if record.field_status == 'archived' %}
    Archived
  {% else %}
    Active
  {% endif %}
{% endif %}
```

You can also use **in**, **not in**, **and**, **or**, etc.

```
{% if record.field_status in ['new', 'open'] and record.field_priority == 'high' %}
  Urgent!
{% endif %}
```

---

---
url: >-
  /knowledgebase/system-configuration/merge-fields/configuration-and-use-of-the-image-merge-field.md
---

# Configuration and use of the Image Merge Field

One thing that can really improve a document is the inclusion of high quality images, particularly if these are personalised. With this in mind, we have developed an image merge field which is designed to inject images such as logos, photographs, charts, QR codes, infographics, etc into your generated documents.

## Example: customer logos

**The following describes how to configure and use an image merge field for customer logos.**

## Configure the object class and field

The object class being used is called Customer. Start by adding a document type field to the object class. In this case, the field is called Customer Logo; it is limited to one file.

![Screenshot 2024-04-02 at 15.22.00.png](../../../images2/zendesk_17942924026141_001_d8c56045fcce.png)

Next, add the field to one of the following to ensure that it is populated with the logo prior to the document being generated:

* A standalone form used to create a Customer record (this is configured in the Forms tab on the object class and can be used to create a record from outside of the system)
* The create/edit display view of the Customer object class
* An update object record type task for the Customer class where a user is required to upload the logo to the document field

**Note:** If using one of the latter two forms, this action must be sequenced prior to the document generation so that the image can be included in the document.

Alternatively, the user should check that the document field has been populated prior to manual generation of the document.

## Add the image merge field to the document template

A WORD document in .docx format must be used to create the document template.

Add the image merge field to your document template using this format:

```jinja
{{record.field\_customer\_logo[0].embedded}}
```

![Screenshot 2024-04-02 at 16.27.33.png](../../../images2/zendesk_17942924026141_002_e48720abe55e.png)

You'll note that the Autologyx logo at the top of the document template is a constant so can be included as a static image. However, the customer logo will be different per record, hence the use of the merge field.

## Control image size and layout

In this example, the image will retain its original size, no text wrapping technique has been employed, and the image may not fit exactly as you would like it.

![Screenshot 2024-04-02 at 18.06.02.png](../../../images2/zendesk_17942924026141_003_8b1b05b95fbe.png)

**Note:** When the document is generated, the unrestricted image size has caused a page break, pushing the information table onto the second page.

Recognising that the dimensions of images uploaded in document fields might not always align with the document layout, we've added a feature that enables you to tailor the image size according to your document's needs.

By using filters in the merge field, you can adjust the image width and height.

**Format:** {{record.field\_customer\_logo\[0].embedded | img\_width(40) | img\_height(40)}}

The width and height measurements are in millimetres.

You can specify only the height or only the width if preferred, and the image will maintain its aspect ratio, thus preventing size distortion.

![Screenshot 2024-04-02 at 18.50.17.png](../../../images2/zendesk_17942924026141_004_f55793222f21.png)

To optimise the placement of the image in your document, you can use a text box with the dimensions and positioning of your choice. Insert the image merge field inside the text box either with or without filters. This is particularly useful when the image is merged into text within a paragraph or next to a section of text.

**Remember:** Remove the border from the text box before you save the document template.

## Generate the document

Complete and save the document template against the object class.

This time, when the document is generated, the logo is smaller and aligned with the text. The page layout has remained intact.

![Screenshot 2024-04-02 at 18.46.18.png](../../../images2/zendesk_17942924026141_005_2101d0964227.png)

[Click here](/knowledgebase/system-configuration/working-with-document-templates/automatic-generation-of-documents-via-the-sequencer/) for a guide to automatic document generation using the sequencer.

[Click here](/knowledgebase/system-configuration/working-with-document-templates/manual-generation-of-a-document-from-a-template/) for a guide to manual document generation from the side panel.

## Useful info

1. An object class can contain up to 2000 fields.
2. An object class can contain up to 1000 document templates.

---

---
url: >-
  /knowledgebase/applied-ai/mcp-services/mcp-work/mcp-work-configuration/configure-ai-and-mcp-integrations.md
---
# Configure AI/MCP integrations

AI/MCP integrations are available from **System configuration** > **Integrations**. You can enable or disable supported integrations and, for integrations in the AI/MCP category, manage their MCP connectors.

## When to use this

Use this area when you need to enable an AI/MCP integration, review its integration configuration, or open its MCP connector management.

## Before you start

You need access to **System configuration** > **Integrations** and the permissions required to edit integrations.

## Find an AI/MCP integration

All integrations in the `ai_mcp` category are displayed in the Integrations UI and are sorted alphabetically within each Integrations tab.

Integration tiles that support MCP are labelled with **MCP** in the title in the later 1.20 UI change.

![Integrations page showing AI/MCP integration tiles labelled MCP](../../../../../images/ai-mcp-integration-tiles.png)

## Enable or disable an integration

Open the required integration and change its enabled state in the same way as other integrations. The Claude integration was moved from a hard-coded UI implementation to the normal integration API flow as part of this release.

## Manage MCP connectors for an integration

Each integration in the AI/MCP category supports MCP connector management. Use its connectors configuration control to open the **MCP connectors** list, where you can create and maintain connectors for that integration.

## Review OAuth endpoint fields

The 1.20 integration configuration adds the following URL fields to the create and edit integration interfaces:

* **Authorization URL**
* **Token URL**
* **Refresh URL**

These values are populated for the earlier OAuth flow and appear under the existing integration fields.

![Integration edit page showing Authorization URL, Token URL and Refresh URL fields](../../../../../images/integration-oauth-url-fields.png)

## Things to remember

* The integration-category implementation itself is not a visible workflow change; it is the basis for grouping and exposing AI/MCP integrations consistently.
* MCP connectors associated with an Object Class become available in that Object Class's **Applied AI** permissions selector.
* Exact integration names available to a customer may depend on the configured/released integration set.

## Useful info

1. Connector lifecycle management is handled from the integration's **MCP connectors** page.
2. Object Class associations are configured on the connector itself.

---

---
url: >-
  /knowledgebase/applied-ai/mcp-services/mcp-work/mcp-work-configuration/configure-mcp-connector-permissions.md
---
# Configure MCP connector permissions

When an MCP connector is associated with an Object Class, you can use the **Applied AI** selector in the Object Class permissions area to review and configure the permissions that apply to that connector.

## When to use this

Use MCP connector permissions when an AI/MCP connector should have a narrower set of permissions than the underlying user/API permission set allows.

## Before you start

* The MCP connector must be associated with the Object Class.
* The relevant permission set must already exist.
* An MCP permission cannot be enabled where the corresponding API/user permission is not available.

## Select an MCP connector

1. Open the Object Class and go to **Permissions**.
2. Open either **Class permissions** or **Record permissions**.
3. Use **Applied AI** to choose the required MCP connector.

The **Applied AI** selector is only shown when at least one MCP connector is associated with the Object Class. **User permissions** is the default selection. Associated connectors are listed alphabetically in the selector.

## Configure Class Permission Set permissions

With **Class permissions** open and an MCP connector selected:

1. Open the permission set's actions menu and select **Edit**.
2. Review the API/user permission column and the MCP connector column.
3. Change the enabled MCP toggles as required.
4. Click **Save** to apply the connector permissions, or **Cancel** to discard your changes.

MCP toggles are only enabled where the corresponding API permission is enabled. For Object Class permissions, the UI enforces these dependencies:

* **Edit** requires **View**.
* **Delete** requires **View**.

For Object Record permissions in a Class Permission Set, there are certain dependencies:

* **Create** requires Object Class **View**.
* **View all** requires Object Class **View**.
* **Edit all** requires **View all** and Object Class **View**.
* **Delete all** requires **View all** and Object Class **View**.

For Task permissions in a Class Permission Set:

* **Create** requires **View all**, **Edit all**, **Complete all**, and **Assign all**.
* **Edit all** requires **View all**.
* **Complete all** requires **View all**.
* **Assign all** requires **View all** and **Complete all**.

![Object Class Permission Set in edit mode showing API values and MCP connector toggles](../../../../../images/class-permission-set-mcp.png)

## Use quick actions

While editing an MCP connector's Class Permission Set, use the quick actions menu to:

* **Enable all** - turns on all MCP toggles that are currently available. Toggles disabled by API permission constraints remain off.
* **Disable all** - turns all MCP toggles off.

The wider permission-set UI also contains quick actions for user/API permission sets.

## Configure Record Permission Set permissions

With **Record permissions** open and an MCP connector selected, edit the required Record Permission Set.

For Object Record permissions, **View** and **Edit** can be configured when their corresponding API permissions are enabled.

For Task permissions in Record Permission Sets:

* MCP toggles are disabled when the corresponding API permission is off.
* **Edit all** remains disabled regardless of the API state.
* **Create** requires **View all**, **Complete all**, and **Assign all**.
* **Complete all** requires **View all**.
* **Assign all** requires **View all** and **Complete all**.

![Record Permission Set in edit mode showing API values and MCP connector toggles](../../../../../images/record-permission-set-mcp.png)

## Compare permissions

You can compare a selected permission set across users and MCP connectors.

1. Click **Compare** beside **Applied AI**.
2. Select the permission set to compare.
3. Select the subjects to compare, up to 5 maximum.
4. Review the permissions side by side.
5. Turn on **Show only differences** to focus on rows where the selected subjects differ.

Enabled permissions are shown with a check mark and disabled permissions with an X. Missing or null values are treated as disabled. Rows with differences are highlighted.

![Permissions comparison panel showing multiple subjects and highlighted differences](../../../../../images/permissions-compare-panel.png)

## Things to remember

* MCP permissions are constrained by the corresponding API/user permissions.
* **Add permission set** is disabled while an MCP connector is selected in **Applied AI**.
* Saving MCP changes updates the selected connector's permissions without changing the API permissions or other connectors' permissions.

## Useful info

1. If no connector is associated with the Object Class, **Applied AI** is not shown.
2. Removing or deleting a connector removes it from the Object Class permissions UI.

---

---
url: >-
  /knowledgebase/administration/elements/configuring-an-element-and-how-it-works-on-a-form.md
---

# Configuring an Element and how it works on a form

After you have written the JavaScript, created the required files in your Git repository, and imported your package successfully, the Element becomes available for use in Catalyst.

This article explains where Elements can be used, how they are configured on a form, and how data is passed from Catalyst to the Element.

## Where Elements can be used

Elements can be made available in the following places:

* Landing page
* Object class forms:
  * Create/Edit view
  * Summary view
  * Standalone form

The configuration process is the same in each location.

## Example: Elements on the Landing page

The following screenshots show Elements being used on the Landing page.

In this example, several Elements are available in the side panel. Two Elements have been added to a section on the Landing page.

The same Element can be used more than once on a page if required.

![Elements available in the side panel and added to the Landing page](/knowledgebase/images/administration/configuring-element-1.png)

Drag the required Element onto the page, then click it to open **Element Details** in the side panel.

The Element properties shown in the side panel are generated from the parameter objects defined in the Element package.

For example:

* `parameter_name` is `end_point`
* `parameter_description` is the help text shown below the input field
* `parameter_type` is `string`, so the field accepts free text

The information entered in this field is passed to the application iframe as part of the message data.

You must also configure the Element height. This is measured in pixels.

After configuring the Element, save the page and check that its position and size are correct.

![Element Details panel showing configurable Element properties](/knowledgebase/images/administration/configuring-element-2.png)

On the Landing page, the pie chart Element shows the total number of Tasks in the system as a percentage for each status:

* Completed
* Outstanding
* Overdue

![Landing page showing a pie chart Element for Task status](/knowledgebase/images/administration/configuring-element-3.png)

## Message data passed to the application

Catalyst passes message data to the Element application.

The example below shows message data for an Element used on the Landing page.

The `endpoint` is populated with the URL of the instance so that API calls used by the Element are sent to the correct environment.

```js
const messageData = {
  user_details: {
    access_token: "",
    first_name: "",
    last_name: "",
    user_id: 1,
    user_name: ""
  },
  object_record_meta: {
    class_id: undefined,
    record_id: undefined,
  },
  endpoint: "https://conference.autologyx.com",
  component_parameters: [
    {
      parameter_description: "Enter the API base url to be used",
      parameter_name: "end_point",
      parameter_type: "string",
      parameter_value: "/api/tasks/"
    }
  ],
  parameters: {
    end_point: "/api/tasks/",
  }
}
```

In this example, `class_id` and `record_id` are `undefined` because the Element is being used on the Landing page.

When the same Element is used on an Object class form, these IDs are passed in the `object_record_meta` section of `messageData`.

The example below shows message data for an Element used on an Object record.

```js
const messageData = {
  user_details: {
    access_token: "",
    first_name: "",
    last_name: "",
    user_id: 1,
    user_name: ""
  },
  object_record_meta: {
    class_id: 265,
    record_id: 17521,
  },
  endpoint: "https://conference.autologyx.com",
  component_parameters: [
    {
      parameter_description: "Enter the API base url to be used",
      parameter_name: "end_point",
      parameter_type: "string",
      parameter_value: "/api/tasks/"
    }
  ],
  parameters: {
    end_point: "/api/tasks/",
  }
}
```

In this case, the Element uses the `record_id` to fetch Tasks related to the selected record and display their statuses in the donut chart.

![Object record showing an Element displaying Task status information](/knowledgebase/images/administration/configuring-element-4.png)

## How message data is received

The message data is passed from Catalyst into the iframe running the Element code.

To receive the message data and allow the Element to work, your Element code must include an event listener.

The example below uses a React hook.

```js
import { useState } from "react";
import { MessageData } from "../types/interfaces";

export const useMessageData = () => {
  const [messageData, setMessageData] = useState<MessageData | undefined>();

  window.addEventListener("message", (event) => {
    const messageData: MessageData = event.data || {};
    if (messageData.user_details) setMessageData(messageData);
  });

  return {
    messageData,
  };
};
```

Whenever the message data changes, the event listener is triggered and the data is saved into the `messageData` variable.

The access token expires every five minutes. It is automatically passed again to the iframe and the message data is updated.

## Things to remember

1. Elements can be used on the Landing page and on Object class forms.
2. The same Element can be used more than once on a page.
3. Element properties are generated from the parameter objects defined in the Element package.
4. Elements used on the Landing page do not receive `class_id` or `record_id`.
5. Elements used on Object class forms receive `class_id` and `record_id` in `object_record_meta`.
6. Your Element code needs an event listener to receive message data from Catalyst.
7. The access token is refreshed automatically and re-passed to the iframe.

---

---
url: >-
  /knowledgebase/administration/communication/configuring-outbound-mail-setup-with-microsoft-client-credentials.md
---

# Configuring Outbound mail setup with Microsoft client credentials

## Step 1: Register an application in Microsoft Entra

1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) Portal.
2. Navigate to **App registrations**.
3. Click **New registration**.
4. Enter a name for your application (for example, "Mail OAuth Integration").
5. Under **Supported account types**, select an option based on your needs:
   * Accounts in this organizational directory only (Autologyx Test only - Single tenant).
   * Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant).
6. Click **Register**.

## Step 2: Configure API permissions

1. In your registered application, go to **API Permissions**.
2. Click **Add a permission > Microsoft Graph > Delegated permissions**.
3. Select the following permission:
   * `Mail.Send`
4. Click **Add permissions**.
5. Click **Add a permission > Microsoft Graph > Application permissions**.
6. Select the following permission:
   * `Mail.Send`
7. Click **Add permissions**.
8. Click **Grant admin consent for \[Your Organization]** to apply permissions.
9. Your app API permissions should look as below:

   ![](../../../images2/zendesk_4673856296095_001_c5246e5d34fe.png)

## Step 3: Create a client secret

1. Navigate to **Certificates & secrets**.
2. Under **Client secrets**, click **New client secret**.
3. Enter a description (for example, "Mail Integration Secret").
4. Set the expiration period. Take note of the expiry date, as a new secret will have to be created when this one expires.
5. Click **Add** and copy the generated secret.
   * **Important:** This secret will only be displayed once. Store it securely.

## Step 4: Assign an Exchange Online license

1. Go to [Microsoft 365 Admin Center](https://admin.microsoft.com) and log in with an admin account.
2. Find the e-mail for setting up your email in Catalyst:
   * Navigate to **Users > Active users**.
   * Search for an e-mail address (for example, "sample@outlook.com").
3. **Assign a license**:
   * Click on the user.
   * Go to the **Licenses and Apps** tab.
   * Look for **Exchange Online (Plan 1 or Plan 2)** or any **Microsoft 365 license that includes Exchange**.
   * If the user does not have an Exchange Online license, **assign one**.
4. Set the expiration period.
5. Click **Save changes** and wait a few minutes for the changes to take effect.

## Step 4: Retrieve the required information

**Gather the following details:**

1. **Tenant ID**: Found under Microsoft Entra admin center > Overview.
2. **Client ID**: Located in the App registration overview.
3. **Client Secret**: Generated in Step 3.
4. **Scope**: `https://graph.microsoft.com/.default`

## Step 5: Add OAuth configuration in Catalyst

1. Go to **Administration > Authentication objects**.
2. Click the **Create** button on an Authentication objects list.
3. Select **Microsoft oAuth 2.0 (Client Credentials flow)** as the Provider.
4. Fill in the required fields using the details from Step 4.\
   ![](../../../images2/zendesk_4673856296095_002_e84cdb54527f.png)

## Step 6: Test and save the Authentication object

1. Click **Test** to verify the Authentication Object.\
   ![Test.gif](../../../images2/zendesk_4673856296095_003_55671d1421be.gif)
2. If the test is successful, click **Save**.

## Step 7: Configure the Outbound mail setup

1. In **Outbound mail setup**, select **Microsoft Office 365 Exchange (Graph) with oAuth 2.0** as the mail service you will be using.
2. Choose the newly created Authentication Object from the dropdown.
3. **Complete** the Microsoft Client Credentials Settings section.
4. Click **Test mail settings** to verify the configuration.
5. If successful, click **Save**.

![](../../../images2/zendesk_4673856296095_004_3c407b641adc.png)

---

---
url: >-
  /knowledgebase/system-configuration/object-class-relationships/configuring-relationships-in-object-classes.md
---

# Configuring relationships in Object classes

Having used the [Relational modeller](https://ng-autologyx.zendesk.com/hc/en-us/sections/10381782694301-Relational-Modeller) to create parent/child relationships between your Object classes, you now need to edit each parent object class in order to add the available child Object classes. This will provide the interface for a user to create relational records.

This is done on the create/edit view under the **Display** tab. Each parent will have to be updated individually.

## Example relationship

As a reminder, below is one of the relationships we saw in the article about [creating a Relational model](/knowledgebase/system-configuration/relational-modeller/creating-the-relational-model/).

![](/knowledgebase/images/img_10495069833245_1776895899.png)

The parent object class, Mortgage Application, has four child object classes:

* Applicant 1
* Applicant 2
* Properties
* Lender

## Add child Object classes to the form

|  |  |
| --- | --- |
| In the create/edit view of the parent class, Mortgage Application, there is a new section which has been added to the bottom of the side bar, "**CHILD OBJECT CLASSES**".  The four child object classes are listed in alphabetical order. These can be dragged and dropped into the create/edit form in the same way as sections, instruction widgets and fields.  Note in this sidebar, the fields section is collapsed. |  |

**Add the first child object class**

Drag and drop your first object class onto the form. You can add it to an existing section, but it is likely that you will want to edit your view by adding a new section or a new column to an existing section in order to accommodate the object class.

When the child object class has been added to the form, you will note that it is greyed out in the sidebar. This is because you will only need it once.

![r3.png](/knowledgebase/images/img_10495069833245_1776895899.png)

## Configure child object class display fields

You can now configure the child object class display with fields from that class. The default fields shown are **ID** and **Actions**.

**Add fields to display**

Click anywhere on the field column header; a plus symbol (+) will appear between these two fields.

![r4.png](/knowledgebase/images/img_10495069833245_1776895900.png)

Click the + symbol. This will open the add field panel - it is the same as used in the column configuration function on the records list and is divided into **Record properties** and **Class fields**.

![](/knowledgebase/images/img_10495069833245_1776895900.png)

Check the boxes adjacent to the fields you require for the view. Then click the **'+ Add columns'** button.

You can reduce the column size by clicking on and dragging the column divider. If your columns exceed the given window, there will be a horizontal scroll bar at the bottom of the window.

![](/knowledgebase/images/img_10495069833245_1776895900.png)

Click out of the section to save the field selection.

## Multi-level relationships

The relationship shown above is only two levels deep. As you will be aware, the Relational modeller allows you to create relationships which have up to five levels.

|  |  |
| --- | --- |
|  | The relationship shown to the left has three levels.  However, **each parent object class will only have their direct child object classes available** in the sidebar. See the below screenshots. |

![r1.png](/knowledgebase/images/img_10495069833245_1776895900.png)

![r2.png](/knowledgebase/images/img_10495069833245_1776895901.png)

## Finish configuration

**Complete the setup**

Continue placing the child object classes into the form so that each is greyed out, and configure the required fields before saving.

![](/knowledgebase/images/img_10495069833245_1776895901.png)

---

---
url: /contributing.md
---

# Contributing

This page outlines the rules to follow when writing documents. Please review them before creating any new content or making edits.

::: tip
Make sure to first scroll through [Vitepress official documentation](https://vitepress.dev/guide/what-is-vitepress).
:::

## General rules

* Keep `120` characters for line (if possible).
* Keep documents small. Split files for multiple if that can be realized.
* Follow [API standards](/api/standards/)

::: tip
Please refer to Vitepress [Markdown guide](https://vitepress.dev/guide/markdown).
:::

## File naming

There are a few file naming rules that help keep the codebase consistent and thus more readable.

* Files and folders should use `kebab-case`, e.g. `object-classes.md`.
* Files should be named after the resource they describe, e.g. `object-record-permission-sets.md`. The only exception
  to this rule are `index.md` files, which serve as a fallback files for directories.

## File structure

The codebase is organized with a clear folder structure that directly reflects the logical layout seen by the end user.
The purpose of this structure is to ensure that file and folder names match the way documentation is presented, with
each path representing the actual URL seen in the browser.

* API-related content lives in the `./docs/api` folder.
  * Catalyst API reference documentation resides in the `./docs/api/catalyst` folder.
  * Event History API reference documentation is stored in the `./docs/api/event-history` folder.
  * API standards documentation is located in the `./docs/api/standards` folder.
* Additional "helps" not directly related to the API are located in the `./docs/helps` folder.

Each file and folder in the structure should match its respective URL path. For example, if the URL is `/helps/enviroments/tenants`,
the corresponding file should be nested under `./docs/helps/enviroments/tenants.md` to ensure consistency.

::: info Note
Each directory can contain its own media folder, reserved exclusively for media files (e.g., images, videos) used by
its child files and folders. This keeps all media assets organized and ensures that each section’s assets are easy to
locate without cluttering other directories.
:::

### Sidebars and nested structure

When a page includes a sidebar, the sections and nesting in the sidebar should also be reflected in both the URL and
folder structure. This approach ensures a consistent and intuitive experience for users, with clear divisions between
different content sections.

::: tip For example
If the `/api/catalyst/` page has a "Resources" section in its sidebar, then this structure should be mirrored in the
URL and folder layout. So if there’s a e.g. "Roles" document under "Resources", the correct URL would be `/api/catalyst/resources/roles.html`,
and the file structure should be `./docs/api/catalyst/resources/roles.md`.
:::

This alignment between sidebar organization, URLs, and file structure keeps different sections distinct and prevents content from different topics or sections from being mixed up in the codebase.

### Reasoning

Having the file structure mirror the URL path is essential for several reasons:

* **Logical Organization**: This approach keeps the documentation logically structured, making it easier for both users and
  developers to find content intuitively.
* **Edit Page Button Functionality**: Each page includes an "Edit Page" button at the bottom, allowing users and developers
  to jump directly to the corresponding file in GitLab. This link relies on the URL structure, so if the file structure
  in the codebase doesn’t match the URL path, the "Edit Page" feature will not work correctly.
* **Maintainability and Consistency**: A consistent structure between URLs and file paths simplifies maintenance and helps
  avoid confusion when updating or adding content.

## Headings rules

* Main title of a document should be level-1 heading - `#`.
* Sections should start from level-2 - `##`.

```markdown
# Document title

## Section 1

### Section 1.1

#### Section 1.1.1

### Section 1.2

## Section 2
```

## Document templates

When documenting a new API resource simply copy, paste and adjust the prepared template file located under
`./docs/contributing/api-resource-template.md`. Do not re-order sections from the template.

## Sidebars

Some pages, such as `/api/catalyst`, have sidebars which are defined in `config.mts` file. In these scenarios, new
pages must be appended to a given sidebar, by editing its corresponding configuration file. Sidebar configs can be
found under `./docs/.vitepress/consts` directory.

::: danger Important
Sidebar items should be sorted alphabetically.
:::

## Helpers

* Pycharm has built-in Markdown editor. In context menu there is an option to paste link, image, table, TOC. Click
  `right mouse button` -> `Insert` and choose option.
* To create table or copy it from other editor use [tablesgenerator](https://www.tablesgenerator.com/markdown_tables)

---

---
url: >-
  /knowledgebase/system-configuration/merge-fields/controlling-whitespace-in-jinja-and-why-it-matters.md
---

# Controlling Whitespace in Jinja (and Why It Matters)

Jinja2 is a templating engine used in Autologyx to dynamically generate content using data, logic, and expressions.

When working with Jinja, it is important to understand how whitespace is handled, as it can affect the validity and formatting of your output.

By default, Jinja preserves whitespace, including spaces and line breaks. While this can improve template readability, it can also lead to unexpected or invalid output.

In cases where exact values are required—such as Booleans, JSON, or API payloads—extra whitespace can cause errors or incorrect behaviour.

## Example: Whitespace Causing Invalid Output

Consider a Boolean local variable. The output must be strictly `true` or `false`, with no additional characters.

```jinja
{% if 1 == 1 %}  
    true  
{% else %}  
    false  
{% endif %}
```

Although this is readable, it renders with leading/trailing spaces and line breaks, resulting in an invalid Boolean value.

## Solution: Use Whitespace Control

Jinja provides whitespace control using a hyphen (`-`), known as a *whitespace control modifier*. This removes whitespace before or after a block.

```jinja
{%- if 1 == 1 -%}  
    true  
{%- else -%}  
    false  
{%- endif -%}
```

Even though the template includes spacing for readability, Jinja strips all surrounding whitespace.

**The final output is exactly:**

true

(or false), with no extra characters.

## Document Automation Example (Including For Loops)

When generating documents, whitespace can create visible layout issues.

### Without whitespace control

```jinja
{% for item in items %}  
```

Item: {{ item }}

```jinja
{% endfor %}
```

This renders a line break before and after each item, resulting in two line breaks between consecutive items. In document generation, these blank lines may accumulate and cause unintended spacing or even additional blank pages.

### With whitespace control

```jinja
{%- for item in items -%}  
```

Item: {{ item }}

```jinja
{%- endfor -%}
```

This removes the extra line breaks, producing clean, consistent output without unintended gaps.

## Other Common Use Cases

Whitespace control is important anywhere exact output is required, including:

* **Boolean variables** — must be exactly `true` or `false`
* **JSON generation** — extra whitespace can break formatting or validation
* **API request bodies** — unexpected characters can cause request failures
* **Document automation** — when using Jinja to render documents, whitespace around control structures (such as for loops) can introduce unintended blank lines or page breaks. This may result in extra blank pages in generated documents.

## Key Takeaway

**Jinja does not automatically trim whitespace.** Use {%- and `-%}` to ensure your output is clean, predictable, and free from unintended whitespace when formatting matters.

---

---
url: >-
  /knowledgebase/system-configuration/working-with-document-templates/create-a-document-template.md
---

# Create a Document Template

In order to create or edit a Document Template, you will need one of the following:

* A Super Admin user account
* A Role with permission to edit object classes
* Be a member of a Permission set which allows the User to edit a specific Object class

Document templates are created for specific object classes so that the document can be generated either manually or in a sequence for records in that class. Object class fields and fields from related object classes can be used to merge into the template.

## Create the document template

From the main navigation menu, click Object classes under System configuration. Find the required object class and double click or select **Edit** in the Actions menu to open it.

Go to the **Document templates** tab and click **+ Create**.

The create page consists of **3 fields**:

* **Template file name**: mandatory. The template name must be unique in the context of the object class.
* **Description**: allows the user to add notes about the template being created. This is useful particularly where you have several similarly named documents which are used under different circumstances, or indeed, for users tasked with editing templates which they did not create. This field is limited to 500 characters; a counter shows characters used/remaining.
* **Upload template file**: mandatory. The saved Word document can be browsed for or dragged and dropped in.

The **Save** button will be disabled until the template file name and the upload template file fields have been populated.

When a file has been uploaded, the upload area is hidden. The file will appear in its own uploaded field tile. The name will appear as a link. If this is clicked, the document will download.

The tile also contains a delete button (**X**) which will remove the file and allow an alternative to be uploaded in the file drop area, which will reappear.

Finally, there is a radio button which, when enabled, will allow you to manually generate the template for a given record from the Templates tab in the side panel. Find out more about [Manual generation of a document from a template](/knowledgebase/system-configuration/working-with-document-templates/manual-generation-of-a-document-from-a-template/) which describes how this works.

When you have completed the create page, click **Save**. The green success toast will fly in stating that "The document template has been created".

However, if the template name is not unique, the following error will be shown and the name will have to be amended before the template can be successfully saved:

![Screenshot 2024-01-15 at 14.50.25.png](/knowledgebase/images/img_11577504591773_1776895843.png)

On save, the user is taken back to the document templates list.

The template file name and the description fields will be available for selection in the document templates list.

## Add merge fields if needed

The above is all you need to do where the document template is the same in all cases; in other words, when it requires no personalisation with the input of data from records via merge fields.

However, this is most often not the case. Please see the [MS Word-add in article](/knowledgebase/system-configuration/working-with-document-templates/ms-word-add-in---configuration/) for how to set up the Catalyst Word Add-in which will allow you to easily select and position the required merge fields from your object class into the document template.

If you don't have access to the Word Add-in, view the article which explains [the correct syntax for merging field data](/knowledgebase/system-configuration/merge-fields/syntax-for-merge-fields/) into your document template.

## Useful info

1. You can create up to 1000 document templates in any object class.
2. Only one document can be uploaded to create the template.
3. Documents uploaded as templates must be in .docx format. Files with other extensions are not supported and will not insert or drop into the file upload area.

---

---
url: /knowledgebase/system-configuration/object-classes/create-a-standalone-form.md
---

# Create a Standalone Form

A standalone form is used for the creation of records in an object class. It will therefore only contain object class fields, ie not non-object class fields.

A link to the form can be made available via a link on the landing page or hosted away from the application, if required. However, a user of the form must have permission to create records specifically for that object class, and they will be required to log in to the form in order to use it.

## Who can create a standalone form

**Users with one of the following can create a standalone form:**

* Super admin account type
* Config admin account type with a Role which allows them to Edit object classes
* Owner of the object class
* Permission set allowing them to Edit the object class

## Steps for creating a standalone form

1. Navigate to the required object class and then to the Forms tab.
2. Click the **+ Create** button.
3. The canvas is presented as the below screenshot with one Section. Enter a name. This field is mandatory and must be unique in the scope of the object class.

![0507a.png](/knowledgebase/images/img_19979679730333_1776895951.png)

### Buttons above the section

There are 3 buttons on the left-hand side above the section:

* **Enable** - this will remain inactive until you have at least one field on the canvas.
* **Redirect** - once enabled, this allows you to enter a URL where the user will be redirected once the form has been submitted. If you leave Redirect disabled, the user will see the default confirmation, as below, on submission of the form:

![Screenshot 2024-07-08 at 14.34.11.png](/knowledgebase/images/img_19979679730333_1776895951.png)

* **Submit** - this button is enabled by default. Disabling it will mean that the default Submit button will be removed from the form. Users will still be able to create records if the form is used on the landing page in an Element - which has its own submit button - or in an Element with the iframe to a third-party system.

4. Click on the section and rename it in the side panel in the Label field. The Alias will be auto-populated but can be edited at this stage.

5. Configure the columns and drag on object class fields.

![0507b.png](/knowledgebase/images/img_19979679730333_1776895951.png)

6. Click on each field so that the side panel displays **Field Options**.

### Options available on each field type

* **Required** - when enabled, this field will be mandatory on the form.
* **Read-only** - when enabled, the user completing the form will see the value but not be able to edit it.

![0507d.png](/knowledgebase/images/img_19979679730333_1776895952.png)

Input type will be available for some field types. For example:

* **Text** - Single or Multi line (shown below)
* **Single select** - Dropdown list or Radio buttons

![0507c.png](/knowledgebase/images/img_19979679730333_1776895952.png)

7. Continue adding sections and fields, and use conditional logic where required.

### Useful buttons while creating and editing the form

Use the **Preview** button at the top right-hand side to check that the form looks and performs as you want. Two other buttons in this location are also useful while creating and editing the form:

* **Revert** - clicking this will remove any unsaved changes and revert the form to its last saved state.
* **Cancel** - clicking this will return the user to the Forms list.

If changes have been made and not saved, in either case the user will be required to confirm the action.

|  |  |
| --- | --- |
| Revert | Cancel |
| revert.png | cancel.png |

8. Remember to **Enable** the form and then **Save**.

9. You will be taken to the Forms tab where you will see the form at the top of the list.

![0507e.png](/knowledgebase/images/img_19979679730333_1776895953.png)

There is a column configuration function on this list but, in default mode, you can clearly see under the **Status** header whether the form has been enabled.

The Name and URL column headers cannot be removed from the list.

Alongside the URL is a copy button. The Actions menu also contains an option to **Copy URL**.

![0507f.png](/knowledgebase/images/img_19979679730333_1776895953.png)

### Other available column headers

* **Created** and **Created by** - these will show the date/time the form was created and the user who created it.
* **Last edited** and **Last edited by** - these will show the date/time the form was last edited and the user who did this.

10. To test the form, open a new browser tab and paste the copied URL into it.

Note that the submit button will not be enabled until all mandatory fields have been completed.

![0507g.png](/knowledgebase/images/img_19979679730333_1776895953.png)

11. Once submitted, go to Workspace/Records and filter to the relevant object class. Depending on whether there are already existing records and how the list is sorted, the record may be added to the top, as below.

![0507h.png](/knowledgebase/images/img_19979679730333_1776895953.png)

## Related articles

These articles will provide more details to help you construct the form:

```json
[SECTIONS AND INSTRUCTIONS](/knowledgebase/record-and-task-forms/formbuilder-components/layout---sections-and-instructions/)
```

[CONDITIONAL LOGIC](/knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/using-conditional-logic-in-a-form/)

[OBJECT CLASS FIELDS](/knowledgebase/system-configuration/object-classes/object-class-field-types-uses-and-attributes/)

## Useful info

1. Each object class can have up to 100 standalone forms.
2. Each standalone form can have up to 200 components (sections, instructions and fields).

---

---
url: /knowledgebase/system-configuration/create-and-manage-your-data-model.md
---
# Create And Manage Your Data Model

**This section is currently empty or under construction.**

---

---
url: /knowledgebase/release-notes/release-notes-1.5/create-task-actor.md
---

# Create task actor

This release is all about simplifying and optimizing your workflow automation experience.

We have removed the Task templates section with the list of available task templates from the side panel. Instead, we introduce the Create task actor.

## Overview

**Configuring tasks is now more intuitive than ever.** No more endless scrolling through a sea of templates.

The Create task actor comes with an intelligent autocomplete search feature. Type in your desired task template, and the results will appear instantly.

![CreateTask\_article.gif](/knowledgebase/images/img_12725533729181_1776895686.png)

## Behavior

**When a task actor is executed for a given record,** the Sequencer creates the corresponding task if it does not already exist.

If the Create task actor is left without any task template selected, the sequence execution engine halts at the actor, preventing unintended actions.

## Events and conditions

**Task actors trigger events** such as Task created and Task completed, providing valuable insights for your workflow automation.

You can also define various conditions to enhance event handling further.

## Summary

**This addition is designed to streamline your task management process** and significantly boost your efficiency within the Sequence designer.

Embrace the future of task automation with Create task actor and discover a whole new world of possibilities.

---

---
url: /knowledgebase/system-configuration/sequence-actors/create-task-actor.md
---

# Create Task Actor

## What does the Create Task actor do?

The Create Task actor is used to create a task from a task template (of the "Automatic" Task creation mechanism) for a record at the required point in the workflow.

This actor is used the first time a task is created for a record from a task template. Subsequent tasks from the same template will require the use of a [**Set Task actor**](/knowledgebase/system-configuration/sequence-actors/set-task-actor/).

![Create Task Workflow Automation](/knowledgebase/images/img_5565921479967_1776895826.png)

## How do I use the Create Task actor?

**To use the Create Task actor:**

1. Click, drag and drop the Create Task actor onto your sequence workspace.
2. Take a trigger to it from the preceding object (this will most often be a Task Assignment actor) and set your trigger conditions. It is worth noting that by default a Task has no assignees unless it is preceded by a [**Task Assignment actor**](/knowledgebase/system-configuration/sequence-actors/task-assignment-actor/) or default task assignees have been configured for the sequence, as shown below.

![Screenshot 2026-04-14 at 11.57.20.png](/knowledgebase/images/img_5565921479967_1776895826.png)

3. Right click on the Create Task actor and select Configure. The Create Task Configuration window will open.

![Screenshot 2026-03-26 at 16.46.39.png](/knowledgebase/images/img_5565921479967_1776895826.png)

**Finding a task template**

The Create task actor comes with an intelligent autocomplete search feature. Click into the Search field; available task templates will be displayed in alphabetical order by name.

"Available task templates" means those of the Update object record type which have been created for the sequence object class and those of the "Complete self contained form" type. The latter task templates are available for use in any object class sequence.

![Screenshot 2026-03-26 at 16.51.42.png](/knowledgebase/images/img_5565921479967_1776895827.png)

Type in your desired task template, and the results will appear instantly.

![Screenshot 2026-03-26 at 16.52.47.png](/knowledgebase/images/img_5565921479967_1776895827.png)

|  |  |
| --- | --- |
| Click to select the task template.  Save the configuration.  The Create Task template will display the task template name and ID number.  If the label is too long it will be truncated but can be viewed by hovering over the name. | Screenshot 2026-03-26 at 16.53.31.png |

**How task creation behaves**

When a Create Task actor is executed for a given record, the Sequencer creates the corresponding task if it does not already exist. This is because the actor is designed to create only one task from the Create Task actor for any record. It will only create another if the first has been deleted.

|  |  |
| --- | --- |
| If the Create Task actor is left without any task template selected, the sequence execution engine halts at the actor, preventing unintended actions.  It is easy to spot a Create Task actor which has not been configured/saved because not only will the label say "Create Task" but alongside will be the red warning exclamation mark. | Screenshot 2026-04-13 at 16.13.13.png |

**Trigger connections and defaults**

A Create Task actor can be connected by a trigger to any other sequence actor.

**The default trigger conditions are:**

* When Task Created
* When Task Completed

![Screenshot 2026-04-13 at 16.24.31.png](/knowledgebase/images/img_5565921479967_1776895828.png)

These can of course be changed to X time period After either Task Created or Completed.

The trigger condition "When Task Completed" is the most commonly used, especially where you want to reference field data captured in the task in the following trigger conditions, thus allowing the workflow to follow different routes depending on the task response.

## Unique functionality

Task Created and task Completed triggers are not dependent on any upstream workflow.

If a Create Task actor is used to create the same task in multiple sequences, this can inadvertently trigger multiple events by creating or completing one task. In other words, a Create Task actor used to create the same task in more than one sequence is considered the same object.

**No other sequence actor works in this way!**

**Useful info:**

1. A Catalyst system can contain up to 10,000 task templates.

---

---
url: /knowledgebase/system-configuration/sequences/creating-a-sequence.md
---

# Creating a Sequence

## Prerequisites

In order to create a Sequence you must have the following:

* A Super admin account, or a Role where the system permission under the Sequencer tab has been enabled for Create and you are an Owner of the Object class
* The Object class configured for which you are to Create the Sequence

In addition, it would be useful to have the User or Users set up who are to be the default task assignees. However, you can return later to Edit the Sequence properties and add or amend these.

## Create a Sequence

Sequences can be created from the Sequences list. Click the **+ Create** button and the page will display as below:

![mceclip0.png](/knowledgebase/images/img_6231828423069_1776895988.png)

### Complete the required fields

**Sequence Name** is a required field, with a character limit of 100, in which a unique value must be entered. You will see the non-unique name error if you try to use a name which already exists.

![mceclip0.png](/knowledgebase/images/img_6231828423069_1776895988.png)

**Description** is optional. Here you can add internal notes about the sequence eg to describe in what instance it is used, what process or sub-process it contains, etc. This can be useful information for Users who have access to Edit the Sequence but who were not responsible for creating it. You'll note that this field has a character limit of 500.

The Object class field is mandatory. If you click into it and do not make a selection, the **Field is required** error will be shown.

![mceclip2.png](/knowledgebase/images/img_6231828423069_1776895988.png)

It is a searchable select field in which you will be able to choose one Object class.\* The Sequence will run against Records in this Object class when the starting conditions have been met and the Sequence status is running.

### Add default task assignees

**Default task assignees** can be selected and will be used every time a Task is created by the sequence.

|  |  |
| --- | --- |
| When the **Manage default task assignees** button is clicked, the Manage default task assignees panel will open in the right of the screen.  You will note that the Default task assignees counter is on zero. | ![mceclip4.png](../../../images2/zendesk_6231828423069_004_7786909cdebc.png) |

|  |  |
| --- | --- |
| Click **Add default assignees**, a search field will be presented. Start typing the first or last name of the first assignee; the list will filter to the matching Users.  You can also search by email address as this too is a mandatory field when creating Users. | ![mceclip5.png](../../../images2/zendesk_6231828423069_005_008ef5b3563e.png) |

|  |  |
| --- | --- |
| Click on the User tile to select them and then click Add. Continue adding Users until all those required have been selected.  Users already selected will be greyed out, unavailable for selection and the **Already added** label will appear alongside their email address. | ![mceclip7.png](../../../images2/zendesk_6231828423069_006_5f1d3398b57d.png) |

![mceclip6.png](/knowledgebase/images/img_6231828423069_1776895989.png)

You will note that the panel now displays the number of Default task assignees and the Avatars of those Users can be seen in the main content area to the left of the **Manage default task assignees** button.

A User can be removed from the list by clicking the X in his/her tile and the Default task assignees counter will decrement.

### Save the Sequence

|  |  |
| --- | --- |
| The Cancel button, in the top right hand side, will allow the User to abort the creation of the Sequence. If clicked, the usual **Unsaved changes will be lost** warning modal will be displayed.  If you confirm **Yes**, you will be taken back to the Sequences list.  If you select **x No, go back** the create page will remain open so that you can continue. | ![mceclip1.png](../../../images2/zendesk_6231828423069_008_64321aa7ba7e.png)  You will also see this warning if you navigate away from the page. |

**Save** will be disabled until all mandatory fields have been populated.

When Save is enabled and clicked the green success toast fly in will be displayed. You will be taken to the the Sequences list. Unless you have applied filtering or sorting to your Sequences list the newly created Sequence will appear at the top of the list. It will be in a Paused state.

|  |  |
| --- | --- |
| The **Actions** menu for your Sequence will now contain 3 options.  Please see related articles for information on:  - Edit properties  - Edit design | ![mceclip0.png](../../../images2/zendesk_6231828423069_009_0b8393ae7435.png) |

## Useful info

1. \*Super admin Users will have access to all Object classes while Users with a Standard account type and Role permissions which allow them to Create Sequences will only be able to select Object classes for which they are an Owner. If they are not the Owner of any Object class, the below error message will be displayed and the Object class field will be disabled as will the Save button:

![mceclip3.png](/knowledgebase/images/img_6231828423069_1776895990.png)

|  |  |
| --- | --- |
| 2. The maximum number of Default task assignees that can be selected is 100. If you reach this number an error message will inform you and the Add default assignees button will be disabled. | ![blobid1.png](../../../images2/zendesk_6231828423069_011_84e7e02e1023.png) |

3. The maximum number of Sequences you can create is 1,000. If this number is reached the Create button will be disabled.

---

---
url: >-
  /knowledgebase/using-help-and-support/we're-here-to-help/creating-a-support-ticket.md
---

# Creating a support ticket

---

---
url: >-
  /knowledgebase/system-configuration/object-classes/creating-object-class-fields.md
---

# Creating Object class fields

This article assumes that the User has the appropriate Role and/or Permission set to allow them to edit an Object class.

## Overview

When in an Object class edit page, the first of five tabs provides an area where fields can be created, edited and removed. The Actions menu also has an option to **View usage**.

The screenshot below shows a newly created Object class which has not yet had fields configured for it. You will note that the field counter at the top left-hand side of the tab is zero (0).

![1006b.png](/knowledgebase/images/img_5962412140317_1776895932.png)

## Add a field

To add the first field, click the **+ Add field** button on the top right-hand side of the tab. This will open the **Add field** panel.

![mceclip0.png](/knowledgebase/images/img_5962412140317_1776895932.png)

The **Add field** panel can contain up to three different sections depending on the field **Type** that is selected. It opens with **Text** Type selected by default. All sections are collapsible.

### Field Properties

Under the **Field Properties** section, which is present for all field types, there are three mandatory fields:

* **Label** is the field name as displayed on the Object record. Unlike the Label field on a Task form, the Label here must be unique in the scope of the Object class. The maximum number of characters allowed in this field is 100.
* **Alias**: again, this value must be unique in the scope of the Object class. Initially the Alias is populated from the Label but you can change it if required. However, if a user edits the Label after the field has been saved, the Alias does not change.

|  |  |
| --- | --- |
| The Alias is used in merge fields. The screenshot shows an example where Object class fields have been merged into a Send Message Actor which is part of an automated workflow in a Sequence.  Aliases are also used in API requests and responses as well as document templates. | mceclip0.png |

* **Type**: this is a drop-down, single select list of the available field types. View information on [field types, their uses and attributes](/knowledgebase/system-configuration/object-classes/object-class-field-types-uses-and-attributes/).

### Selection Options

The **Selection Options** section is only shown for field types **Single select**, **Multi select** and **User**. This allows you to define what options will be available in the drop-down, radio buttons or checkboxes for the select types, and which users will be available in the User field.

### Validation

The **Validation** section is shown for field types **Text**, **Integer**, **Decimal**, **Multi select**, **Email**, **Phone**, **Document** and **User**. It allows you to add validation such as force unique value, maximum/minimum number of selections or number of documents allowed.

Configure your new field as required. Note that the **+ Add** button will remain disabled until all mandatory fields have been completed in the Add field panel.

![mceclip1.png](/knowledgebase/images/img_5962412140317_1776895933.png)

Click the **+ Add** button on the bottom right-hand side of the panel. The green toast success message will be shown on-screen. Note that when the field is saved, the Add field panel remains open so that you can continue adding further fields. Each new field added will appear at the top of the fields list.

![mceclip2.png](/knowledgebase/images/img_5962412140317_1776895933.png)

## Fields list

The Fields list contains five columns which are static; there is no column configuration setting. You can change the column width by dragging right or left on the column delineation. The column headers are self-explanatory.

It is worth noting that in any Object class you can have none, one or more fields for which, in the Validation section, **"Unique value"** is enabled. This means that no records in that class can contain the same value in a field marked Unique (see Agreement Number in the screenshot below).

The furthest right column is the Actions menu which, dependent on a User's permissions, has three options: **Edit**, **View usage** and **Remove**.

This list also has a Search field where you can search for fields by Label; search is not case sensitive.

Another important feature of this list is the ability to re-order the fields by dragging and dropping into place. However, please note that this feature is disabled if you have any side panels open or when the search filter is applied. The dotted drag-and-drop indicators are shown on the left-hand side of every row when reordering is allowed:

![Reorder\_fields.jpg](/knowledgebase/images/img_5962412140317_1776895934.png)

## Identifier

Also noteworthy is the use of the **Identifier**.

Only one field in an Object class can be used as the identifier. If no field is given this property, the Autologyx ID Number will automatically be used as such.

![identifier.png](/knowledgebase/images/img_5962412140317_1776895934.png)

The field marked Identifier will be shown for records in the:

|  |  |
| --- | --- |
| - top left hand corner of the card view | card\_view\_identifier.png |
| - top of the Tasks, Templates, Activity log and Record access panels | record\_panel\_identifier.png |

Find out more about List pages and Card view [list pages](/knowledgebase/finding-your-way-around/ui-and-navigation/list-pages/).

## Useful info

1. The maximum number of fields which an Object class may have is 2,000.
2. If you enable the Unique value in any Object class field, this means each Object record where that field is populated must contain a unique value. This feature can be used to de-duplicate records within an Object class.
3. Only field types **Text**, **Integer**, **Email**, **Phone**, **Date**, **Date/Time** and **URL** can be used as the Identifier. An Object class can have only one field marked as the identifier. If a User selects a new Identifier field, the previous Identifier is automatically checked off.

---

---
url: >-
  /knowledgebase/system-configuration/relational-modeller/creating-the-relational-model.md
---

# Creating the Relational model

View an article which explains [who can create/edit the relational model](/knowledgebase/system-configuration/relational-modeller/who-can-create-a-relational-model/).

Before you can use the Relational modeller to configure parent/child relationships between Object classes, your Object classes must have been created. Later, you will need a create/edit view enabled under the display tab for each parent class so that child object classes can be added to the parent view.

## Open the Relational modeller

Go to the System configuration section of the main navigation menu. Click **Relational modeller**. If no relationships have been configured, the page will be displayed like this with a blank canvas.

![](/knowledgebase/images/img_10381821293725_1776895904.png)

You'll notice that the page title is, "Edit relational model". This is because the Catalyst system is provided with a default empty model, so effectively you are in edit mode.

## Page components

The page components are:

* **Relational model canvas**. There is a prompt on the canvas advising you to drop an object class on it to get started.
* **Sidebar**. All object classes are shown in a list on the right-hand side. They are presented in alphabetical order by the object class name. There is a search facility so that if your system has a lot of object classes, you do not have to scroll through them to find the required one.
* **Save** and **Cancel** buttons. These are available above the canvas on the right-hand side.

## Build the model

Go to the sidebar and click, drag, and drop the first class for your model. This will automatically centre at the top of the canvas.

![rm3.png](/knowledgebase/images/img_10381821293725_1776895904.png)

In addition, the starting prompt is removed and three control buttons appear on the top left-hand side of the canvas. These allow you to **zoom in**, **zoom out**, and **reset**.

There will be a bin icon on the object class which will allow you to remove it.

|  |  |
| --- | --- |
| In the sidebar your chosen object class will be greyed out as an object class can only be used once in the relational model. |  |

This first object class is a **root parent class**.

The next one you select can be either:

* **Another root parent**, in which case you can simply click, drag, and drop it onto the canvas in the same way as before. It will be positioned adjacent to the first, on the same level:

![](/knowledgebase/images/img_10381821293725_1776895905.png)

* **A child of the first object class**, in which case you drop it onto that first object class as shown below on the left.

|  |  |
| --- | --- |
|  | rm5.png |

It will be positioned under the parent with a vertical connector between them.

The child object class will have a ratio selector on it as shown above on the right.

### Ratio options

The ratio options are:

* **1:N** ie one to many. This means that any one client record may have none, one, or more child project records associated with it.
* **1:1** ie one to one. This means that any one client record may have none or one project associated with it.

|  |  |
| --- | --- |
| The parent will have a collapse icon with a tooltip when hovered on, as shown. |  |
| When the parent object class is collapsed, the tooltip changes and a new icon indicates that child object classes are hidden. |  |

Having selected the correct ratio, you can continue to build your relational model.

If more than one child is added at the same level, the vertical connector will join to a horizontal connector split to each child.

![](/knowledgebase/images/img_10381821293725_1776895906.png)

## Model limits

Each parent class can have up to **five child classes**. The below error message is shown if this limit has been reached and the user attempts to add a sixth child object class.

![](/knowledgebase/images/img_10381821293725_1776895906.png)

Each tree in the relational model can be up to **five object classes deep**. The below error message is shown if the user attempts to add a sixth level.

![](/knowledgebase/images/img_10381821293725_1776895906.png)

The relational model can have a maximum of **five root parent classes**. When you add the fifth root parent object class, the below error message is shown and you will not be able to add any further object classes at the top level:

![](/knowledgebase/images/img_10381821293725_1776895907.png)

## Save the model

When you **Save** the model, you will be taken to the main System configuration page, and a green success toast message will be displayed:

![](/knowledgebase/images/img_10381821293725_1776895907.png)

When your Relational model is configured and saved, you will need to edit each parent object class in order to add the available child Object classes; this will provide the interface for a user to create relational records. Find out more [about configuring relationships in object classes](/knowledgebase/system-configuration/object-class-relationships/configuring-relationships-in-object-classes/).

Find out more about the [Relational modeller](/knowledgebase/system-configuration/relational-modeller/what-is-the-relational-modeller/).

## Useful info

1. If you delete an object class from the model, all its descendents will also be deleted and that object class or classes will be available for selection in the sidebar.
2. Object classes can be moved to a new parent or to the top level and become a root parent. When you do this, all descendent object classes will move too.
3. The canvas can be moved (dragged) with the mouse when you hold down the shift key.
4. The mouse wheel can be used to zoom in/out.

---

---
url: /knowledgebase/system-configuration/theme/creating-the-theme.md
---

# Creating the Theme

Only users with a Super admin account type will be able to create a Theme.

The Theme configuration page can be found in the System configuration section of the main menu. Users who do not have a Super admin account type will not see the Theme menu item.

Clicking on Theme will open the Configure Theme page on the Media tab. The Theme is disabled by default.

[More about the Theme](/knowledgebase/system-configuration/theme/about-the-theme/)

**The page has 3 tabs:**

## Media

Here you can upload your logo or the logo of your client/customer for whom the system is being prepared or maintained.

The logo must be in SVG format (because these are easily resized without loss of resolution) and cannot be larger than 100KB. You can drag and drop the required logo or browse for it.

You might find the following image convertors useful:

<https://www.pngtosvg.com/>

<https://www.adobe.com/express/feature/image/convert/png-to-svg>

An incorrectly uploaded logo can be removed by clicking the X to the right hand side of the Main logo field.

![Logo050123.jpg](../../../images2/zendesk_8601770282525_001_491814a7aa0f.jpg)

Your logo will replace the default Autologyx Catalyst logo throughout the application including, on the login page, at the top of the main menu and on the forgotten password screen.

![mceclip0.png](../../../images2/zendesk_8601770282525_002_41b546c45002.png)

The logo is not mandatory. If a file is not uploaded, the default Autologyx logo will be used throughout the system.

## Text overrides

Here you can change the text which is displayed on the right hand side of the login page.

You can use this area to add a welcome message or instructions to users, but bear in mind that there is a 1000 character limit in each text field.

|  |  |
| --- | --- |
| *Default text* | *Customised text* |
| ![mceclip1.png](../../../images2/zendesk_8601770282525_003_f1a48e9a67da.png) | ![mceclip2.png](../../../images2/zendesk_8601770282525_004_a16b085f88a9.png) |
| ![mceclip0.png](../../../images2/zendesk_8601770282525_005_e7b01373703c.png) | ![mceclip3.png](../../../images2/zendesk_8601770282525_006_18bb6b0a91ab.png) |

## Colours

This tab allows you to define which colours are used throught your system. Colours have to be entered as Hex numbers. The tab is split into 3 sections:

**Core colours**

*Primary colour* - this controls areas such as Radio buttons, the + Create buttons for instance on the Object classes and Task templates lists, the + Add buttons such as the + Add field button in an Object Class, the gradient colour on the right hand side of tiles in the System configuration and Administation menu pages.

*Secondary colour* - this controls the colour of the menu place and dividing lines as well as the filter and column configuration button graphics, the list page control icons and section names as well as the text on the "Cancel" and "X No, go back" buttons. It is also used for the field names in Object records and the Task summary tab.

*Tertiary colour* - this controls the colour of the Save and Complete buttons.

**Additional colours**

*Navigation panel background colour* - this clearly controls the background colour of the main menu on the left hand side. It also provides the gradient colour on the right hand side of tiles in the System configuration and Administation menu pages.

**Form colours**

*Section content background* - this controls the background colour on the create/view Object record form, the standalone form used to create Object records and Task forms.

*Section header background* - this controls the colour of the section headers on the same forms.

**Cancelling changes**

You'll note that there is a Cancel button on the top right hand side of the page. Clicking this will display the "Unsaved changes will be lost" modal.

Click Yes to confirm the cancellation. The Theme will revert to the last saved version.

Click X No, go back to retain the Theme you are working on.

![mceclip1.png](../../../images2/zendesk_8601770282525_007_1efbdcb56c52.png)

Having configured your Theme, remember to click the Enable button and Save so that it can be applied throughout the application.

A user with a Super admin account can edit the theme at any time by clicking on Theme in the main menu. This allows you to keep your theme updated to match new branding requirements.

**Useful info:**

Colour control fields are mandatory. Hex values must be entered into the fields to determine which colours will be used for each colour control. Once entered, the corresponding colour will be displayed above with its hex value overlayed. It is important to note that:

1. The colour control will never allow an empty value because it will reset to the previous valid value if the control field is not populated.
2. The colour control will never allow an invalid value because it will reset to the previous valid value if an invalid entry is made.

---

---
url: >-
  /knowledgebase/workspace/tasks/creation-of-a-manual-task-for-an-object-record.md
---

# Creation of a Manual Task for an Object Record

Tasks can be created for Object records in two different ways:

* automatically from the Sequencer as part of a larger workflow
* manually from the Workspace

This article explains how to create Manual Tasks from the Workspace.

Manual Tasks are created from a Task Template where the **Task creation mechanism** is set to **Manual**. This means they can be created on an ad-hoc basis from an Object record.

## Manual task setup and availability

The Task Template shown below has been configured as an Update object records type.

It can only be used to create Tasks for records in the Mortgage Application Object class.

![Task Template configured for manual task creation](/knowledgebase/images/workspace/creation-of-manual-task-1.png)

To create Manual Tasks for an Object record, the user must have one of the following:

* a Super Admin account type
* Object class Owner access
* a Permission Set for the Object class that allows them to create Tasks

If these conditions are met, the user sees the **+ Create task** button in the Tasks tab of an Object record.

![Tasks tab showing the Create task button](/knowledgebase/images/workspace/creation-of-manual-task-2.png)

In this example, no Tasks have been created for Record ID 303. The selected record is indicated by the highlighted row in the Records table.

The Mortgage Application Number is displayed in the top-left corner of the Tasks tab because this field was selected as the Identifier on the Object class.

## Create a Manual Task

To create a Manual Task, click **+ Create task**.

The Create task screen opens in the Tasks tab and is split into three sections:

* Task details
* Assignment of stages
* Instructions

There are three mandatory fields.

### Task name

It may be useful to use the name given to the Task Template, although a more specific name can be entered if preferred.

This can be helpful because manually created Tasks can be created more than once for the same Object record. The Task name does not have to be unique.

### Task template

This search-select field is used to choose the Task Template.

The field is limited to Task Templates that:

* are configured for Manual creation
* are available for the Object class containing the selected record

Task Templates are displayed alphabetically.

### Complete

Use this field to select the user or users who are expected to complete the Task.

The search list is presented alphabetically, so the Task creator can scroll through it or search for a specific user.

![Create task screen showing Task details, Assignment of stages, and Instructions](/knowledgebase/images/workspace/creation-of-manual-task-3.png)

## Assign users to complete the Task

Users with Super Admin, Standard, or one-time completion account types can be selected to complete the Task.

If a one-time completion user is selected, no additional users can be added.

The search field becomes disabled and a tooltip is displayed on hover.

![One-time completion user selected for a manual Task](/knowledgebase/images/workspace/creation-of-manual-task-4.png)

![Tooltip explaining that no additional users can be selected](/knowledgebase/images/workspace/creation-of-manual-task-5.png)

When a Super Admin or Standard user is selected, one-time completion users become unavailable for selection.

![One-time completion users unavailable after selecting a Standard user](/knowledgebase/images/workspace/creation-of-manual-task-6.png)

Selected users appear as avatars to the right of the search field in the order they were added.

Clicking an avatar displays the user's contact details.

![Selected users displayed as avatars beside the Complete field](/knowledgebase/images/workspace/creation-of-manual-task-7.png)

Click **Edit** to open a modal where users selected in error can be removed.

Click the **X** to the right of a user's name to remove them.

![Edit assignees modal showing selected users](/knowledgebase/images/workspace/creation-of-manual-task-8.png)

## Task fields and completion view

### Due date

Use this field to provide a target date for completing the Task.

Click into the field and choose one of the following:

* **No due date** - selected by default
* **Date**

If **Date** is selected, a further field is displayed where you can choose the required date.

Past dates cannot be selected because this would make the Task immediately overdue.

![Due date field shown during manual Task creation](/knowledgebase/images/workspace/creation-of-manual-task-9.png)

### Instructions

Use this field to enter instructions specific to the selected Object record.

Task Templates are often configured with generic instructions, while this field allows record-specific guidance to be added.

![Instructions field shown during manual Task creation](/knowledgebase/images/workspace/creation-of-manual-task-10.png)

When a user opens the Task completion screen, the instructions entered during Task creation are displayed under the Task properties.

![Task completion screen showing manually entered instructions](/knowledgebase/images/workspace/creation-of-manual-task-11.png)

## Create or cancel the Task

When the Task has been configured correctly, click **+ Add** to create the Task for the Object record.

The **+ Add** button is disabled until all mandatory fields have been completed.

After the Task is created, it appears as a tile on the Tasks tab.

The Task counter increases accordingly.

The tile displays:

* Task name
* Due date
* Status

Initially, the status is **Outstanding**.

The Task is visible only to users who:

* were selected in the **Complete** field
* have a Super Admin account type
* are the Object class Owner
* have a Permission Set containing **Tasks > View all**

![Newly created Task displayed as a tile on the Tasks tab](/knowledgebase/images/workspace/creation-of-manual-task-12.png)

To cancel Task creation, click **Cancel** in the bottom-right corner of the Create task screen.

The Create task screen closes and the tab returns to the existing Tasks view.

## Things to remember

1. The maximum number of users that can be assigned to complete a Manual Task is 100.
2. If the Task creator changes the selected Task Template before the Task is created, any data entered in the other fields remains.
3. The Instructions field has a character limit of 9,000.
4. One-time completion users cannot be assigned alongside other users.
5. The **+ Add** button is disabled until all mandatory fields have been completed.

---

---
url: /api/catalyst/resources/custom-components.md
---
# Custom Components

This technical design describes implementation and API for Custom Components.

Implementation details can be found in external document: [Custom Components - Technical Design](https://autologyx.sharepoint.com/:w:/s/Dev/ESWpW0nrn_5Bn0xS5VTqQxMBknb_78re6p3-lA0sOLNC6A?e=vBjfAv).

## Permissions

To manage Custom Component a new permission resource custom\_component will be used.

Following actions will be available for resource:

```
list
view
create
edit 
```

Actions will be not manageable, and only Super Admin users will get those permissions.

## POST /api/custom-components/repository/

Creates Custom Components Repository.

### Permissions

Requires `authentication` and `custom_component.create` permission.

### Request example

* Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

### Body

| Key            | Type   | Required | Notes |
|----------------|--------|----------|-------|
| repository\_url | url    | True     |       |
| username       | string | True     |       |
| token          | string | True     |       |

### Validations

* User is validated by account type, `one_time_completion` account cannot be owner.
* Custom component repository field name `repository_url` is required.
* Custom component repository field name `repository_url` max length is 2048.
* Custom component repository field name `username` is required.
* Custom component repository field name `username` max length is 100.
* Custom component repository field name `token` is required.
* Custom component repository field name `token` max length is 150.

### Sample request body

POST /api/custom-components/repository/

```json
{
   "repository_url": "https://repo.git",
   "username": "alx.dev@autologyx.com",
   "token": "sample token",
}

```

### Response

* Successful status `201 Created`
* Response body:

```json
{
   "id": "1",
   "repository_url": "https://git.com/p.git",
   "username": "alx.dev@autologyx.com",
   "created_at": "2023-07-10T09:28:27.679165+02:00",
   "created_by": {
     "id": 256,
     "first_name": "John",
     "last_name": "Smith",
     "username": "j.smith@autologyx.com",
     "company_name": "Autologyx",
     "is_deleted": false
   }
}
```

## GET /api/custom-components/repository/`repository_id`/

Retrieves the Custom Component Repository details.

### Permissions

Requires `authentication` and `custom_component.view` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> GET /api/custom-components/repository/`repository_id`/

### Response

| Key                | Type     | Notes                                     |
|--------------------|----------|-------------------------------------------|
| id                 | int      | Automatically generated by the backend. 	 |
| repository\_url     | string   |                                           |
| username           | string   |                                           |
| status             | enum     |                                           |
| errors             | Object   |                                           |
| version            | string   |                                           |
| publisher          | string   |                                           |
| publisher\_url      | url      |                                           |
| logo               | url      |                                           |
| imported\_at        | datetime |                                           |
| created\_at         | datetime |                                           |
| created\_by         | user     |                                           |
| \_meta.permissions | Object   | Object describing permissions.            |

* Successful status `200 OK`
* Response body schema:

- Response `errors`

For statuses different from `failed`, `errors` will be null.
For status `failed` the `errors` can return:

| Error                                                                                                      | Value                                                                                      |
|------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------|
| Required file is missing                                                                                   | "{missing\_file}": "This file is required."                                                 |
| config.json has > 100000 chars                                                                             | "config.json": "Ensure this file has no more than 100000 characters."                      |
| config.json structure is different than expected                                                           | "config.json": "A valid file structure is required."                                       |
| User has not perm to given resource's instance or Resource's instance with {repository\_url} does not exist | "repository\_url": "The requested Git resource is either inaccessible or not found."        |
| {attribute} is missing                                                                                     | "{attribute}": \["This field is required."]                                                 |
| {attribute} is blank                                                                                       | "{attribute}": \["This field may not be blank."]                                            |
| {value} for {attribute} is out of choices                                                                  | "{attribute}": \[""{value}" is not a valid choice."]                                      |
| Value of different type than an array of objects for `parameters`                                          | "parameters": \[{"non\_field\_errors": \["Expected a list of items but got type "str"."]}]   |
| Nested error for item in `parameters`                                                                      | "parameters": \[{"parameter\_{field}": \[{error}]}]@                                          |
| Wrong type for `parameters.parameter_options`                                                              | "parameters": \[{"parameter\_options": \["Expected a list of items but got type "str"."]}]  |

```json
{
    "id": 87, 
    "repository_url": "https://test.com/repo/project0.git",
    "username": "user0",
    "status": "processing",
    "errors": null,
    "version": "1.2",
    "publisher": "Test Publisher",
    "publisher_url": "https:/test.test",
    "logo": "https:/test.test/logo.png",
    "imported_at": "2023-08-02T09:41:44.203051Z",
    "created_at": "2023-08-02T09:41:44.203383Z",
    "created_by": {
        "id":41,
        "first_name": "first name",
        "last_name": "last name",
        "username": "test.autologyx@autologyx.com",
        "company_name": "autologyx",
        "is_deleted": false,
        "account_type": "full"
    },
    "_meta": {
        "permissions": {
            "create": true,
            "edit": true,
            "list": true,
            "view": true
        }
    }
}
```

### Errors

| Error                                     | Response code   | Message                                                        |
|-------------------------------------------|-----------------|----------------------------------------------------------------|
| Insufficient permissions                  | 403 Forbidden   | "detail": "You do not have permission to perform this action." |
| Repository for `repository_id` not found. | 404 Not Found   | 	                                                              |

## OPTIONS /api/custom-components/repository/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> OPTIONS /api/custom-components/repository/

### Response

* Successful status `200 OK`
* Response body:

```json
{
   "details": {
      "schema": [
         {
            "alias": "repository_url",
            "type": "url",
            "required": true,
            "validators": [
               {
                  "type": "max_length",
                  "length": 2048
               }
            ]
         },
         {
            "alias": "username",
            "type": "string",
            "required": true,
            "validators": [
               {  
                  "type": "max_length",
                  "length": 100
               } 
            ] 
         },
         {
            "alias": "token",
            "type": "string",
            "required": true,
            "validators": [
               {
                  "type": "max_length",
                  "length": 150 
               }
            ]
         }
      ]
   }
}
```

## PATCH /api/custom-components/repository/`repository_id`/

### Response example

* Status `405 Method Not Allowed`

## POST /api/custom-components/

Creates Custom Components and if repository status imported the task with the installing repository is running in the background.

1. If repository status is imported the component status is processing
2. If repository status is processing the component status is processing
3. `created_by` and `modified_by` is the user who executed the POST.
4. `created_at` and `modified_at` is the timestamp when the component was created.

### Permissions

Requires `authentication` and `custom_component.create` permission.

### Request example

* Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

### Body

| Key             | Type    | Required | Notes |
|-----------------|---------|----------|-------|
| name            | string  | True     |       |
| description     | string  | False    |       |
| repository      | int     | True     |       |
| is\_enabled      | bool    | False    |       |
| available\_use   | Object  | True     |       |

* Response `available_use` Object

| Key                          | Type    | Notes |
|------------------------------|---------|-------|
| landing\_page                 | bool    |       |
| object\_class\_create\_form     | bool    |       |
| object\_class\_summary\_form    | bool    |       |
| object\_class\_standalone\_form | bool    |       |
| task\_template\_form           | bool    |       |

### Validations

* At most custom components can be created: 100.
* Repository status if is failed during importing.
* User is validated by account type, `one_time_completion` account cannot be owner.
* Custom component field name `name` is unique.
* Custom component field name `name` is required.
* Custom component field name `name` max length is 100.
* Custom component field name `description` max length is 500.
* Custom component field name `repository` is required.
* Custom component field name `repository` must be repository ID.
* Custom component field name `repository` cannot be associated with any other custom component.
* Custom component field name `available_use` is required.
* Custom component field name `available_use` field name `landing_page` is required.
* Custom component field name `available_use` field name `object_class_create_form` is required.
* Custom component field name `available_use` field name `object_class_summary_form` is required.
* Custom component field name `available_use` field name `object_class_standalone_form` is required.
* Custom component field name `available_use` field name `task_template_form` is required.
* Custom component field name `available_use` must be an object with keys listed above.

### Sample request body

> POST /api/custom-components/

```json
{
   "name": "Component 1"",
   "description": "Test description",
   "repository": 1,
   "is_enabled": true,
   "available_use": {
      "landing_page": true,
      "object_class_create_form": false,
      "object_class_summary_form": false,
      "object_class_standalone_form": false,
      "task_template_form": false
   }
}

```

### Response

* Successful status `201 Created`
* Response body:

```json
{
   "name": "Component 1",
   "description": "Test description",
   "repository": 1,
   "is_enabled": true,
   "status": "processing",
   "created_at": "2023-07-10T09:28:27.679165+02:00",
   "created_by": "some name (test.autologyx@autologyx.com)",
   "modified_at": "2023-07-10T09:28:27.679165+02:00",
   "modified_by": "some name (test.autologyx@autologyx.com)",
   "available_use": {
      "landing_page": true,
      "object_class_create_form": false,
      "object_class_summary_form": false,
      "object_class_standalone_form": false,
      "task_template_form": false
   }
}
```

## GET /api/custom-components/

Returns list of Custom Components.

### Permissions

Requires `authentication` and `custom_component.view` permission.

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

### Response `results` array

| Key                | Type     | Notes                                     |
|--------------------|----------|-------------------------------------------|
| id                 | int      | Automatically generated by the backend. 	 |
| name               | str      |                                           |
| repository         | int      |                                           |
| repository\_url     | string   |                                           |
| is\_enabled         | bool     |                                           |
| status             | enum     |                                           |
| created\_at         | datetime |                                           |
| created\_by         | user     |                                           |
| modified\_at        | datetime |                                           |
| modified\_by        | user     |                                           |
| available\_use      | Object   |                                           |
| index\_url          | string   |                                           |
| version            | string   |                                           |
| publisher          | str      |                                           |
| publisher\_url      | url      |                                           |
| \_meta.permissions | Object   | Object describing permissions.            |

### Response `available_use` Object

| Key                          | Type    | Notes |
|------------------------------|---------|-------|
| landing\_page                 | bool    |       |
| object\_class\_create\_form     | bool    |       |
| object\_class\_summary\_form    | bool    |       |
| object\_class\_standalone\_form | bool    |       |
| task\_template\_form           | bool    |       |

```json
{
  "limit": 10,
  "filtered_count": 9,
  "total_count": 9,
  "next": null,
  "previous": null,
  "offset": 0,
  "results": [
    {
      "id":5,
      "name":"16 08 2023 component",
      "repository":13,
      "repository_url":"https://github.com/repository",
      "is_enabled":true,
      "status":"installed",
      "created_at":"2023-08-16T10:38:12.476104+02:00",
      "created_by": {
        "id":28,
        "first_name":"John",
        "last_name":".",
        "username":"john@autologyx.com",
        "company_name":"",
        "is_deleted":false,
        "account_type":"super_admin"
      },
      "modified_at":"2023-08-16T10:38:15.858505+02:00",
      "modified_by": {
        "id":28,
        "first_name":"John",
        "last_name":".",
        "username":"john@autologyx.com",
        "company_name":"",
        "is_deleted":false,
        "account_type":"super_admin"
      },
      "available_use": {
        "landing_page":true,
        "object_class_create_form":true,
        "object_class_summary_form":true,
        "object_class_standalone_form":true,
        "task_template_form":true
      },
      "index_url":"https://autologyx.com/alx_release_candidate_next_version_qa/85f1b0cd-b112-499b-9f0d-32131232313/index.html",
      "version":"1.1.0",
      "publisher":"acme",
      "publisher_url":"https://example.com",
      "_meta": {
        "permissions": {
          "list":true,
          "view":true,
          "create":true,
          "edit":true
        }
      }
    }]
}
   
```

### Errors

| Error                                     | Response code   | Message                                                        |
|-------------------------------------------|-----------------|----------------------------------------------------------------|
| Insufficient permissions                  | 403 Forbidden   | "detail": "You do not have permission to perform this action." |

## GET /api/custom-components/`custom_component_id`/

Retrieves the Custom Component details.

### Permissions

Requires `authentication` and `custom_component.view` permission.

### URL parameters

| Key                       | Type | Notes                           |
|---------------------------|------|---------------------------------|
| custom\_component\_id       | int  | 	                               |

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key                | Type     | Notes                                     |
|--------------------|----------|-------------------------------------------|
| id                 | int      | Automatically generated by the backend. 	 |
| name               | str      |                                           |
| description        | str      |                                           |
| repository         | int      |                                           |
| is\_enabled         | bool     |                                           |
| status             | enum     |                                           |
| created\_at         | datetime |                                           |
| created\_by         | user     |                                           |
| modified\_at        | datetime |                                           |
| modified\_by        | user     |                                           |
| available\_use      | Object   |                                           |
| index\_url          | string   |                                           |
| version            | string   |                                           |
| parameters         | Object   |                                           |
| publisher          | str      |                                           |
| publisher\_url      | url      |                                           |
| \_meta.permissions | Object   | Object describing permissions.            |

### Response `parameters` Object

| Key                   | Type  | Notes |
|-----------------------|-------|-------|
| parameter\_description | str   |       |
| parameter\_name        | str   |       |
| parameter\_type        | str   |       |
| parametr\_limit        | int   |       |
| parameter\_options     | list  |       |

### Response example

* Status `200 OK`
* Body

```json
{
  "id":5,
  "name":"16 08 2023 component",
  "description": "description",
  "repository":13,
  "is_enabled":true,
  "status":"installed",
  "created_at":"2023-08-16T10:38:12.476104+02:00",
  "created_by": {
    "id":28,
    "first_name":"John",
    "last_name":".",
    "username":"john@autologyx.com",
    "company_name":"",
    "is_deleted":false,
    "account_type":"super_admin"
  },
  "modified_at":"2023-08-16T10:38:15.858505+02:00",
  "modified_by": {
    "id":28,
    "first_name":"John",
    "last_name":".",
    "username":"john@autologyx.com",
    "company_name":"",
    "is_deleted":false,
    "account_type":"super_admin"
  },
  "available_use": {
    "landing_page":true,
    "object_class_create_form":true,
    "object_class_summary_form":true,
    "object_class_standalone_form":true,
    "task_template_form":true
  },
  "index_url":"https://autologyx.com/alx_release_candidate_next_version_qa/85f1b0cd-b112-499b-9f0d-32131232313/index.html",
  "version":"1.1.0",
  "parameters": [
    {
      "parameter_description": "description",
      "parameter_name": "name",
      "parameter_type": "type",
      "parameter_limit": 5,
      "parameter_options": []
    }
  ],
  "publisher":"acme",
  "publisher_url":"https://example.com",
  "_meta": {
    "permissions": {
      "list":true,
      "view":true,
      "create":true,
      "edit":true
    }
  }
}
```

### Errors

| Error                                       | Response code | Message                                                        |
|---------------------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions                    | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Custom Component with "id " does not exists | 404 Not Found | "detail": "Not found."                                         |

## OPTIONS /api/custom-components/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> OPTIONS /api/custom-components/

### Response

* Successful status `200 OK`
* Response body:

```json
{
   "list": {
      "columns": [
         {
            "alias": "id",
            "type": "int",
            "predicates": [
               "exact",
               "gt",
               "gte",
               "lt",
               "lte",
               "range" 
            ],
            "sort_ok": true
         },
         {
            "alias": "name",
            "type": "string",
            "predicates": [
               "exact",
               "iexact",
               "contains",
               "icontains",
               "startswith",
               "istartswith",
               "endswith",
               "iendswith" 
            ],
            "sort_ok": true
         },
         {
            "alias": "status",
            "type": "enum",
            "predicates": [ 
               "exact",
               "in" 
             ],
            "sort_ok": false,
            "values": [
               {
                  "value": "processing",
                  "text": "Processing" 
               },
              {
                  "value": "failed",
                  "text": "Failed" 
               }, 
               {  
                  "value": "Installed",
                  "text": "Installed" 
              }
            ]
         },
         {
            "alias": "version",
            "type": "string",
            "predicates": [ ],
            "sort_ok": false
         },
         {
            "alias": "publisher",
            "type": "string",
            "predicates": [
               "exact",
               "iexact",
               "contains",
               "icontains",
               "startswith",
               "istartswith",
               "endswith",
               "iendswith" 
            ],
            "sort_ok": true
         },
         {
            "alias": "repository_url",
            "type": "url",
            "predicates": [ ],
            "sort_ok": false
         },
         {
            "alias": "is_enabled",
            "type": "bool",
            "predicates": [
               "exact" 
            ],
            "sort_ok": false
         },
         {
            "alias": "created_at",
            "type": "datetime",
            "predicates": [
               "exact",
               "gt",
               "gte",
               "lt",
               "lte",
               "range" 
            ],
            "sort_ok": true
         },
         {
            "alias": "created_by",
            "type": "user",
            "predicates": [
               "exact",
               "in" 
            ],
            "sort_ok": false,
            "autocomplete": "/api/users/autocomplete/?text__icontains=" 
         },
         {
            "alias": "modified_at",
            "type": "datetime",
            "predicates": [
               "exact",
               "gt",
               "gte",
               "lt",
               "lte",
               "range" 
            ],
            "sort_ok": true
         },
         {
            "alias": "modified_by",
            "type": "user",
            "predicates": [
               "exact",
               "in" 
            ],
            "sort_ok": false,
            "autocomplete": "/api/users/autocomplete/?text__icontains=" 
         }
      ]
   },
   "details": {
      "schema": [
         {
            "alias": "name",
            "type": "string",
            "required": true,
            "validators": [
               {
                  "type": "min_length",
                  "length": 1
               },
               {
                  "type": "max_length",
                  "length": 100
               }
            ]
         },
         {
            "alias": "description",
            "type": "string",
            "required": false,
            "validators": [
               {
                  "type": "max_length",
                  "length": 500
               }
            ]
         },
         {
            "alias": "is_enabled",
            "type": "bool",
            "required": false
         },
         {
            "alias": "available_use",
            "required": false,
            "schema": [
               { 
                  "alias": "landing_page",
                  "type": "bool",
                  "required": true
               },
               {
                  "alias": "object_class_create_form",
                  "type": "bool",
                  "required": true
               },
               { 
                  "alias": "object_class_summary_form",
                  "type": "bool",
                  "required": true
               },
               {
                  "alias": "object_class_standalone_form",
                  "type": "bool",
                  "required": true
               },
               {  
                  "alias": "task_template_form",
                  "type": "bool",
                  "required": true
               }
           ]
         }
      ]
   },
   "restrictions": {
      "limit_items": 100
   }
}
```

## PATCH /api/custom-components/`custom_component_id`/

Update the form.

### Permissions

Requires `authentication` and `custom_component.edit` permissions.

### Allowed parameters

| Key           | Type   | Notes  |
|---------------|--------|--------|
| name          | string |        |
| description   | strin  |        |
| is\_enabled    | bool   | 	      |
| available\_use | json   | 	      |

* `available_use` json

| Key                          | Type   | Notes |
|------------------------------|--------|-------|
| landing\_page                 | bool   | 	     |
| object\_class\_create\_form     | bool   |       |
| object\_class\_summary\_form    | bool   |       |
| object\_class\_standalone\_form | bool   |       |
| task\_template\_form           | bool   |       |

Any parameter not listed above are silently ignored if passed.

### Request example

* Headers

```
Request Method: PATCH
Location: /api/custom-components/1/
Authorization: JWT access_token
```

* Body

```json

{
    "name": "name",
    "description": "description",
    "is_enabled": true,
    "available_use": {
        "landing_page": false, 
        "object_class_create_form": true, 
        "object_class_summary_form": true, 
        "object_class_standalone_form": true, 
        "task_template_form": true
    }
}
```

### Response

| Key               | Type     | Notes                           |
|-------------------|----------|---------------------------------|
| id                | uuid     | 	                               |
| name              | string   | 	                               |
| description       | int      | 	                               |
| repository        | enum     | 	                               |
| is\_enabled        | bool     | 	                               |
| status            | str      |                                 |
| created\_at        | datetime | 	                               |
| created\_by        | user     | 	                               |
| modified\_at       | datetime | 	                               |
| modified\_by       | user     | 	                               |
| available\_use     | json     |                                 |

### Response example

* Status `200 OK`
* Body

```json
{
    "id": 1,
    "name": "name",
    "description": "description",
    "repository": 1,
    "is_enabled": true,
    "status": "installed",
    "created_at": "2023-08-09T07:24:42.621472Z",
    "created_by": {
        "id": 1,
        "first_name": "ALX",
        "last_name": "Master",
        "username": "username@test.pl",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_at": "2023-08-10T11:20:13.312085Z",
    "modified_by": {
        "id": 1,
        "first_name": "ALX",
        "last_name": "Master",
        "username": "username@test.pl",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "available_use": {
        "landing_page": false,
        "object_class_create_form": true,
        "object_class_summary_form": true,
        "object_class_standalone_form": true,
        "task_template_form": true
    }
}
```

## DELETE /api/custom-components/`custom_component_id`/

Deletes single Custom Component.

### Permissions

Requires `authentication` and `custom_component.delete` permission.

### Request

* URL parameters

| Key                  | Type | Notes       |
|----------------------|------|-------------|
| custom\_component\_id  | int  |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> DELETE /api/custom-components/`custom_component_id`/

```json
```

### Response

* Successful status `204 No Content`

### Errors

| Error                                      | Response code | Message                                                        |
|--------------------------------------------|---------------|----------------------------------------------------------------|
| Custom Component in use                    | 400 Forbidden | "detail": "Custom component is in use by {used\_by}."           |
| Insufficient permissions                   | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Custom Component with "id" does not exist  | 404 Not Found | "detail": "Not found."                                         |

## GET /api/custom-components/`custom_component_id`/usage/

### Request example

* Headers

```
Request Method: GET
Location: /api/custom-components/1/usage/
Authorization: JWT access_token
```

### Response

| Key                                        | Type  | Notes                           |
|--------------------------------------------|-------|---------------------------------|
| object\_class\_summary\_forms                 | array |                                 |
| object\_class\_create\_forms                  | array |                                 |
| object\_class\_standalone\_forms              | array |                                 |
| num\_of\_object\_class\_summary\_forms          | int   |                                 |
| num\_of\_object\_class\_create\_forms           | int   |                                 |
| num\_of\_landing\_pages                       | int   |                                 |
| num\_of\_object\_class\_standalone\_forms       | int   |                                 |

### Response `object_class_summary_forms` array

| Key          | Type       | Notes                      |
|--------------|------------|----------------------------|
| id           | int        | Object class id            |
| name         | str        | Name of the Object class   |

### Response `object_class_create_forms` array

| Key          | Type       | Notes                      |
|--------------|------------|----------------------------|
| id           | int        | Object class id            |
| name         | str        | Name of the Object class   |

### Response `object_class_standalone_forms` array

| Key                     | Type       | Notes                                    |
|-------------------------|------------|------------------------------------------|
| id                      | int        | Object class id                          |
| name                    | str        | Name of the Object class                 |
| standalone\_form\_name    | str        | Name of the Object class standalone form |

### Response example

* Status `200 OK`
* Body

```json
{
  "object_class_summary_forms": [
    {
      "id": 1,
      "name": "Object class 1"
    }
  ],
  "object_class_create_forms": [
    {
      "id": 2,
      "name": "Object class 2"
    }
  ],
  "object_class_standalone_forms": [
    {
      "id": 3,
      "name": "Object class 3",
      "standalone_form_name": "Standalone Form" 
    }
  ],
  "num_of_object_class_summary_forms": 1,
  "num_of_object_class_create_forms": 1,
  "num_of_landing_pages": 1
  "num_of_object_class_standalone_forms": 1
}
```

### Errors

| Error                         | Response code   | Message                                                            |
|-------------------------------|-----------------|--------------------------------------------------------------------|
| `id` is invalid               | 404 Bad Request | 'detail': "Not found."                                             |
| Unauthorized API call         | 403 Bad Request | 'detail': "You do not have permission to perform this action."     |

---

---
url: /knowledgebase/release-notes/release-notes-1.8/database-views.md
---

# Database views

Tired of juggling data tools and battling with complex databases? Catalyst introduces a feature that transforms the way you connect with your database management system, particularly in the realm of ClickHouse. This empowers users to leverage their preferred data management tools while creating dynamic views based on Autologyx data.

Whether you're managing complex datasets or conducting in-depth analyses, Catalyst's ClickHouse integration ensures a seamless and consistent data management experience. This feature empowers users to confidently manage and analyse diverse live datasets without compromising on performance of the main application.

## Connect and explore

Users can now establish a connection to their ClickHouse database within a selected domain, provided they possess the requisite connection credentials. Upon login, users can explore "Event History" tables and select "Resource" tables (replica) directly from their chosen DBMS.

**Autologyx Cross-Platform views** provide a read-only perspective, ensuring users can view but not modify any schema or data within the "Event History" or "Resource" tables.

## Create views from records

One of the standout features is the ability for users to craft views of records within any Object class. These views are designed to provide a structured snapshot of data, featuring essential details such as **Record ID**, Record Identifier, **Record Creation Datetime**, and more.

## Support for analysis across teams

Compliance teams can use this integration to easily scrutinise event histories related to specific cases, pinpointing relevant data with laser focus.

Lawyers can dive into resource tables, analysing historical contract data to identify trends and potential risks.

M\&A specialists can leverage cross-platform views to seamlessly compare data across different companies, streamlining due diligence processes.

Litigators can explore event histories with ease, gathering crucial evidence to support their arguments.

**Different data sources, the same exceptional experience.** With this feature, you can confidently manage and analyse diverse datasets without compromising on quality. This integration not only facilitates data access but transforms it into a dynamic, interactive experience. From browsing historical events to crafting insightful views, Catalyst's ClickHouse integration is designed to empower users in their data-driven endeavours.

---

---
url: /knowledgebase/release-notes/release-notes-1.11/delayed-account-activation.md
---

# Delayed account activation

Perfect timing is crucial when managing organisational access, especially in scenarios where coordination and precision matter. Whether you're preparing for a department-wide rollout where every team member needs access at the same time, setting up intricate permission structures before users even log in, or ensuring compliance with mandatory review processes before granting system access, timing plays a key role.

Our new delayed account activation feature streamlines these challenges, allowing you to control when and how accounts become active, ensuring a well-orchestrated user experience.

## Delayed activation when creating a user

When adding a new user, you can decide whether to send the activation email immediately or hold off until a later time. If you choose not to send the email at the time of creation, the user will be listed in the system but won’t be able to set up their account until an activation email is sent.

![Delayedaccount\_article.gif](../../../images2/zendesk_4720324915359_001_315f4c6672b5.gif)

## User details status section

To make account management easier, we’ve updated the User details page with a new **Status** section.

**Here’s what you’ll see:**

1. **Created** – the user has been added to the platform, but their activation email hasn't been sent yet. If needed, you can send it manually from this page.
2. **Pending** – the activation email has been sent, but the user hasn’t completed their account setup. You can see the last time the email was sent and resend it if necessary.
3. **Active** – the user has successfully activated their account, with details on when the activation occurred.

![Delayedaccount2\_article.gif](../../../images2/zendesk_4720324915359_002_1ef183806a9e.gif)

## User List updates

The User List now includes a **status** column, making it easy to filter and identify users who haven't activated their accounts.

![Delayedaccount3\_article.gif](../../../images2/zendesk_4720324915359_003_ffc663ee755e.gif)

**In summary**, delayed account activation gives you control over the entire user activation timeline, letting you create accounts now but activate them precisely when it makes sense for your organisation. No more rushed setups or premature access grants!

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.13/delete-option-in-set-task-actor.md
---

# Delete option in Set Task actor

**Workflows can now manage tasks from creation to deletion** with the new action in the Set Task actor. Previously, Catalyst users could create tasks within workflows, but had no way to remove them programmatically. This meant manual cleanup, cluttered interfaces, and potential conflicts when tasks became obsolete or workflows needed to be reset.

The enhanced Set Task actor now includes a **Delete** action in addition to the existing **Re-create** option. When you select **Delete**, you can target exactly which tasks to remove. This granular control transforms how workflows handle task management.

**You can now build processes that:**

* clean up after themselves
* reset when conditions change
* prevent conflicting assignments from accumulating over time

## Delete targets

After selecting your Task Template, the **Action** dropdown presents a new **Delete** option. Choosing **Delete** reveals a second dropdown for **Delete Target** with six precision options:

* **All tasks**: removes every task for the chosen template in a record, regardless of status.
* **All outstanding tasks**: removes only incomplete tasks for the chosen template in a record.
* **All complete tasks**: removes only finished tasks for the chosen template in a record.
* **Most recent task**: removes the last created task for the chosen template, regardless of status.
* **Most recent outstanding task**: removes the newest incomplete task for the chosen template.
* **Most recent complete task**: removes the newest finished task for the chosen template from the record.

![Set task 1.gif](/knowledgebase/images/img_4915133707679_1776895586.png)

## Behaviour and use cases

When the actor executes, Catalyst removes tasks based on your specifications. If no matching tasks exist on the record, the actor completes silently without errors, making it safe to include in conditional workflows.

**This Delete action gives your sequences the flexibility to handle real-world scenarios more elegantly.**

* When a client withdraws mid-onboarding, you can instantly remove all outstanding tasks without manual cleanup.
* Document review cycles become cleaner when you delete previous assignments before creating new ones, eliminating reviewer confusion.
* Compliance workflows can remove completed quarterly reviews whilst preserving active tasks, then generate fresh assignments as requirements evolve.

The feature integrates seamlessly with existing workflow logic, supporting conditional branching and complex automation scenarios whilst ensuring deleted tasks are permanently removed from records. This straightforward addition transforms workflows from simple task creators into comprehensive task managers, providing the control needed for truly dynamic process automation.

---

---
url: /knowledgebase/system-configuration/sequence-actors/docauto-actor.md
---

# DocAuto Actor

## What does the DocAuto actor do?

The DocAuto actor does what it says on the tin. It is used to generate documents where needed in the workflow. It will be used in conjunction with the Document Picker actor.

The DocAuto actor will facilitate any merge fields, IF statements or other Jinja features used in a template. In the screenshot below, the template, "Declaration", is one saved against the object class.

The DocAuto actor can follow all sequence operations, for example completion of a task, sending of a message, an Update Record actor being used to change a status or other record field value, and so on.

It might be sequenced immediately after a field being updated, ie "When Record Updated". **To ensure minimal processing**, in this instance, you would state both which field has been updated and the value of that field as additional conditions, as in the example below:

![Screenshot 2026-03-16 at 18.36.19.png](/knowledgebase/images/img_5500025073951_1776895823.png)

The DocAuto actor is sometimes sandwiched between two Document Picker actors, the first collecting a document from, for instance, a GET request API call (to a document repository) and the latter allowing the merged document to be sent to the record via an Update Record actor or used as an attachment in a Send Message actor.

An example of this is described in more detail at the end of the next section.

## How do I use the DocAuto actor?

As with all sequence actors, the DocAuto actor can be clicked and dragged from the actor menu, then dropped onto the sequence workspace.

**Connection requirements**

It must be connected from the Object class object if a document is being generated at the beginning of a sequence, or from the preceding sequence object.

|  |  |
| --- | --- |
| Right click on the DocAuto actor and select Configure. | Screenshot 2026-03-16 at 18.52.36.png |
| In this case, you will have only one option in the source field, Document Template.  Select this. | Screenshot 2026-03-16 at 18.51.27.png |
| The template field will show all available document templates for the Object class.  Select the template you wish to generate.  Save. | Screenshot 2026-03-16 at 18.51.51.png |
| Remember to right click/select Properties and add a name for the DocAuto actor.  Good labelling will be invaluable to other users. | Screenshot 2026-03-16 at 19.19.57.png |

Configure a Document Picker actor to allow you to move the generated template further through the process.

|  |  |
| --- | --- |
| When configuring the Document Picker actor, select "DocAuto Actor" in the Source field.  This will ensure that the generated document is available.  Save. | Screenshot 2026-03-16 at 19.03.59.png |

In the below scenario, the DocAuto actor follows a document picker which has taken a document from a field in a completed task.

**Note:** the DocAuto actor configuration now has the additional Source option - Document Picker.

![Screenshot 2026-03-17 at 15.02.42.png](/knowledgebase/images/img_5500025073951_1776895825.png)

The document can be populated with data from the Mortgage Application record or any related record at this point so long as it contains the appropriate Jinja merge fields.

The final Document Picker actor takes the document from the DocAuto and makes it available to be selected as an attachment in the Send Message actor.

![Screenshot 2026-03-17 at 17.42.38.png](/knowledgebase/images/img_5500025073951_1776895825.png)

## Further reading

This article will provide further information about [Automatic Document Generation](/knowledgebase/system-configuration/working-with-document-templates/automatic-generation-of-documents-via-the-sequencer/).

This article has a section which explains how the [Combine Results feature in a Document Picker](/knowledgebase/system-configuration/using-docusign-with-catalyst/7.-how-to-retrieve-the-signed-document-and-store-within-catalyst/) works. You will need to scroll about half way down.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.14/document-records-enhancements.md
---

# Document & Records Enhancements

## Improved "File name" display on tables and records

We’ve enhanced how documents are displayed across tables and records to make information clearer and more intuitive at a glance.

When a document field contains a single file, it will now display the **actual file name** instead of the generic “1 document”, making it easier to quickly identify content without additional clicks.

![Screenshot 2026-04-01 at 15.24.47.png](../../../images2/zendesk_5585539107615_001_8992ffba508c.png)

When multiple documents are present, the existing behaviour remains unchanged, continuing to display the total number of documents (eg “x documents”).

![Screenshot 2026-04-01 at 15.26.43.png](../../../images2/zendesk_5585539107615_002_f45b0657c64d.png)

## Filter Object records by document type fields

We’ve introduced new filtering capabilities to help you quickly find the records you need.

**Available filter options**

You can now filter record lists using document type fields, with the following options available:

* **Is empty**
* **Is not empty**

![Screenshot 2026-04-01 at 16.19.13.png](../../../images2/zendesk_5585539107615_003_bf742e84d4ac.png)

This makes it easy to identify records where documents are present, or highlight where key documents may be missing, helping you stay on top of your workflows.

## API enhancement: file metadata endpoint

We’ve introduced a new API endpoint to streamline how file metadata is retrieved.

**The endpoint**

```
GET /api/object-records/files/?object_class=<object_class_id>&id__in=<id1>
```

**What this enables**

Allows you to fetch metadata for up to 50 files in a single request, removing the need to call the record details endpoint for each file individually.

### Example response structure

```
{
  "limit": 50,
  "offset": 0,
  "filtered_count": 21,
  "total_count": 21,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 71346,
      "name": "Attachment 2 Case-Specific Confidentiality Guidelines.pdf",
      "url": "https://catalyst-environment.autologyx.com/api/object-records/17829/files/278ad436-3187-4f38-862b-4xxxxxxxxxxx/",
      "size": "47910",
      "type": "application/pdf" 
    },
    {...
    }
  ]
}
```

This enhancement not only provides richer insights into your files, but also significantly reduces the number of API calls required, making integrations faster and more efficient.

---

---
url: >-
  /knowledgebase/system-configuration/merge-fields/document-assembly-using-the-.docx-merge-field.md
---

# Document Assembly Using the .docx Merge Field

Use the `.docx` merge field to merge one or more `.docx` documents into a master `.docx` document.

This is useful when you need to create document packs, insert heavily formatted annexes, or maintain shared clauses in one central location while reusing them across multiple templates.

## When to use this

Use the `.docx` merge field when you need to insert complete `.docx` documents into another `.docx` document. Common examples include:

* creating document packs for review, audit, transaction filing, or signing;
* pulling large clauses, annexes, schedules, or terms into contracts and other legal documents;
* maintaining content centrally so that it can be reused across multiple templates without updating each template individually.

The inserted documents must be held in fields on the record or on a related record.

This feature is not intended for image files. Use the image merge field when you need to merge images into a document. Images must be stored in document fields on the record, or on a related record, where the master document will be generated.

For smaller conditional clauses, consider using the Jinja2 template language supported by Catalyst. Jinja2 IF statements and other functions can conditionally include content directly in a document template. The `.docx` merge field is better suited to larger or more heavily formatted content, especially where the same content is reused across many templates.

## Before you start

Before configuring a `.docx` merge field, check the following:

* The master document must be a `.docx` document.
* The inserted document must also be a `.docx` document.
* The inserted document must be stored in a document field on the record or on a related record.
* The master document can be generated by the Sequencer or manually from the template in the record side panel.
* The merge field must include an index, such as `[0]`, even if the field contains only one document.
* If the document field may be empty when the master document is generated, use an IF statement to avoid returning unwanted empty content.

## .docx merge field syntax

There are two ways to merge `.docx` content, depending on whether you want the content inserted within the current paragraph or to replace the paragraph entirely.

### Inline merge

Use an inline merge when you want the `.docx` content inserted within the paragraph where the merge field sits.

```jinja
{{ record.field_annexes[0].embedded }}
```

This places the `.docx` content within the paragraph where the merge field appears. Use this when embedding content into a block of text, or where paragraph breaks are controlled outside the inserted document.

### Paragraph replacement

Use paragraph replacement when you want the inserted `.docx` content to replace the entire paragraph where the merge field appears.

```jinja
{{ p record.field_annexes[0].embedded.inline }}
```

This is useful when:

* you want to preserve the exact formatting from the inserted `.docx` content;
* you are embedding long content, such as multi-paragraph annexes;
* you want to avoid nesting block elements inside another paragraph.

## Example use case 1: Create a trade document pack

### Scenario

A deal has a buyer and a seller, and your client is the buyer.

At a specific point in the workflow, several documents must be generated and reviewed before they are passed to the relevant parties for signing. The file handler reviews these documents as one combined document called the Trade Document Pack.

The Trade Document Pack includes three documents:

* Purchase Agreement
* Redemption Document
* Disbursement Sheet

### Configuration

All four documents have been created as templates on the object class.

![Document Templates](/knowledgebase/images/img_mergefields_docxmerge1.png)

The Trade Document Pack includes record merge fields where the other three documents will be stored on the record after they are generated.

![Merged Documents](/knowledgebase/images/img_mergefields_docxmerge2.png)

The documents you merge into the master document do not have to come from templates in Catalyst. They may also have been saved to fields by:

* an intake form completed by your client;
* a task completed by a user;
* a GET request to a third-party system;
* a record created by the file uploader or an import script.

For example, when a document is received by Catalyst through a GET request, it can be sequenced through a DocAuto actor so that record merge fields are applied.

### Sequence

In this workflow, the Purchase Agreement and Redemption Document have already been generated and filed to the record fields in a previous sequence.

![Sequence](/knowledgebase/images/img_mergefields_docxmerge3.png)

1. The sequence object class is **Client**.
2. An **Update record** actor updates the record status to **Ready for pack**.
3. A **DocAuto** actor generates the Disbursement Sheet from the template and merges record data into the document.
4. A **Document picker** actor collects the generated Disbursement Sheet.
5. An **Update record** actor files the document on the record in the **Disbursement Sheet** document field.
6. At this stage, all three documents required for the pack are ready to collate. A **DocAuto** actor generates the Trade Document Pack. Record data, including the three documents, is merged into the master document.
7. A **Document picker** actor collects the generated Trade Document Pack.
8. An **Update record** actor files the document on the record in the **Trade Document Pack** document field and updates the status to **Ready for Review**.
9. A **Task assignment** actor assigns the next task to the file handler.
10. A **Create task** actor creates a task from the **Review Trade Documents** task template.

The document pack can be opened in the side panel viewer.

![Viewed in Task](/knowledgebase/images/img_mergefields_docxmerge4.png)

The document can also be downloaded for review.

The Purchase Agreement document is merged into the Trade Document Pack, together with the other two documents.

![Purchase Agreement merged](/knowledgebase/images/img_mergefields_docxmerge5.png)

If the review outcome is that all documents are acceptable, the next steps are:

11. An **Update record** actor updates the status to **Review outcome - pass**.
12. A **Sequence runner** actor activates the next part of the process, where the documents are sent to DocuSign for signing.

## Example use case 2: Include current Terms of Business in an agreement

### Scenario

A boilerplate document called **Terms of Business** must be attached to every Client Services Agreement.

The Terms of Business document is stored in iManage. It may change from time to time, but the current document is always available from the same location. Other third-party document repositories, or a separate Catalyst object class, can be used in the same way to maintain a single current version of the document.

To make sure that each Client Services Agreement contains the current Terms of Business, the Terms of Business document is pulled into a field on the record immediately before the Client Services Agreement is generated.

### Template configuration

The Client Services Agreement contains the following merge fields:

1. In the document header, an image merge field includes the client logo.

![Image merge in header](/knowledgebase/images/img_mergefields_docxmerge6.png)

2. Towards the end of the document, the `.docx` merge field includes the Terms of Business.

![Terms merge field](/knowledgebase/images/img_mergefields_docxmerge7.png)

The Client Services Agreement has been created as a template on the object class.

![New Template created](/knowledgebase/images/img_mergefields_docxmerge8.png)

### Sequence

This workflow can be divided into four functions:

* getting the current Terms of Business from iManage;
* saving the Terms of Business to the field on the record;
* generating the Client Services Agreement, including the merged Terms of Business;
* saving the Client Services Agreement and starting the DocuSign process.

![Sequence](/knowledgebase/images/img_mergefields_docxmerge9.png)

1. The sequence is activated from another sequence when a user completes a task.
2. An **API Call** gets the document version number. At this stage, the document number is already known and forms part of the API Call URL, but the document version number is not yet known.
3. A **Local Variable** stores the document version number.
4. A second **API Call** sends a GET request. This time, both the document number and the version number are included in the URL so that the API Call can return the most recent version of the Terms of Business.
5. A **Document picker** actor collects the Terms of Business.
6. An **Update record** actor files the Terms of Business on the record in the **Terms of Business** document field.
7. A **DocAuto** actor generates the Client Services Agreement from the template and merges record data into the document.
8. A **Document picker** actor collects the Client Services Agreement.
9. An **Update record** actor files the document on the record in the **Client Services Agreement** document field.
10. A **Sequence runner** actor activates the next part of the process, where the Client Services Agreement is sent to DocuSign for signing.

Depending on the process, the Client Services Agreement could also be included in a review task, as in the first scenario. It could also be emailed to the client for review before being sent to DocuSign.

The following screenshots are taken from the document viewer on the record.

The image merge field has merged the client logo into the top left of the document header.

![See logo in header](/knowledgebase/images/img_mergefields_docxmerge10.png)

The Terms of Business have been merged into the Client Services Agreement.

![Terms document merged into CSA](/knowledgebase/images/img_mergefields_docxmerge11.png)

## Handling optional .docx merge fields

If there is any possibility that a document merge field may be empty when the master document is generated, include an IF statement.

```jinja
{% if record.field_data_security_clause %}
{{ p record.field_data_security_clause[0].embedded.inline }}
{% endif %}
```

This prevents the merge field from trying to merge content from an empty field.

## Things to remember

1. The `.docx` merge field works only in document templates.
2. The feature supports only `.docx` files.
3. An index is always required. If your field holds only one document, you must still specify `[0]`.
4. If you refer to an index that does not exist, such as `[2]` where the field has only one file, the merge field returns an empty string.
5. Use an IF statement where the document field may be empty at the time the master document is generated.
6. Use the image merge field for image files rather than the `.docx` merge field.
7. Use Jinja2 conditional logic for smaller conditional clauses that do not need to be stored as separate `.docx` documents.

---

---
url: /knowledgebase/system-configuration/document-automation.md
---
# Document Automation

**This section is currently empty or under construction.**

---

---
url: /knowledgebase/system-configuration/sequence-actors/document-picker-actor.md
---

# Document Picker Actor

The Document Picker actor facilitates the onward movement of documents processed through a DocAuto actor or captured in a Get request API call or Record field.

It enables documents to be available as attachments in a Send Message actor or for "filing" in a Record field.

When configuring a Post or Patch API Call actor with Data Type "Form Data", "Multipart Data" or "Binary Data" after a Document Picker, you will find a "Files" section under Parameters. This allows you to send multiple documents seamlessly, extracted from one or several Document Picker actors connected in series.

Each Document Picker can handle multiple documents depending on what is in the field selected. However, you should be cautious about using Document Pickers on fields which contain dozens of documents, as this can slow your process down. As an alternative, the "Combine results" feature allows Document Pickers to collect any number of documents in a process path and handle them as a set of documents at a suitable point.

## How do I use the Document Picker actor?

A Document Picker actor can be clicked and dragged from the actor menu, then dropped onto the sequence workspace.

Drag a trigger to it from the preceding sequence object and add the required conditions.

Right-click on the Document Picker and select "Configure".

**Depending on the preceding object, the Source field could have the following options:**

* **Document Field** - when this option is selected, the Object class Document type fields will be available as a single-select in "Field"
* **API Call Document**
* **DocAuto Actor**

**If the Document Picker actor is the first object in the sequence, or it follows a Create Task, Set Task, Record Access or other actor than DocAuto or API,** the only option available in the Source field will be "Document Field".

![Screenshot 2026-03-23 at 12.12.25.png](../../../images2/zendesk_5505947633567_001_10587325e422.png)

Select the appropriate document field.

**The document will then be available:**

* **To be sent as an attachment in an email**

![Screenshot 2026-03-23 at 12.26.41.png](../../../images2/zendesk_5505947633567_002_beff1336dcfd.png)

* **To be sent via API to a third party**

![Screenshot 2026-03-23 at 12.29.43.png](../../../images2/zendesk_5505947633567_003_d57366071b6a.png)![Screenshot 2026-03-23 at 12.38.09.png](../../../images2/zendesk_5505947633567_004_9a7bcc4e0d27.png)

* **To be sent via API to another record in a different object class within the Autologyx system or to another Autologyx system**

  A use case for this could be: having negotiated a new contract you might want to use it as a template and create a new record for it to make it available for future processing.

**If the Document Picker follows a DocAuto actor,** the Source field will also contain the option to take the document from the DocAuto actor.

In the workflow below, the task contains fields which will be populated in the document templated selected in the DocAuto actor. The Document Picker collects the processed document and makes it available for onward use.

![Screenshot 2026-03-23 at 12.49.24.png](../../../images2/zendesk_5505947633567_005_8f038b4c76a4.png)![Docsmultipart2\_article.gif](../../../images2/zendesk_5505947633567_006_170008d08de6.gif)

**If the Document Picker follows an API Call actor,** the Source field will also contain the option to take the document from the API Call.

![Screenshot 2026-03-24 at 10.57.54.png](../../../images2/zendesk_5505947633567_007_d5fa9409aa87.png)

## Document Picker/DocAuto processing

Having picked a document, if it is in Word format (.docx) and contains Jinja merge fields or functions, the Document Picker can be connected to a DocAuto actor where the Jinja will be processed.

This article will give you a start on [the correct syntax for merge fields](/knowledgebase/system-configuration/merge-fields/syntax-for-merge-fields/).

**In the example below, two Document Pickers can be seen. The process comprises:**

1. API Get request to iManage to fetch a document template
2. Document Picker collects returned document from API call
3. DocAuto actor is used to "process" Jinja merge fields
4. Document Picker collects processed document
5. Document is filed in a record Document field via the Update Record actor
6. Document is made available for review in a Create Task actor

![Screenshot 2026-03-24 at 12.56.00.png](../../../images2/zendesk_5505947633567_008_702d698816e6.png)

## How does Combine Results work?

You will have noted that the Document Picker actor configuration contains a checkbox labelled "**Combine results**".

This feature allows you to process documents through a workflow and get them all together in a field or as attachments to an email, usually towards the end of sequence process.

![doc5.png](../../../images2/zendesk_5505947633567_009_7ec95bca1bcb.png)

**If enabled (checked),** the Document Picker will pick up all the documents in the sequence path leading to it. **If not enabled (unchecked),** the Document Picker will only pick the document from the immediately preceding sequence actor.

**For example, in the sequence workflow below:**

![doc6.png](../../../images2/zendesk_5505947633567_010_c1c87d10b8fb.png)

* **The Update Record actor labelled 3** will update the document field with documents generated by:

  * the API call actor labelled 1
  * the DocAuto actor labelled 2

  because both the preceding Document Pickers have “Combine results” on.

* **The Send Message actor labelled 4.2** will contain attachments from:

  * the API call actor labelled 1
  * the DocAuto actor labelled 2
  * the DocAuto actor labelled 4.1

  because all three of the preceding Document Pickers have “Combine results” ticked, ie ON.

* **The Send Message actor labelled 5.2** will contain an attachment only from the DocAuto actor labelled 5.1 because the Document Picker immediately preceding this Send Message actor has “Combine results” unticked, ie OFF.

## Related articles

For related articles, have a look at these:

```json
[The DocAuto actor](/knowledgebase/system-configuration/sequence-actors/docauto-actor/)
```

[Create Document Template](/knowledgebase/system-configuration/working-with-document-templates/create-a-document-template/)

[Automatic Document Generation](/knowledgebase/system-configuration/working-with-document-templates/automatic-generation-of-documents-via-the-sequencer/)

---

---
url: >-
  /knowledgebase/system-configuration/working-with-document-templates/document-templates-list.md
---

# Document templates list

The Document templates list can be found by clicking the **Document templates** tab in an Object class.

To view this list, and the other tabs in an Object class, you will need one of the following:

* A Super Admin user account
* A Role with permission to edit object classes
* Be a member of a Permission set which allows the User to edit a specific Object class

## What you can see at the top of the list

**At the top of the list, you will see:**

* a counter which shows the number of templates in the list
* the **+ Create** button - used to create a new template. [Click here](/knowledgebase/system-configuration/working-with-document-templates/create-a-document-template/) for further information on creating a document template
* pagination function
* column configuration button - allowing you to add additional columns to the list

## Default listing

**The default listing comprises:**

* *ID* - the unique ALX ID number associated with the document template
* *Name* - name given to the template by the user who created or last edited it. This column cannot be removed
* *Template File Name* - name of uploaded Word document in .docx format. This appears as a link so that when clicked the template file is downloaded
* *Actions* - menu with options to **Edit**, **Download** or **Delete** the template, as well as an option to **View usage**. This column cannot be reordered or removed

![Screenshot 2024-01-24 at 19.25.21.png](../../../images2/zendesk_16309720012701_001_f8159ca18fec.png)

**View usage** shows in which sequences, if any, the document template is generated via a DocAuto actor. Templates can only be deleted if not used in any sequences.

## Additional columns

**Other column headers are available via the Column configuration button:**

![Screenshot 2024-01-24 at 19.34.50.png](../../../images2/zendesk_16309720012701_002_f20cd508f85b.png)

* *Created* - shows the date/time that the template was created
* *Created by* - shows the avatar and name of the user who created the template
* *Description* - this is an optional field when creating or editing the template. It is useful if you have a number of similarly named templates which are used under different circumstances, to help a user tasked with editing a template which they didn't create
* *Last edited* - shows the date/time that the template was last amended
* *Lasted edited by* - shows the avatar and name of the user who was last to edit the template
* *Manual generation* - indicates whether "document manual generation" has been enabled. [Click here](/knowledgebase/system-configuration/working-with-document-templates/manual-generation-of-a-document-from-a-template/) for more information

![Screenshot 2024-01-24 at 19.35.40.png](../../../images2/zendesk_16309720012701_003_b6ca9a9cd1be.png)

## Editing from the list

A user can double-click on a row to edit the document template setup. [Click here](/knowledgebase/system-configuration/working-with-document-templates/edit-a-document-template/) for further information about editing a document template.

## Empty state

If no document templates have been created, the list will be empty with a "No Document templates created" message displayed instead.

## Useful info

1. You can have up to 1000 document templates in any object class.
2. This list does not have a filter, but you can sort by ID or Name to find required templates.

---

---
url: /knowledgebase/release-notes/release-notes-1.5/documents-in-sequencer.md
---

# Documents in Sequencer

The Sequencer, your trusted ally in workflow management, has just become even more versatile. We're excited to present our latest feature: binary and multipart documents support in a Sequencer, designed to provide you with unparalleled flexibility, control, and dynamism.

## Form Data

When configuring your API Call actor with Data Type **"Form Data,"** you'll now find a new **Files** section under Parameters.

This addition allows you to send multiple documents seamlessly, extracted from one or multiple Document Picker actors connected in series. Whether you're creating contracts, proposals, or other essential documentation, this feature will save you time, reduce errors, and elevate the quality of your work.

**Validation is included**: forget to name your file? We'll catch that for you.

![Docsmultipart\_article.gif](../../../images2/zendesk_12572795517085_001_3d15e6b7fe3b.gif)

## Binary Data mode

For those times when you just need a single document, the API Call actor's **Binary Data** mode has you covered.

In the **Files** section, you can choose a single document from the available options, ensuring precise and efficient data handling.

Now, you can effortlessly use selected documents for a range of tasks, from sending them via email to integrating them into other processes.

![Docsmultipart2\_article.gif](../../../images2/zendesk_12572795517085_002_170008d08de6.gif)

**Manage and send crucial documents effortlessly**, making data handling swift and efficient. Experience automation like never before and boost your efficiency to accomplish more. Happy automating!

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.13/dynamic-document-assembly-with-.docx-merge-fields.md
---

# Dynamic document assembly with .docx merge fields

Legal documents live in fragments before they become whole. You've got pre-approved clauses sitting in one place, witness statements in another, and regulatory annexes scattered across different files. With our latest enhancement to Document Templates, you can now merge the content of `.docx` files stored on a record directly into your generated documents, using a precise and highly controllable merge field syntax.

## New merge field syntax

```jinja
{{ record.field_&lt;alias&gt;[index].embedded }}
```

With this syntax, you can embed the full content of a `.docx` file into a template, precisely where the merge field is placed.

That file can be:

* A pre-approved clause block
* A formatted cover page
* A pre-signed declaration
* Any other component your team has stored in a document field

This merge field reads the content from the `.docx` file and injects it directly into the generated document at that exact location, preserving all formatting, headings, spacing, styles, etc.

**This opens up powerful use cases such as:**

* Assembling client letters from pre-approved legal paragraphs
* Generating bespoke contracts by slotting in optional `.docx` annexes
* Dynamically inserting terms & conditions or disclaimers based on record logic

You have two options for how the `.docx` content is merged, depending on whether you want it inserted within a paragraph or to replace the paragraph entirely.

## Merge options

### **Inline merge (default)**

```jinja
{{ record.field_annexes[0].embedded }}
```

This places the `.docx` content within the paragraph where the merge field sits. Use this when embedding into a block of text, or where paragraph breaks are controlled externally.

### **Paragraph replacement (inline paragraph merge)**

```jinja
{{p record.field_annexes[0].embedded.inline }}
```

This version replaces the entire paragraph where the merge field appears.

**This is especially useful when:**

* You want exact formatting from the inserted `.docx` block
* You’re embedding long content such as multi-paragraph annexes
* You want to avoid nesting block elements inside other paragraphs

The {{p ... }} syntax ensures clarity and structure in the output document.

## Important rules and validations

To ensure predictable behavior, keep the following in mind:

* **Works only in Document Templates:** If used elsewhere (e.g. Sequencer), the merge field returns an **empty string**.
* **Supports only `.docx` files:** If the referenced file is not a `.docx` (e.g. PDF, TXT), the merge field resolves to an **empty string**.
* **Index is always required:** Even if your field only holds one file, you must specify `[0]`. Example: {{ record.field\_clauses\[0].embedded }} Omitting the index will return an empty result.
* **Out-of-range index? Empty result:** If you refer to an index that doesn't exist (e.g. `[2]` in a field with one file), the merge field returns an empty string.

## In summary

Document assembly just became modular. Store your `.docx` building blocks in document fields, reference them through merge fields, and create templates that adapt to real-world needs without manual intervention.

No more copy-paste workflows. No more formatting inconsistencies. Just professional documents assembled exactly as you intended them.

---

---
url: >-
  /knowledgebase/system-configuration/working-with-document-templates/edit-a-document-template.md
---

# Edit a Document Template

## Before you begin

To edit a Document Template, you will need one of the following:

* A Super Admin user account
* A Role with permission to edit object classes
* Be a member of a Permission set which allows the User to edit a specific Object class

## Edit the template

From the System configuration section of the main navigation menu, go to **Object classes**. Double click the row for the required **Object class** or select **Edit** in the **Actions** menu.

Click the Document templates tab. By default, document templates are listed alphabetically by **Name**.

Either double click the row for the template you wish to edit or select **Edit** in the **Actions** menu.

![Screenshot 2024-01-24 at 12.00.32.png](../../../images2/zendesk_16299755890717_001_4a655a5e41a0.png)

You can then edit the document template **Name**, **Description**, and enable or disable document manual generation. The document template name must be unique in the context of the **Object class**.

In addition, you can download the existing template and add or amend merge fields, IF Statements, and other function Statements, as well as change the document text, layout, and formatting. This revised version will need to be saved locally.

**Important:** When all required changes have been made, remember to remove the existing template and upload the amended one in its place.

![Screenshot 2024-01-24 at 12.35.35.png](../../../images2/zendesk_16299755890717_002_da5b554509c5.png)

![Screenshot 2024-01-24 at 12.14.32.png](../../../images2/zendesk_16299755890717_003_e5182e297de6.png)

Click **Save**. You will be taken back to the document template list.

---

---
url: >-
  /knowledgebase/system-configuration/object-classes/edit-object-class---configure-displays.md
---

# Edit Object class - configure displays

Once an Object class has been created, you are asked whether you would like to add fields for it now. If you choose to do this straight away, you will be taken to the Edit Object class page.

There are actually 5 tabs which can be configured: **Fields, Display, Forms,** Document Templates **and Permissions**. However, you will need to create fields to be used in the Display tab before you can create your 3 views. Fields are also required before you can configure Forms and Document Templates.

Note that when you visit the Display tab for the first time, the Card view is enabled and will contain the field which has been chosen as the Identifier. If no field has been marked as such, the ALX ID will be used instead.

![1206a.png](/knowledgebase/images/img_5980422270109_1776895947.png)

In the below screenshot, Mortgage Application Number is the Identifier. As it is auto-selected in the Card view, it is greyed out in the Fields menu on the right.

![1206b.png](/knowledgebase/images/img_5980422270109_1776895947.png)

Both the Create and edit view and the Summary view are disabled by default.

It is important to understand where each of the 3 views will be used in the system so that you can make best use of the available fields for each view and show useful data once Object records have been created.

## Card view

This view is given as an alternative to the traditional list view in the Object record list.

The list view is like all other lists, with records shown in alternating white and grey rows, with a selected record in blue.

![mceclip0.png](/knowledgebase/images/img_5980422270109_1776895947.png)

|  |  |
| --- | --- |
| The list has an additional icon for Card view. When the User hovers over the icon it will display, "Switch to card view". | mceclip4.png |

Card view is displayed as below.

![1206c.png](/knowledgebase/images/img_5980422270109_1776895948.png)

The Card view is designed to provide key details which can be edited in what is effectively a snapshot view.

However, each record has an "Open" icon in the top left-hand corner which will allow you to open it to view the full details and edit, depending on your permissions.

|  |  |
| --- | --- |
| When in card view, the list view icon allows the User to switch to list view. | mceclip3.png |

## Create and edit view

Here you are essentially configuring a form which will allow Users to create and update Object records. This form will be presented when:

* the + Create record button is used from the Records list
* a User double clicks on a Record in the Records list
* a User selects "Open" in the Record Actions menu
* a User clicks "Open" in the Card view

## Summary view

The Summary is shown in the right-hand panel when a User selects or opens a record in the list or card view.

|  |  |
| --- | --- |
| If the Summary is not displayed in the side panel, click View in the top right hand side horizontal menu.  Click on Summary so that a blue tick is displayed to the left.  View will close and the Summary will appear in the panel. | 1206e.png |

It is useful when clicking through records in the list or card view to have the Summary open in the side panel so that you can view the essential data without having to open each record individually.

It is for information only and is not editable.

## Configuring the displays

**The premise for configuring each view is exactly the same.**

Double click on the view or select **Configure** in the Actions menu. This will take you to the edit display screen for the particular view. Here you will find a form builder made up of the canvas in the middle section and the available Components for selection in the side stack. Components are generally in three sections: **Layout** (not Card view), **Fields** and **Properties**.

Components can be dragged and dropped into sections on the canvas. Once the component is in place, click on it to open the properties or options panel where you can configure it as required.

[CLICK HERE](/knowledgebase/record-and-task-forms/formbuilder-components/) for section describing formbuilder, components and fields.

### The Card view

The Card view has only one section; you will not be able to create any further sections. However, you can select 2 or 3 columns for the Section. In addition, when configuring the Card view there is no Instructions component, so the Layout section is not shown.

You will be able to select a Column ratio which will determine the width of each column in the Section. You will also have the ability to set spacing around the fields and within the field, the same as for the other views.

### In the Create and edit view

The User will be able to configure numerous Sections containing 1, 2 or 3 columns. They will be able to use Conditional Visibility for additional Sections to be displayed on the basis of previous field values.

In the below form, the Section entitled "Details Regarding Interest" is shown only on the basis of the selection in field "Mortgage type" being "Interest only".

![cond\_vis\_create\_edit.jpg](/knowledgebase/images/img_5980422270109_1776895949.png)

|  |  |
| --- | --- |
| It is important to remember to Enable the display once you have configured it. | mceclip6.png |

There is a Preview button next to Save on the right-hand side so that the User can check how the form looks. Note that Sections which are conditionally displayed will not show unless the dependent field(s) have been populated correctly.

![mceclip7.png](/knowledgebase/images/img_5980422270109_1776895949.png)

![mceclip8.png](/knowledgebase/images/img_5980422270109_1776895949.png)

Click the Exit preview button to return to the display configuration.

### The Summary view

The Summary view can contain numerous sections but there is a limit of 2 columns, as the area where this view is displayed in the side panel is much narrower.

![mceclip9.png](/knowledgebase/images/img_5980422270109_1776895950.png)

|  |  |
| --- | --- |
| Each view has a Revert button which will only be enabled when a view has been saved and is then amended. When clicked the User will be asked to confirm the revert action or to they can choose to Cancel. | mceclip0.png |

If a User makes a change to the Object class Fields, eg creates a new field, amends or removes an existing field, those changes will be reflected in all three views under the Display tab:

* Newly added fields are shown in the Components panel
* Deprecated fields are removed from the form (if applicable) and from the Components panel
* Changes to field Labels are updated in the form or panel depending where they reside

## Useful info

1. All Object class fields are available for selection in all views.
2. System fields are available to be displayed in all views. These fields are: ALX ID, Created date/time which records when the Record was created, Updated date/time which shows when the Records was last edited and Owners which will display the Avatars of all Users who are Owners of the record (not Card view).
3. The Card view can contain only one section with up to 15 fields.
4. Card view is enabled by default but Create/edit and Summary views must be enabled for use.
5. A maximum of 100 sections and 200 other components (instructions, fields and properties) can be added to the Create and edit view.

---

---
url: >-
  /knowledgebase/system-configuration/object-classes/edit-object-class---creating-class-permissions-and-addremove-assignees.md
---

# Edit Object class - creating Class permissions and add/remove Assignees

## Overview

When in Edit mode, one of the tabs on an Object class is Permissions.

In order to be able to create a Permissions set, you must be one of the following:

* A User with a Super admin account type
* An Owner of the Object class

The User who created the Object class will immediately become an Owner.

The Owners' Permissions are set by default and are fully enabled. These cannot be edited.

However, the Owner can add further Owners and additional sets of Permissions to which Users and/or User groups can be added as Assignees.

Click on the Permissions tab. This is defaulted to Class permissions. You will see the Owners and any other Permission sets which have already been created ie Mortgage Handler, shown below.

![](/knowledgebase/images/img_5982027957277_1776895956.png)

Click [HERE](/knowledgebase/system-configuration/object-classes/explanation-of-class-permissions/) for an explanation of Class Permissions.

## Add a new Class permission set

**To add a new Class permission set:** ensure you are on the Class permissions tab, then click the + Add permission set button.

A new modal will be presented where a name for the Permissions set must be entered. All permissions are defaulted to disabled until the Owner enables those which are required.

![](/knowledgebase/images/img_5982027957277_1776895956.png)

Having enabled the required Permissions, click the green tick button.

![](/knowledgebase/images/img_5982027957277_1776895957.png)

A green Success toast message will be seen onscreen.

The Permission set will be created and there will be a link to Add assignees.

![](/knowledgebase/images/img_5982027957277_1776895957.png)

## Add assignees

**To add assignees:** click the Add assignees link and the Manage assignees side panel will open.

Note that there are two tabs so that you can select and add individual users and/or User groups.

### Add individual users

**To add individual users:** stay on the Users tab and click the + button.

![](/knowledgebase/images/img_5982027957277_1776895957.png)

You will now be able to search for Users whom you wish to give these permissions.

As you start typing, the list of available Users will be filtered to those matching the search query.

Users with a 1-time completion account type will not be shown as they cannot be given class permissions.

![](/knowledgebase/images/img_5982027957277_1776895957.png)

Click on each User. Their name will grey out and adjacent will be displayed, "Already selected".

![](/knowledgebase/images/img_5982027957277_1776895958.png)

When you have selected all required Users, click out of the search field. Users will be listed as shown below.

Click the + Add button in the bottom right hand side of the panel.

![](/knowledgebase/images/img_5982027957277_1776895958.png)

You will see a green toast Success message.

### Add User groups

**To add User groups:** click onto the User groups tab and click the + button.

Search for and select the required User group(s), then click the green + Add button.

|  |  |
| --- | --- |
|  |  |

The number of Users and User groups added will be shown in brackets.

![](/knowledgebase/images/img_5982027957277_1776895959.png)

Click Close in the bottom right hand side of the panel.

Assignee avatars will be shown at the top of the new Permission set; User groups first (squared), then individuals (round). Users will have the defined permissions immediately irrespective of whether individual or in a group.

![](/knowledgebase/images/img_5982027957277_1776895959.png)

## Remove assignees

**To remove assignees:** click the kebab menu on the appropriate Class permission set and select Manage assignees.

![](/knowledgebase/images/img_5982027957277_1776895959.png)

The Manage assignees side panel will open. It is defaulted to the Users tab.

The assignees are listed in alphabetical order by first name. The User's avatar, last name and username are also shown.

![](/knowledgebase/images/img_5982027957277_1776895959.png)

|  |  |
| --- | --- |
| Simply click the X on the right hand side of the User you wish to remove.  The confirmation modal will be displayed.  If you click Cancel, the User will remain in the assignees list.  If you click Yes, remove, the User will be removed from the list and the total number of assignees will reduce accordingly. |  |

User groups can be removed in the same way from their tab.

When you have removed the unwanted User(s)/User group(s), click Close.

![](/knowledgebase/images/img_5982027957277_1776895960.png)

The side panel will close and the Permission set will be saved with the remaining Users and User groups' avatars shown under the Permission set Name.

The removed Users will immediately lose the permissions associated with the Permission set.

## Related information

**Record Permission sets are created in the same way. However, Owners and Assignees of these Permission sets are managed against individual records.**

Click [HERE](/knowledgebase/system-configuration/object-classes/explanation-of-record-permissions/) for an explanation of Record Permissions.

Click [HERE](/knowledgebase/system-configuration/object-classes/edit-object-class---editing-permission-sets/) for more information about Editing Permission sets.

## Useful info

1. Each Object class can have up to 10 Permission sets.
2. Each Permission set can have up to 100 Assignees.
3. Each Permission set can have up to 10 User groups.

---

---
url: >-
  /knowledgebase/system-configuration/object-classes/edit-object-class---editing-permission-sets.md
---

# Edit object class editing permission sets

To edit a Permission set, you must be one of the following:

* A User with a Super admin account type
* An Owner of the Object class

It is worth noting that other Users can view the content of the Permissions tab but cannot edit it. These are:

* Users who have a Role where the Edit permission for Object classes is enabled on the Data Model tab
* Users who have a Permission set where the Edit Object class permission is enabled

**To access permission sets:** navigate to the Object class, then select **Edit** in the Actions menu.

Click on the **Permissions** tab.

By default, you will be on the Class permissions section. If you want to edit Record permissions, click on this section instead.

You will not be able to edit Owners' permissions in either section, as these are set to fully enabled.

Owners can be added or removed from the kebab menu on the Class permissions/ Owners' Permission set, while Assignees can be added or removed in the same way from other Class permission sets.

Owners and Assignees for Record permissions are not managed here. They are managed against individual records in the class.

|  |  |
| --- | --- |
| 1i.png | 1j.png |

## Manage Owners

Selecting this option will open the Manage owners side panel where the User can:

* Add owners
* Remove Owners, inluding themself

|  |  |
| --- | --- |
| In the event that an Owner chooses to remove themself the adjacent warning is shown.  The Owner can confirm or cancel.  If the Owner proceeds and has a Super Admin account the Manage Owners panel will remain open, their tile is removed from the Manage Owners panel and the Owner counter is decremented.  If the Owner is a Standard User with Edit class permissions, the Manage Owners panel will close and the Permissions tab content becomes read-only.  If the Owner is a Standard User without Edit class permissions, the Manage Owners panel and Edit Object class page will close and the User is redirected to the Landing page. | mceclip1.png |

|  |  |
| --- | --- |
| In order to add Owners, the current Owner or Super admin User must click the blue Add owners button. | mceclip2.png |

|  |  |
| --- | --- |
| This will allow them to search the Users and select those who are to become Owners of the Object class.    Click the green + Add button in the bottom right of the panel.    The green success toast will be displayed on-screen.    Close the panel to finish the process. | mceclip3.png |

As Owners are added or removed, the number of Owners shown in the Manage Owners panel and the Owners column on the Object class list will increase or decrease accordingly.

## Manage Assignees

Users can add and remove Assignees of other Class Permission sets in the same way. The kebab menu for these Permission sets has 3 options.

Select **Manage assignees**. The Manage assignees panel will open on the right hand side.

![1k.png](/knowledgebase/images/img_4471977904159_1776895962.png)

An Assignee can be deleted by clicking the **X** in their tile.

|  |  |
| --- | --- |
| A modal will be displayed asking the User if they are sure.  Selecting Cancel will close the modal.  Confirming Yes, remove will mean that the User is removed from the Permission set. The number of Assignees will alter accordingly.  The removed User will immediately lose the associated permissions. | Screenshot 2024-08-01 at 19.30.07.png |

Click **+ Add assignees** to give additional Users these permissions.

Start typing in the search field so that the list filters to match the parameters entered.

![1l.png](/knowledgebase/images/img_4471977904159_1776895962.png)

|  |  |
| --- | --- |
| Click on the User name. The User name will grey out and "Already selected" will be displayed to the right of it.  Continue adding the required Users, then click the green + Add button in the bottom right of the panel. Close the panel to complete the process.  The newly added User(s) will immediately have the associated permissions. Click **[Here](/knowledgebase/system-configuration/object-classes/edit-object-class---creating-class-permissions-and-addremove-assignees/)** for more information on creating Permission sets. | Screenshot 2024-08-01 at 19.36.18.png |

The other options in the kebab menu for both Class and Record additional permission sets are:

* **Edit** - which will allow the User to change the permissions for the Object class or Object records and/or Tasks associated with the records.

  Selecting this option will open the Permission set modal. The permissions can be changed. So for instance, in the example of the Mortagage Handler Permission set, the Delete all permission under Object records has been given in error, as has the Assign all permission under Tasks.

|  |  |
| --- | --- |
| mceclip5.png | Disable the wrongly assigned permissions.  Click the green tick button and the amended Permission set will be saved.    mceclip7.png  Users will immediately lose the removed permissions. |

* **Delete** - which will allow the User to delete the Permission set. A warning modal will be displayed like this:

![mceclip10.png](/knowledgebase/images/img_4471977904159_1776895964.png)

The User can opt to **Cancel**, which will close the modal and return the Permission set to the resting position.

If they choose to confirm, **Yes delete**, the warning modal closes and the Permission set is deleted from the Permissions table. The Assigned Users will have their permissions for the Object class or Record removed immediately.

**Useful info:**

1. Each Object class can have up to 10 Permission sets.
2. Each Permission set can have up to 100 Assignees.
3. Avatars of Owners and Permission set Assignees are always shown in alphabetical order.

---

---
url: >-
  /knowledgebase/system-configuration/object-classes/edit-object-class---remove-fields.md
---

# Edit Object class - Remove fields

## Permissions required

To remove fields from an Object class, you must have one of the following:

* A Super admin account type
* Be an Owner of the Object class
* Have a Role with the Object class Edit permission enabled on the Data Model tab
* Have a Permission set for the specific Object class with the Object class Edit permission enabled

## Remove a field

**To remove a field:** find the field on the Fields list and select **Remove** from the Actions menu.

![mceclip0.png](../../../images2/zendesk_6006848684061_001_8c9f76caf443.png)

A warning message is displayed to the User, as shown below.

![mceclip1.png](../../../images2/zendesk_6006848684061_002_0c1175c5354b.png)

* If this action was unintentional and you select **Cancel**, the modal will close and you will remain on the Fields list.
* If you select **Remove** and the field is not populated in any Object records or used in any task templates for the Object class, you will see the green success toast message on-screen.
* If the View usage or Edit panel was open when the field was removed, it will be automatically closed.

## If the field is in use

If you select **Remove** and the field is populated in any Object records or used in any task templates for the Object class, the modal below will be displayed.

![mceclip2.png](../../../images2/zendesk_6006848684061_003_db0dbf227c3b.png)

When you click **OK**, the modal will close and the View usage panel will open. This provides a summary of where in the system the field is in use:

![mceclip3.png](../../../images2/zendesk_6006848684061_004_e12fc5747820.png)

In the screenshot above, the field to be removed is in use only by 5 Object records. **Only when these field associations have been removed** will you be able to remove the field itself.

---

---
url: /knowledgebase/system-configuration/sequences/editing-a-sequence---design.md
---

# Editing a Sequence - Design

Once you have created a Sequence, you will need to edit it in order to construct the workflow. This is done from the Sequence list. Either double click the Sequence row or select **Edit design** in the Actions menu. Either will open the Edit page in a new browser tab.

## Requirements

In order to edit any part of the Sequence design, you must meet one of the following requirements:

|  |  |
| --- | --- |
| - You have a Super admin account type - You have a Role with the Edit permission enabled under the Sequencer tab. This is commonly enabled together with the Create permission but can be applied alone if the User's Role is more about system maintenance rather than design and creation. In addition, you must be an Owner of the Object class for which the Sequence has been created | mceclip0.png |

If you are editing the Sequence design for the first time, the page will open with an empty **Workflow** area like this:

![mceclip0.png](/knowledgebase/images/img_6231868039837_1776895996.png)

## Workflow design

The Object class which was selected when the Sequence was created will be displayed in the Object class section at the top of the Sequence.

Click **[HERE](/knowledgebase/system-configuration/sequences/navigation-and-menus/)** for information about Sequence navigation and menus.

**To start constructing your Sequence:** click **Edit** in the top horizontal menu.

Click and drag the first object into the Workflow area. Let's say this is a Task template; in this example the Object class is Mortgage Application and the Task template is GDPR Agreement. You will need to click on the Object class in the object class area of the Sequence and drag a connector to the Task template object like this:

![mceclip0.png](/knowledgebase/images/img_6231868039837_1776895997.png)

When the receiving object is outlined in green, you can release the mouse to drop the connector. A trigger configuration modal will open like this:

![mceclip1.png](/knowledgebase/images/img_6231868039837_1776895997.png)

## Starting conditions

You will need to select the starting condition.

A Sequence can be triggered to commence **when** the selected method is true, or it can be delayed. Open the drop-down which is defaulted to **When** and there is an option for **After**.

Select **After** and two further fields are displayed before After. The second of these fields has options based on time.

![mceclip2.png](/knowledgebase/images/img_6231868039837_1776895997.png)

|  |  |
| --- | --- |
| Select the appropriate time option delay and enter the number required in the first field, as shown above. When the trigger configuration is saved a clock icon is shown on the trigger to indicate that this is a timed trigger. | mceclip3.png |

### Record created

**Record created** - the most commonly used method of starting a Sequence. This is **When** (or **After** a specified time) a **Record is Created**. This simply means that when a record of the selected Object class is added to the system, the Sequence will commence the workflow. It doesn’t matter what method is used to create the record, the Sequence will run.

### Record updated

**Record updated** - this is another commonly used method of starting a Sequence or a particular workflow contained in a Sequence. It relies on data in the Object Record being added or amended. However, it is rarely used without further conditions being added.

In the below example, the Sequence workflow is started by an update to a record in the Mortgage Application Object class, with an additional condition being that a field on the record called “Risk level” must have the value “High”.

![mceclip4.png](/knowledgebase/images/img_6231868039837_1776895998.png)

It is important to note that addition or change to an Object record by certain methods constitutes an update to the record and can therefore be used to commence a Sequence. The change made manually directly into the Object Record or via an Update object record Task type is an update.

A change made via an API Call is also considered an update. However, a change made via an Update Record Actor in a Sequence does **NOT** constitute an update in terms of commencing Sequence workflow. This is a deliberate architectural limitation in order to prevent eternal loop processing.

### Record created or updated

**Record created or updated** - the Sequence will start when a record is created/added to the Object class OR when an Object record is amended.

### Sequence Activated

**Sequence Activated** - this method allows you to activate the Sequence from another Sequence. In the example shown, the Sequence called “Mortgage Application-primary2” has the starting trigger, “When Sequence Activated”.

![mceclip5.png](/knowledgebase/images/img_6231868039837_1776895998.png)

In the Sequence below called “Mortgage Application-primary1”, you can see in the Sequences section of the left hand menu, there is a Sequence called "Mortgage Application-primary2".

This Sequence object can be dragged and dropped onto the workspace of another Sequence and connected from any other object. **Note:** the pink object on the Workflow.

![mceclip7.png](/knowledgebase/images/img_6231868039837_1776895998.png)

## Related articles

Other articles which may be of interest:

```json
[Adding conditions for Sequence commencement](/knowledgebase/system-configuration/sequences/adding-conditions-for-sequence-commencement/)
```

## Useful info

1. Only Task templates with the **Task creation mechanism** set to **Automatic** will be available for selection in the left hand menu.

---

---
url: >-
  /knowledgebase/system-configuration/sequences/editing-a-sequence---properties.md
---

# Editing a Sequence - Properties

Editing a Sequence is split into two distinct parts: **Properties** and **Design**.

## Access requirements

To edit any part of a Sequence, you must meet one of the following requirements:

|  |  |
| --- | --- |
| - You have a Super admin account type - You have a Role with the Edit permission enabled under the Sequencer tab. This is commonly enabled together with the Create permission but can be applied alone if the User's Role is more about system maintenance rather than design and creation | mceclip0.png |

## Opening the Edit properties page

To edit Sequence properties, find the Sequence in the list and select **Edit properties** from the Actions menu.

If you double-click the Sequence row, you will be taken to the Edit screen for the Sequence design.

The Edit properties page will open and look similar to the below:

![mceclip1.png](/knowledgebase/images/img_6231912369949_1776895999.png)

## Editable and non-editable properties

### Editable properties

The Sequence Name and Description can be amended, but the restrictions from creation are carried through, ie:

* **Name** must be unique and is mandatory, so cannot be blank; the character limit is 100
* **Description** has a character limit of 500. However, this field can be wiped as it is optional

### Non-editable properties

The Object class cannot be edited. This field is disabled.

## Managing default task assignees

Users can be added or removed as default task assignees.

Click the **Manage default task assignees** button to open the **Manage default task assignees** panel in the side stack.

|  |  |
| --- | --- |
| Existing default task assignees can be removed by clicking the x in their tile.  If you select **Cancel** the modal will close.  If you select **Yes, remove**, the User's tile will be removed, the default task assignees counter will decrement and the User's avatar will be removed from the main content page to the left of the **Manage default task assignees** button. That User will no longer be able to complete tasks created from the Sequence. | mceclip2.png |

|  |  |
| --- | --- |
| To add Default task assignees click the **Add default assignees** button. A search field will be presented. Start typing the first or last name or email address of the assignee you wish to add; the list will filter to the matching Users.  Click on the User tile to select them and then click Add. The green success toast fly-in will be shown.  Continue adding Users until all those required have been selected. | mceclip5.png |

|  |  |
| --- | --- |
| Users already selected will be greyed out, unavailable for selection and the **Already added** label will appear alongside their email address. | mceclip4.png |

The **Default task assignees** counter will be altered according to the changes made. Tiles representing the new Default task assignees will be added in the **Manage default task assignees** panel, and their avatars will be shown to the right of the **Manage default task assignees** button in the main content area.

## Saving and leaving the page

The **Cancel** button can be used to navigate away from the Sequence Edit page, but any changes made will persist.

This is true in the case of adding Default task assignees if the **Add** button in the panel has been clicked. Otherwise, the **Unsaved changes will be lost** warning modal will display.

There is no **Save** button, as this page supports in-place editing and changes take immediate effect.

For information on editing Sequence design, please click **[HERE](/knowledgebase/system-configuration/sequences/editing-a-sequence---design/)**.

---

---
url: >-
  /knowledgebase/administration/communication/editing-a-single-sign-on-setting.md
---

# Editing a Single sign-on setting

A Single sign-on (SSO) setting controls how users authenticate through an external identity provider.

You can edit most settings after an SSO configuration has been created. Changes take effect immediately and apply to future authentication requests.

## Permissions

Only the following users can edit Single sign-on settings:

* Users with a Super Admin account type.
* Users whose Role includes the **Create/Edit** or **Edit** permission for **Single sign-on settings** under the **Administration** section.

## Open an existing Single sign-on setting

From the **Single sign-on settings** list, either:

* double-click the required row, or
* select **Edit** from the **Actions** menu.

The Edit page displays the current configuration.

![Single sign-on configuration edit page](/knowledgebase/images/administration/editing-a-sso-setting-1.png)

## Editable settings

### Configuration name

The **Single sign-on configuration Name** can be changed at any time.

The name is mandatory and must remain unique. If you enter a name that already exists, a validation error is displayed and the configuration cannot be saved.

![Validation error shown when a duplicate configuration name is entered](/knowledgebase/images/administration/editing-a-sso-setting-2.png)

### Enabled

The **Enabled** switch can be turned on or off at any time.

When enabled, the configuration is available to users on the login page. The current state is also reflected in the **Enabled** column of the Single sign-on settings list.

![Enabled switch for a Single sign-on configuration](/knowledgebase/images/administration/editing-a-sso-setting-3.png)

### Single sign-on provider

The selected identity provider **cannot be changed** after the configuration has been created.

If you need to use a different provider, create a new Single sign-on configuration.

### Tenant ID

The **Tenant ID** is mandatory and can be updated if required.

### Client ID

The **Client ID** is mandatory and can also be updated.

Mandatory fields cannot be left empty. If a required value is removed, the **Save** button is disabled until the error is corrected.

![Validation message shown for an empty mandatory field](/knowledgebase/images/administration/editing-a-sso-setting-4.png)

### Client secret

For security, the **Client secret** is displayed as a series of asterisks.

When you click into this field, the stored value is cleared and you must enter the complete replacement secret before saving.

### Redirect URI

The **Redirect URI** is automatically generated when the connection between Autologyx and your identity provider is established.

This field is read-only and cannot be edited.

## Automatically create users

The **Automatically create user** option determines what happens when someone successfully authenticates through your identity provider but does not yet have a user account in Autologyx.

When this option is enabled, an additional field called **Roles to assign to created user** becomes available.

![Automatically create user enabled with Roles field displayed](/knowledgebase/images/administration/editing-a-sso-setting-5.png)

You can assign one or more Roles that will automatically be applied to newly created users.

A maximum of **10 Roles** can be assigned.

![Selecting Roles for automatically created users](/knowledgebase/images/administration/editing-a-sso-setting-6.png)

If no Roles are selected, newly created users can still sign in successfully but will have very limited access. For example:

* they can access the Landing page
* their Workspace will contain no records
* their Tasks list will be empty until appropriate permissions or task assignments are granted

Changes to the assigned Roles affect only users created after the configuration is updated. Existing users are not modified.

## Cancel or save changes

Click **Save** to apply your changes immediately.

Click **Cancel** to discard your edits.

You can also leave the page using the navigation menu or close the browser tab.

If there are unsaved changes, you'll be asked to confirm before leaving the page.

![Unsaved changes warning dialog](/knowledgebase/images/administration/editing-a-sso-setting-7.png)

## Things to remember

1. The Single sign-on provider and Redirect URI cannot be changed after a configuration has been created.
2. Mandatory fields must contain valid values before the configuration can be saved.
3. The Client secret must be entered again whenever it is updated.
4. Automatically created users can be assigned up to **10 Roles**.
5. Changes to assigned Roles affect only users created after the update.

---

---
url: >-
  /knowledgebase/system-configuration/object-classes/editing-a-standalone-form.md
---

# Editing a Standalone Form

## Permissions

**Users with one of the following will be able to edit a standalone form:**

* Super admin account type
* Config admin account type with a Role which allows them to edit object classes
* Owner of the object class
* Permission set allowing them to edit the object class

## Edit a standalone form

Navigate to the appropriate object class and click the **Forms** tab.

Either double-click the row of the form you wish to edit, or select **Edit** in the **Actions** menu.

![0807a.png](/knowledgebase/images/img_20048053057821_1776895954.png)

Once the form is opened, it will display as it was last saved, but without any object class fields which have since been deleted from the object class. If any field names have been changed, these will be displayed with the new field names.

## Available edits

**The following edits can be made:**

* **Disable the form.** If you do this, make sure that you have removed the link to the form if being hosted outside of your Catalyst application. Ensure that users are informed and that alternative arrangements have been put in place for the creation of records, if required. In the Forms list, the Status of the form will show as **Disabled**:

![0807b.png](/knowledgebase/images/img_20048053057821_1776895954.png)

If a user clicks the link to the form, they will be shown the below message:

![Screenshot 2024-07-08 at 15.02.56.png](/knowledgebase/images/img_20048053057821_1776895955.png)

* **Change the form name.** You must remember that this is a required field, so cannot be left empty, and the form name must be unique in the scope of the object class.
* **Change the Redirect.** You can enter a new URL for the page the user will be shown once the form has been submitted.
* **Remove the Redirect.** In this case, the user will see the default confirmation, as below, on submission of the form:

![Screenshot 2024-07-08 at 14.34.11.png](/knowledgebase/images/img_20048053057821_1776895955.png)

* **Disable Submit.** This will remove the submit button from the form. Users will still be able to create records if the form is used on the landing page in an Element - which has its own submit button - or, in an Element with the iframe to a third-party system.

## Change layout and content

**In addition, the layout and content of the form can be changed as follows:**

* Change section names
* Add or remove sections
* Add, change or remove conditional logic
* Add, change or remove instructions
* Add or remove fields
* Change field input types
* Enable/disable the **Required** option on a field
* Enable/disable the **Read-only** option on a field

## Preview, revert, and cancel

Use the **Preview** button at the top right-hand side to check that the form looks and performs as you want.

**Two other buttons in this location are useful while creating and editing the form:**

* **Revert** - clicking this will remove any unsaved changes and revert the form to its last saved state.
* **Cancel** - clicking this will return the user to the Forms list.

If changes have been made and not saved, in either case, the user will be required to confirm the action.

|  |  |
| --- | --- |
| Revert | Cancel |
| revert.png | cancel.png |

**Remember to save and test your changes.**

Having saved the form, you will be taken to the Forms list under the **Forms** tab.

## Useful info

1. Changes made while editing the form will take effect on newly opened forms. Forms in use when changes have been saved will not be affected.

---

---
url: >-
  /knowledgebase/system-configuration/task-group-templates/editing-a-task-group-template.md
---

# Editing a Task group template

You will be able to edit a task group template only if you meet one of the following requirements:

|  |  |
| --- | --- |
| - You have a Super admin account type - You have a Role with the Edit Task group templates permission enabled under the Task configuration tab | mceclip1.png |

## Edit the task group template

Double click the row for the Task group template you need to edit, or select **Edit** in the Actions menu. Either will take you into the Edit screen.

You will be able to change the following in any Task group template:

1. **Name**: The Task group template Name is a mandatory field, so you will not be able to remove it. Whatever you do change it to must constitute a unique value, otherwise you will see an error message:

   ![mceclip2.png](/knowledgebase/images/img_6115796703645_1776895983.png)

2. **Description**: This can be amended or removed as it is an optional field.

## Editing a Task group template which contains *Self contained form* type Task templates only

* You can add and remove Object classes without restriction as Task templates of the Self contained form type can be used across all Object classes. Tasks which have already been created for Records in the removed Object class will not be affected.
* You can add more Task templates of the Self contained form type without restriction. This will have no effect on Records for which Tasks from the original Task group template have already been created.
* You can remove Task templates without restriction. This will have no effect on Records where the Task group template has already created these Tasks.

## Editing a Task group template which contains *Update object record* type Task templates

The thing to remember with a Task template of the Update object record type is that this Task type is configured for a specific Object class. It is used to update Records in that Object class only and cannot be shared with another because it comprises fields which are bespoke to the Object class.

* **Adding Object classes**: You will not be able to add another Object class unless you remove the original one.
* **Removing the original Object class**: If you remove the original Object class, all the Update object record type Task templates will be automatically removed. Task templates of the Self contained form type will remain.
* **Adding one Object class**: If you then add one Object class, you will be able to select any Update object record type Task templates for that class and any additional Self contained form type Task.
* **Adding two or more Object classes**: If you add two or more Object classes, you will not be able to select any Update object record type Task templates.
* **Removing Task templates**: You can remove Task templates without restriction. This will have no effect on Records where the Task group template has already created these Tasks.

## Useful info

1. Your system can have up to **10,000** Task group templates. If this limit is reached, the **+ Create** button will be disabled and an error message will inform you that the limit has been reached.

---

---
url: /knowledgebase/system-configuration/task-templates/editing-a-task-template.md
---

# Editing a Task template

You will be able to edit a Task template only if you meet one of the following requirements:

|  |  |
| --- | --- |
| - You have a Super admin account type - You have a Role with the Edit Task templates permission enabled under the Task configuration tab | mceclip1.png |

## Open the edit screen

Double-click the row for the Task template you need to edit, or select **Edit** in the Actions menu. Either option will take you to the Edit screen.

## Fields you can edit

The fields that can be edited in a Task template are limited. These fields are:

1. **Task template Name**. Because this is a mandatory field, you will not be able to remove it. Whatever you change it to must constitute a unique value; otherwise, you will see an error message:

![mceclip0.png](/knowledgebase/images/img_6145347144989_1776895927.png)

2. **Description**. This can be amended or removed, as it is an optional field.

3. **The Response form**

   * adding and removing fields
   * adding, amending and removing options in select fields

   *When making the above changes, you need to be mindful of whether an existing field or field value is used in a Sequence trigger. If you remove it, you will break your workflow.*

   * changing the Input type for Single select and Text field types
   * changing the precision, min and max values in a Numeric field
   * adding, amending or removing a field description
   * changing the Required value
   * increasing/decreasing the number of files allowed in a File upload field (but no more than 10)

4. **Lifecycle and expiry**. The Task template can be changed from:

   * "This task is completed just once" to "This is a task that should expire", and an expiry timeframe can be set
   * "This is a task that should expire" to "This task is completed just once"

## Effect of changes

Any changes made while in **Edit** mode will only be reflected in Tasks created from the Task template after **Save**. Existing Tasks will not be amended.

## Fields you cannot change

**You will not be able to change the following:**

1. Task type
2. Task creation mechanism
3. Object class - for Task type Update objects records
4. The Response form - Field type

These fields are disabled, so cannot be changed.

---

---
url: /knowledgebase/administration/user-groups/editing-a-user-group.md
---

# Editing a User group

## Who can edit a User group?

The following users can edit User groups and manage their members:

* **Users with a Super Admin account type** have unrestricted access to all User Groups, including owner and member management and permission configuration.
* **User Group Owners with a Config Admin account type** can access the User Group from the Administration menu. They can promote members, demote owners, remove users from the group, and delete the User Group. However, they cannot add new members because they can only see users who are already members of the group.
* **User Group Owners with an Internal account type** do not see the User Group in the Administration menu. However, they can access it directly using a URL such as:

  `https://catalyst-domain-url/administration/user-groups/89`

  where `89` is the User Group ID. With the correct URL, they have the same permissions as a Config Admin User Group Owner.

A User Group Owner is always a member of the User Group, and a User Group can have multiple owners.

The User Group page can be accessed by double-clicking the User Group row in the list or by selecting **Open** from the **Actions** menu.

![User Group opened for editing](/knowledgebase/images/administration/editing-a-user-group-1.png)

## What can be edited?

### Edit page

The **Edit** page displays the User Group name and description.

These fields can be edited in place by clicking into them, making the required changes, and clicking elsewhere on the page. No additional save action is required.

The description field includes a character counter and supports up to 500 characters.

The page also displays:

* the number of members in the User Group
* the avatars of the User Group owners

This information is read-only and updates automatically when owners or members are added or removed.

Below this section is the List Page Filter Editor.

For more information, see [List Page Filter Editor](/knowledgebase/finding-your-way-around/ui-and-navigation/list-page-filter-editor/).

Alongside the filter editor is a list filter with the following options:

* **Members** (default)
* **Non-members**
* **Owners**

Users with a Super Admin account type also have an option to display all users in the system.

### User Group member list

The member list contains the following columns:

* **Name** – the user's first and last name
* **Username** – the user's email address
* **Added** – the date the user became a member or owner
* **Membership** – whether the user is an Owner or Member
* **Actions** – available actions for the selected user

### Actions available for members

If the selected user is a **Member**, the following actions are available:

* **Promote to owner**
* **Remove from group**

![Actions menu for a User Group member](/knowledgebase/images/administration/editing-a-user-group-2.png)

If the selected user is an **Owner**, the following actions are available:

* **Demote to member**
* **Remove from group**

![Actions menu for a User Group owner](/knowledgebase/images/administration/editing-a-user-group-3.png)

## Using filters and actions

Using the list filters and action menus, users can:

* add or remove owners
* add or remove members
* promote members to owners
* demote owners to members

### Adding members

When viewing the **Non-members** list, multiple users can be added to the User Group at the same time.

After selecting one or more users using the checkboxes, the **+ Add as members** button becomes available.

![Adding multiple users from the Non-members list](/knowledgebase/images/administration/editing-a-user-group-4.png)

### Removing members

When viewing the **Members** list, multiple members can be removed in a single action.

![Removing multiple members from a User Group](/knowledgebase/images/administration/editing-a-user-group-5.png)

When the action is completed, a confirmation toast message is displayed.

![Confirmation message after updating User Group membership](/knowledgebase/images/administration/editing-a-user-group-6.png)

### Managing owners

When viewing the **Owners** list:

* checkboxes are not displayed
* bulk actions are not available
* column filters are not available
* rows-per-page controls are not available

This is because a User Group can have a maximum of 10 owners.

![Owners view showing User Group owners](/knowledgebase/images/administration/editing-a-user-group-7.png)

After ownership changes are made, a confirmation toast message is displayed.

![Confirmation message after updating User Group ownership](/knowledgebase/images/administration/editing-a-user-group-8.png)

For more information, see [User Group Permissions](/knowledgebase/administration/user-groups/user-group-permissions/).

## Things to remember

1. Users with a Super Admin account type do not need to be an owner or member of a User Group.
2. Members of a User Group with a Config Admin or Internal account type can view the User Group but cannot edit or delete it.
3. When a Super Admin clicks an owner or member avatar, the user's contact information is displayed.
4. If you cannot find a user in the Members or Non-members lists, remember that the default page size is 10 rows. Increase the page size or use the search function.
5. A User Group can have multiple owners.
6. Owners are always members of the User Group.
7. The maximum number of owners in a User Group is 10.

---

---
url: /knowledgebase/administration/elements/editing-an-element.md
---

# Editing an Element

Only users with a Super admin account type will have access to the list of Elements in order to edit one.

![](../../../images2/zendesk_13414440883869_001_4080a0425abb.png)

When you select **Edit** in the Actions menu, you are taken to the edit page for that Element.

**Note:** The fields in the **Package Management** section will be greyed out. These fields cannot be edited.

![1706n.png](../../../images2/zendesk_13414440883869_002_a74f42ffaca6.png)

If you want to make any updates to the way the Element looks or works, this will have to be done in your `config.json` file or `ccs` file in your Git repository. You would then need to create a new Element for this updated version.

## What you can edit

You can edit the following:

* **Element name** - this can be changed but must continue to be a unique value in the context of Elements in your Catalyst system.
* **Description** - add or amend the description. This information is useful for users who have not been involved in the development or creation of the Element, as it can be used to provide a brief overview of the functions the Element provides.
* **Available Use** - you can change your selections as to where the Element is available for use on system forms. If you switch off availability, the Element will no longer appear in the Elements section of the side panel for that particular form.
* **Disable/Enable** - if you disable an Element, it will cease to appear on all possible forms. Remember, the Element will continue to count towards the total in your system unless you delete it.

## Useful info

**Coming soon:** "Disable" will follow shortly as an option in the Actions menu so that you won't have to edit an Element in order to disable it.

---

---
url: >-
  /knowledgebase/system-configuration/object-classes/editing-object-class-fields.md
---

# Editing Object class fields

If you need to change a field Label or remove some of the options from an Object class single or multi-select field, for instance, you can do this from the fields list within the Object class.

## Permissions

To edit Object class fields, you must have one of the following:

* A Super admin account type
* Be an Owner of the Object class
* Have a Config admin account type and a Role with the Object class Edit permission enabled on the Data Model tab
* Have a Permission set for the specific Object class with the Object class Edit permission enabled

The below illustrates Role "Administrator" which can be given to a user with a Config admin account type:

![mceclip0.png](../../../images2/zendesk_5978442126365_001_875da6a980a3.png)

The below is an example of an Object class permission set called "SME". A user given this permission set will be able to make edits to the "Lease Agreements" Object class:

![mceclip1.png](../../../images2/zendesk_5978442126365_002_245441313dd3.png)

## Edit a field

Having found the field you wish to change, select **Edit** in the Actions menu or double click on the field row. This will open the **Edit field** panel, which has the same sections and the same components as the **Add field** panel.

**Key points:**

* The **Save** button will be disabled until a change is made.
* The **Alias** and **Type** fields are greyed out and cannot be edited.

![mceclip2.png](../../../images2/zendesk_5978442126365_003_59794c4b9e2e.png)

When a change is made, the **Save** button is enabled.

![mceclip3.png](../../../images2/zendesk_5978442126365_004_ce9a5c3c0bf5.png)

When **Save** is clicked, the green success toast message is displayed on-screen and the Edit field panel remains open.

This allows you to select another field and make any necessary edits in the panel without having to keep opening/closing it.

## Specific changes and how they are applied

### Field Label

If a change has been made to the field Label, this will be reflected in:

* The Fields list
* Object class Display views and standalone forms
* Object records
* Update Object record type tasks where the field is used
* Drop-down field lists in the sequencer, etc

### Default value

Changes to the Default value will only be effective for records created after the change; they do not affect existing records.

### Use as Identifier

If the Use as identifier flag is switched from off to on, this flag on the previously selected Identifier field is switched off. This is because only one field in an Object class can be used as such.

If the Use as identifier flag is switched from on to off, the Autologyx ID becomes the identifier but you will not see this field in the Fields list. The change of identifier will be reflected in the:

* Fields list
* Record card view
* Record: Tasks, Templates, Activity Log and Record access panel tabs
* Search return against a child object class in the parent create/edit view

### Unique value

The Unique value flag can be removed from any field without restriction. However, you will not be able to add this flag to a field where duplicate values already exist. The Edit field panel will contain the below message which tells you that the field has duplicate values.

![mceclip4.png](../../../images2/zendesk_5978442126365_005_d8088852496a.png)

### Select options

You can add select options without affecting any existing records, processes or any other system resource.

If you delete a select option which has already been chosen in a field on an Object record, it will remain in place until you edit the record at which point the value:

* will have to be replaced with an existing option if the field is required
* can be cleared if the field is not required

If you delete a select option which is used in a sequence trigger, the trigger is effectively broken and will no longer work.

Select options can be renamed but this is equivalent to deleting the original and creating a new option unless the change is simply letter case eg "First name" is changed to "First Name". Renamed select options are not updated in existing records.

### Changing Validation

When Validation settings are changed, existing data remains unchanged until a record is edited at which point the system will enforce any new constraints.

### Text field type

Increasing or clearing the Max length allowed for this field type will have no effect on existing records. Similarly, decreasing or setting (when it has not previously been set) a Max length will have no effect on existing records. However, the existing values that exceed the new Max length must be changed when the record is edited.

### Integer and Decimal field types

* Decreasing or clearing the Min value for these field types does not affect existing records.
* Increasing or setting the Min value does not affect existing records. However, an existing value which is below the new Min value must be changed when the record is edited.
* Decreasing or clearing the Max value for these field types does not affect existing records. However, an existing value which exceeds the new Max value must be changed when the record is edited.
* Increasing or clearing the Max value of a numeric type field does not affect existing records.

### Multi select field type

* Decreasing or clearing the Min selections of a multi select field type has no effect on existing records.
* Increasing or setting the Min selections of a multi select field type does not effect existing records. The existing values that have fewer than the new Min selections remain unchanged until the record is edited, at which point the value must be changed.
* Decreasing or setting the Max selections of a multi select field type does not affect existing records. However, the existing values that exceed the new Max selections must be changed when the record is edited.
* Increasing or clearing the Max selections of a Multi select field type does not affect existing records.

### Document field type

Increasing the Max number of files allowed for this field type will have no effect on existing records. However, if you decrease the Max number of files allowed, records which exceed the new limit will have to be amended accordingly when next edited.

### User field type

Individual Users and User groups can be added to/removed from this field type.

The avatars of User groups are listed first then individual user avatars follow in alphabetical order in the "Users and user groups that can be selected" (in the Edit field/Selection Options).

If a User is removed from the selection options, or a User is removed from a User Group, their avatar will remain on the records where they have already been selected, as below:

![Screenshot 2025-10-23 at 17.42.07.png](../../../images2/zendesk_5978442126365_006_f650d9539705.png)

But if the field is clicked into on the record, individual Users will be shown as greyed out and they will not be available for selection in records going forward. Users removed from a User group in the field will no longer be available for selection.

![Screenshot 2025-10-16 at 17.10.55.png](../../../images2/zendesk_5978442126365_007_de8bd0038dcd.png)

|  |  |
| --- | --- |
| Validation on the Min and Max selections on the field configuration will prevent a User from Editing the field and removing User options which would make it impossible for these constraints to be met on the record create/edit forms.    The Save button is disabled until the number of available selections or the Min/Max selections are altered.    setting/editing the min and max users selections will take account of both individual users and those who are accessed via a User group. | ![Screenshot 2025-10-23 at 18.09.16.png](../../../images2/zendesk_5978442126365_008_b9b303faee68.png) |

**[Click here](/knowledgebase/system-configuration/object-classes/object-class-field-types-uses-and-attributes/)** for more information on specific field types and their attributes.

## Useful info

1. If you delete an option from a Single select type field which had been used as the Default value, the Default value drop-down will be cleared.
2. In the case of a Multi select type field, if either of the min/max selections become invalid, for instance because max becomes larger than the number of remaining options, the value will be cleared.
3. The maximum number of fields you can have in an Object class is 2,000.

---

---
url: /knowledgebase/workspace/records/editing-object-records.md
---

# Editing Object records

Depending on your permissions, the Workspace contains two main areas: **Records** and Tasks.

## Open a record for editing

Clicking on **Records** opens the [Records list](/knowledgebase/workspace/records/records-list/).

One of the ways an Object record can be updated is from the list by selecting **Open** from the **Actions** menu, or by double-clicking an Object record.

This opens the Create and edit view that was configured in the Object class **Display** tab.

If the Records list is displayed in Card View, each record includes an **Open** icon in the top-left corner.

![Open icon displayed on a record card in Card View](/knowledgebase/images/workspace/editing-object-rec-1.png)

The edit form supports **in-line editing**, which means changes take effect immediately and no additional save action is required.

## Validation warnings

If a value is changed to one that already exists in another record and the field has been configured as **Unique**, an onscreen warning is displayed and the record is not updated.

The duplicate value must be corrected before the change can be applied.

![Validation warning displayed when a duplicate value is entered into a unique field](/knowledgebase/images/workspace/editing-object-rec-2.png)

If a value is removed from a field that has been configured as **Required**, an onscreen warning is displayed.

A value must be entered before the record can be updated.

![Validation warning displayed when a required field is left blank](/knowledgebase/images/workspace/editing-object-rec-3.png)

## Side panel tabs

While in Edit View, the side panel is available if one or more side panel options have been enabled in the Object class **View** settings.

![Object class View settings showing available side panel tabs](/knowledgebase/images/workspace/editing-object-rec-4.png)

### Summary

**Information only.** This view cannot be edited.

The Summary tab is configured in the Object class **Display** tab and can be disabled if it is not required.

### Tasks

With the appropriate permissions, a user can:

* view tasks
* create tasks
* complete tasks
* assign tasks

### Record access

This tab is available to:

* Object record Owners
* users with a Super admin account
* Object class Owners

From here, authorised users can add or remove record Owners.

### Activity log

The Activity log displays the history of the record.

It is shown as a timeline, with the most recent activity displayed first.

Each entry includes a date and time stamp and indicates whether the action was performed by a named user or by the system.

## Things to remember

1. Changes made in Edit View are applied immediately through in-line editing.
2. Unique fields cannot contain values that already exist elsewhere in the same Object class.
3. Required fields must contain a value before changes can be applied.
4. The side panel tabs available depend on the Object class configuration and your permissions.
5. Access to the Record Access tab is restricted to authorised users.

---

---
url: /knowledgebase/workspace/records/manual-creation-of-object-records.md
---

# Editing Object records

Depending on your permissions, the Workspace contains two main areas: **Records** and Tasks.

## Open a record for editing

Clicking on **Records** opens the [Records list](/knowledgebase/workspace/records/records-list/).

One of the ways an Object record can be updated is from the list by selecting **Open** from the **Actions** menu, or by double-clicking an Object record.

This opens the Create and edit view that was configured in the Object class **Display** tab.

If the Records list is displayed in Card View, each record includes an **Open** icon in the top-left corner.

![Open icon displayed on a record card in Card View](/knowledgebase/images/workspace/man-creation-of-records-1.png)

The edit form supports **in-line editing**, which means changes take effect immediately and no additional save action is required.

## Validation warnings

If a value is changed to one that already exists in another record and the field has been configured as **Unique**, an onscreen warning is displayed and the record is not updated.

The duplicate value must be corrected before the change can be applied.

![Validation warning displayed when a duplicate value is entered into a unique field](/knowledgebase/images/workspace/man-creation-of-records-2.png)

If a value is removed from a field that has been configured as **Required**, an onscreen warning is displayed.

A value must be entered before the record can be updated.

![Validation warning displayed when a required field is left blank](/knowledgebase/images/workspace/man-creation-of-records-3.png)

## Side panel tabs

While in Edit View, the side panel is available if one or more side panel options have been enabled in the Object class **View** settings.

![Object class View settings showing available side panel tabs](/knowledgebase/images/workspace/man-creation-of-records-4.png)

### Summary

**Information only.** This view cannot be edited.

The Summary tab is configured in the Object class **Display** tab and can be disabled if it is not required.

### Tasks

With the appropriate permissions, a user can:

* view tasks
* create tasks
* complete tasks
* assign tasks

### Record access

This tab is available to:

* Object record Owners
* users with a Super admin account
* Object class Owners

From here, authorised users can add or remove record Owners.

### Activity log

The Activity log displays the history of the record.

It is shown as a timeline, with the most recent activity displayed first.

Each entry includes a date and time stamp and indicates whether the action was performed by a named user or by the system.

## Things to remember

1. Changes made in Edit View are applied immediately through in-line editing.
2. Unique fields cannot contain values that already exist elsewhere in the same Object class.
3. Required fields must contain a value before changes can be applied.
4. The side panel tabs available depend on the Object class configuration and your permissions.
5. Access to the Record Access tab is restricted to authorised users.

---

---
url: >-
  /knowledgebase/system-configuration/relational-modeller/editing-the-relational-model.md
---

# Editing the Relational model

View an article which explains [who can create/edit the relational model](/knowledgebase/system-configuration/relational-modeller/who-can-create-a-relational-model/).

Go to the System configuration section of the main navigation menu. Click Relational modeller. The relationships which have already been configured will be displayed.

All object classes will be presented in the sidebar in alphabetical order. Those which have already been used in the model will be greyed out.

## What can be edited?

* **Object classes can be moved** to a new parent or to the top level and become a root parent. When you do this, all descendent object classes will move too.
* **Object classes can be deleted**, but all descendent classes will be deleted too.

There are some limitations around being able to move or delete object classes from the canvas.

### Padlock and bin icons

With the below as the starting model, the first thing to note is that some object classes have a padlock icon rather than the bin icon.

![](/knowledgebase/images/img_10381824697885_1776895908.png)

These object classes cannot be deleted.

|  |  |
| --- | --- |
| When the padlock is hovered over, the tooltip tells you that you cannot move the relationship. |  |

In most cases, the padlock indicates that a record has been created with a relationship between the locked object classes. This is true in the case of Mortgage Applications and Applicant 1 above. As an example, Mortgage Application number 123987 record below clearly shows that there is a related Applicant 1 record, called Tom Jones.

![](/knowledgebase/images/img_10381824697885_1776895908.png)

Therefore, neither of these object classes can be removed from the canvas. This record shows that there is no related Applicant 2 or Property. These two object classes do not have padlock icons, which tells the user that there are no records in these classes that have been related to a Mortgage Application record.

### Removing a root parent object class

In the relationship shown on the left-hand side of the canvas, there are employee records which have related employment contracts. An example for Sam Smith is shown below.

![](/knowledgebase/images/img_10381824697885_1776895909.png)

However, there are no records in the system under the root parent object class called Employee Management (HR).

![](/knowledgebase/images/img_10381824697885_1776895909.png)

But, this object class still shows a padlock rather than a bin. It cannot be deleted because its child and grandchild cannot be deleted.

To remove the redundant object class, Employee Management (HR), at the top of the relationship:

1. Drag Employees off Employee Management (HR).
2. Employee Contracts will move with Employees.
3. Employees can then become a root parent itself, assuming that your model does not already contain five root parent object classes.

|  |  |
| --- | --- |
|  |  |

![](/knowledgebase/images/img_10381824697885_1776895910.png)

The Employee Management (HR) object class is then shown with the bin icon and can be deleted.

If the model already has five root parent object classes, the below error message will be shown.

![](/knowledgebase/images/img_10381824697885_1776895910.png)

### Model limits

* You can add further child object classes to any parent so long as they do not already have five.
* You can also extend the relationship with further levels, but your model cannot exceed five levels deep.

The below error message is shown if the user attempts to add a sixth level.

![](/knowledgebase/images/img_10381824697885_1776895910.png)

### Impact on the create/edit view

It is important to understand that if you delete a child object class component from the model which has been added to the create/edit view of the parent like this:

![childinmodel.png](/knowledgebase/images/img_10381824697885_1776895910.png)

* the child object class component will be removed from the parent sidebar
* the create/edit view will display like this:

![childnotinmodel.png](/knowledgebase/images/img_10381824697885_1776895910.png)

You can remove this component from the display, or if the model has been incorrectly edited, the child object class can be re-instated and the parent create/edit view will return to the original.

## Useful info

1. The relational model can accommodate five root parent object classes. Each of these can have 5 child object classes. In turn, each child can have five children and so on to five levels deep. Although it is highly unlikely that there will ever be the need for such vast relationships, the model can accommodate five relationships each consisting of 781 object classes.

---

---
url: /knowledgebase/administration/user-groups/editing-user-group-permissions.md
---

# Editing User Group Permissions

Each User Group contains three default permission sets:

* **Owners**
* **Members**
* **Everyone**

Additional custom permission sets can be created, allowing a User Group to have up to 10 permission sets in total.

For an overview of User Group permissions, see [User Group Permissions](/knowledgebase/administration/user-groups/user-group-permissions/).

## Who can edit User Group permissions?

The following users can manage User Group permission sets.

### Super Admin users

Users with a Super Admin account type have unrestricted access to:

* create permission sets
* edit permission sets
* assign and remove users
* assign and remove User Groups
* delete custom permission sets
* delete User Groups

### User Group Owners with a Config Admin account type

User Group Owners with a Config Admin account type can:

* access and edit the User Group
* create custom permission sets
* edit existing permission sets, except **Owners**
* assign and remove users
* assign and remove User Groups
* delete custom permission sets
* delete the User Group

**Note:** These users can normally see only users who belong to User Groups they own, unless they have also been granted the **View Users** permission.

### User Group Owners with an Internal account type

User Group Owners with an Internal account type do not see the User Group in the Administration menu.

However, they can access it directly using a URL such as:

`https://catalyst-domain-url/administration/user-groups/89`

where `89` is the User Group ID.

With the correct URL, they have the same permissions as a User Group Owner with a Config Admin account type.

## Editing permission sets

Each User Group permission set has an **Actions** menu alongside its name.

![User Group permission sets showing the Actions menu beside each permission set](/knowledgebase/images/administration/editing-user-group-permissions-1.png)

### Edit permissions

Open the **Actions** menu and select **Edit**.

![Actions menu with the Edit option selected for a User Group permission set](/knowledgebase/images/administration/editing-user-group-permissions-2.png)

You can configure the following permissions:

* **View** - allows users to see the User Group, including membership and permissions
* **Edit** - allows users to modify the User Group name, description, membership, and permissions
* **Delete** - allows users to delete the User Group

After making your changes, click the tick icon to save.

A confirmation toast message is displayed and the updated permissions take effect immediately.

![Permission editor showing View, Edit and Delete permissions for a User Group permission set](/knowledgebase/images/administration/editing-user-group-permissions-3.png)

## Managing assignees

### Remove users or User Groups

Open the **Actions** menu and select **Manage assignees**.

The Manage assignees panel contains two tabs:

* **Users**
* **User Groups**

The number of currently assigned users and User Groups is displayed on each tab.

To remove an assignment, click the **X** on the relevant tile.

![Manage assignees panel showing users and User Groups assigned to a permission set](/knowledgebase/images/administration/editing-user-group-permissions-4.png)

A confirmation modal is displayed.

Click **Yes, unassign** to remove the assignment, or **Cancel** to keep it.

![Confirmation modal asking whether to unassign a user or User Group from a permission set](/knowledgebase/images/administration/editing-user-group-permissions-5.png)

The assigned user or User Group is removed immediately and the displayed totals are updated accordingly.

### What happens when users are removed?

When a user or User Group is removed from a permission set:

* permissions are revoked immediately
* users do not need to log out and back in
* a page refresh may be required before changes become visible

If the removed users no longer have the **View Users** permission, they also lose access to User Group membership information.

### Add users or User Groups

For information about assigning users and User Groups to permission sets, see [User Group Permissions](/knowledgebase/administration/user-groups/user-group-permissions/).

## Things to remember

1. All permission sets except **Owners** can be modified.
2. A maximum of 100 individual users can be assigned to a permission set.
3. A maximum of 10 User Groups can be assigned to a permission set.
4. A User Group can contain a maximum of 10 permission sets.
5. Permission changes take effect immediately after they are saved.
6. Users removed from a permission set lose the associated permissions immediately.

---

---
url: /knowledgebase/administration/elements.md
---

# Elements

Elements allow you to extend Autologyx with custom web components that integrate seamlessly into the platform. They can be used to embed dashboards, third-party applications, bespoke user interfaces, and other functionality into pages and forms throughout your solution.

This section explains what Elements are, how to create and manage them, and how they communicate securely with Autologyx.

## Getting started

### What are Elements?

Learn what Elements are, where they can be used, and how they can extend the functionality of your Autologyx solution.

* [What are Elements and what can you do with them?](/knowledgebase/administration/elements/what-are-elements-and-what-can-you-do-with-them/)

### Creating an Element

Learn about the files, repository structure, configuration, and prerequisites required to build and import an Element.

* [Everything you need to create an Element](/knowledgebase/administration/elements/everything-you-need-to-create-an-element/)

## Configuring Elements

### Configure an Element on a page or form

Learn how to place an Element onto a page, configure its parameters, and understand the data passed to it by Autologyx.

* [Configuring an Element and how it works on a form](/knowledgebase/administration/elements/configuring-an-element-and-how-it-works-on-a-form/)

### Edit an Element

Learn how to update an existing Element after it has been imported into your system.

* [Editing an Element](/knowledgebase/administration/elements/editing-an-element/)

## Things to remember

1. Only users with a Super Admin account type can create and manage Elements.
2. Elements can be reused across Landing Pages, Object Class forms, and Standalone Forms.
3. Elements communicate securely with Autologyx through a controlled messaging mechanism.
4. Every Element must be developed, packaged, and imported before it can be configured for use.

---

---
url: /knowledgebase/record-and-task-forms/formbuilder-components/elements.md
---

# Elements

Users with a Super admin account type where the Catalyst system uses Elements will probably have access to comprehensive documentation with use cases and code samples.

As an alternative, we have a section in the knowledgebase which explains what they are and how to configure them. Click [HERE](https://ng-autologyx.zendesk.com/hc/en-us/sections/13243331683229-Elements) for more information.

## Access and permissions

You will need a Super admin account type to be able to create/edit Elements.

**Elements can be used in the following forms:**

* The landing page
* Object classes
  * create/edit view
  * summary view
  * standalone forms

The Element create/edit config has radio buttons to enable use in each area.

![1706n.png](../../../images2/zendesk_19546006842397_001_8ba68c3710d0.png)

Users with the account type Config Admin and a Role which allows them to Edit Object classes, or with a Permission set which allows them to Edit a specific Object class, will be able to select the Element on the Object class forms.

These users will not have access to create/edit the Landing page, as that is a Super admin function.

## Using Elements in forms

The below shows the use of a Zuva Document Viewer Element in the Summary view of a record.

**Best practice:** Create a dedicated section, with a clear name if the header is to be shown, for any Elements included in your forms.

### Add an Element

Drag and drop the Element component onto the canvas.

Unlike other form components, it does not become greyed out; you could add it again in the same or another section. This is because the same type of Element can be configured to display different views/results, etc.

![1706p.png](../../../images2/zendesk_19546006842397_002_332912a399b6.png)

### Configure an Element

When in place, click on the Element to configure the height, colours, or other characteristics specific to the type of Element, to make it different to the default.

![1706q.png](../../../images2/zendesk_19546006842397_003_dd46b871353a.png)

**Save the form.**

**Example:** An example of the Element in the Summary view of a record:

![1706u.png](../../../images2/zendesk_19546006842397_004_9afb0ba5b71c.png)

---

---
url: /knowledgebase/release-notes/release-notes-1.5/elements.md
---

# Elements

## Overview

Our star feature—Elements—is a border-crossing innovation that allows the Autologyx platform to showcase selected content from third-party sources.

**Installation is designed to be quick and trouble-free.** Just provide your credentials to the repository where your Element is located, and our system will handle the rest—securely validating, downloading, and installing your Element in a flash.

**You supply two key files:** `index.html` containing your element's content and `ison.config` with customizable parameters. Once installed, just place your new element anywhere on a summary panel or landing page and watch it come to life.

![Elements2\_article.gif](../../../images2/zendesk_12552115159069_001_bf49f9d821dd.gif)

## Versatility and use cases

**The beauty of Elements lies in their versatility.** It is now possible to display a wide range of content within the component, from interactive widgets and dynamic charts to captivating maps and even entire web pages.

**Elements can help transform your Catalyst platform into a powerhouse of possibilities.** With interactive maps, you can visualize geographic data, track regional performance, and make informed decisions for targeted expansion. Interactive widgets provide real-time analytics and key performance indicators, empowering executives to monitor critical metrics at a glance. Meanwhile, dynamic diagrams offer a concise representation of complex data, simplifying communication and facilitating collaboration among team members.

By integrating third-party content such as specialized databases, relevant references, or even entire research platforms, you can streamline your analysis process and enhance your case management. It's like having a library at your fingertips, ready to assist you at a moment's notice.

Whether you're in legal, finance, or any other industry, incorporating such diverse content brings a new level of efficiency and clarity to your workflows, propelling your business forward with data-driven insights and enhanced decision-making capabilities.

![Elements1\_article.gif](../../../images2/zendesk_12552115159069_002_cef5482ab3f1.gif)

## Summary

With Elements, Autologyx Catalyst is redefining the boundaries of business automation. Imagine the power of having all the information you need at your fingertips, without the need for multiple tools or websites. Embrace the power of Autologyx Elements and witness the transformative impact it brings to the platform.

---

---
url: >-
  /knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors.md
---

# Embedding Model Actors

**Status:** This page is being prepared.

---

---
url: /knowledgebase/release-notes/release-notes-1.14/error-handling-reliability.md
---

# Error Handling & Reliability

## Improved error messaging and validation

We’ve enhanced error handling across key areas of the platform to provide clearer guidance, reduce debugging time, and help users resolve issues faster.

### Clearer permissions feedback when creating sequences

We’ve improved the error messaging shown when a Config Admin user attempts to create a sequence without sufficient permissions.

Users who are not owners of any Object Class will now see a clearer, more informative message explaining why the action cannot be completed, helping to remove ambiguity and guide next steps.

**New message:**

```
You can only create sequences for classes you own. Currently you are not an owner
of any class. Hence will not be able to create this sequence.
Click 'Cancel' to leave this page. 
```

### Improved validation when configuring the Loop actor

We’ve introduced enhanced validation for the Loop actor to help catch configuration issues earlier in the process.

**What’s improved:** The JSON Path field is now validated in real time to ensure it resolves to a valid iterable array, preventing errors from surfacing later during execution.

|  |  |
| --- | --- |
| clipboard-202511261230-yexmo.png | clipboard-202511261207-5z011.png |

If the JSON Path does not point to an array, the field will be highlighted in red and the actor cannot be saved until the issue is resolved.

|  |  |
| --- | --- |
| A warning icon will also appear on the Sequence canvas, making it easy to identify misconfigured actors at a glance | clipboard-202511261221-myfll (1).png |

These improvements help reduce time spent debugging and provide greater confidence when building complex workflows.

*Note: This validation does not apply to Loop actors configured after a Document Picker actor.*

### Enhanced error reporting for Object Class relations

We’ve introduced more detailed validation and error reporting when removing Object Class relations via:

```
PATCH /api/object-models/<id>/
```

**What’s improved:** The API now returns clearer **400 Bad Request** responses, explicitly identifying which **Sequences, Document Templates, or Records** are preventing the operation, along with relevant IDs where applicable.

This makes it significantly easier to understand dependencies and take the necessary steps to resolve them, streamlining both development and maintenance workflows.

---

---
url: /api/event-history.md
---

# 🕘 Event History API Reference

Welcome to the Event History API reference.

This section documents the Event History microservice used to store, retrieve, and manage historical event data for Autologyx client environments. It covers the APIs used to initialise tenant storage, upload and retrieve associated files, and create or query event records.

::: warning
This section documents technical and service-level Event History APIs and is intended for internal platform use and controlled engineering workflows. It should not be treated as part of the main general-purpose external Catalyst integration surface. This area is outside general support coverage, so please contact your Customer Success team if you need guidance.
:::

## 📚 What this section covers

The Event History API is organised around a small number of technical areas:

### 🧱 Tenant management

* [Tenants](/api/event-history/resources/tenants)\
  Endpoints used to initialise and delete tenant-specific Event History storage and related service configuration.

### 📁 File handling

* [Files](/api/event-history/resources/files)\
  Endpoints used to generate presigned upload URLs and manage file handling for history events with associated file content.

### 🧾 Event storage and retrieval

* [Events](/api/event-history/resources/events)\
  Endpoints used to create history events, retrieve stored events, and access event-related file content.

## 🧩 How the service works

At a high level, the Event History service stores historical event data in tenant-specific storage. The attached technical pages show that tenant setup is handled separately, file upload support is provided through presigned URLs, and event records can then reference stored file content where needed. :contentReference\[oaicite:4]{index=4} :contentReference\[oaicite:5]{index=5} :contentReference\[oaicite:6]{index=6}

A typical flow looks like this:

1. A tenant is initialised for the client in the Event History service
2. A file upload URL is generated if an event needs to reference file content
3. The file is uploaded to storage
4. An event is created or ingested with the relevant metadata
5. Event records are later queried through the history endpoints

## 👥 Who this documentation is for

This section is primarily intended for:

* Autologyx internal developers
* platform and infrastructure engineers
* technical teams working on event ingestion, storage, or retrieval
* engineers integrating Catalyst services with the Event History microservice

## 🧭 How to use this documentation

A good reading order for this section is:

1. Start with [Tenants](/api/event-history/resources/tenants) to understand tenant initialisation and deletion
2. Continue with [Files](/api/event-history/resources/files) to understand presigned upload handling
3. Then use [Events](/api/event-history/resources/events) for event creation, querying, and event-related file access
4. Use [Healthcheck](/api/event-history/) and [Version](/api/event-history/) for service-level operational reference

## 🎯 Common use cases

Teams typically use this section when they need to:

* initialise Event History storage for a client
* upload files that must be associated with historical events
* create event records from platform or integration activity
* query stored event history for a given client
* retrieve file content linked to an event
* validate service health or deployed version

---

---
url: /api/event-history/resources/events.md
---
# Events

This page documents the Events endpoints in the Event History API microservice.

The Event History service is used to store and retrieve historical activity for a client environment. During client creation in the main Autologyx system, a client-specific ClickHouse database is created for history data, and a corresponding tenant entry is created in the default ClickHouse database. The tenant entry is used to resolve the correct client database from the `client_id`.

::: warning
This section documents technical and service-level Event History APIs and is intended for internal platform use and controlled engineering workflows. It should not be treated as part of the main general-purpose external Catalyst integration surface. This area is outside general support coverage, so please contact your Customer Success team if you need guidance.
:::

## API overview

This page covers the following endpoints:

* `POST /api/event-bridge/create-event`
* `POST /api/system-events/batch`
* `GET /api/history/events`
* `GET /api/history/events/`event\_id`/file`

***

## POST /api/event-bridge/create-event

Creates a History Event record in ClickHouse through the AWS EventBridge → Lambda → Event History API flow.

### Permissions

Requires `authentication`.

### Request

#### Headers

```text
Request Method: POST
Content-Type: application/json
X-API-Key: API_KEY
```

#### Body schema

```json
{
  "version": "string",
  "id": "string",
  "detail-type": "string",
  "source": "string",
  "account": "string",
  "time": "2022-11-10T10:26:12.111Z",
  "region": "string",
  "resources": [],
  "detail": {
    "event_id": "string",
    "event_time": "2022-11-10T10:26:12.111Z",
    "event_type_id": 1,
    "record_id": 0,
    "source_id": 0,
    "source_type_id": 0,
    "event_data": [
      "string"
    ]
  }
}
```

### Response

#### Success

* Status: `201 Created`

```json
{
  "detail": "<string>"
}
```

### Filtering

No filters are supported.

### Errors

| Error | Response code | Message |
|---|---|---|
| Tenant not found | `400 Bad Request` | `"detail": "'{tenant}' tenant not found in database."` |
| Wrong API key | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |
| Missing authorization header | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |

***

## POST /api/system-events/batch

### Overview

Inserts a batch of System Events into the tenant-specific `system_events` table in ClickHouse.

Intended producers are internal platform services that emit lifecycle, authentication, or configuration events (for example the Catalyst backend or the auth service) and need a high-throughput, idempotent write path. Records are routed to the per-tenant ClickHouse database resolved from the `X-Client-Id` header, and persisted to the `system_events` table in that database.

### Authentication

Both headers are required.

| Header | Notes |
|---|---|
| `X-API-Key` | Service API key. Same key shape as the rest of the Event History API. |
| `X-Client-Id` | Tenant identifier (UUID v4). Used to resolve the destination ClickHouse database. |

### Request

#### Headers

```text
Request Method: POST
Content-Type: application/json
X-API-Key: API_KEY
X-Client-Id: client_id
```

#### Body schema

```json
{
  "events": [
    {
      "id": "550e8400-e29b-41d4-a716-446655440000",
      "event_timestamp": "2026-06-19T10:00:00.000000Z",
      "category": 1,
      "event_type": 1,
      "source_id": 42,
      "source_type": 1,
      "source_info": "browser",
      "source_ip": "1.2.3.4",
      "event_data": "{\"auth_type\": \"PW\"}"
    }
  ]
}
```

#### Event fields

| Key | Type | Required | Default | Notes |
|---|---|---|---|---|
| id | uuid | Yes | — | Event identifier. Idempotency key — see [Idempotency contract](#idempotency-contract). |
| event\_timestamp | datetime | Yes | — | ISO 8601 UTC timestamp with microsecond precision. |
| category | enum (int) | Yes | — | Event category. See [Category values](#category-values). |
| event\_type | enum (int) | Yes | — | Event type within the category. See [Event type values](#event-type-values). |
| source\_id | int | No | `0` | Identifier of the source entity (e.g. user ID). |
| source\_type | enum (int) | No | `0` | Source type. See [Source type values](#source-type-values). |
| source\_info | string | No | `""` | Free-form metadata about the source (e.g. user agent label). |
| source\_ip | string | No | `""` | Origin IP address. |
| event\_data | string | No | `""` | JSON-encoded event payload. Schema is event-specific and is stored as a raw string. |

##### Category values

Defined by the backend `EventCategories` enum.

| Value | Name | Description |
|---|---|---|
| `1` | auth | Authentication-related events. |

##### Event type values

Defined by the backend `SystemEventTypes` enum. Values are scoped by `category` — currently all defined event types belong to `category = 1` (auth).

| Value | Name | Description |
|---|---|---|
| `1` | login\_success | Successful login. |
| `2` | login\_failed | Login failed (generic). |
| `3` | login\_failed\_sso | Login via SSO failed. |
| `4` | login\_failed\_inactive\_account | Login rejected because the account is inactive. |
| `5` | login\_failed\_invalid\_auth\_method | Login rejected because the auth method is not allowed for the account. |
| `6` | account\_locked | Account was locked (e.g. after repeated failed logins). |
| `7` | password\_reset\_request\_success | Password reset request submitted successfully. |
| `8` | password\_reset\_request\_failed | Password reset request failed. |
| `9` | password\_reset\_success | Password reset completed successfully. |
| `10` | password\_reset\_failed | Password reset attempt failed. |

##### Source type values

Defined by the backend `SourceTypes` enum (shared with the History Events API).

| Value | Name | Description |
|---|---|---|
| `1` | user | Event originated from a user action. |
| `2` | sequence | Event originated from an automated sequence. |
| `3` | system | Event originated from the platform itself. |
| `4` | mcp | Event originated from an MCP integration. |

### Response

#### Success

* Status: `201 Created`

```json
{
  "inserted": 1
}
```

| Key | Type | Notes |
|---|---|---|
| inserted | int | Number of rows actually written to `system_events` after deduplication. May be lower than the batch size if some `id`s were duplicates within the batch or already present in the table. |

### Idempotency contract

The endpoint provides at-most-once write semantics keyed by `id`:

* **Intra-batch dedup** — If the same `id` appears more than once in a single request, only the first occurrence is written; the rest are skipped silently.
* **Cross-batch dedup** — If an `id` is already present in the `system_events` table, the incoming row is skipped silently.
* **Reported count** — The `inserted` value reflects rows actually persisted after both dedup steps.

::: warning ClickHouse MergeTree caveat
Deduplication is enforced on the write path by checking `id` against the bloom filter index and the table. ClickHouse MergeTree does not enforce primary key uniqueness on its own, so producers must not rely on the database to reject duplicates outside of this endpoint — any direct INSERT bypassing this API can introduce duplicate `id`s.
:::

### Limits

| Limit | Default | Configuration |
|---|---|---|
| Maximum events per request | `10000` | `SYSTEM_EVENTS_BATCH_MAX_SIZE` environment variable. |

Requests containing more than the configured maximum are rejected with `422 Unprocessable Entity`.

### Errors

| Error | Response code | Message |
|---|---|---|
| Wrong API key | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |
| Missing authorization header | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |
| Tenant not found | `400 Bad Request` | `"detail": "'{tenant}' tenant not found in database."` |
| Client ID header is missing | `400 Bad Request` | `"detail": "Unauthorized Client."` |
| Client from header does not match any tenant | `400 Bad Request` | `"detail": "Failed to connect to tenant db."` |
| Malformed JSON body | `400 Bad Request` | `"detail": "Invalid JSON body."` |
| Batch exceeds size limit | `422 Unprocessable Entity` | `{"detail": [{"loc": ["body", "events"], "msg": "ensure this value has at most 10000 items", "type": "value_error.list.max_items", "ctx": {"limit_value": 10000}}]}` |
| Missing required field on an event | `422 Unprocessable Entity` | `{"detail": [{"loc": ["body", "events", 0, "id"], "msg": "field required", "type": "value_error.missing"}]}` |
| Invalid `id` (not a UUID) | `422 Unprocessable Entity` | `{"detail": [{"loc": ["body", "events", 0, "id"], "msg": "value is not a valid uuid", "type": "type_error.uuid"}]}` |
| Invalid `event_timestamp` format | `422 Unprocessable Entity` | `{"detail": [{"loc": ["body", "events", 0, "event_timestamp"], "msg": "invalid datetime format", "type": "value_error.datetime"}]}` |
| Invalid `category` / `event_type` / `source_type` value | `422 Unprocessable Entity` | `{"detail": [{"loc": ["body", "events", 0, "category"], "msg": "value is not a valid enumeration member", "type": "type_error.enum"}]}` |
| ClickHouse write failure after retries | `500 Internal Server Error` | `"detail": "Failed to persist system events."` |
| Upstream ClickHouse unavailable | `503 Service Unavailable` | `"detail": "ClickHouse temporarily unavailable."` |

### Example

#### Request

```bash
curl -X POST https://<host>/api/system-events/batch \
  -H "Content-Type: application/json" \
  -H "X-API-Key: API_KEY" \
  -H "X-Client-Id: 1a2b3c4d-5e6f-4a8b-9c0d-1e2f3a4b5c6d" \
  -d '{
    "events": [
      {
        "id": "550e8400-e29b-41d4-a716-446655440000",
        "event_timestamp": "2026-06-19T10:00:00.000000Z",
        "category": 1,
        "event_type": 1,
        "source_id": 42,
        "source_type": 1,
        "source_info": "browser",
        "source_ip": "1.2.3.4",
        "event_data": "{\"auth_type\": \"PW\"}"
      }
    ]
  }'
```

#### Response

* Status: `201 Created`

```json
{
  "inserted": 1
}
```

### Operational notes

* **Bloom filter index on `id`** — The `system_events` table carries a bloom filter secondary index on the `id` column to keep the cross-batch dedup lookup cheap. Producers should treat `id` as a stable, high-entropy UUID v4 so the filter retains its selectivity.
* **`async_insert` enabled** — Writes use ClickHouse [`async_insert`](https://clickhouse.com/docs/en/optimize/asynchronous-inserts), so the `201` response is returned once the batch is accepted into the server-side buffer, not once it is fully merged into the part. Reads issued immediately after a successful write may not see the new rows until the buffer flushes.
* **Retry on `ServerError`** — The endpoint retries transient ClickHouse `ServerError` responses up to 5 attempts with exponential backoff before surfacing a `500` / `503` to the caller. Idempotency by `id` makes these retries safe.

***

## GET /api/history/events

Returns a paginated list of History Events based on query parameters.

### Permissions

Requires `authentication` and `client_id` in the request header.\
`client_id` must be a UUID v4 value.

### Request

#### Headers

```text
Request Method: GET
Content-Type: application/json
X-API-Key: API_KEY
X-Client-Id: client_id
```

### Response

#### Top-level response

| Key | Type | Notes |
|---|---|---|
| limit | int | Page size |
| offset | int | Page offset |
| total\_count | int | Total number of history events visible to the API client |
| filtered\_count | int | Number of events returned after filters are applied |
| results | Array | Event records |

#### `results` array fields

| Key | Type | Notes |
|---|---|---|
| event\_id | uuid | Event identifier |
| event\_datetime | datetime | Event timestamp |
| event\_type | enum | Values include `record_created`, `owner_initialized`, `owners_added`, `owners_removed`, `assignees_added`, `assignees_removed`, `field_values_changed`, `record_deleted`, `document_generated`, `status_initialized` |
| event\_data | json | Schema depends on `event_type` |
| source\_type | enum | Values: `user`, `sequence`, `system`, `mcp` |
| source\_id | int | Source identifier |
| source\_name | string | Source display name. For `source_type: mcp`, resolved from the users table by `source_id`. Returns `null` if the `source_id` does not exist in the users table. |
| source\_info | string | Additional information about the event source. For MCP events, contains the AI model identifier (e.g. `"claude-code 2.1.158"`). Returns `""` for all other event types. |

### `results.event_data` by event type

The structure of `event_data` depends on the `event_type`.

#### `owner_initialized`, `owners_added`, `owners_removed`

Returns an array of owner objects.

| Key | Type | Notes |
|---|---|---|
| id | int | User ID |
| type | enum | Value: `user` |
| name | string | User label |

```json
[
  {
    "id": 9768,
    "type": "user",
    "name": "John Smith"
  }
]
```

#### `assignees_added`, `assignees_removed`

Returns an array of assignee objects.

| Key | Type | Notes |
|---|---|---|
| id | int | User ID |
| type | enum | Value: `user` |
| name | string | User label |
| permission\_set | Object | Permission Set object |

##### `permission_set`

| Key | Type | Notes |
|---|---|---|
| id | int | Permission Set ID |
| name | string | Permission Set label |

```json
[
  {
    "id": 9768,
    "type": "user",
    "name": "John Smith",
    "permission_set": {
      "id": 35,
      "name": "PermSet"
    }
  }
]
```

#### `field_values_changed`, `record_created`

Returns an array of field-value objects.

| Key | Type | Notes |
|---|---|---|
| field\_id | int | Field ID |
| field\_type | enum | Field type |
| field\_value | Any | Any JSON-compatible field value |
| field\_name | string | Field label |

```json
[
  {
    "field_id": 9768,
    "field_type": "string",
    "field_value": "Value",
    "field_name": "Car"
  }
]
```

#### `record_deleted`

Returns an empty array.

```json
[]
```

#### `document_generated`

The source page indicates this event contains document-related payload data. A representative example is:

```json
[
  {
    "document_template_id": 123,
    "field_id": 12,
    "file_id": "1a2b3c4d-5e6f-7g8h-9i0j-1k2l3m4n5o6p"
  }
]
```

### Response examples

#### Example: `record_deleted`

* Status: `200 OK`

```json
{
  "limit": 1,
  "offset": 0,
  "filtered_count": 2,
  "total_count": 4,
  "results": [
    {
      "event_id": "6e165f4b-8729-487c-93eb-7bf3445554e9",
      "event_datetime": "2021-10-27T12:27:43.462803+00:00",
      "event_type": "record_deleted",
      "source_type": "mcp",
      "source_id": 6,
      "source_name": null,
      "source_info": "claude-code 2.1.158",
      "event_data": []
    }
  ]
}
```

#### Example: `document_generated`

* Status: `200 OK`

```json
{
  "limit": 1,
  "offset": 0,
  "filtered_count": 2,
  "total_count": 4,
  "results": [
    {
      "event_id": "6e165f4b-8729-487c-93eb-7bf3445554e9",
      "event_datetime": "2021-10-27T12:27:43.462803+00:00",
      "event_type": "document_generated",
      "event_data": [
        {
          "document_template_id": 123,
          "field_id": 12,
          "file_id": "1a2b3c4d-5e6f-7g8h-9i0j-1k2l3m4n5o6p"
        }
      ],
      "source_type": "user",
      "source_id": 1
    }
  ]
}
```

### Sorting

Sorting cannot be controlled through the request.

Results are returned in descending order by `event_datetime`. No other sorting is supported.

Notes:

1. `record_created` is the first event in chronological order, so it is sorted at the end of the descending result set.
2. `owner_initialized` immediately follows `record_created` in chronological order.

### Filtering

For the full description of standard predicates, see [ALX API standards - Developers guide](/api/standards/).

| Parameter | Example |
|---|---|
| event\_datetime | `/api/history/events?event_datetime=2022-01-01` |
| event\_datetime! | `/api/history/events?event_datetime__exclude=2022-01-01` |
| event\_datetime\_gt | `/api/history/events?event_datetime__gt=2022-01-01` |
| event\_datetime\_gt! | `/api/history/events?event_datetime__gt__exclude=2022-01-01` |
| event\_datetime\_gte | `/api/history/events?event_datetime__gte=2022-01-01` |
| event\_datetime\_gte! | `/api/history/events?event_datetime__gte__exclude=2022-01-01` |
| event\_datetime\_range | `/api/history/events?event_datetime__range=2022-01-01,2022-02-01` |
| event\_datetime\_range! | `/api/history/events?event_datetime__range__exclude=2022-01-01,2022-02-01` |
| record\_id | `/api/history/events?record_id=1` |
| source\_type | `/api/history/events?source_type=user` |
| source\_type! | `/api/history/events?source_type__exclude=sequence` |
| source\_type\_\_in | `/api/history/events?source_type__in=system,user` |
| source\_type\_\_in! | `/api/history/events?source_type__in__exclude=sequence` |
| source\_id | `/api/history/events?source_id=user` |
| source\_id! | `/api/history/events?source_id__exclude=sequence` |
| source\_id\_\_in | `/api/history/events?source_id__in=system,user` |
| source\_id\_\_in! | `/api/history/events?source_id__in__exclude=sequence` |
| source\_info | `/api/history/events?source_info=claude-code+2.1.158` |
| source\_info\_\_exclude | `/api/history/events?source_info__exclude=claude-code+2.1.158` |
| source\_info\_\_in | `/api/history/events?source_info__in=claude-code+2.1.158,cursor+1.0.0` |
| source\_info\_\_in\_\_exclude | `/api/history/events?source_info__in__exclude=claude-code+2.1.158` |
| field\_id | `/api/history/events?field_id=1` |
| field\_id\_\_in | `/api/history/events?field_id__in=121,122,150` |
| field\_id\_\_in! | `/api/history/events?field_id__in__exclude=121,122` |

`field_id__in` returns events whose `field_id` matches any value in the comma-separated list; `field_id__in__exclude` returns events whose `field_id` matches none of the listed values. Both variants only apply to events that actually carry a `field_id` (currently `field_values_changed`); they combine with all other filters (`record_id`, `event_type__in`, `source_*`, `event_datetime__*`) via AND. Non-integer values in the CSV are silently dropped; an all-invalid CSV skips the filter entirely.

::: tip Notes on `source_info` filters

* Filtering is case-sensitive (ClickHouse compares byte-by-byte).
* `source_info` (exact match) accepts an empty string `""` — filters for events without metadata (i.e. non-MCP events).
* `source_info__in` ignores empty entries (e.g. a trailing comma value is treated as a value).
  :::

### Errors

| Error | Response code | Message |
|---|---|---|
| Tenant not found | `400 Bad Request` | `"detail": "'{tenant}' tenant not found in database."` |
| Source type invalid | `400 Bad Request` | `{'detail': [{'loc': ['query', 'source_type'], 'msg': "value is not a valid enumeration member; permitted: 'user', 'sequence', 'system', 'mcp'", 'type': 'type_error.enum', 'ctx': {'enum_values': ['user', 'sequence', 'system', 'mcp']}}]}` |
| Source ID invalid | `400 Bad Request` | `{"detail": [{"loc": ["query", "source_id"], "msg": "value is not a valid integer", "type": "type_error.integer"}]}` |
| Field ID invalid | `400 Bad Request` | `{"detail": [{"loc": ["query", "field_id"], "msg": "value is not a valid integer", "type": "type_error.integer"}]}` |
| Client ID header is missing | `400 Bad Request` | `"detail": "Unauthorized Client."` |
| Client from header does not match any tenant | `400 Bad Request` | `"detail": "Failed to connect to tenant db."` |
| Wrong API key | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |
| Missing authorization header | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |
| Any request method other than GET is used | `405 Method Not Allowed` | |
| Event datetime range wrong format - too many items | `422 Unprocessable Entity` | `{'detail': [{'loc': ['range_value'], 'msg': 'ensure this value has at most 2 items', 'type': 'value_error.list.max_items', 'ctx': {'limit_value': 2}}]}` |
| Event datetime range wrong format - too few items | `422 Unprocessable Entity` | `{'detail': [{'loc': ['range_value'], 'msg': 'ensure this value has at least 2 items', 'type': 'value_error.list.min_items', 'ctx': {'limit_value': 2}}]}` |
| Event datetime range wrong format on range item | `422 Unprocessable Entity` | `{'detail': [{'loc': ['range_value', 0], 'msg': 'invalid datetime format', 'type': 'value_error.datetime'}, {'loc': ['range_value', 0], 'msg': 'invalid date format', 'type': 'value_error.date'}]}` |

***

## GET /api/history/events/`event_id`/file

Generates a presigned URL for downloading a file from S3.\
The client instance is identified through the `X-Client-Id` header.

### Permissions

Requires `authentication`.

### Request

#### Headers

```text
Request Method: GET
Content-Type: application/force-download
X-API-Key: API_KEY
X-Client-Id: client_id
```

#### Example path

```text
GET /api/history/events/1a2b3c4d-5e6f-7g8h-9i0j-1k2l3m4n5o6p/file
```

### Errors

| Error | Response code | Message |
|---|---|---|
| Tenant not found | `400 Bad Request` | `"detail": "'{tenant}' tenant not found in database."` |
| Client ID header is missing | `400 Bad Request` | `"detail": "Unauthorized Client."` |
| Client from header does not match any tenant | `400 Bad Request` | `"detail": "Failed to connect to tenant db."` |
| Wrong API key | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |
| Missing authorization header | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |
| Any request method other than GET is used | `405 Method Not Allowed` | |
| Event not found | `404 Not Found` | `"detail": "Event not found."` |

---

---
url: >-
  /knowledgebase/administration/elements/everything-you-need-to-create-an-element.md
---

# Everything you need to create an Element

Before you can create and use an Element, there are several prerequisites to consider.

Elements allow you to extend Autologyx with your own web components, but they require both a correctly structured package and access to a Git repository from which the package can be imported.

## Before you begin

Ensure you have:

1. A Super Admin account type. Only Super Admin users can create, import and manage Elements.
2. Access to a Git repository that stores your Element package.
3. A working knowledge of JSON, as Elements are configured using a `config.json` file.
4. A clear understanding of where the Element will be used and any configuration options it should expose to administrators.

## Prepare your Git repository

Our recommended approach is to maintain two repositories:

* a development repository containing your source code
* a deployment repository containing the production-ready files that Autologyx imports

### Required files

Every Element package must contain the following files:

* `config.json` — defines the Element metadata and configuration
* `index.html` — the entry point loaded by Autologyx

Without both files, the import will fail.

![Required files within an Element package](/knowledgebase/images/administration/create-an-element-1.png)

## Configure the `config.json` file

The `config.json` file must follow the required schema exactly.

If the structure or required properties are incorrect, the Element cannot be imported.

![Example config.json structure](/knowledgebase/images/administration/create-an-element-2.png)

### Important configuration fields

Several configuration properties are particularly important:

* **Version** — a string identifying the Element version. This can contain numbers or descriptive text.
* **Logo** — a URL pointing to the Element logo.
* **Publisher** — the company or organisation responsible for the Element. This is displayed in the Elements list.
* **Publisher URL** — a website that users can open directly from the Publisher field.

![Key configuration fields within config.json](/knowledgebase/images/administration/create-an-element-3.png)

### Parameters

The first three parameter properties are mandatory.

These parameters generate the configuration fields shown when administrators place the Element onto a page or form.

For more information, see [Configuring an Element and how it works on a form](/knowledgebase/administration/elements/configuring-an-element-and-how-it-works-on-a-form/).

![Parameter definitions within config.json](/knowledgebase/images/administration/create-an-element-4.png)

If `parameter_type` is set to `enum`, you must also define `parameter_options`, which populate the drop-down list presented to administrators.

An example is shown below.

![Example enum parameter configuration](/knowledgebase/images/administration/create-an-element-5.png)

> **Note:** `parameter_limit` is currently reserved and is not used.

## The index.html file

If your Element is built using React, the `index.html` file is responsible for loading the compiled application from the Assets folder.

![Example index.html file](/knowledgebase/images/administration/create-an-element-6.png)

The Assets folder typically contains:

* the compiled JavaScript bundle
* CSS files
* loader images and other supporting assets

![Typical Element assets folder](/knowledgebase/images/administration/create-an-element-7.png)

## Create an Element in Autologyx

Navigate to:

**Administration** → **Elements**

Click **+ Create**.

Enter a unique **Name** for the Element. You can also provide an optional description to help administrators understand its purpose.

![Create Element page](/knowledgebase/images/administration/create-an-element-8.png)

## Package Management

The **Package Management** section requires information from your Git repository.

### Git repository URL

*(The following example uses GitLab.)*

Open the **Clone** menu and copy the **Clone with HTTPS** URL.

Paste this into the **Git repository URL** field.

![Copying the repository HTTPS URL from GitLab](/knowledgebase/images/administration/create-an-element-9.png)

### Git repository username and access token

In GitLab, navigate to:

**Settings** → **Access Tokens**

Create a new access token.

![Creating a GitLab access token](/knowledgebase/images/administration/create-an-element-10.png)

### Required scopes

The access token must include both of the following scopes:

* `read_api`
* `read_repository`

After creating the token:

* copy the token immediately into the **Git repository token** field in Autologyx
* copy the **Token name** into the **Git repository username** field

For security reasons, GitLab only displays the access token once.

Most access tokens expire after a fixed period (commonly four weeks). If the token expires before you re-import or update the Element, the import will fail. Consider using a longer expiry period if permitted by your organisation's security policy.

## Import the Element

Once all repository details have been entered:

1. Select the system areas where the Element should be available.
2. Enable the Element.
3. Click **Import**.

A successful import enables the **Save** button.

Click **Save** to add the Element to your Elements list.

## Further reading

For guidance on creating repository access tokens, refer to your provider's documentation:

* GitLab: https://docs.gitlab.com/ee/user/project/settings/project\_access\_tokens.html
* GitHub: https://docs.github.com/en/enterprise-server@3.6/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens
* Bitbucket: https://support.atlassian.com/bitbucket-cloud/docs/create-a-repository-access-token/

## Things to remember

1. Only Super Admin users can create and manage Elements.
2. Every Element package must include both `config.json` and `index.html`.
3. The `config.json` file must follow the required schema exactly.
4. Repository access tokens must include both `read_api` and `read_repository` scopes.
5. Expired access tokens will prevent future imports.
6. After a successful import, click **Save** to add the Element to your system.

---

---
url: >-
  /knowledgebase/system-configuration/object-classes/explanation-of-class-permissions.md
---

# Explanation of Class Permissions

When in Edit mode, one of the tabs on an Object class is Permissions.

The Permissions tab contains sub tabs for:

* Class permissions
* Record permissions

This article is designed to explain what each of the options in a Class permissions set means.

A Class permissions set includes permissions pertaining to the Object class itself, all Object records within the class, and all Tasks assigned to records in the class.

## Default owner permissions

The Object class Owners' Permissions are set by default and are fully enabled. These cannot be edited.

The User who created the Object class will immediately become an Owner and, as such, they can add further Owners and additional sets of Permissions to which Users can be added as Assignees.

A user with a Super admin account type can also create and edit permission sets.

The below screenshot shows the default Owner permissions and a permission set for Mortgage Handlers which is much less permissive.

**A User with the Mortgage Handler Permissions shown below will:**

* not have access to the Object class configuration
* be able to View the Object class usage, ie see how many records exist, which Task templates are available, and which Sequences have been created for the Object class
* be able to see and edit all records in the Object class
* be able to see and complete all tasks assigned to all records in the Object class

![0907a.png](/knowledgebase/images/img_4471889748767_1776895964.png)

## Summary of Class permissions and what they mean

In the below screenshots, a User has been given the Mortgage Handler Class permissions.

|  |  |
| --- | --- |
| **Object class** | |
| Screenshot 2024-08-06 at 15.18.19.png | VIEW    This permission is designed to be granted with Object records Create, View all, Edit all and/or Delete all.  Note that when any of the Object records permissions are applied, the View permission in the Object class is auto-enabled.  If granted alone, the User will see no benefit. |
| With the above permissions (and no Record permissions), the User can view, edit and create records. Note, they have not been granted any task permissions, hence no results on the Tasks tab.    Screenshot 2024-08-06 at 15.24.04.png | |
| Screenshot 2024-08-06 at 15.47.14.png | EDIT  This permission requires that the List permission is also granted. Object classes will appear in the main menu under System Configuration. The User will be able to add and amend Fields and edit all 3 views under the Display tab. They will be able to create/edit Forms and Document Templates.  They will be able to view the Permissions tab but not edit any of the configuration or add assignees, and they cannot create new permission sets. |
| This permission is useful for an internal user type who is limited to config admin for only the specific object class.  Screenshot 2024-08-06 at 15.43.01.png | |
| Screenshot 2024-08-06 at 15.51.59.png | DELETE  As above, this permission requires that the List permission is also granted. The User will have Object classes in the main menu under System Configuration. The Object class will be displayed in the list. The User will be able to delete the Object class but not be able to edit it! |
| Screenshot 2024-08-06 at 15.49.13.png | |
| Screenshot 2024-08-01 at 15.27.59.png | LIST  The User will have Object classes in the main menu under System Configuration.  The Object class will be displayed in the list.  If the User does not have the View all Object record Class permission or is not an Owner or Assignee of a record, there will be no options in the Actions menu.  However, if any of these are true, they will see the option to View usage (as below left).  The Object class will also appear in the User's Record list, irrespective of whether they have any Record access permissions (as below right). |
| Screenshot 2024-08-01 at 15.23.32.png | Screenshot 2024-08-07 at 16.38.54.png |
| The List permission is useful when granted at parent level (Mortgage Application) together with the Create and Edit permissions but can be left out of the child Object class permissions (Lender and Properties) so that child records are not available to the User in the Records list. | Screenshot 2024-08-07 at 16.43.55.png |
| Below the User has a Permission set with the Object class List permission enabled for Mortgage Application, hence it can be seen in the Records list. The User's Permission sets for Properties and Lenders does not have List enabled. However, from a Create Mortgage Application form they can create or select Properties and Lenders records because they have the Object records permissions Create and View all enabled. | |
| Screenshot 2024-08-07 at 15.42.56.png | Screenshot 2024-08-07 at 15.49.40.png |
| The Edit and Delete permissions cannot be applied without the View permission. This will automatically enable if either Edit or Delete is enabled. | |
| **Object records** | |
| Screenshot 2024-08-06 at 16.04.57.png | CREATE  This will allow the user to create Records in the Workspace for this Object class.  They will become the Owner of any Records they create and as such will be able to edit and delete them as well as complete all their Tasks, ie they will have full Object record permissions.  However, they will not be able to view, edit or delete any Records for which they are not the Owner or for which they have not been assigned a Record permissions set. |
| In the below screenshot, the Mortgage Handler is the Owner of the record.  Screenshot 2024-08-06 at 16.07.39.png | |
| Screenshot 2024-08-06 at 16.14.56.png | VIEW ALL  The User will be able to see all the display views for all the Records in the Object class in the Workspace.  They will not be able to edit any data (other than where they are the Owner or where they have Record permissions) and they will not be able to create any new Records. |
| Screenshot 2024-08-06 at 17.57.25.png | |
| Screenshot 2024-08-06 at 18.01.45.png | EDIT ALL  With this configuration, the User will be able to see all the display views for all Records in the Object class in the Workspace.  In addition, they will be able to edit those Records but they will not be able to create any new Records. |
| Screenshot 2024-08-07 at 17.01.08.png | |
| Screenshot 2024-08-06 at 18.12.26.png | DELETE ALL  With the Delete all permission enabled, Users will be able to select Delete in the Actions menu of all Records and thus permanently remove then from the system.  With this configuration, they can view records but cannot Edit them, and they cannot Create records. |
| Screenshot 2024-08-06 at 18.14.43.png | |
| The Edit all and Delete all permissions cannot be applied without the View all permission. If either is enabled the View all permission will be automatically enabled.  None of the Object records permissions can be applied without the View permission in the Object class being enabled. | |
| **Tasks** | |
| Screenshot 2024-08-07 at 10.47.51.png | CREATE  Tasks are not created from the Task list.  The User will need Record access in order to create a Task from a Task template.  In the "normal" user interface, only Task templates with the Task creation mechanism set to Manual will be available.  When the Create permission is enabled, all other permissions in this section are automatically enabled. |
| Screenshot 2024-08-07 at 10.49.54.png | |
| mceclip10.png | VIEW ALL  The User will have access to Tasks under their Workspace.  The Record Identifier will be blanked out for records where the User is not the Owner, or for which they have not been assigned a Record permissions set. Therefore, this permission is more likely to be granted together with Object records/ View all.  The Action menu for each Task will contain an option to View.  The User will be able to View all Tasks but will not be able to Complete or Delete those where they have no further permissions. |
| In the screenshot below, the User is the Owner of record ID 728 but has no record permissions for the others.  Screenshot 2024-08-07 at 11.17.03.png | |
| Screenshot 2024-08-07 at 14.56.49.png | EDIT ALL  This permission will make no obvious change to the normal User experience as tasks are not editable from the user interface.  However, it will allow a User to make PATCH API calls to edit the Due Date of a Task associated to a record.  However, this type of User is most likely to have a Config Admin account type and a Role which allows them to create sequences. |
| Screenshot 2024-08-07 at 11.19.23.png | COMPLETE ALL  The User will have access to Tasks under their Workspace. The Action menu for each Task will contain an option to Complete.  However, without record access the Record Identifier will be blanked out! Therefore, it is likely that Object records/ View all will be granted at the same time.  The User will be able to Complete all Tasks but will not be able to Delete them. |
| Screenshot 2024-08-07 at 11.20.40.png | |
| Screenshot 2024-08-07 at 14.47.10.png | ASSIGN ALL  This permission will also allow the User to View and Complete all Tasks as these permissions are auto-enabled with Assign all.  It allows the User to make themself or another User the Owner of the task.  This action is done by selecting Complete in the task Actions menu which will open the task.  In the top section, a Task owner can be selected or changed by clicking the Assign owner or Reassign ownership link, respectively.  If the User has record access, this action can also be completed from the record side panel/Tasks tab. |
| Screenshot 2024-08-07 at 14.54.31.png | Screenshot 2024-08-07 at 14.53.31.png |
| When Edit all or Complete all is enabled View all is automatically enabled.  When Assign all is enabled, View all and Complete all are automatically enabled. | |

**Important:** If a User is granted more permissive Class permissions than Record permissions, these will override the Record permissions. For example, a User is given Class permissions which include Complete all Tasks but their Record permissions only gives View all Tasks, they will be able to Complete all Tasks for records to which they are assigned.

## Useful info

1. Each Object class can have up to 10 Permission sets and 100 Owners.
2. Each Permission set can have up to 100 Assignees.

---

---
url: >-
  /knowledgebase/system-configuration/object-classes/explanation-of-record-permissions.md
---

# Explanation of Record Permissions

When in Edit mode, one of the tabs on an Object class is **Permissions**.

The Permissions tab contains sub tabs for:

* Class permissions
* Record permissions

This article is designed to explain what each of the options in a Record permissions set means.

A Record permissions set includes permissions pertaining to Object records within the class and Tasks associated with the record.

## Default owner permissions

The Record Owners' Permissions are set by default and are fully enabled. These permissions cannot be edited.

A User who creates a record will immediately become its Owner and as such they will be able to:

* Assign a Record Permission set to other Users
* Revoke another User's access to the record by removing the Permission set
* Give up ownership

However, having done the latter, if they are not the Owner of the Object class or a User with a Super Admin account type, they will not be able to get ownership back. They will lose access to the record unless they have other permissions which allow this.

An Object class owner or a user with a Super admin account type can create and edit Record permission sets.

## Example shown below

The larger screenshot further below shows the default Record Owner permissions and a permission set for Mortgage Reviewer.

|  |  |
| --- | --- |
| It is worth pointing out at this stage, that a User with this Record permissions set will also need Class permission/ Object class/ List. This will allow "Records" to appear in the main navigation menu, and the Object class can be selected in the Records list filter. | Screenshot 2024-08-14 at 12.29.51.png |
| Screenshot 2024-08-14 at 12.36.53.png | |

With these Record permissions, and List under Class permissions, the Mortgage Reviewer:

* Can view the records for which they are granted this Permission set
* Can view all the tasks associated with these records
* Cannot edit or delete any records
* Cannot complete or delete any tasks

![0508a.png](/knowledgebase/images/img_4475972812575_1776895974.png)

**Note:** Unlike for Class Permissions, there are no avatars to show which Users have been granted these Permission sets. This is because access is given from individual records.

In a following article, we will see how other Users can be given Ownership or a Record permission set.

## Summary of Record permissions and what they mean

**NB:** Throughout, it is assumed that the Mortgage Reviewer has been granted Class permission/ Object class/ List.

|  |  |  |
| --- | --- | --- |
| **Object Record** | | |
| Screenshot 2024-08-08 at 17.51.24.png | VIEW  The User can view the summary and activity log in the side panel. They can generate and download documents from the templates tab but cannot file them on the record. The user has no access to the tasks associated with the record, hence "No results" on this tab.  The Record access tab is not available.  They can view the full record via the "Open" option in the Actions menu, but they are not able to edit or delete the record. | |
| Screenshot 2024-08-08 at 17.53.22.png | | |
| Screenshot 2024-08-08 at 18.03.41.png | EDIT  Again, the Actions menu will contain the option to Open the record. However, once open the User can edit the record. They cannot delete it.  The user has no access to the tasks associated with the record, hence "No results" on this tab. Summary and activity log are available to view. Documents can be generated, downloaded or saved to a field on the record.  The Record access tab is not available. | |
| Screenshot 2024-08-14 at 13.00.36.png | | |
| Screenshot 2024-08-08 at 18.09.14.png | DELETE  The User can view the summary and activity log in the side panel. They can generate and download documents from the templates tab but cannot file them on the record. The user has no access to the tasks associated with the record, hence "No results" on this tab.  The Record access tab is not available.  The User can delete the record but although they can open it to view it they cannot edit it. | |
| Screenshot 2024-08-14 at 13.06.21.png | | |
| The Edit and Delete permissions cannot be applied without the View permission. This will automatically enable if either Edit or Delete is enabled. | | |

|  |  |  |
| --- | --- | --- |
| **Tasks** | | |
| Screenshot 2024-08-12 at 16.52.27.png | CREATE  In the "normal" user interface, tasks cannot be created from the Tasks list, so the User will need Record access in order to create a Task from a Task template. Therefore, as a minimum, Object record/ View permission should be granted. As described above, it follows that the User will also need Class permission/ Object class/ List.  Task templates with the Task creation mechanism set to Manual will be available.  When the Create permission is enabled, all other permissions in this section are automatically enabled. This means that the User can:   - Save and Complete tasks - Assign and Reassign ownership of the task   The User will be able to create tasks for all records they are assigned to. | |
| Screenshot 2024-08-14 at 13.17.45.png | | |
| Screenshot 2024-08-12 at 18.06.29.png | VIEW ALL  Again, this permission is only useful if the User is granted the Object record/ View permission and the Class permission/ Object class/ List. This allows the user to see and identify the record to which Tasks in the Task List belong.  The User can view all tasks for all records they are assigned to. They will be able to do this from the Tasks list via the Actions menu/ View or from the record's Tasks tab in the side panel.  They will not be able to enter data, save or complete the task. | |
| With Class permission/ Object class/ List and Object record/ View permission  Screenshot 2024-08-12 at 18.14.22.png | | |
| Screenshot 2024-08-12 at 18.12.58.png | | |
| Without Class permission/ Object class/ List and Object record/ View permission: record data is hidden  Screenshot 2024-08-14 at 13.32.27.png | | |
| Screenshot 2024-08-14 at 13.40.48.png | EDIT ALL  This permission will make no obvious change to the normal User experience as tasks are not editable from the user interface.  However, it will allow a User to make PATCH API calls to edit the Due Date of a Task associated to a record. This could be done via a third party application such as Postman.  In this case, the User is granted edit task permission for all tasks associated with all records they are assigned to.  As an alternative, a User needing to do this type of activity may have a Config Admin account type and a Role which allows them to create/edit task templates and sequences. This would grant global permissions rather than to one Object class. | |
| Screenshot 2024-08-12 at 19.56.20.png | COMPLETE ALL  As before, this permission should be granted with the Object record/ View permission and Class permission/ Object class/ List so that the User is able to see and identify records to which tasks belong.  Users can complete all tasks associated with records they are assigned to.  They will be able to do this from the Tasks list or from the record's Tasks tab in the side panel. | |
| Screenshot 2024-08-12 at 19.59.13.png | | |
| Screenshot 2024-08-12 at 19.58.09.png | | |
| Screenshot 2024-08-14 at 14.02.43.png | ASSIGN ALL  Again this permission should be granted with Object record/ View permission and Class permission/ Object class/ List so that the User is able to see and identify records to which tasks belong.  Users will be able to do the following for all tasks of records where they are given this permission set:   - Save and Complete tasks - Assign and Reassign ownership of the task | |
| Screenshot 2024-08-14 at 14.00.32.png | | |
| When Edit all or Complete all is enabled View all is automatically enabled.  When Assign all is enabled, View all and Complete all are automatically enabled. | | |

---

---
url: /knowledgebase/using-help-and-support/faqs.md
---
# FAQs

**Browse the sections below:**

* [How Do I Grant View Users Permission To Config Admins](/knowledgebase/using-help-and-support/faqs/how-do-i-grant-view-users-permission-to-config-admins/)

---

---
url: /knowledgebase/system-configuration/merge-fields/field-types-and-formatting.md
---

# Field types and formatting

| Field Type | Merge Field Example | Output Example |
| --- | --- | --- |
| String | {{ record.field\_text }} | `John` |
| Integer | {{ record.field\_int }} | `123` |
| Float | {{ record.field\_float }} | `123.45` |
| Boolean | {{ record.field\_bool }} | `True` / `False` |
| Enum | {{ record.field\_enum }} | `Apple` |
| Set | {{ record.field\_set }} | `['Apple', 'Pear']` |
| Email | {{ record.field\_email }} | `user@example.com` |
| Phone | {{ record.field\_phone }} | `123456789` |
| Date | {{ record.field\_date }} | `2023-04-17` |
| DateTime | {{ record.field\_datetime }} | `2023-04-17 12:37:00+02:00` |
| Time | {{ record.field\_time }} | `12:37:00` |
| URL | {{ record.field\_url }} | `https://autologyx.com` |
| JSON | {{ record.field\_json }} | `{"key": "value"}` |
| Document | {{ record.field\_document }} | List of documents (with URLs) |
| User Field | {{ record.field\_\<alias>.users }} | List of user objects |
| Group Field | {{ record.field\_\<alias>.user\_groups }} | List of groups |

## **Formatting output**

You can format the output using filters. These are applied by appending a pipe (`|`) and the filter name to the field.

| Filter | Example | Output Example |
| --- | --- | --- |
| `date` | {{ record.field\_date | date('%d %B %Y') }} | `17 April 2023` |
| `datetime` | {{ record.field\_datetime | datetime('%H:%M') }} | `12:37` |
| `default` | {{ record.field | default('N/A') }} | If field is empty → `N/A` |
| `join` | {{ record.field\_set | join(', ') }} | `Apple, Pear` |
| `length` | {{ record.field\_set | length }} | `2` |
| `lower` / `upper` | {{ record.field\_text | upper }} | `JOHN` |
| `capitalize` | {{ record.field\_text | capitalize }} | `John` |
| `replace` | {{ record.field\_text | replace('a', 'b') }} | Replaces `a` with `b` |

---

---
url: /knowledgebase/release-notes/release-notes-1.13/file-upload-component.md
---

# File upload component

Does your team handle cases with hundreds or even thousands of documents? Traditionally, that meant manually creating records one by one, navigating complex forms, and spending hours in front of screens. But not anymore.

## Overview

The File upload component is available as a drag-and-drop module on any Landing page. Once added, administrators can configure:

* The Object class for which new records should be created
* The specific document-type field into which each uploaded file will be attached
* An optional custom header and description text to guide end users

![File upload 1.gif](../../../images2/zendesk_4893354621471_001_322a31157ad7.gif)

## User experience

**From the user’s perspective, the process is simple:**

1. Upload a `.zip` archive containing the documents to ingest
2. Click **“Start processing”**
3. Done — the user can grab a coffee while we do the rest

### File requirements

The ZIP must contain only documents — no subfolders or nested structures. Every file will be treated as a separate, standalone entry.

**Maximum ZIP file size:** 5GB

## What happens behind the scenes?

This is where Catalyst really earns its name.

### Step 1: Upload

The ZIP is uploaded directly through the user interface and streamed securely to Catalyst’s servers. The user must remain on the page during this step, and clear visual feedback is provided.

### Step 2: Secure file processing

Once the upload completes, Catalyst takes over:

* **Antivirus scan:** Every file is scanned for known threats. If malware or corruption is detected, that file is isolated and marked as failed.
* **Extraction and validation:** The archive is unpacked. Each file is inspected and validated individually to ensure it meets document field requirements.
* **Record creation:** For each valid file, a new record is created within the target Object class. The file is automatically attached to the specified document field.

![File upload 2.gif](../../../images2/zendesk_4893354621471_002_9b7954a4a3b7.gif)

### Results and history

Once done, users get a clear summary showing how many records were created and which files failed. Any errors appear under a **“Failed files”** tab — just one click to see what didn’t process and why.

Even if the user leaves the browser or goes offline, nothing is lost. The component remembers every upload. Users can revisit the upload history, check ongoing processing, or review detailed summaries of past uploads.

![File upload 3.gif](../../../images2/zendesk_4893354621471_003_7b3d4baf45b7.gif)

This entire process runs in the background. Users are free to navigate away, log out, or get on with other tasks.

## Integration with Catalyst automation

**Most powerful of all, this isn’t just a standalone tool.** The File upload component integrates directly with Catalyst’s broader automation framework. After upload:

* You can immediately launch a Sequencer workflow to enrich records, route them for review, or notify users
* Records are fully usable, searchable, and filterable like any other manually created item
* Each file is automatically indexed and attached without manual input

## Scale and use cases

We support ZIPs up to 5GB. How much fits into 5GB? That depends on the file types, but for standard legal PDFs (~250 KB each), that’s well over 20,000 documents in a single upload. Lawyers and legal teams can now automate record creation in batches, eliminate human error, and reclaim hours and budgets.

This is built for professionals who work with vast document sets: mass discovery, contract ingestion, employment disclosures — anywhere volume would traditionally block progress. Our File upload component streamlines these scenarios, letting your team focus on what truly matters: legal analysis, strategy, and client relationships.

---

---
url: /api/websockets/resources/files.md
---
# File Upload Events

This page documents the WebSocket endpoint used to monitor and control file upload workflows for Object Records in Catalyst.

The endpoint supports bidirectional communication. After the WebSocket connection is established, the client can request presigned upload URLs, notify the backend when uploads are complete, and receive progress and monitoring updates as the backend processes uploaded files.

::: warning
This section documents technical and service-level WebSocket APIs. It should be used as implementation reference material and not treated as end-user documentation.
:::

## Endpoint overview

This page covers the following endpoint:

* `GET /ws/object-records/uploads/<upload_id>/`

## GET /ws/object-records/uploads/\<upload\_id>/

Connects the client to an upload process identified by `upload_id`.

### Permissions

Requires `authentication`.

Authentication is based on the `uuid` query string parameter used when establishing the WebSocket connection.

### Request

#### Upgrade request example

```text
Request Method: GET
Connection: Upgrade
Upgrade: websocket
```

### Connection behaviour

When the connection is established, communication is bidirectional:

* the WebSocket server sends status, progress, and result messages to the client
* the client sends JSON messages to request upload actions or to confirm upload completion

## Supported client messages

### 1. Request a presigned upload URL

To initiate an upload, the client sends a JSON message with the following fields:

| Key | Type | Notes |
|---|---|---|
| type | enum | `request_presigned_url` |
| file\_name | string | Original file name |
| file\_size | integer | File size in bytes |
| file\_type | string | File content type, for example `application/zip` |

### 2. Notify the backend that a single-part upload is complete

After the client uploads a ZIP file using a previously returned single presigned URL, it must notify the backend by sending:

| Key | Type | Notes |
|---|---|---|
| type | enum | `upload_complete` |
| upload\_id | uuid | Upload session identifier returned earlier |
| s3\_key | string | Full S3 key where the file was uploaded |

### 3. Notify the backend that a multipart upload is complete

After the client uploads a ZIP file using multipart presigned URLs, it must notify the backend by sending:

| Key | Type | Notes |
|---|---|---|
| type | enum | `complete_multipart_upload` |
| parts | array | Array of uploaded part descriptors |

#### `parts` array

| Key | Type | Notes |
|---|---|---|
| part\_number | int | Part number, starting from 1 |
| e\_tag | string | ETag returned by S3 for the uploaded part |

## Server responses

### Connection established

When the WebSocket connection is successfully opened, the server returns:

* WebSocket upgrade status: `101 Switching Protocols`

```json
{
  "type": "connection_established",
  "message": "WebSocket connected successfully"
}
```

## Presigned URL response

When the client requests a presigned upload URL, the server responds with a `presigned_url_ready` message.

### Example response

```json
{
  "type": "presigned_url_ready",
  "message": {
    "upload_id": "3c2b9b89-2f2a-497c-aa0a-1be5a8fd93c8",
    "temp_upload_id": "temp_1749545666136_csyydasgl",
    "presigned_url": "https://s3.amazonaws.com/advanced-uploader-bucket/uploads/1/0e6a1a81.zip?...",
    "fields": {},
    "s3_key": "some.domain.com/upload/1/0e6a1a81.zip",
    "is_multipart": false,
    "part_urls": [],
    "s3_upload_id": null,
    "chunk_size": null,
    "total_parts": 1
  }
}
```

### Response fields

| Key | Type | Notes |
|---|---|---|
| type | enum | Event type |
| message | object | Upload session data |

#### `message`

| Key | Type | Notes |
|---|---|---|
| upload\_id | uuid | Internal backend ID for this upload session |
| temp\_upload\_id | string | Temporary client-side ID used to map the response to the originating request |
| presigned\_url | string | Full S3 PUT presigned URL. For multipart uploads this is `null` |
| fields | object | Empty for PUT-based uploads |
| s3\_key | string | Target key in the S3 bucket |
| is\_multipart | boolean | Indicates whether multipart upload is required |
| part\_urls | array | Used only for multipart uploads |
| s3\_upload\_id | string | Multipart upload identifier used by S3 |
| chunk\_size | integer | Chunk size for multipart uploads |
| total\_parts | integer | Total number of parts expected |

### `message.part_urls` for multipart uploads

When `is_multipart` is `true`, the `part_urls` array contains presigned URLs for each upload part.

| Key | Type | Notes |
|---|---|---|
| url | string | Presigned URL for this part |
| part | int | Part number, starting from 1 |

## Monitoring updates

After the file has been uploaded, scanned, and unpacked, the backend sends monitoring updates describing the processing state.

### Monitoring update structure

| Key | Type | Notes |
|---|---|---|
| type | enum | `monitoring_update` |
| message | object | Monitoring data |

#### `message`

| Key | Type | Notes |
|---|---|---|
| attempt | int | Attempt number |
| timestamp | string | ISO 8601 timestamp |

There may also be additional fields depending on whether the message represents a success state, an error, or an intermediate monitoring attempt.

### Example: success monitoring update

```json
{
  "type": "monitoring_update",
  "message": {
    "step_name": "extracting_file",
    "av-status": "clean",
    "extracted_files": 100,
    "message": "Done Extracted 100 files",
    "status": "success",
    "attempt": 10,
    "timestamp": "2025-07-10T14:30:45.123456"
  }
}
```

## Progress updates

The backend also emits progress messages during different processing phases.

### Extracting and saving files

During this phase, the backend emits periodic progress updates such as:

```json
{
  "type": "progress_update",
  "message": {
    "step_name": "saving_files",
    "upload_id": "99b90581-4e29-4482-b25a-eea4d6dbe78f",
    "is_complete": false,
    "total_count": 2,
    "progress_count": 1,
    "timestamp": "2025-07-17T06:18:51.325683+00:00"
  }
}
```

### Creating records

After antivirus scanning and file saving are completed, the backend begins creating Object Records and adding them to the target Object Class.

During this phase, the backend emits periodic progress messages such as:

```json
{
  "type": "progress_update",
  "message": {
    "step_name": "creating_records",
    "upload_id": "3c2b9b89-2f2a-497c-aa0a-1be5a8fd93c8",
    "is_complete": false,
    "total_count": 120,
    "progress_count": 23,
    "timestamp": "2025-07-17T06:18:51.325683+00:00"
  }
}
```

### Progress update fields

| Key | Type | Notes |
|---|---|---|
| type | enum | `progress_update` |
| message | object | Progress information |

#### `message`

| Key | Type | Notes |
|---|---|---|
| step\_name | string | Processing step name |
| upload\_id | uuid | Upload session ID |
| is\_complete | boolean | Indicates whether the step is complete |
| total\_count | integer | Total number of items expected |
| progress\_count | integer | Number of processed items |
| timestamp | string | ISO 8601 timestamp |

## Errors

| Error | Response code / close status | Message |
|---|---|---|
| Incorrect WebSocket URL path | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_INCORRECT_URL", "detail":"Incorrect WebSocket URL."` |
| `upload_id` is invalid, already used, or expired | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_INVALID_UUID", "detail":"A valid UUID is required."` |
| Upload ID does not match or the requesting user is not the transaction creator | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_DOES_NOT_EXIST", "detail":"Not found."` |
| File type is not `application/zip` | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_UNSUPPORTED_FILE_TYPE", "detail":"File extension “{file_type}” is not allowed. Allowed extensions are: {allowed_types}."` |
| Missing or malformed payload | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_INVALID_PAYLOAD", "detail": "Required fields: type, temp_upload_id, file_name, file_size, file_type, object_class, class_field"` |
| File is too large | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_FILE_TOO_LARGE", "detail":"Max file size is {limit} GB."` |
| File is empty or has size less than or equal to 0 bytes | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_FILE_EMPTY", "detail":"File size must be larger than 0."` |
| `file_name`, `file_size`, or `file_type` is `null` | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_NULL_FIELD", "detail":"Field “{field}” may not be null."` |
| `file_name` or `file_type` is empty | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_NULL_FIELD", "detail":"Field “{field}” may not be empty."` |
| Unexpected server error during URL generation | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_SERVER_ERROR", "detail": "Upload could not be initialized. Please try again later."` |
| Unexpected S3 error during URL generation | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_GENERATION_ERROR", "detail": "Failed to generate presigned URL"` |
| Invalid `type` value in request | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_INVALID_TYPE", "detail": "Type “{type}” is not allowed. Allowed types are: [{allowed_types}]."` |
| Request message is JSON but not an expected dictionary/object | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_INVALID_TYPE", "detail": "Invalid message type. Expected a JSON object."` |
| Multipart upload finalization failed in S3 | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_S3_FINALIZE_FAILED", "detail": "Could not finalize multipart upload. Please try again later."` |
| Upload marked as complete before the file is available in S3 | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_FILE_INCOMPLETE", "detail": "Upload has not yet completed or file is not available."` |
| Error during the handshake | `500 Internal Server Error` | |

## Notes

WebSocket standard close/error definitions are described in [RFC 6455](https://datatracker.ietf.org/doc/html/rfc6455#section-7.4.1).

---

---
url: /api/catalyst/resources/files.md
---
# Files

Below API endpoints allow to upload and store files in ALX system.

Files technical design can be found in
[File uploads - Tech design](https://autologyx.sharepoint.com/:w:/s/Dev/Ea5Vh4nikwVKimrhQjqupFoB8e1rOS1Nz_7Tu48cY--Y6Q?e=LiIXXV)

## Permissions

| Permission | Manageable via Roles | Description                                                                                 |
|------------|----------------------|---------------------------------------------------------------------------------------------|
| store      | false                | Allows to store uploaded file in the public storage. Any authenticated user has it enabled. |
| list       | false                | Allows to list files in the public storage. Only Super Admin has it enabled.                |
| delete     | false                | Allows to delete files in the public storage. Only Super Admin has it enabled.              |

Permissions for `files` can be checked by:

| Context       | Endpoint                         | Location            | Available perms           |
|---------------|----------------------------------|---------------------|---------------------------|
| Global scope  | `GET /api/users/permissions/`    | `files`             | `store`, `list`, `delete` |
| Specific file | `GET /api/files/public-storage/` | `_meta.permissions` | `delete`                  |

## References

* [File uploads](https://autologyx.sharepoint.com/:w:/s/Dev/Ea5Vh4nikwVKimrhQjqupFoB8e1rOS1Nz_7Tu48cY--Y6Q?e=LiIXXV)

## POST /api/files/upload/

Uploads single file as temporary file to be used in other places in the ALX system.
Unique token is returned in a response, to identify file on backend side.
The token can be used for any compatible endpoint supporting uploaded files.

### Permissions

Requires `authentication`.

### Request

* Body parameters

Request's body contains binary data of uploaded file.

* Headers

```
Content-Disposition: attachment; filename=<filename>
Authorization: JWT access_token
```

* Schema

```json
POST /api/files/upload/

<binary data>
```

### Validations

#### Allowed File Extensions

```
    csv,
    doc,
    docx,
    dot,
    gif,
    jfif,
    jpe,
    jpeg,
    jpg,
    json,
    odf,
    ods,
    odt,
    pdf,
    png,
    pot,
    potx,
    ppa,
    pps,
    ppsx,
    ppt,
    pptx,
    pwz,
    rdf,
    rtf,
    rtx,
    text,
    txt,
    wiz,
    wsdl,
    xla,
    xlb,
    xlc,
    xlm,
    xls,
    xlsx,
    xlt,
    xlw,
    xml,
    xpdl,
    xsl
```

* Content-Disposition header:
  * filename is required
* Binary data:
  * cannot be empty
  * file extension should be allowed
  * max size 50 MB

### Response

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| token             | string   | Automatically generated by the backend. |

* Successful status `201 Created`
* Response body schema

```json
{
  "token": <string>
} 
```

### Errors

| Cause                                            | Response code    | Message                                                                                                        |
|--------------------------------------------------|------------------|----------------------------------------------------------------------------------------------------------------|
| Binary data is empty                             | 400 Bad Request  | "detail": \["Empty content."]                                                                                   |
| Missing Content-Disposition header with filename | 400 Bad Request  | "detail": \["Missing filename. Request should include a Content-Disposition header with a filename parameter."] |
| Not allowed file extension                       | 400 Bad Request  | "detail": \["File extension “\<extension>” is not allowed. Allowed extensions are: \<allowed\_extensions>."]   |
| Size of file is too big                          | 400 Bad Request  | "detail": \["Max file size is 50.0 MB."]                                                                        |
| Not authorized                                   | 401 Unauthorized |                                                                                                                |
| Timeout                                          | 504 Timeout      |                                                                                                                |

## POST /api/files/public-storage/

Permanently saves uploaded files in storage without time limit.

### Permissions

Requires `authentication` and `files.store` permission.

### Request

* Body parameters

| Key   | Type   | Notes       |
|-------|--------|-------------|
| token | string |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/files/public-storage/

{
  "token": <string>
} 
```

### Validations

* token
  * Max length: 36

### Restrictions

* Up to 10000 Public Files can be added, limit is configurable per build.

### Response

| Key               | Type     | Notes                                       |
|-------------------|----------|---------------------------------------------|
| uuid              | uuid     | Automatically generated by the backend.     |
| filename          | string   | Name of a file without extension.           |
| extension         | string   | File extension (contains dot), like ".jpg". |
| url               | url      | Link to file's content.                     |
| created\_at        | datetime |                                             |
| created\_by        | user     |                                             |
| \_meta.permissions | Object   | Object describing permissions.              |

* Successful status `201 Created`
* Response body schema

```json
{
  "uuid": <uuid>,
  "filename": <string>,
  "extension": <string>,
  "url": <url>,
  "created_at": <datetime>,
  "created_by": <user>,
  "_meta": {
    "permissions": {
      "delete": <bool>
    }
  }
} 
```

### Errors

| Cause                            | Response code    | Message                                                        |
|----------------------------------|------------------|----------------------------------------------------------------|
| "token" is missing               | 400 Bad Request  | "token": \["This field is required."]                           |
| "token" is empty string          | 400 Bad Request  | "token": \["This field may not be blank."]                      |
| "token" is null                  | 400 Bad Request  | "token": \["This field may not be null."]                       |
| "token" is not string            | 400 Bad Request  | "token": \["Not a valid string."]                               |
| File with "token" does not exist | 400 Bad Request  | "token": \["Invalid token {token}."]                            |
| Insufficient permissions         | 403 Forbidden    | "detail": "You do not have permission to perform this action." |

## GET /api/files/public-storage/

Returns list of files from public storage.

### Permissions

Requires `authentication` and `files.list` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/files/public-storage/
```

### Response

| Key               | Type  | Notes                                                                              |
|-------------------|-------|------------------------------------------------------------------------------------|
| limit             | int   |                                                                                    |
| offset            | int   |                                                                                    |
| total\_count       | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count    | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next              | url   | Next page URL (null if there is no next page)                                      |
| previous          | url   | Previous page URL (null if there is no previous page)                              |
| results           | Array | List of results. Described in the next table.                                      |

#### Response `results` array

| Key               | Type     | Notes                                       |
|-------------------|----------|---------------------------------------------|
| uuid              | uuid     |                                             |
| filename          | string   | Name of a file without extension.           |
| extension         | string   | File extension (contains dot), like ".jpg". |
| url               | url      | Link to file's content.                     |
| created\_at        | datetime |                                             |
| created\_by        | user     |                                             |
| modified\_at       | datetime |                                             |
| modified\_by       | user     |                                             |
| \_meta.labels      | Object   | Object containing labels for attributes.    |
| \_meta.permissions | Object   | Object describing permissions.              |

* Successful status `200 OK`
* Response body schema

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str>,
  "previous": <str>,
  "results": [
    {
      "uuid": <uuid>,
      "filename": <string>,
      "extension": <string>,
      "url": <url>,
      "created_at": <datetime>,
      "created_by": <user>,
      "_meta": {
        "permissions": {
            "delete": <bool>
        }
      }
    }
  ]
}
```

### Sorting

| Parameter  | Example                                         | Notes          |
|------------|-------------------------------------------------|----------------|
| filename   | /api/files/public-storage/?ordering=filename    | Ascending      |
| filename   | /api/files/public-storage/?ordering=-filename   | Descending (-) |
| created\_at | /api/files/public-storage/?ordering=created\_at  | Ascending      |
| created\_at | /api/files/public-storage/?ordering=-created\_at | Descending (-) |

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter  | Type     |
|------------|----------|
| filename   | string   |
| created\_at | datetime |
| created\_by | username |

### Errors

| Error                    | Response code   | Message                                                                             |
|--------------------------|-----------------|-------------------------------------------------------------------------------------|
| Wrong ordering value     | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."] |
| Insufficient permissions | 403 Forbidden   | "detail": "You do not have permission to perform this action."                      |

## DELETE /api/files/public-storage/`uuid`/

Deletes single file from public storage.

### Permissions

Requires `authentication` and `files.delete` permission.

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| uuid           | uuid    |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
DELETE /api/files/public-storage/`uuid`/
```

### Response

* Successful status `204 No Content`

### Errors

| Error                           | Response code | Message                                                        |
|---------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions        | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| File with "uuid" does not exist | 404 Not Found | "detail": "Not found."                                         |

## OPTIONS /api/files/public-storage/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/files/public-storage/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
  "list": {
    "columns": [
      {
        "alias": "uuid",
        "type": "uuid",
        "predicates": [],
        "sort_ok": false
      },     
      {
        "alias": "filename",
        "type": "string",
        "predicates": [
          "exact",
          "iexact",
          "contains",
          "icontains",
          "startswith",
          "istartswith",
          "endswith",
          "iendswith"
        ],
        "sort_ok": true
      },
      {
        "alias": "extension",
        "type": "string",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "url",
        "type": "url",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_at",
        "type": "datetime",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range"
        ],
        "sort_ok": true
      },
      {
        "alias": "created_by",
        "type": "user",
        "predicates": [
          "exact",
          "in"
        ],
        "sort_ok": false,
        "autocomplete": "/api/users/autocomplete/?text__icontains="
      }
    ]
  },
  "details": {
    "schema": [
      {
        "alias": "token",
        "type": "string",
        "required": true,
        "validators": [
          {
            "type": "max_length",
            "length": 36
          }
        ]
      }
    ]
  },
  "restrictions": {
    "limit_items": 10000
  }
} 
```

## GET /api/files/public-storage/`uuid`/

Download file from public storage.

### Permissions

No requires any `authentication` (is public).

### Request

* Headers

```
Content-Type: application/force-download
```

* Schema

```json
GET /api/files/public-storage/4fef1510-7b0b-46fd-84d4-7b933d3b6f72/
```

## GET /api/files/response/file/`uuid`/

Download file from task response attachment.

### Permissions

Requires `authentication` and `task.view` permission. For task related to given file.

### Request

* Headers

```
Content-Type: application/force-download
```

* Schema

```json
GET /api/files/response/file/4fef1510-7b0b-46fd-84d4-7b933d3b6f72/
```

## GET /api/object-records/`record_id`/files/`uuid`/

Download file from object record document field.

### Permissions

Requires `authentication` and `object-records.view` permission. For object record related to given file.

### Request

* Headers

```
Content-Type: application/force-download
```

* Schema

```json
GET /api/object-records/3/files/4fef1510-7b0b-46fd-84d4-7b933d3b6f72/
```

---

---
url: /api/event-history/resources/files.md
---
# Files

This page documents the file-handling endpoints in the Event History API microservice.

The Files API supports event workflows where a history event must reference a file stored in S3. Before an event with an associated file can be recorded, the file must first be uploaded through the Event History service flow using a presigned URL.

At a high level, the process is:

1. The Event History API generates a presigned S3 upload URL
2. The client uploads the file directly to S3 using that URL
3. The file is then referenced by a related history event record

The presigned URL is generated by the Event History API microservice using AWS credentials with access to the target object storage. The URL is exposed to the calling service and remains valid only for a limited period of time.

::: warning
This section documents technical and service-level Event History APIs and is intended for internal platform use and controlled engineering workflows. It should not be treated as part of the main general-purpose external Catalyst integration surface. This area is outside general support coverage, so please contact your Customer Success team if you need guidance.
:::

## API overview

This page covers the following endpoint:

* `GET /api/files/upload-url`

***

## GET /api/files/upload-url

Generates a presigned URL for uploading a file to S3.

The file key prefix is based on the client instance database name. See [Tenants](/api/event-history/resources/tenants) for the related tenant model. The client instance is identified through the `X-Client-Id` header, and a UUID v4 is generated for the file name.

### Permissions

Requires `authentication`.

### Request

#### Headers

```text
Request Method: GET
Content-Type: application/json
X-API-Key: API_KEY
X-Client-Id: client_id
```

### Response

#### Success

* Status: `200 OK`

| Key | Type | Notes |
|---|---|---|
| upload\_url | string | Presigned URL for uploading the file to S3 |
| file\_id | string | Unique file identifier |

#### Response example

```json
{
  "upload_url": "https://s3.eu-west-2.amazonaws.com/cluster-1-namespace-2/alx_demo/1a2b3c4d-5e6f-7g8h-9i0j-1k2l3m4n5o6p",
  "file_id": "1a2b3c4d-5e6f-7g8h-9i0j-1k2l3m4n5o6p"
}
```

### Errors

| Error | Response code | Message |
|---|---|---|
| Tenant not found | `400 Bad Request` | `"detail": "'{tenant}' tenant not found in database."` |
| Client ID header is missing | `400 Bad Request` | `"detail": "Unauthorized Client."` |
| Client from header does not match any tenant | `400 Bad Request` | `"detail": "Failed to connect to tenant db."` |
| Wrong API key | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |
| Missing authorization header | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |
| Any request method other than GET is used | `405 Method Not Allowed` | |

---

---
url: /knowledgebase/finding-your-way-around.md
---
# Finding your way around

This section is designed to help you get comfortable with the Autologyx platform interface and understand where to find the things you use most often.

It focuses on the parts of Catalyst that help users move around the system confidently, understand what they are looking at, and make practical use of the tools available to them in day-to-day work.

## What you will find in this section

### My Account

Learn about the personal settings and account information available to you, including what you can edit and how changes to your account may affect your experience in the platform.

* [My Account](/knowledgebase/finding-your-way-around/my-account/)

### UI and Navigation

Understand how key parts of the interface work, including list pages, filters, layouts, and navigation patterns used across the platform.

* [UI and Navigation](/knowledgebase/finding-your-way-around/ui-and-navigation/)

### Some things you might find useful

Explore supporting guidance that can help you understand the platform more quickly, including system areas, the UI, and the glossary.

* [Some things you might find useful](/knowledgebase/finding-your-way-around/some-things-you-might-find-useful/)

## Useful places to go next

If you are still getting oriented, these sections may also help:

* [Welcome / Introduction to Catalyst](/knowledgebase/welcome-introduction-to-catalyst/)
* [Getting Started](/knowledgebase/getting-started/)
* [Workspace](/knowledgebase/workspace/)
* [Using Help and Support](/knowledgebase/using-help-and-support/)

## Notes

::: info
This section is about **understanding how to move around** Catalyst and make sense of the interface, rather than configuring the platform.
:::

::: tip
If you are new to the platform, a good path is to start with **UI and Navigation**, then review **My Account**, and then explore the Workspace section once you are ready to begin working in the system.
:::

---

---
url: /knowledgebase/record-and-task-forms/formbuilder-components.md
---
# Formbuilder Components

This section introduces the main components used to build forms in Autologyx.

The Catalyst formbuilder gives builders the tools to design forms that are clear, structured, and effective for end users. These components control how information is laid out, how fields behave, and how users interact with Object Records and Tasks.

Use this section to understand the building blocks available in the formbuilder and how they can be configured to support the wider process, data model, and user experience.

## What you will find in this section

* [Overview of Formbuilder](/knowledgebase/record-and-task-forms/formbuilder-components/overview-of-formbuilder/)
* [Layout - Sections and Instructions](/knowledgebase/record-and-task-forms/formbuilder-components/layout---sections-and-instructions/)
* [Properties](/knowledgebase/record-and-task-forms/formbuilder-components/properties/)
* [Elements](/knowledgebase/record-and-task-forms/formbuilder-components/elements/)
* [Task Form Fields and how to configure them](/knowledgebase/record-and-task-forms/formbuilder-components/task-form-fields-and-how-to-configure-them/)

## Notes

::: info
This section is focused on the individual components and configuration areas within the formbuilder.
:::

::: tip
If you are new to this area, start with **Overview of Formbuilder** before moving on to layout, properties, and more specific component types.
:::

---

---
url: /knowledgebase/getting-started.md
---

# Getting Started

Welcome to **Getting Started**.

This section is designed to help different types of Autologyx users find the right starting point based on how they interact with the platform. Whether you are carrying out day-to-day work, administering the platform, or designing new applications and processes, the guides here will help you orient yourself and move quickly to the areas most relevant to your role.

## Who this section is for

**Getting Started is useful for:**

* users who are new to the Autologyx platform
* business users carrying out operational work
* platform administrators responsible for global setup and access
* analysts and process designers building new applications and workflows
* delivery teams supporting rollout and adoption

## Choose the path that best matches your role

### Performing Work

**This path is for** users whose main focus is carrying out work in the platform rather than configuring it.

It covers the day-to-day use of Autologyx, including creating and working with object records, managing tasks, handling documents, and setting personal preferences.

### Platform admin (Administrators)

**This path is for** users responsible for the administration of the platform.

It is aimed at people who need to maintain the global setup of the system, including users, roles, permissions, authentication, and outbound communications. In practice, this area is most relevant to Super Admin style users and those responsible for organisational governance of the platform.

### Building applications (Analysts)

**This path is for** analysts, solution designers, and others involved in building or extending applications in Autologyx.

It introduces the key components that typically go into an application, including required outcomes, data collection, integrations, people and permissions, communications, and documents. It also links to a practical checklist of the common setup work needed across applications.

* [Building applications (Analysts)](/knowledgebase/getting-started/building-applications-analysts/)

## Suggested starting points

**If you are not sure where to begin, use the following as a guide:**

* If you mainly work with records, tasks, and documents, start with **Performing Work**
* If you are responsible for users, permissions, or system-wide setup, start with **Platform admin (Administrators)**
* If you are designing processes or planning a new application, start with **Building applications (Analysts)**
* If your role is focused on implementation support or operational rollout, review **Performing work (Delivery)**

## Notes

::: info
This section is intended to help users get oriented quickly by role and responsibility, rather than by technical feature area alone.
:::

::: tip
If you are new to Autologyx, begin with the path that best matches your role, then use the linked section pages to drill into more detailed guidance.
:::

---

---
url: /knowledgebase/applied-ai/mcp-services/getting-started-with-mcp.md
---

# Getting started with MCP

MCP services allow approved AI assistants and agents to connect to Autologyx through governed tools.

This means an agent can do more than answer questions. Where the right tools and permissions are enabled, it can help users find records, review information, create tasks, generate documents, update structured data, and support work as it moves through an Autologyx process.

This page is a starting point for users who want to understand how to begin using MCP with Autologyx. You do not need to learn every MCP tool before using an MCP-enabled agent. In normal use, the agent can read the available MCP tool catalogue, understand what each tool is for, and choose the appropriate tool for the task.

## What you can use MCP for

Autologyx MCP services can support different types of agentic assistance.

**For operational work**, use [Autologyx MCP Work](/knowledgebase/applied-ai/mcp-services/mcp-work/). MCP Work allows approved agents to interact with live Autologyx records, tasks, documents, and processes.

**For configuration guidance and platform knowledge**, use [Autologyx MCP Customer Success](/knowledgebase/applied-ai/mcp-services/mcp-customer-success/). MCP Customer Success helps users understand Autologyx concepts, configuration patterns, and implementation guidance.

## Before you start

Before using an MCP-enabled agent with Autologyx, check that:

1. MCP services are enabled for your environment
2. the agent or AI assistant has been approved for use
3. the correct MCP service has been connected
4. the user or service account has the right permissions
5. the agent has only the tools it needs for the intended use case
6. any required human review steps have been agreed
7. audit and monitoring expectations are understood

MCP is powerful because agents can interact with real Autologyx data and workflows. Access should be granted deliberately and reviewed regularly.

## Using Autologyx with Claude CoWorker

Claude CoWorker can connect to Autologyx through a custom connector.

The exact labels in Claude may change over time, but the usual process is to add a custom connector, provide the Autologyx MCP endpoint, connect as a user, and then authorise access through Autologyx.

### Add the custom connector

In Claude Teams edition, an administrator can add the connector from the organisation settings.

1. Go to **Organisation settings**.
2. Open **Connectors**.
3. Click **Add**.
4. Choose **Web**.
5. Enter a connector name that users will recognise.
6. Enter the Autologyx MCP endpoint URL.
7. Open **Advanced settings**.
8. Set the client ID to `Claude`.
9. Leave the OAuth client secret blank unless your implementation requires one.
10. Use **Individual sign-in** as the connection method.
11. Click **Add**.

### Set connector permissions

After the connector has been created, open the new connector entry and set the tool permission restrictions to **No restrictions**.

This may sound broad, but it allows Autologyx to control access through MCP mappings, the user account, associated groups, and the normal Autologyx permission model. This gives finer-grained control through the Autologyx governance gateway, rather than relying only on the connector-level restriction settings in the agent client.

### Connect as a user

After the connector is available, a user can connect it to their Claude session.

1. Start a new chat session.
2. Click **Customise**.
3. Select the newly added connector.
4. Click **Connect**.

Claude redirects the user to Autologyx for authentication.

Enter your Autologyx credentials and click **Sign In & Authorize**.

After successful authentication, the browser tab closes or redirects back to Claude. The connector should then show as connected.

### Check the connection

Open a new Claude chat and ask a question about the newly connected Autologyx environment.

For example, you might ask the agent to describe what it can see in the connected system, find records, or explain the high-level data structure.

![Claude CoWorker chat showing a successful response after connecting to the Autologyx MCP endpoint](/knowledgebase/images/claude-cowork-connected-chat-example.png)

## Using Autologyx with OpenAI Web

OpenAI Web can connect to Autologyx by creating a new app that points to the Autologyx MCP endpoint.

The exact interface may change over time, but the general pattern is to create an app, provide the MCP server URL, configure OAuth, connect the app, authorise through Autologyx, and then test the connection in a new chat.

### Create the app

In ChatGPT, open the Apps settings area.

1. Open **Settings**.
2. Select **Apps**.
3. Click **Create app** or **Add more**, depending on the view.

### Add the Autologyx MCP endpoint

Create a new app for the Autologyx MCP endpoint.

1. Enter a clear app name.
2. Add a short description so users understand what the connection is for.
3. Select **Server URL** as the connection type.
4. Enter the Autologyx MCP endpoint URL.
5. Set **Authentication** to **OAuth**.
6. Open **Advanced OAuth settings**.
7. Set the OAuth client name or client ID to `Openai`.
8. Accept the default custom MCP server warning.
9. Click **Create**.

The new app appears as a draft app. Open it and click **Connect**.

### Authorise the connection

OpenAI Web displays a connection modal. Click **Sign in with Autologyx**.

A new tab opens for Autologyx authentication.

Enter your Autologyx credentials and click **Sign In & Authorize**.

After successful authentication, you are returned to OpenAI Web. The app should show that it is connected.

The app also appears under **Enabled apps**.

### Check the connection

Open a new chat and ask a question about the connected Autologyx environment.

For example, you might ask what the agent knows about the environment, what records are available, or what the connected Autologyx system is used for.

![OpenAI Web chat showing a successful response after connecting to the Autologyx MCP endpoint](/knowledgebase/images/openai-web-connected-chat-example.png)

## Connecting other MCP clients to Autologyx

Other MCP-compatible clients can also connect to Autologyx where the client supports the required transport and authentication pattern.

The exact steps depend on the client, but the setup usually follows the same pattern.

1. Create or add a new MCP server connection in the client.
2. Enter a clear name for the Autologyx connection.
3. Enter the Autologyx MCP endpoint URL.
4. Configure OAuth authentication.
5. Set the client ID or client name expected by the Autologyx MCP service.
6. Save or create the connection.
7. Connect as a user.
8. Authenticate through Autologyx.
9. Return to the client and confirm the connection is active.
10. Start a new agent session and test with a simple request.

The customer or implementation team should confirm the exact MCP endpoint URL, client ID, authentication settings, and permission model before connecting a new MCP client.

### Permissions for other clients

Where possible, avoid relying only on broad client-side restrictions to govern access.

Autologyx permissions, MCP mappings, user accounts, user groups, and governance gateway controls should be used to decide what the agent can see and do. This is especially important where the agent can use write tools, create tasks, update records, generate documents, or perform bulk actions.

### Testing a new MCP client

When connecting a new MCP client, start with a narrow test.

**Good first tests include:**

* asking the agent what tools are available
* asking the agent to describe the connected environment
* searching for a small number of records
* retrieving one known record
* testing a read-only operation before enabling write actions

Do not begin with bulk updates, document generation, or task creation until the connection, authentication, permissions, and audit logging have been checked.

## Co-pilot and autonomous use

MCP can support both co-pilot and autonomous patterns.

In a co-pilot pattern, the agent works alongside a user. The user asks for help, reviews the response, and may approve or direct the next action.

In an autonomous pattern, the agent may perform a defined set of actions without a user prompting every step. This can be useful for repeatable operational work, but it needs narrower permissions, stronger monitoring, and clear human review gates.

Some co-pilot style agents may ask users to confirm certain actions before continuing. Bulk updates and higher-impact changes are common examples. This confirmation behaviour is controlled by the agent or AI client, not by Autologyx MCP tools.

## Example MCP Work interaction

A user might ask an approved agent:

> Find new intake records that are missing key information and create follow-up tasks for the legal operations team.

Depending on its permissions, the agent might:

1. search for the relevant Object Class
2. search for matching Object Records
3. review record fields
4. identify missing information
5. create a Manual Task
6. assign the task to a user group

Each action is performed through an MCP tool and can be controlled by permissions and audit logging.

## Example MCP Customer Success interaction

A user might ask:

> Help me think through the right Object Class structure for a new legal intake process.

The agent can use Autologyx knowledge and documentation to explain configuration options, suggest design patterns, and help the user plan the solution.

This does not mean the agent is changing the Autologyx configuration. MCP Customer Success is intended to support understanding, design, and adoption.

## When to look at the tool reference

Most users do not need to study the tool catalogue in detail.

You may want to review the detailed tool pages if you are:

* designing an autonomous agent pattern
* deciding which tools an agent should be allowed to use
* reviewing the risk of write actions
* planning audit or monitoring controls
* troubleshooting agent behaviour
* building an advanced MCP workflow

For more detail, see [Available MCP Work tools](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/).

## Governance and review

MCP should be treated as an operational capability, not just a chat feature.

Before enabling an agent, consider:

* what the agent is allowed to see
* what the agent is allowed to change
* which tools it can use
* which users or service accounts it acts as
* whether actions require approval
* how tool calls are audited
* how errors are reviewed
* how access can be removed if needed

Start with a narrow, well-defined use case. Expand access only when there is a clear benefit and the governance model is understood.

## Important reminder about agentic AI

::: warning Important reminder
AI agents can make mistakes.

Even where tools, permissions, prompts, and workflows have been carefully designed, an agent may misunderstand a request, choose the wrong tool, rely on incomplete context, or produce an unexpected result.

Permissions, tool design, audit logging, validation, deterministic workflow checks, and human review can reduce risk, but they cannot remove it entirely.

Use human review where an agent action affects important decisions, external communications, sensitive data, record updates, document generation, or task completion.
:::

## Things to remember

1. MCP lets approved agents connect to Autologyx through governed tools.
2. Most users do not need to learn every tool before using an MCP-enabled agent.
3. MCP Work is for operational records, tasks, documents, and process interaction.
4. MCP Customer Success is for Autologyx knowledge, configuration guidance, and solution design support.
5. Claude CoWorker, OpenAI Web, and other MCP clients may each have slightly different connection flows.
6. Co-pilot patterns are usually the best starting point.
7. Autonomous patterns need narrower permissions and stronger governance.
8. Tool access should be limited to the tools and data the agent genuinely needs.
9. Audit logging and human review are essential for higher-risk actions.

---

---
url: >-
  /knowledgebase/finding-your-way-around/some-things-you-might-find-useful/glossary.md
---

# Glossary

---

---
url: /knowledgebase/release-notes/release-notes-1.10/groups-as-task-assignees.md
---

# Groups as Task assignees

Managing tasks across large teams shouldn't require an army of administrators. Our new **User Groups in Tasks** feature changes task management, replacing endless individual assignments with intelligent group-based automation. As people join or leave groups, their task assignments instantly adjust to match their roles. No more manual updates, no more missed assignments, just seamless task distribution that scales with your organisation.

## Assigning User Groups to tasks

The first place where you can assign User Groups to tasks is in the **Create Task panel**. Here, User Groups are now available alongside individual users in the same selection area. You can choose to assign **individual users, entire User Groups, or a combination of both** as task assignees.

![Groups in Tasks\_1.gif](../../../images2/zendesk_4483047253279_001_0e9249a7e420.gif)

When you select a User Group as a task assignee, **all members of that group are automatically assigned to the task**. If any changes occur within the group - such as users being added or removed - these changes are reflected in the task assignments without the need for manual intervention. Whether you’re managing a project with multiple teams or assigning tasks across departments, this functionality ensures that everyone required is automatically on board.

![Groups in Tasks\_2.gif](../../../images2/zendesk_4483047253279_002_14bcbc8faf9a.gif)

## Permissions and limits

**Permissions:** You can only select users and groups for which you have permission to list. This maintains the security and integrity of task assignments within your workflows.

**Limit:** By default, you can assign up to **10 User Groups** to a single task. All selected groups will appear as task assignees both in the task list and within the individual task details.

## Filtering tasks by User Groups

We've made **task filtering more flexible** by adding the ability to filter by User Groups. In addition to the existing "Tasks I'm Only an Assignee Of" filter (which works as before), you can now precisely search for tasks assigned to specific groups. This allows for more granular analysis of your tasks.

![Groups in Tasks\_4.gif](../../../images2/zendesk_4483047253279_003_94ee3ed782a3.gif)

## Summary

The introduction of User Groups to task management represents a significant leap forward in automating and streamlining task assignments. You can now assign entire departments with a single click, while automated group sync ensures task distribution updates as teams evolve. This approach to task management means instant updates and reduced administrative overhead.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.10/groups-in-class-permission-sets.md
---

# Groups in Class Permission Sets

**Managing permissions is now easier** with our latest update to Class Permission Sets. We know that handling permissions across multiple users can be a bit of a juggling act, but what if you could simplify the process?

Now, instead of assigning permissions to individual users one by one, you can assign entire User Groups with just a few clicks.

## Add a User Group to a Class Permission Set

**Adding a User Group to a class permission set is straightforward.** Start by navigating to your class permission set and opening the **Manage Assignees** panel. You’ll notice a refreshed UI, now divided into two tabs:

* **Users**
* **User Groups**

![Groups in Class Permission sets\_1.gif](../../../images2/zendesk_4485010905759_001_6a4b4265db97.gif)

**In the Users tab,** the process remains the same as before. Clicking the “+” button will take you to the **Add Assignees** panel, where you can select individual users. This functionality hasn’t changed, so you can continue managing user assignments as you always have.

![Groups in Class Permission sets\_2.gif](../../../images2/zendesk_4485010905759_002_6f0c29d19c16.gif)

**To add a User Group,** switch to the **User Groups** tab. Click the “+” button, and you’ll be taken to a panel that allows you to select User Groups. You’ll see only the groups for which you have view permissions, ensuring that you’re only managing the groups relevant to your role.

By default, you can assign up to 10 groups to each permission set. This allows you to scale your permission management according to your needs, ensuring that the right people always have the right access.

![Groups in Class Permission sets\_3.gif](../../../images2/zendesk_4485010905759_003_26668e78b473.gif)

## Manage assigned User Groups

**After adding a User Group,** it will appear as a standard tile within the **User Groups** tab. Here, you can easily manage the group’s permissions just as you would with individual users.

If you need to un-assign a User Group, simply click the “x” on the group’s tile and confirm the un-assignment. This removes the group from the Class Permission Set, and the associated permissions will be automatically revoked from all users in that group.

![Groups in Class Permission sets\_4.gif](../../../images2/zendesk_4485010905759_004_69086e3f2029.gif)

## Benefits

**With this new feature,** you have more control over who gets access to what, without the need for tedious manual updates. By linking permissions directly to User Groups, you can instantly adjust access for entire teams in just a few clicks.

For corporations with hundreds or thousands of users, this means cutting down hours of manual permission updates to mere minutes. Your security teams can now respond swiftly to organisational changes while maintaining robust access control - all through a streamlined, group-based permission system that scales with your company's growth.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.10/groups-in-user-type-class-fields.md
---

# Groups in User type Class fields

Managing user access and responsibilities across different areas of the system can often feel like trying to piece together a complex puzzle. Our new **User Type Class fields** feature simplifies this process, giving you the tools to define who can interact with what, and how, within your records. Whether you’re managing permissions, assigning tasks, or simply tracking who’s involved in what, this feature provides the flexibility and precision you need.

## What’s new

Now, when setting up a Class Field of the user type, you’re no longer limited to selecting individual users. You can also choose **User Groups**. This means greater efficiency and scalability, especially in large organisations where teams often work together as cohesive units.

When defining a User Type Class Field, you decide which users and User Groups are available for end-users to select. Importantly, you only see and select those users and groups for which you have list permissions. This ensures that configurations are secure and relevant, limiting access to only those with the proper clearance.

![Class field user\_1.gif](../../../images2/zendesk_4482862400543_001_b8c5da83e029.gif)

## Group interaction options

When you define a User Group in a Class Field, you need to decide how end users will interact with it:

* **Allow Syncing Group Members**: Selecting this option means that end users can choose the entire group as a single entity. The group’s members will be automatically synchronised whenever the group is utilised, ensuring that no one is left out.
* **Allow Selecting Individual Members**: With this option, end users can select specific members from the group, providing more granular control over who is involved.

You can enable one or both of these options, giving you the flexibility to design workflows that match your exact needs.

## Selection limits

To further refine how fields are used, you can set **Min and Max Users** selection limits. This feature defines the minimum and maximum number of users, including group members, that can be selected in a field. This is particularly useful for tasks that require a specific level of oversight or involvement.

You can also use **Min/Max Groups** selection to control how many User Groups can be selected within a record. For example, in a compliance audit, you might want to ensure that at least three different teams are involved, but no more than five to avoid overcrowding and ensure focused collaboration.

By default, the system allows up to 100 users or 10 User Groups to be defined as selection options in a User type Class field.

![Class field user\_2.gif](../../../images2/zendesk_4482862400543_002_db3ee7b1f49c.gif)

## Where the field can be applied

After configuring your User Type Class field, it can be applied in various parts of the system:

* **Object classes display forms**: including Card view, Create and edit view, and Summary view.
* **Standalone forms**.
* **Task templates**: for record update task types.

## Additional field behaviour options

Once you’ve added the User Type Class field to the chosen form builder, you have the option to further customise how this field behaves:

* **Required**: end-users must make a selection before they can save or proceed with the record.
* **Read-only**: the field can only be populated or modified via automation through Sequencer, preventing end-users from changing it manually. This is ideal in scenarios where user or group assignments are determined by predefined business logic and should not be altered.

![Class field user\_3.gif](../../../images2/zendesk_4482862400543_003_a11cf706aeb5.gif)

## Summary

The User Type Class fields feature is all about precision and control. It empowers you to define exactly how end users can interact with records. By incorporating both individual users and User Groups into your workflows, you can create a more flexible, efficient, and secure system.

Stay tuned to explore how these features can transform your daily operations - in our next article , we’ll dive deep into how end-users can interact with these fields when creating and editing records or managing tasks.

---

---
url: /knowledgebase/release-notes/release-notes-1.10/groups-in-user-type-fields.md
---

# Groups in User type fields

After configuring your User Type Class field, it’s time to explore how end-users can interact with these fields within records and tasks.

The User Type Class field is more than just a selection tool - it’s a dynamic, interactive element that adapts to the specific configurations you’ve set.

**How it operates across different scenarios**

## 1. Groups with syncing group members

If the Class field was configured with User Groups and the option to “Allow syncing group members”, end-users will see the available User Groups listed in the field.

Each group can be expanded to reveal its members, and there will be a toggle labelled "Sync group members."

![User type field\_1.gif](../../../images2/zendesk_4482979355551_001_2d582a704569.gif)

Selecting a group with this option means the entire group will be treated as a single entity. Whenever the field is utilised - whether for assigning permissions, tasks or simply tracking responsibilities - the group’s members are automatically synced and included in the action. This ensures that all group members are involved, making it ideal for scenarios like compliance reviews, where ensuring full team participation is critical.

When a group is chosen with the sync option, it will be marked with a special sync icon in the list. If the user decides to change their selection, they can simply return to the field and toggle off the sync option, removing the group from the field.

![User type field\_2.gif](../../../images2/zendesk_4482979355551_002_562604ff5eb0.gif)

## 2. Groups with selecting individual members

If the Class field was configured with the option to “Allow selecting individual members”, end-users interacting with the field will see the User Groups available for selection. However, instead of a sync option, they can pick specific members from within the group.

Each group will be displayed with a list of its members, and there will be a "Search for users" search bar to help quickly locate the desired individuals, which is particularly useful in large teams. Once a member is selected, they will appear with a checkmark in the list and be added to the main selection list in the field.

![User type field\_3.gif](../../../images2/zendesk_4482979355551_003_21636b504460.gif)

To remove a selected member, the user can simply click on their name either in the main list or within the group member list.

This setup is ideal for managing detailed financial audits where specific expertise is crucial. For instance, during a complex financial audit, you might need only a forensic accountant and a tax specialist from the finance department to examine intricate financial statements and tax compliance issues. By selecting individual members, you can ensure that only those with the requisite expertise are involved in the review, streamlining the process and enhancing the accuracy of the audit results.

## 3. Groups with both: sync and individual members selection

For Class fields that were set up with both “Allow syncing group members” and “Allow selecting individual members”, end-users get the best of both worlds. They can choose to sync an entire group or select individual members from that group.

Groups selected with the sync option will be indicated with a sync icon, while individually chosen members will be listed under their respective groups with checkmarks. This dual option is highly versatile, making it suitable for dynamic team setups, where certain projects might require the full participation of one group but only select members from another.

![User type field\_4.gif](../../../images2/zendesk_4482979355551_004_02b1776e7cdb.gif)

## 4. Combining individual users and groups

The most advanced configuration allows for selecting both individual users from outside of groups and User Groups, with options for syncing groups or selecting specific members. In this scenario, the field will display individual users alongside available User Groups, offering maximum flexibility.

End-users can choose to involve key individuals for direct responsibility while also engaging entire teams or specific team members as needed. This configuration is perfect for scenarios where both broad group involvement and specific individual expertise are needed. For example, in a legal review of a complex case, you might need to ensure that the entire legal team is notified while specifically selecting key attorneys who will be responsible for detailed parts of the review.

## Selection requirements and limits

Regardless of the configuration, it’s essential to remember that fields can also be set as required. This means that, depending on the Class field’s setup, end-users must make a selection - be it individual users, group members, or entire groups - before they can save or proceed with the record.

Additionally, if Minimum or Maximum user/group selections were defined, users will be guided to select within those constraints. If a minimum number of users or groups is required, the user must meet that threshold to create or edit the record. Conversely, if a maximum limit is set, the system will prevent the user from selecting more than the allowed number of options, ensuring compliance with predefined rules.

![User type field\_5.gif](../../../images2/zendesk_4482979355551_005_cb3da8c033e9.gif)

## Use in tasks

The flexibility of the User Type Class field extends beyond record creation and editing. It also seamlessly integrates with task management, particularly in record update tasks. If the User Type Class field is added to a task template, users assigned to complete these tasks will interact with the field in the same way they do within records. This consistency across records and tasks ensures that your workflows remain streamlined and intuitive, whether you’re managing data entries or overseeing task completion.

This feature's flexibility makes it applicable in any sector, from legal to finance, allowing organisations to tailor their processes with precision. This intelligent approach to user management scales effortlessly across your workflows, turning complex access patterns into simple, maintainable structures.

---

---
url: /api/catalyst/resources/platform-information/healthcheck.md
---
# Health Check

This technical design describes implementation and API for healthcheck.

# API

## GET /api/health/\<access\_token>/

### Permissions

Requires `access_token` in url. `access_token` if configured per namespace and can be adjusted in vault.

### Request

* URL parameters

| Key           | Type   | Notes                                        |
|---------------|--------|----------------------------------------------|
| format        | string | `json` value will format response into json. |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key         | Type     | Notes                                                                                      |
|-------------|----------|--------------------------------------------------------------------------------------------|
| cache       | string   | Status of given backend. `working` or exception error formatted. Nested data per resource. |
| celery      | string   | Status of given backend. `working` or exception error formatted. Nested data per resource  |
| cloud\_front | string   | Status of given backend. `working` or exception error formatted. Nested data per resource  |
| history     | string   | Status of given backend. `working` or exception error formatted. Nested data per resource  |
| postgres    | string   | Status of given backend. `working` or exception error formatted.                           |
| s3          | string   | Status of given backend. `working` or exception error formatted.                           |
| rabbit      | string   | Status of given backend. `working` or exception error formatted.                           |
| redis2      | string   | Status of given backend. `working` or exception error formatted.                           |
| redis       | string   | Status of given backend. `working` or exception error formatted.                           |
| vault       | string   | Status of given backend. `working` or exception error formatted.                           |
| websocket   | string   | Status of given backend. `working` or exception error formatted.                           |

* Successful status `200 OK`
* Response body schema:

```json
{
    "cache": {
        "data": {"status": "working", "response_time": "0.1"},
        "pages": {"status": "working", "response_time": "0.1"},
        "task_lock": {"status": "working", "response_time": "0.1"},
        "task_queue": {"status": "working", "response_time": "0.1"}
    },
    "celery": {
        "ping": {"status": "working", "response_time": "0.1"},
        "queues.high_priority": {"status": "working", "response_time": "0.1"},
        "queues.medium_priority": {"status": "working", "response_time": "0.1"},
        "queues.low_priority": {"status": "working", "response_time": "0.1"},
    },
    "cloud_front": {
        "custom_component": {"status": "working", "response_time": "0.1"}
    },
    "history": {
        "clickhouse": {"status": "working", "response_time": "0.1"}",
        "e2e": {"status": "working", "response_time": "0.1"}",
        "event_bridge.api_destination": {"status": "working", "response_time": "0.1"},
        "event_bridge.connection": {"status": "working", "response_time": "0.1"},
        "event_bridge.credentials": {"status": "working", "response_time": "0.1",
        "event_bridge.rule": {"status": "working", "response_time": "0.1",
        "api": {"status": "working", "response_time": "0.1",
        "files:": {"status": "working", "response_time": "0.1"
    },
    "s3": {
        "custom_component": {"status": "working", "response_time": "0.1"
    },
    "postgres": {"status": "working", "response_time": "0.1",
    "rabbit": {"status": "working", "response_time": "0.1",
    "redis2": {"status": "working", "response_time": "0.1",
    "redis": {"status": "working", "response_time": "0.1",
    "vault": {"status": "working", "response_time": "0.1",
    "websocket": {"status": "working", "response_time": "0.1"
}
```

Where `response_time` is in seconds.

### Errors

| Error                                  | Response code          | Message                               |
|----------------------------------------|------------------------|---------------------------------------|
| Wrong `format` query string parameter  | 404 Not Found          | "detail": "Not found."                |
| Missing `access_token`                 | 404 Not Found          |                                       |
| Wrong `access_token`                   | 405 Method Not Allowed | "detail": Method "GET" not allowed. |

---

---
url: /helps.md
---

# Helps

Welcome to the Helps!

You can use the sidebar on left hand side to navigate between pages.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.11/hierarchical-records-creation-endpoints.md
---

# Hierarchical records creation endpoints

Building complex data hierarchies no longer requires juggling multiple API calls or meticulously tracking relationships. Legal and financial systems inherently rely on complex data hierarchies - law firms manage cases with multiple clients, each tied to contracts, documents, and payments, while banks process loan applications linked to applicants, co-applicants, and verification records.

Previously, constructing these relationships required step-by-step API calls, increasing the risk of errors and inefficiencies. Now, with our new hierarchical record creation endpoint, you can build entire parent-child structures in a **single request**, ensuring data consistency, streamlining operations, and significantly reducing processing time:

`POST /api/object-models/{model_id}/object-records/descendants/`

## Request details

The request body defines a hierarchical structure where each record has an `object_class`, associated fields, and optional children:

```
{  
"object_class": <int>,  
"field_<field_alias>": <any_allowed>,  
"...": "...",  
"children": [  
  {  
   "object_class": <int>,  
   "field_<field_alias>": <any_allowed>,  
   "...": "...",  
   "children": [  
    {  
     "object_class": <int>,  
     "field_<field_alias>": <any_allowed>,  
     "...": "...",  
     "children": []  
    }  
   ]  
 },  
 {  
 "object_class": <int>,  
 "field_<field_alias>": <any_allowed>,  
  "...": "...",  
  "children": []  
  }  
 ]  
}
```

The `field_<field_alias>` fields are optional - they depend on the object class configuration and represent class fields.

Nested `children` arrays define parent-child relationships.

**You can create multiple levels of hierarchy** in a single request.

## Response and processing

When you submit the request, it is processed asynchronously, and you receive an immediate response:

```
{
  "id": 12345,
  "status": "queued",
  "url": "https://{domain}/api/object-models/{model_id}/object-records/transactions/12345/"
}
```

**Response fields:**

* `id` - unique identifier for the transaction.
* `status` - initially set to `queued`, indicating the request is being processed.
* `url` - provides a link to check the transaction status.

To check the processing status, send a request to:

`GET /api/object-models/{model_id}/object-records/transactions/{transaction_id}/`

**Possible statuses:**

* `queued` - the request is waiting to be processed.
* `processing` - the records and relationships are being created.
* `completed` - all records have been successfully created.
* `failed` - validation errors occurred, and records were not created.

**Example response:**

```
{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "status": "processing"
}
```

## Validation and ownership

If the request fails, it will return `failed` status. **Common reasons include:**

* Standard validation errors for creating object records.
* Relationship validation issues between parent and child records.
* Incorrect field values or missing required fields.

**No records will be created if validation fails.**

The user who submits the request becomes the owner of all created records.

## History events

Standard history events are logged:

* `owner_initialized` - Ownership assigned.
* `record_created` - Records successfully created.

The world of complex data structures just got much simpler. Legal cases with intricate client documentation trees, financial applications with multi-layered verifications, and healthcare records with branching patient histories - all can now materialise through a single API call.

---

---
url: >-
  /knowledgebase/administration/communication/how-do-i-configure-single-sign-on-for-users.md
---

# How do I configure single sign-on for users?

Single sign-on (SSO) means users do not need a separate username and password for Catalyst. Users can sign in using their organisation's SSO credentials on any device or supported web browser, while helping your organisation manage access securely.

This article describes how to set up single sign-on in Microsoft Azure using OpenID Connect.

## Access and prerequisites

Single sign-on settings in Catalyst can be found under **Administration** in the main menu.

Only the following users have access to this page:

* users with a Super admin account type;
* users with a Role where the create and edit permissions for single sign-on have been enabled on the **Administration** tab.

![docs](/knowledgebase/images/administration/sso1.png)

You will also need access to your Microsoft Azure domain administration area. This is usually managed by IT, so you may need help from someone in that team.

## Create the single sign-on configuration in Catalyst

In Catalyst, go to **Administration** > **Single sign-on settings**.

The list page will be blank when single sign-on has not been configured.

![docs](/knowledgebase/images/administration/sso2.png)

Click **+ Create** to get started.

Microsoft Azure OpenID Connect is currently the default and only provider available. All fields are mandatory.

The **Tenant ID**, **Client ID**, and **Client secret** can only be obtained from your Microsoft Azure admin account. You will return to these fields after creating the Azure application registration.

![docs](/knowledgebase/images/administration/sso3.png)

### Additional settings

There are two settings at the bottom of the page. Both are disabled by default:

* **Enable Catalyst login support**: enable this to allow users to log in via single sign-on.
* **Enable Catalyst Word add-in support**: enable this if you also want to support the Catalyst Word add-in. See [MS Word Add-in - configuration](/knowledgebase/system-configuration/working-with-document-templates/ms-word-add-in---configuration/) for more information.

The permissions required for Catalyst login support and Word add-in support are different. You can use one Azure registration for both user single sign-on and the Word Add-in, but separate registrations may be easier to manage and give you more flexibility.

In the **Internal user access** section, the **Automatically create user** option allows users who do not already have an account in Catalyst to be created the first time they use single sign-on.

Users created in this way are given an Internal user account type.

## Create the Azure application registration

To populate the **Tenant ID** and **Client ID** fields, you need to create a registration entry on your Azure tenancy.

In Microsoft Azure, go to **Enterprise applications** and click **+ New application**.

![docs](/knowledgebase/images/administration/sso4.png)

The page may show pre-existing third-party applications.

![docs](/knowledgebase/images/administration/sso5.png)

You will not use these applications. Instead, create your own new application.

![docs](/knowledgebase/images/administration/sso6.png)

Click **Create your own application**.

![docs](/knowledgebase/images/administration/sso7.png)

Give the application a name, leave the setting as defaulted, and click **Create**.

![docs](/knowledgebase/images/administration/sso8.png)

Creation of the application in the directory can take a few seconds. When it is done, you are taken to the **Overview** page.

From here, click **Properties** in the left-hand menu.

![docs](/knowledgebase/images/administration/sso9.png)

On the properties page, click the **application registration** link.

![docs](/knowledgebase/images/administration/sso10.png)

## Copy the Tenant ID and Client ID

From the application registration page, click **Overview** in the left-hand menu.

This page gives you the **Tenant ID** and **Client ID**, which should be copied and pasted into the appropriate fields in your Catalyst single sign-on configuration.

![docs](/knowledgebase/images/administration/sso11.png)

![docs](/knowledgebase/images/administration/sso12.png)

## Create and copy the Client secret

The next piece of information needed is the **Client secret**.

Return to the Azure application properties page and click **Certificates & secrets** in the left-hand menu.

![docs](/knowledgebase/images/administration/sso13.png)

On the **Certificates & secrets** page, click **+ New client secret**.

![docs](/knowledgebase/images/administration/sso14.png)

Give the secret a description and select an expiry period.

Make sure the expiry date is recorded in whichever system you use to track configuration credentials. A new secret must be entered into Catalyst before this one expires.

![docs](/knowledgebase/images/administration/sso15.png)

Click **Add**.

You will then see an entry for your new client secret. You have a short time to copy the secret value and paste it into the **Client secret** field in Catalyst. The secret value is removed from the Azure page automatically.

![docs](/knowledgebase/images/administration/sso16.png)

Paste the secret into the **Client secret** field in the single sign-on configuration in Catalyst and click **Save**. The client secret is saved into a secure vault.

You are taken back to the single sign-on listing page. Like all list pages, this page can be configured to show different column headers and filtered to show relevant listings.

If the single sign-on configuration has been enabled, the **Enabled** column shows a green tick. If **Auto user creation** has been enabled, that column also shows a green tick.

![docs](/knowledgebase/images/administration/sso17.png)

## Add the Redirect URI and Logout URL in Azure

Edit the Catalyst single sign-on configuration to get the final information you need to add to Azure.

Catalyst generates URL values in the background. These URLs must be added to the Azure application so that Azure knows where to send callbacks for users who have been successfully authenticated.

In edit mode, the **Client secret** has been replaced with asterisks and will be removed if any user tries to edit that field.

The **Redirect / Callback URI** and **Logout URL** fields have also been created and populated with the required URLs. These are read only fields.

![docs](/knowledgebase/images/administration/sso18.png)

Copy these URLs.

In your Azure application, click **Authentication** in the left-hand menu.

![docs](/knowledgebase/images/administration/sso19.png)

On the **Authentication** page, click **+ Add a platform**.

![docs](/knowledgebase/images/administration/sso20.png)

The **Configure platforms** options are shown on the right-hand side of the page. Click **Web**.

![docs](/knowledgebase/images/administration/sso21.png)

Paste the **Redirect / Callback URI** from Catalyst into the **Redirect URIs** field.

![docs](/knowledgebase/images/administration/sso22.png)

In the **Front-channel logout URL** field, enter the **Logout URL** from Catalyst.

![docs](/knowledgebase/images/administration/sso23.png)

Untick **ID tokens (used for implicit and hybrid flows)**.

Click **Save**.

The following page is displayed.

![docs](/knowledgebase/images/administration/sso24.png)

Click **Disable**. You are taken back to the **Authentication** page showing the Front-channel logout URL.

## Configure Azure API permissions

Finally, you need to give the application in Azure permissions to access users' details so that Catalyst can authenticate them.

Click **API permissions** in the left-hand menu. Then click **+ Add a permission**.

![docs](/knowledgebase/images/administration/sso25.png)

The API permission options are displayed on the right-hand side. Click **Microsoft Graph**.

![docs](/knowledgebase/images/administration/sso26.png)

You will see two options on the next display:

* **Delegated permissions**
* **Application permissions**

You only need **Delegated permissions**. Click this option to open the permissions.

Tick **email** and **profile**.

![docs](/knowledgebase/images/administration/sso27.png)

Then enter **User** in the search field under **Select permissions**.

Expand the possible **User** permissions and tick **User.Read** and **User.Read.All**.

![docs](/knowledgebase/images/administration/sso28.png)

Click **Add permissions**.

Back in the centre of the **API permissions** page, you need to grant access for the **User.Read.All** permission. You can see from the screenshot below that there is an error message informing you that this permission has not been granted. This permission needs an extra step because it has a significant capability and must be confirmed.

![docs](/knowledgebase/images/administration/sso29.png)

Click **Grant admin consent for Autologyx LTD**.

Click **Yes** on the admin consent confirmation.

![docs](/knowledgebase/images/administration/sso30.png)

The permission is granted and the status changes accordingly.

![docs](/knowledgebase/images/administration/sso31.png)

## Complete the configuration

The Azure and Catalyst configuration is now complete.

When enabled, the name given for the configuration appears in the **Single sign-on** list on the Catalyst system login page.

![docs](/knowledgebase/images/administration/sso32.png)

If single sign-on has not been configured and enabled, the login page does not show this option. Users must log in with a username and password.

![docs](/knowledgebase/images/administration/sso33.png)

## Useful info

1. The maximum number of single sign-on configurations for your system is 25.
2. The name used to replace **Unnamed configuration** must be unique.
3. See [What happens when an individual uses single sign-on?](/knowledgebase/administration/all-about-users/what-happens-when-an-individual-uses-single-sign-on/) for information about the user login experience.

---

---
url: >-
  /knowledgebase/administration/communication/how-do-i-configure-user-activation-rules.md
---

# How do I configure user activation rules?

To configure user activation rules, it is useful to understand the user experience first, so this is where we are starting.

## User activation experience

When a new user has been created with a full account, the user will receive an activation email like the one shown below:

![Screenshot 2023-09-05 at 19.49.22.png](../../../images2/zendesk_4402906557329_001_6c41aff7ec51.png)

This email will contain an activation link. It will also let the user know how long this link will be active.

When clicked, the user will be taken to the "Activate your user account" page. The user will need to provide a password. The user will not be able to access their instance until they have completed all fields and the Activate button is enabled.

The Activate your user account page looks like this:

![Screenshot 2023-09-05 at 19.58.47.png](../../../images2/zendesk_4402906557329_002_d066f0925e24.png)

You will note that the user's email address is not shown in full. We do this for security reasons in case our email has been opened by someone other than the intended recipient.

The password rules are clearly shown and, as the user fulfils each requirement, the symbol on that requirement changes from an X to a ✔ and changes colour from grey to green.

![Screenshot 2023-09-05 at 20.08.45.png](../../../images2/zendesk_4402906557329_003_dd532a002723.png)

When the account is successfully activated, the user will be taken to the Autologyx landing page.

## Configure the activation rules

**To set the activation rules, go to the Standard authentication page under Administration in the main navigation menu.**

Here you can:

* **Set** the number of days for which the activation link in the email will be active.
  * The minimum is one day and the maximum is 30 days.
  * This feature can be set to "Off", which means that the link will only become inactive once the user account has been created.
* **Set** the Password Rules.
* **Select** the minimum characters a user login password must contain.
* **Set** the number of days after which a user will be asked to change their password.
* **Choose** to prevent password re-use.

![Screenshot 2023-09-05 at 19.41.43.png](../../../images2/zendesk_4402906557329_004_1dc9c43ceb0a.png)

## Notes

**The rules set here are applied globally across the system.** However, if you are editing the password complexity rules, they will only be applied to new activations and password changes. They will not be enforced for active passwords.

**Changes to the Rotation interval and Prevent password re-use settings will take immediate effect for all users.**

It is worth checking with your IT department about the company policy for user login password rules and security to ensure that you are maintaining the expected standards.

---

---
url: /knowledgebase/administration/roles-and-permissions/how-do-i-create-a-role.md
---

# How do I create a role?

Roles allow you to control which areas of **Administration** and **System configuration** a user can access. They are assigned only to users with the Config Admin account type.

To create a new role, go to:

**Administration** > **Roles**

The Roles list will open.

## Create a role

Click **+ Create** in the top-left corner of the page.

The **Role name** field is mandatory and initially displays **Unnamed role** as a placeholder. Every role must have a unique name.

![Create role page showing the mandatory Role name field](/knowledgebase/images/administration/how-do-i-create-a-role-1.png)

The **Description** field is optional but recommended. It allows you to describe the purpose of the role, making it easier to distinguish between similar roles.

Both the Role name and Description are displayed in the Roles list.

![Role name and Description fields on the Create role page](/knowledgebase/images/administration/how-do-i-create-a-role-2.png)

## Configure system permissions

The **System permissions** section controls which administrative areas users assigned this role can access.

Permissions are grouped into the main areas of Catalyst.

### Sequencer

Controls whether users can create, edit, or delete Sequences.

### Task configuration

Separate permissions are available for:

* Task Templates
* Task Group Templates

Each includes **Create** and **Edit** permissions.

### Data model

Controls the ability to create, edit, and delete Object Classes.

### Administration

Administration permissions are divided into several areas.

For single-page settings, such as **Company Details** and **Standard Authentication**, only an **Edit** permission is available.

When enabled, users can:

* see the page in the navigation menu
* open the page
* edit its settings

If disabled, the page is hidden and cannot be accessed.

![Administration permissions available when creating a role](/knowledgebase/images/administration/how-do-i-create-a-role-3.png)

Other Administration areas, such as Authentication Objects and Single Sign-on Settings, support multiple items and therefore include **Create**, **Edit**, and **Delete** permissions.

**User Groups** are slightly different. Only the **Create** permission is available because the user who creates a User Group automatically becomes one of its Owners. Ownership then determines who can edit or delete that User Group.

Role permissions control access to administration features only. Permissions for working with Object Classes and Object Records are configured separately using Object Class and Record Permission Sets.

All permissions are **disabled by default**.

## Understanding permission behaviour

### Create and Edit

Enabling **Create** automatically enables **Edit**.

Users will then be able to:

* access the area from the navigation menu
* view existing items
* create new items
* edit existing items

### Delete

The **Delete** permission can be enabled independently.

Users with Delete permission can:

* access the list page
* delete existing items

### Create disabled

If **Create** is disabled but **Edit** remains enabled:

* the **+ Create** button is hidden
* existing items can still be edited

![Role without Create permission showing no Create button](/knowledgebase/images/administration/how-do-i-create-a-role-4.png)

### Create and Edit disabled

If both **Create** and **Edit** are disabled:

* the navigation item is removed unless Delete is enabled
* users cannot access that area

![Role with Create and Edit disabled](/knowledgebase/images/administration/how-do-i-create-a-role-5.png)

![Navigation menu with hidden administration area](/knowledgebase/images/administration/how-do-i-create-a-role-6.png)

![Administration list unavailable without permissions](/knowledgebase/images/administration/how-do-i-create-a-role-7.png)

![Example of restricted access when permissions are removed](/knowledgebase/images/administration/how-do-i-create-a-role-8.png)

## Things to remember

1. If a user has multiple Roles, Catalyst grants the most permissive combination of permissions.
2. Users can delete Task Templates only when those templates have no responses associated with them.
3. Up to **5,000 Roles** can be created in a system. Once this limit is reached, the **+ Create** button is disabled.
4. Users with the Super Admin account type automatically have all of these permissions and do not require Roles.

---

---
url: >-
  /knowledgebase/system-configuration/task-group-templates/how-do-i-create-a-task-group-template.md
---

# How do I create a task group template?

## Prerequisites

In order to create a Task group template you must have one of the following:

* A Super admin account
* Be the Owner of an Object class
* A Role where the system permissions under the Task configuration tab for Task Group Templates have been enabled for create and a Permission set which allows you to View the Object class

And:

* The Object class(es) configured for which you are to create the Task group template
* The Tasks configured which you will add to the Task group template

## Create a task group template

Task group templates can be created from the Task group template list. Click the **+ Create** button and the page will display as below:

![create\_tgt.jpg](/knowledgebase/images/img_4402907146897_1776895981.jpg)

### Complete the basic details

The Task group template must be given a **Name** as this is a mandatory field. The name must be unique.

Next is the optional **Description** field. Here you can add internal notes about the Task group template, for example to describe in what instance it is used to create Tasks.

### Select the applicable object class

The user must then select the Object class(es) for which this template can be used.

**Applicable to object classes** is a searchable multi-select field. When no Object class has been chosen, all Task templates of the Update object records type are filtered out of the Task template selection field. The same thing will happen if more than one Object class is selected.

If you intend to include a Task of the Update object records type, you should select only the Object class to which the fields in this task belong. In this instance, once the Object class has been selected, Task templates of the Update object records type for any other Object class will not be available for selection and you will not be able to add another Object class when you have selected a Task template of this type. At least one Object class must be selected as this is a mandatory field.

### Select task templates

The Task templates available will be filtered only to those for which the **Task creation mechanism** is **Automatic**. One or multiple Task templates can be added by selecting them and then using the left to right arrow. However, bear in mind that if you are creating the Task group template for more than one Object class, you will not be able to include Task templates of the Update records type.

![mceclip1.png](/knowledgebase/images/img_4402907146897_1776895982.png)

![mceclip2.png](/knowledgebase/images/img_4402907146897_1776895982.png)

If you are in the process of configuring the Task group template for one specific Object class and you have included tasks of the Update object records type, then remove the Object class, the Update object record type tasks will be removed automatically.

### Save the template

Having selected the required Task templates, click **Save**. The Save button will only be enabled when all mandatory fields have been populated.

![mceclip3.png](/knowledgebase/images/img_4402907146897_1776895982.png)

Unless you have applied filtering or sorting to your Task group template list, the newly created template will appear at the top of the list.

On Save, the green success toast message will appear on-screen to confirm.

|  |  |
| --- | --- |
| Next to the Save button in the top right hand corner is the Cancel button. This can be used to abort the creation of the template. The **Unsaved changes will be lost** warning will be displayed.  If you confirm **Yes**, you will be taken back to the Task group template list.  If you select **x No, go back** the create page will remain open so that you can continue. | mceclip0.png  You will also see this warning if you navigate away from the page. |

## Useful info

1. You can have up to 10,000 Task group templates in your system.

---

---
url: >-
  /knowledgebase/system-configuration/task-templates/how-do-i-create-a-task-template.md
---

# How do I create a task template?

To create a Task template, you will need one of the following:

* A Super admin account type
* For Task templates of the **Complete self contained form** type: a Role where the permission for Task Templates Create has been enabled under the Task configuration tab
* For Task templates of the **Update object record** type: a Role where the permission for Task Templates Create has been enabled under the Task configuration tab **and** you are the Owner of the Object class

Tasks are created from Task templates. You can think of these as the blueprint for what needs to be done in the Task.

You will find Task templates in the left hand menu under System configuration. This takes you to the Task templates list.

From here, click the **+ Create** button to start building a new Task template.

## Basic details

You need to give your Task template a name. This is a required field and it must be given a unique value. If you keep it fairly generic, you will be able to use the same Task template for more than one Object class.

There is also an optional field where you can add a **Description**. This can be useful if you have a number of Task templates with similar names, or where one person is responsible for the creation of Task templates but another deals with maintenance and upkeep.

![mceclip2.png](/knowledgebase/images/img_4402907130897_1776895916.png)

You'll notice that the template is divided into the following **3 sections** or tabs:

* **Response configuration**
* **Lifecycle**
* **Stages**

## Response configuration

This area allows you to define the requirements of the task response.

In the **Task Definition** section, you must select the **Task type**. Each of the task types available has dedicated articles which can be found here:

```json
[Task Type - Complete self-contained form](/knowledgebase/system-configuration/task-templates/response-configuration---task-type---complete-self-contained-form/)
```

[Task type - Update object record](/knowledgebase/system-configuration/task-templates/response-configuration---task-type---update-object-record/)

Having selected the Task type, you must then select the **Task creation mechanism**. There are two choices:

* **Automatic** - for Tasks designed to be used in a Sequence. These Tasks will be created for Records in a specific Object class at a particular point in the workflow.
* **Manual** - for Tasks which can be created for Records on an ad hoc basis from the Tasks panel.

## Lifecycle

This area allows you to define whether the task:

* is completed only once, or if it is a Task which will expire
* has an SLA for its completion

![mceclip3.png](/knowledgebase/images/img_4402907130897_1776895916.png)

|  |  |
| --- | --- |
| For either Lifecycle option you can set a Due Date. Your choices are:   - No due date - the task should be completed ASAP - Date - you will be prompted to select a specific date by which the task should be completed - Time frame - here you can select a number of days/weeks/months after the Task is created by which it should be completed | mceclip0.png |

The **Due Date** is important in determining the **Status** of a Task. When a Task is created it is **Outstanding**. Once it has gone beyond its Due Date without being Completed, its Status will change to **Overdue**.

If you choose the Lifecycle option **This is a task that should expire**, a new menu item called **Expiry rules** will be added to the Lifecycle tab.

|  |  |
| --- | --- |
| When you click on this, a new Section called **Task Expiry** is displayed.  Here you must configure the expiry date for the Task. There are 4 options as follows: | mceclip2.png |

|  |  |
| --- | --- |
| **After a time frame has elapsed** - here you can select a number of days/weeks/months after completion of the Task. | mceclip3.png |
| **A specific date** - this must be a date in the future! | mceclip4.png |
| **Monthly** - you will be prompted to select a day of the month for the expiry. Note that if the 31st is chosen the default will become the last day of the month. | mceclip5.png |
| **Annually** - you will be prompted to select a day of the year. | mceclip6.png |

If a Task expires, it will still be completed.

## Stages

For now, we have one completion stage for the Task.

If the Task is **Automatic**, the User or Users responsible for completing the Task will be determined in the Sequence setup. For Manual Tasks, Users who may complete the Task are defined at the time of Task creation.

In a future version of Catalyst, the stages section will allow the user to determine whether the task will simply need to be completed or if it requires an approval step. Further, you will be able to define approval conditions. Beyond this we plan to add the ability to define more than one completion stage so that multiple Users will be able to input towards the Task response prior to approval by another.

Each stage can be assigned to an individual user or multiple users. In future, you will be able to select a User group in order that multiple Users can be selected in one action.

### Who can complete a Task?

In order to complete a Task you must have one of the following:

* A Super admin account type
* Be an Owner of the Object class
* An Object Class Permission set which allows you to Complete all tasks
* Be an Assignee of the specific Task

## Useful info

1. The maximum number of Task templates you can have in your system is 10,000.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.13/how-do-i-create-a-test-user-account.md
---

# How do I create a test user account?

This article explains how to create test user accounts in Catalyst.

## Microsite 365 plus addressing

**Plus addressing** is enabled in Microsoft 365. This means you can create an unlimited number of test email addresses that all deliver to your own inbox. There is no setup required.

**When creating an account in Catalyst**, simply use the correct format for your email address, for example:

```json
[firstname.lastname+anything@yourdomain.com](mailto:firstname.lastname+anything@yourdomain.com)
```

<initiallastname+anything@yourdomain.co.uk>

or whatever is appropriate.

**Examples**

* anjie.matthews+juniortestuser@autologyx.com
* amatthews+seniortestuser@autologyx.com

**All emails** sent to these addresses will arrive in your normal inbox.

## Alternative mailbox providers

Most mailbox providers have plus addressing enabled by default, so clients can usually use the same approach when testing.

Alternatively, we recommend clients use a secure alternative such as MailSlurp.

If you encounter any scenarios where you’re unable to complete testing using this method, get in touch with your usual Autologyx contact and we’ll look at alternatives with you.

[View general information on how to create a user account.](/knowledgebase/administration/all-about-users/how-do-i-create-a-user-account/)

---

---
url: >-
  /knowledgebase/administration/all-about-users/how-do-i-create-a-user-account.md
---

# How do I create a user account?

If you have a Super Admin account type, you can manually create user accounts for other individuals.

Go to:

**Administration** > **Users**

Clicking **Users** opens the Users list.

At the top of the page, click **+ Create** to open the Create user page.

The first thing you need to decide is which account type the user needs. **User account type** is mandatory, as shown by the red asterisk.

![Create user page showing the mandatory User account type field](/knowledgebase/images/administration/how-do-i-user-acc-1.png)

## User account types

### 1-time completion

Users with this account type do not log in.

They can complete tasks from links in email notifications sent to them after task assignment.

This account type is suitable for users who are rarely asked to complete a task and do not need to interact with records.

Once created, the status of this user account immediately becomes **Active**.

### Internal

Internal users are part of your own organisation.

They usually work with records and tasks and may be members of one or more User groups. They may also be given Object class and/or record permissions.

Users created through Single sign-on are always given an Internal account type.

### External

External users are individuals outside your organisation, such as clients, suppliers, or other third parties.

They may need record permissions to access a defined set of records, or they may have no record permissions and only access tasks assigned to them.

### Service Internal

Service Internal accounts are designed for integrations and automated Catalyst processes that need to authenticate to the platform without relying on a named individual user.

Examples include:

* API integrations
* automated workflows
* background services
* system-to-system communications

Service Internal accounts are automatically activated when created and do not use the standard account activation process.

Unlike standard users, Service Internal accounts can use username and password authentication even when your organisation has disabled password-based login for human users in favour of Single Sign-on (SSO).

This allows integrations and automated processes to continue operating without affecting user authentication policies.

Service Internal accounts are granted Super Admin permissions automatically.

### Service External

Service External accounts are intended for external integrations and automated processes that require authenticated access to Catalyst.

Examples include:

* third-party integrations
* external automation platforms
* partner system integrations
* external API consumers

Like Service Internal accounts, Service External accounts are automatically activated when created and do not require account activation emails.

Service External accounts can use username and password authentication even when password-based login has been disabled for standard users.

Unlike Service Internal accounts, Service External accounts do not receive any permissions automatically.

If access to records, tasks, or Object classes is required, permissions must be assigned using:

* User Groups
* Object Class Permission Sets
* Record Permission Sets

### Config admin

Config admin users are usually internal users who need access to selected areas under System configuration and Administration.

They may have a Business Analyst or Implementation Specialist role and be responsible for configuring the data model, tasks, and sequence workflows.

## Roles

When the Config admin account type is selected, a **Roles** section is displayed.

Click into the field and select the required Role.

If there are many Roles, start typing the name of the Role to filter the list.

![Roles field shown for a Config admin user account](/knowledgebase/images/administration/how-do-i-user-acc-2.png)

![Selected roles shown for a Config admin user account](/knowledgebase/images/administration/how-do-i-user-acc-3.png)

[Find out more about Roles](/knowledgebase/administration/roles-and-permissions/why-do-users-need-roles/).

## Managing Service Accounts

Service Accounts are created and managed from the same Users area as standard user accounts.

You can:

* view Service Account details
* create Service Accounts
* edit usernames and personal information
* reset passwords
* delete Service Accounts
* view account-type limits

Service Accounts are useful when integrations or automated processes need a dedicated account that is separate from a named user account.

This makes it easier to manage security, audit activity, and integration ownership independently of individual users.

### Super admin

This account type should be given sparingly to users who require all possible permissions.

Super Admin users do not require a Role. They also do not need Object class, record, or User group permissions. However, you may still add them to a User group for task assignment or messaging.

Users with this account type are the only users who can access **Users** and **Roles**. They cannot edit their own user account type.

The Super Admin account type is required for:

* configuration of the Landing page
* configuration of Outbound mail setup
* configuration of the Theme

## Username

A user's email address is their username, so this field must contain a valid email address.

Each user must be created with a unique email address.

If you try to create a user with an email address that already exists, an error message is displayed.

![Duplicate username error shown when an email address already exists](/knowledgebase/images/administration/how-do-i-user-acc-4.png)

If you enter an unrecognised format, a validation error is displayed.

![Error shown when an email address is in an unrecognised format](/knowledgebase/images/administration/how-do-i-user-acc-5.png)

## Password

This field is not editable.

A password cannot be edited by any user from this page.

If a user wants to change their account password, they must do this from **My account**, which is available from the menu under their name in the top-right corner of the page.

![My account shown in drop down](/knowledgebase/images/administration/how-do-i-user-acc-6.png)

Users with an Internal, External, Config admin, or Super admin account type receive an activation email either when their account is created or later, if that option is chosen.

The activation email contains a unique URL that takes the user to the account activation page. From there, they can set their password.

## Personal Information

In this section, the new user's **First name** and **Last name** are mandatory.

The other fields are optional.

For external users, it can be useful to include the **Company name**.

![Personal Information section on the Create user page](/knowledgebase/images/administration/how-do-i-user-acc-7.png)

The information entered in this section is shown when the user's avatar is clicked elsewhere in the system.

![User's Avatar information shown](/knowledgebase/images/administration/how-do-i-user-acc-8.png)

When you are done, click **Save** in the top-right corner.

A modal is displayed asking whether you want to send an activation email.

* Click **I'll do it later** to create the account without notifying the user immediately.
* Click **Send email** to send the activation email immediately.

![Send email to user now or later shown](/knowledgebase/images/administration/how-do-i-user-acc-9.png)

Unless filtering or sorting has been applied to the Users list, the new user is added to the top of the list and is given a User ID.

If the **Status** column is visible on your Users list, the new user is shown with the status **Created**.

![Users list showing a newly created user account with Created status](/knowledgebase/images/administration/how-do-i-user-acc-10.png)

## Account statuses

Most user accounts use one of the following statuses:

* **Created** - the user account has been created but not activated.
* **Pending** - the account activation email has been sent but the account has not been activated.
* **Active** - the user has activated their account and logged in.

Service Accounts are activated automatically when they are created and do not normally pass through the Created and Pending stages.

## Things to remember

1. The **+ Create** button is disabled when you reach the maximum number of users allowed.
2. The maximum number of users allowed in your system is 1,000,000.
3. Only users with the Super Admin account type can create, edit, and delete user accounts.
4. The maximum number of Roles you can assign to a user with a Config admin account is 25.
5. Service Accounts are automatically activated when created.
6. Service Accounts can use username and password authentication even when standard users authenticate through Single Sign-on.
7. Once a Service Account has been created, its account type cannot be changed to a standard user account.
8. Standard user accounts cannot be converted into Service Accounts.
9. Service Internal accounts automatically receive Super Admin permissions.
10. Service External accounts require permissions to be assigned explicitly if access to records, tasks, or Object classes is required.

---

---
url: >-
  /knowledgebase/system-configuration/object-classes/how-do-i-create-an-object-class.md
---

# How do I create an Object Class?

## Create an Object class

Like most lists in your system, the Object classes list has a **+ Create** button on the top left-hand side. This, of course, is dependent on you having permission to create an Object class via your Role or because you have a Super admin account type.

When the **+ Create** button is clicked, you will be presented with a simple page containing two fields.

![mceclip0.png](../../../images2/zendesk_4402900717969_001_96eb0af5e08d.png)

**Fields**

* The **Name** field is mandatory and must be given a unique value. The **Save** button will not be enabled until this field is populated.
* The **Description** field is optional, but is useful to determine the differences between Object classes with similar names.

On clicking **Save**, the success toast message will confirm that the Object class has been saved. In addition, you will be asked whether you want to add fields for the Object class.

![mceclip3.png](../../../images2/zendesk_4402900717969_002_e6dcaf412a75.png)

If you select **"Add fields"**, you will be taken to the Edit Object class page where the first tab allows you to [configure the required fields](/knowledgebase/system-configuration/object-classes/creating-object-class-fields/).

**Four further tabs** allow you to configure:

* **Display** — card view, create/edit view and summary view
* **Forms** — a stand alone form used to create records
* Document templates — view a section which will explain [how to create and use document templates](/knowledgebase/system-configuration/working-with-document-templates/)
* **Permissions** for sets of Users who will administer the Object class or interact with the associated records and/or tasks

![1006b.png](../../../images2/zendesk_4402900717969_003_8f84c4465c23.png)

If you select **'I'll do it later'**, your Object class will be saved and you will be taken back to the Object classes list.

## Useful info

1. The maximum number of Object classes you can have in your system is **10,000**. If this limit is reached, the **+ Create** button on the Object classes list will be disabled.
2. The maximum number of Object fields you can have in each Object class is **2,000**.

---

---
url: >-
  /knowledgebase/using-help-and-support/faqs/how-do-i-grant-view-users-permission-to-config-admins.md
---

# How do I grant "view users" permission to Config admins

![image (6).png](/knowledgebase/images/img_4655677873311_1776896087.png)

## What this permission allows

This permission allows the Config admin (with appropriate role permissions) to:

* **View user details** when clicking user avatars on lists, drop-downs, etc.
* **Add any user** to a field.
* **Add any user** to a User group.
* **Create for / re-assign** a manual task to any "available" user, i.e. for that record.
* etc.

---

---
url: >-
  /knowledgebase/administration/all-about-users/how-does-a-1-time-completion-user-interact-with-catalyst.md
---

# How does a 1-time completion user interact with Catalyst?

First, it is important to understand who 1-time completion users might be.

This type of user account has been designed for individuals who will infrequently need to complete a task.

These people may be senior managers within your organisation, or they may be individuals from third party organisations who are asked to provide specific information or advanced/specialist subject matter.

## How 1-time completion users interact with Catalyst

**No login is required.** They do not log in and have no direct interaction with the system. If they are assigned to a task, they will be notified by email.

Although 1-time completion users do not log in, they must have an account in your system. This is created in the same way as for any other user, but the account type is 1-time completion, as shown below:

![1tc.png](../../../images2/zendesk_10634086671005_001_8c66df4b2936.png)

The user will have no knowledge of the account and no indication that an account has been created for them. They are not sent the account creation email which users with a Super admin account receive.

**Task assignment email.** When a 1-time completion user has been assigned a task, they will receive an email as shown below. The email will contain a link to the task.

![](../../../images2/zendesk_10634086671005_002_18a022863f8b.png)

When the link is clicked, the task will open in a new window in their browser.

![](../../../images2/zendesk_10634086671005_003_3729fec44c05.png)

**Saving progress.** The user can part-complete the task, then click the "Save progress" button if they are not able to finish the task in one go.

Saving of the task will be confirmed on-screen. The user will be able to open the task later from the link in the original email.

![](../../../images2/zendesk_10634086671005_004_694087bb6de8.png)

**Completing the task.** When they have finished the task, the user must click the "Complete" button. The Complete button will only be enabled when all mandatory fields in the task have been completed.

Until this is done, the Complete button will remain disabled and, when hovered over, the tooltip will advise that "Mandatory fields are not complete".

![Screenshot](../../../images2/zendesk_10634086671005_005_7ddb1053cbad.png)

When the task is completed, the on-screen confirmation will be shown as below:

![](../../../images2/zendesk_10634086671005_006_91a227aa5ec3.png)

## If the task link is no longer valid

If the 1-time completion user clicks on a link in an email for a task which is:

* overdue (because it is beyond the due date set when the task was created)
* already completed by them
* completed by another user
* reassigned to another user
* deleted

They will be shown the following message:

![](../../../images2/zendesk_10634086671005_007_2f6858efdf47.png)

## Useful info

The link to a task in the email notification will remain active as follows:

1. If a due date has been set and the task has not been completed by this date, the status of the task will become "Overdue" and the link will no longer be active.
2. If a due date has not been set, the link to the task will remain active until it is completed.

---

---
url: >-
  /knowledgebase/workspace/working-with-relational-records/how-to-associate-child-records-with-existing-parent-records.md
---

# How to associate child records with existing parent records

Having used the Relational modeller to create parent/child relationships between your Object classes ([**click here**](/knowledgebase/system-configuration/relational-modeller/creating-the-relational-model/) for how to), and edited each parent object class in order to add the available child Object classes into the create/edit view ([**click here**](/knowledgebase/system-configuration/object-class-relationships/configuring-relationships-in-object-classes/) for how to), your users will now be able to associate child records with existing parent records, if they have the appropriate permissions.

This is done from the Workspace.

In the example previously shown, Mortgage Application is a parent object class with 4 child object classes.

![](../../../images2/zendesk_10476276795677_001_3beddd3de79f.png)

This object class will be used throughout this article. However, the parent:child ratio for child object class Applicant 1 will be changed to demonstrate the different child component views and functionality.

## Open the parent record

Filter to the parent object class records, then find and select the record to which you wish to add child records.

![](../../../images2/zendesk_10476276795677_002_8b2cce5ff452.png)

Then double click or select "Open" in the Actions menu. You will be taken to the edit view for the record, as shown below.

![](../../../images2/zendesk_10476276795677_003_5d7b806f4d5e.png)

**In this example, there are 3 sections where child records can be selected:**

* Applicants - you can select an Applicant 1 record and an Applicant 2 record
* Property to be mortgaged - you can select a Property record
* Lender - you can select a Lender record

However, remember that your parent record does not have to contain all its anticipated children right from the start. A Mortgage Application may only have one applicant so, in some cases, it might never contain an Applicant 2 record.

## When the parent:child ratio is 1:1

**When the parent:child ratio has been set at 1:1** in the relational model, the child record selector will appear as below.

![child\_search.png](../../../images2/zendesk_10476276795677_004_a215914cbd1c.png)

It has a search field which, when clicked into, will display the available child records in alphabetical or numerical order by the field marked as the identifier, followed by the ALX ID number underneath. If no identifier has been set in the object class, the records will appear in numerical order by ALX ID.

![](../../../images2/zendesk_10476276795677_005_63e5bfbe682a.png)

The list of available records will filter according to what is entered in the search field. Matching characters will be shown in bold, as below:

![](../../../images2/zendesk_10476276795677_006_e77b7fdeda90.png)

Select the required record by clicking on it to make the association with the parent record.

![](../../../images2/zendesk_10476276795677_007_537f2716e621.png)

You will not be able to add more than one child record, so if the user clicks into the search field again, they will be shown an error message telling them the maximum number of related records has been added.

![](../../../images2/zendesk_10476276795677_008_2b5e842dcada.png)

## When the parent:child ratio is 1:N

**If the parent:child ratio has been set as 1:N** in the relational model, the child record selector will appear as below. This time it has a results counter in the top right-hand corner.

When no child records are associated with the parent, the counter remains at zero (0 results).

![N1.png](../../../images2/zendesk_10476276795677_009_69a25181b538.png)

When child records have been associated with the parent, the counter will increase to show the total number of associated records. The component will show a maximum of 5 child records.

![](../../../images2/zendesk_10476276795677_010_1338eed18b48.png)

There are pagination controls which will allow you to click through further pages of 5 records at a time.

If you have several pages of associated child records, the child search control serves a dual purpose. It can be used to add new children to the parent record, and it can be used for finding an existing child.

Having found an existing child, the list is filtered to show only the selected record and the page controls become disabled.

![oneofsix.png](../../../images2/zendesk_10476276795677_011_fcc36aedf6e8.png)

The filter can be removed by clicking on the X to the right of the search lookup control.

When adding more child records, those already added to the relationship will be shown in the search field with an adjacent "Already added" label.

![alreadyadded.png](../../../images2/zendesk_10476276795677_012_da4b8bbb289f.png)

Child records will appear in the order they are added to the parent, with the last added at the top.

## General information irrespective of parent:child ratio

1. Row heights within the child component adjust according to the row settings in user preferences (the same as in other lists). [**Click here**](/knowledgebase/finding-your-way-around/my-account/what's-in-my-account/) for an article which will explain how to access these settings.

2. Selecting a child record will highlight it in blue, and if you have the "Child record summary" selected in the View menu, this summary will open in the sidebar.

![](../../../images2/zendesk_10476276795677_013_46f75fd5f431.png)

3. At the top of the child record summary is a button which will allow you to open the child record in the main window using the create/edit view configured in the object class.

4. Each child record has an Actions menu at the right-hand side of its listing. When this is clicked, there is an option to remove the record.

![](../../../images2/zendesk_10476276795677_014_fad008502987.png)

5. If the user double clicks on a child record row, it will open as a flyout.

6. The child class component has a "+Create" button. This will allow you to create child records and associate them with the parent at the same time. **Click here** for an article which explains more about this. Please note that you will only be able to create child records to be associated with parent records if you have permission to create records for the child object class and permission to edit records in the parent object class.

## Permissions

Depending on user permissions, some components of the child listing may be disabled or hidden.

For example, in the case where the user only has “view record” permission for the parent record (and hence the record form is opened in read-only mode), they are not allowed to add or remove child records, so the +Create button and the child lookup controls are hidden.

Where the user does not have “view class” permission for the child class, the control contains only the below. Even the child object class name is hidden:

![Screenshot](../../../images2/zendesk_10476276795677_015_fef7538d7fec.png)

If the user has “view class” permission for the child class, but does not have any record permissions for records in this class, the control looks like in the previous case except the child class name is shown instead of the ID:

![](../../../images2/zendesk_10476276795677_016_5279e641904e.png)

When the child record component is empty, the message displayed will depend on the user's permissions as follows:

|  |  |  |  |
| --- | --- | --- | --- |
| Child class permissions | | |  |
| View class | List records | Create records | Message |
| YES | NO | YES | No records available. Create new records to add them. |
| YES | YES | NO | No records available. Search for existing records to add them. |
| YES | YES | YES | No records available. Search for existing records to add them or create new records. |

## Useful info

1. A limit of 1,000 child records, per child object class, can be associated with a parent. If this limit is reached:

   a. The user will be prevented from creating a new child object record as the create button will be disabled and a tooltip will be shown as below:

![Screenshot](../../../images2/zendesk_10476276795677_017_784fcd00acde.png)

b. The user will be prevented from adding any further children as the search field will be hidden and the below message will appear in its place:

![Screenshot](../../../images2/zendesk_10476276795677_018_8891d309f1c1.png)

2. A limit of 50 children can be created when the parent is being created.

---

---
url: >-
  /knowledgebase/system-configuration/landing-page/how-to-configure-the-landing-page.md
---

# How to configure the Landing page

If you are reading this article in-application, you will have a Super admin User account, as this is required to configure the Landing page.

If you have accessed the article from our Zendesk knowledgebase, go to the System configuration section in the main menu and click Landing page.

## **Overview**

The page will look like this:

![mceclip0.png](/knowledgebase/images/img_6204034667421_1776896002.png)

The Landing page will be disabled.

The main content area will have the first section ready to use.

In the Layout panel, you have the ability to drag and drop further sections, and there is also an HTML component which can be used as many times as needed.

The Section works in exactly the same ways as in all Catalyst forms.

![mceclip2.png](/knowledgebase/images/img_6204034667421_1776896002.png)

## **Set up the first section**

1. Click on the first section to give it an appropriate label and select the required number of columns, as well as their ratio.
2. Adjust the spacing if desired.
3. Drag an HTML component into the first column.

![mceclip3.png](/knowledgebase/images/img_6204034667421_1776896002.png)

## **Use the HTML editor**

The HTML editor allows you to:

* enter and format text
* insert tables and horizontal lines
* insert images and media files via a hosted URL
* insert iframes from systems such as Power BI which will provide access to live reports

|  |  |
| --- | --- |
| - click the HTML icon in order to copy/paste or write HTML code directly into the area | mceclip0.png |

|  |  |
| --- | --- |
| - you can also click Source to paste or write HTML code directly here | mceclip1.png |

When the HTML snippet is displayed, remember to click the edit icon on the top right-hand side to enable edit mode.

![edit\_html.jpg](/knowledgebase/images/img_6204034667421_1776896003.jpg)

When you have added your code, the changes can be saved or discarded by clicking the green tick or red cross icons respectively.

![edit\_html\_2.jpg](/knowledgebase/images/img_6204034667421_1776896003.jpg)

The same icons should be used when you click on an item to edit it.

## **Navigation buttons**

In the top right-hand side of the main content area, you will find the following navigation buttons:

* **Cancel** - Clicking this after Save will take you back to the main System configuration page. However, if you have unsaved changes, the warning modal will display.

![mceclip2.png](/knowledgebase/images/img_6204034667421_1776896003.png)

Your changes will be retained but remain unsaved when you click **x No, go back**. Your changes will be lost by clicking **Yes**.

* **Revert** - Clicking this when you have unsaved changes will display this warning modal:

![mceclip3.png](/knowledgebase/images/img_6204034667421_1776896003.png)

Your changes will be retained but remain unsaved when you click **Cancel**. Your changes will be lost and the configuration will revert to the last saved version if you click **Revert**.

* **Preview** - Allows you to check how the Landing page will present to Users when they log in. Click **Exit preview** to return to edit mode.

* **Save** - Does what is says on the tin. Remember to Enable the page in the top left-hand corner, then Save, when you are happy for it to become live.

## **Useful info**

1. In this first version of Catalyst, there is only one Landing page which will be displayed to all Users when they log in. Therefore, this needs to be constructed in such a way that it is relevant to everyone.
2. Section headers can be hidden by disabling the **Show this section header** button:

|  |  |
| --- | --- |
| section\_properties.jpg | mceclip1.png |
| mceclip0.png |

---

---
url: >-
  /knowledgebase/workspace/working-with-relational-records/how-to-create-a-child-record-from-the-parent-record.md
---

# How to create a child record from the parent record

From any parent record, a child record can be created as long as the user has permission to create records in the child object class and to create or edit records in the parent object class.

This is because the create button within the child component will be enabled regardless of whether the parent record has been created. That is, a child record can be created while the parent is itself being created (the parent does not have to be saved before the child can be created) or if the parent record is being edited. The process for creating the child is the same for both.

## Example relational model

For the purposes of this article, the relational model being used is shown below:

![Screenshot](../../../images2/zendesk_11410536962717_001_6449f4f043ea.png)

Object class "Employee Management (HR)" is the root parent with one child and one grand-child.

The "Employees" object class is a child of "Employee Management (HR)" and a parent to "Employment Contracts". This means that an Employee record can be created from a record in Employee Management HR and an Employment Contract can be created from a record in Employees.

## Example scenario

The following scenario shows how a record can be created in all three object classes at the same time.

### Start from the records list

Starting with the Records list filtered to the object class Employee Management (HR), there is currently only one record, ID 1708.

![Screenshot](../../../images2/zendesk_11410536962717_002_58bfcb007bb3.png)

Clicking the + Create record button on this list will allow us to create a new record in the Employee Management (HR) class. The create/edit record display form will open in the main content window.

![Screenshot](../../../images2/zendesk_11410536962717_003_a3902c6f5680.png)

The above screenshot shows that an Employee Management (HR) record is being created and that there are no Employee child records associated with it. The + Create button on the Employee child component is enabled.

### Create the child record

Clicking this button will open a fly-out of the create/edit view for the child object class. This is a modal page that does not have its own URL. No tabs will be available in the right-hand side panel whilst creating the record.

![Screenshot](../../../images2/zendesk_11410536962717_004_4d0c099368e9.png)

![Screenshot](../../../images2/zendesk_11410536962717_005_8d7aec6c7451.png)

The menu in the breadcrumbs at the top of the modal clearly shows that the current page is creating an Employee record; the text is in **bold**. We can also see that the parent is in the process of being created.

**Important:** You can return to the parent record from the menu. However, this will close the child record with no warning. Alternatively, if you click the X in the top left hand corner of the child record or the Cancel button in the top right after entering data into the child record, you will see the below "Unsaved changes will be lost" warning.

![Screenshot](../../../images2/zendesk_11410536962717_006_103d4ecc605c.png)

### Create the grandchild record

Clicking the + Create button on the Employment Contracts component will open a fly-out modal so that an Employment Contract record can be created.

![Screenshot](../../../images2/zendesk_11410536962717_007_428bae65adee.png)

Now the menu shows us that we are in the process of creating three records, each in a different object class.

Having completed the data entry for the Employment Contract, ensuring that all mandatory fields have been populated, click the **Save** button at the top right of the modal. You will see the green fly-out confirmation that the record has been created.

The Employment Contract modal will close and you will have the Create Employees record modal in the main content area. The newly created child will be selected in the Employment Contracts child component and the Child record summary will be displayed in the side panel, if it was selected in the View menu.

![Screenshot](../../../images2/zendesk_11410536962717_008_a0c077d46c87.png)

### Save the child record

Complete the data entry for the Employees record and click **Save**.

![Screenshot](../../../images2/zendesk_11410536962717_009_ae04ca833503.png)

The green fly-out confirming successful creation of the record will be seen.

The Employee record will be created and the child modal will close. The create Employee (HR) record will be in the main content area. The newly created child will be selected in the Employees child component and the Child record summary will be displayed in the side panel.

### Save the parent record

Once the data entry is complete for the root parent record (Employee Management (HR)), click **Save**.

The record will be created. A blank create record page will be displayed in case you want to create another record.

If you don't want to create another record, click the **Cancel** button at the top right hand side of the page or "Records" in the breadcrumbs to take you back to the Records list.

![Screenshot](../../../images2/zendesk_11410536962717_010_8eabe1259ddd.png)

The newly created record can be found in the records list as shown above, ID 1723.

Filtering the list to Employees or Employment Contracts will allow you to find the newly created child and grandchild records of this one. However, these can be accessed via the newly created root parent record.

Find out more about [interacting with child records via the parent record](/knowledgebase/workspace/working-with-relational-records/interacting-with-associated-child-records-via-the-parent/).

## Useful info

If the create form is blank, the Revert button (next to Cancel and Save) will be disabled. However, if data has been entered, the Revert button will allow the user to reset it. If the form contains unsaved changes, the user will be asked for confirmation:

![Screenshot](../../../images2/zendesk_11410536962717_011_82987f079509.png)

---

---
url: /knowledgebase/release-notes/release-notes-1.8/image-merge-fields.md
---

# Image merge fields

At Catalyst, we're constantly striving to elevate document creation, empowering our clients to craft visually compelling and engaging materials. We are thrilled to introduce a dedicated merge field that promises to transform your documents into vibrant canvases.

**The new merge field** is designed to inject images into your generated documents. Now, you can effortlessly insert any logo, image, chart, or QR code, giving your documents a dynamic edge. It's a game-changer in document personalization and customization.

![Image merge field.gif](../../../images2/zendesk_16325379538205_001_7c35cd75c1a6.gif)

## Using the image merge field

**This new merge field is simple to use.** Just append an index pointing to the attached file at the end of a standard document-type merge field, followed by '.embedded.' The generated document will then feature the selected document.

**For instance:**

```
{{ record.document_field[0].embedded }}
```

## Adjusting image size

Recognizing that the dimensions of images uploaded in document fields might not always align with the document layout, we've added a feature that enables you to tailor the image size according to your document's needs. By utilizing filters in the merge field, you can easily adjust the image width and height.

**An example of a merge field with size adjustment:**

```
{{ record.document_field[0].embedded |img_width(size)|img_height(size) }}
```

## Positioning images in documents

**To optimize image placement in your document,** consider creating a text box with the dimensions and positioning of your choice. Inside the text box, insert the image merge field - whether with filters or without - and generate your document. It's that easy!

![Image merge field2.gif](../../../images2/zendesk_16325379538205_002_53454fb03f69.gif)

**With this functionality,** your documents can now come to life with high-resolution photographs of key exhibits, dynamic timelines of events, or engaging infographics summarizing complex data. The possibilities are limitless, offering a new dimension to document creation within Catalyst. From business reports to contracts showcasing product mockups to court filings enriched with interactive maps, let your documents tell a visual story that captivates your audience.

**Embrace** the transformative potential of image merge fields in Catalyst, where documents cease to be static and evolve into dynamic expressions.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.6/imanage-authentication-objects.md
---

# iManage Authentication objects

The iManage and Catalyst integration isn't just a technical collaboration; it's a game-changer for businesses seeking a dynamic, intuitive, and secure document management solution.

**Single login access**

Just one login grants access to a realm where documents flow effortlessly, saving you from the hassle of repetitive logins.

To create an iManage Authentication object, you need specific credentials: your username, password, client ID, and host. Once entered, these credentials form the key that unlocks the door to iManage vast document repository.

![iManage\_article.gif](/knowledgebase/images/img_14581367172253_1776895669.png)

**Test during creation and editing**

One of the standout options is the ability to test your Authentication Object during both its creation and editing phases. This process ensures that the authentication is flawless, granting you the confidence that it will function seamlessly in subsequent operations.

**Use within workflows**

This new feature gives you the ability to leverage your iManage Authentication object within sequences. With a few simple configurations of API Actor, you can seamlessly integrate iManage documents into your workflow.

Whether you need to retrieve some data or documents, the API Call actor becomes your trusted assistant, connecting Catalyst directly with iManage robust document management capabilities.

**Collaboration and security**

Once authenticated, users can collaborate seamlessly, regardless of their physical location. Real-time document sharing, reviewing, and approving become intuitive tasks.

Security and compliance are non-negotiable in document management. The iManage and Catalyst integration takes these concerns to heart. Robust security protocols safeguard your sensitive data, ensuring compliance with legal standards and industry regulations.

The integration of iManage and Catalyst is a giant leap in how businesses approach document management. It's a revolution waiting to transform your workflow, making collaboration effortless, precision automation a reality, and security an unwavering promise.

---

---
url: /knowledgebase/system-configuration/integrations/imanage-cloud-integration.md
---

# iManage Cloud integration

The iManage Cloud integration allows users to work with iManage documents directly inside Catalyst records.

This helps reduce context switching and allows users to stay inside Catalyst while browsing, previewing, and managing documents stored in iManage.

## Before you start

* The iManage integration must be enabled.
* Users must have valid iManage credentials.
* You must have permission to edit record display forms.

## Add the iManage component to a form

When the integration is enabled, a new **iManage Cloud** component becomes available in the form builder.

Go to:

**System Configuration** > **Object Classes** > **Record display form**

The component appears in the **Integrations** section of the form builder.

![Form builder showing the iManage Cloud component](/knowledgebase/images/sys-config-imanage-1.gif)

To add the component:

1. Open the required record display form.
2. Drag the **iManage Cloud** component onto the layout.
3. Save the form.

Users opening the record will then be prompted to authenticate with iManage using OAuth 2.0.

After authentication, users can:

* browse iManage documents inside the record
* navigate folders and matters
* preview files without leaving Catalyst

## Associate an iManage folder with a record

You can define which iManage folder opens by default for a record.

### Associate the folder manually

1. Open the iManage component inside the record.
2. Right-click the required folder.
3. Select **Associate with Catalyst record**.

The selected iManage location is then linked to the record.

The next time the record is opened, the component automatically loads the associated folder.

### Associate the folder using the API

You can also assign iManage locations programmatically.

Endpoint:

```text
POST /api/integrations/{integration_id}/object-record-metadata/{record_id}/
```

Example payload:

```json
{
  "imanage_location": "iManage_folder_id"
}
```

## iManage API Call templates

When the integration is enabled, dedicated iManage API Call templates become available in Sequencer.

![Sequence showing the iManage Cloud API actor](/knowledgebase/images/sys-config-imanage-3.gif)

These templates help simplify:

* document upload workflows
* document retrieval
* authentication setup
* endpoint configuration
* file synchronisation

## Things to remember

* Users authenticate with iManage only once until the token expires.
* If no iManage location is associated with a record, the default iManage view loads.
* API-based folder assignment is useful for automated onboarding or matter-creation workflows.
* Integration availability depends on feature enablement.

---

---
url: /knowledgebase/release-notes/release-notes-1.8/imanage-in-api-call-actor.md
---

# iManage in API Call actor

**Document management** takes the spotlight in this release, and we're thrilled to introduce a dedicated feature within our beloved API Call actor. This addition facilitates seamless integration with iManage, enabling swift file exchange between the two systems.

To harness the full potential of what we offer, the first step is to create an iManage Authentication object. This object becomes the linchpin in executing sequences and connecting with iManage effectively.

## Configuring the API Call actor

**Setup**

Configuring the API Call actor is effortless—simply choose '**iManage**' as the option in the 'Template' field, then select the appropriate Authentication object.

**Specify the method:**

* **GET** to retrieve files from iManage
* **POST** to upload documents from Catalyst to iManage

![iManage API call.gif](/knowledgebase/images/img_16323433493789_1776895658.png)

## Required fields

**Provide the following fields during setup:**

* **Customer ID**: The unique identifier assigned to the customer, retrievable through a discovery request.
* **Library ID**: The ID of the target library (formerly known as a database).
* **Folder ID**: The ID of the target folder.

**Important:** These fields, along with placeholders like {Hostname} and {documentId}, must be filled in by the user configuring the actor in the URL input.

![iManage API call\_get.gif](/knowledgebase/images/img_16323433493789_1776895659.png)

## Outcome

Upon successful connection testing, you can revel in integrated processes, transferring documents between iManage and Catalyst.

The future of document management is here. Stay tuned for even more exciting integrations coming soon!

---

---
url: /knowledgebase/release-notes/release-notes-1.13/imanage-integration.md
---

# iManage integration

We know many of our clients rely on **iManage** as their daily workspace for documents and matters. That’s why this release brings the two worlds closer together, allowing you to access your iManage documents directly from Catalyst record views, with no context switching and no extra tabs.

Here’s how it works and what you need to do to get started.

## Adding the iManage component to the form

Once the iManage integration is both **active** and **enabled**, Catalyst form designers will notice a new section in the Create/edit record display form builder under **Integrations**. Inside it is a drag-and-droppable iManage Cloud component.

Just drop it anywhere onto your record layout, hit save, and you’re ready to go.

![iManage 1.gif](../../../images2/zendesk_4893251571359_001_277fda880453.gif)

From that point forward, any user opening that record will be prompted to log in to iManage. This is a one-time authentication using OAuth 2.0 (Authorization Code Grant flow), secure and enterprise-ready.

After that, they can:

* Browse documents stored in iManage directly inside the record
* Navigate between folders or matters
* Preview files without leaving the Catalyst UI

**The best part:** You only need to sign in once. Your session is remembered until your token expires - no repeated logins or broken workflows.

![iManage 2.gif](../../../images2/zendesk_4893251571359_002_ce708daa2ffb.gif)

## Predefine which iManage folder opens per record

Every matter operates differently, and default context is critical. That’s why we’ve introduced two complementary ways to define which iManage folder should appear first when a user opens a record.

### Assign the folder directly in the iManage component

When viewing the iManage component on a record:

**Right-click any folder → select “Associate with Catalyst record”.**

Catalyst will automatically bind the currently selected iManage location to that record - no API calls, no configuration steps. The next time anyone opens the record, the component will automatically jump to that folder. This is the quickest option for day-to-day users who prefer working visually rather than configuring automation.

### Assign the folder programmatically via API

For teams automating matter setup, onboarding flows, or bulk operations, the assignment can also be done using the new endpoint:

```
POST /api/integrations/{integration_id}/object-record-metadata/{record_id}/
```

**Where:**

* `integration_id` = the ID of your iManage integration
* `record_id` = the ID of the Catalyst record you're linking to

**Payload example:**

```json
{"imanage\_location":"iManage\_folder\_id"}
```

The next time a user opens that record, the iManage component will jump straight to the assigned folder or matter. If no location is set, it will load the default iManage screen.

## Simplify API Calls with built-in templates

Working with the iManage API inside Catalyst just got easier too. When the integration is enabled, you’ll find a dedicated API Call template inside the Sequencer, tailored specifically for iManage.

**This helps you:**

* Send files to iManage or retrieve documents back into Catalyst
* Configure parameters quickly
* Avoid manual guesswork with auth headers or endpoints

Use it in automation workflows to connect your records with the right files, at the right time, without custom scripting.

![iManage 4.gif](../../../images2/zendesk_4893251571359_003_aed303d9b72e.gif)

This integration makes working with documents across Catalyst and iManage feel natural. You can browse files, upload new versions, and jump between Matters and |all without leaving the record, switching tabs, or losing your flow.

You stay in context, with everything you need right where you expect it. And most importantly, it all happens inside Catalyst - the tool your team already relies on to manage the work that matters most.

---

---
url: /knowledgebase/release-notes/release-notes-1.2/improved-breadcrumbs.md
---

# Improved breadcrumbs

Breadcrumbs may seem like a small addition to a complex record-keeping system, but they can make a world of difference in usability and efficiency. That's why we're excited to introduce our refreshed breadcrumbs, designed to help you navigate your records with ease.

![Breadcrumbs\_article.gif](/knowledgebase/images/img_10871407802653_1776895708.png)

## What the refreshed breadcrumbs show

**Each breadcrumb is both functional and informative.** It displays the Object Class name and the Identifier or ID of the record, providing crucial information at a glance. This added context allows you to quickly identify the record you're looking for and helps you keep track of where you are in the record hierarchy.

## Why this helps

**The result is simpler navigation and less confusion.** Upgrade your record-keeping system with our new and improved breadcrumbs. No more confusion or lost records—our breadcrumbs will help you glide smoothly to your desired record location.

---

---
url: /knowledgebase/release-notes/release-notes-1.2/improved-instructions-editor.md
---

# Improved instructions editor

**No more plain and simple instructions!** We understand that instructions are critical components of any form, and that clear, concise, and well-structured guidance is vital to ensure a seamless user experience.

With this in mind, we have enhanced the text editor in instructions so that you can create informative, engaging, and user-friendly manuals visible on forms across the Autologyx platform. We have upgraded our existing text editor with an array of powerful features that make creating instructions more intuitive, efficient, and enjoyable than ever before.

## What’s new

**The enhanced text editor** now boasts a range of functions, including font size, type, and color, text alignment, and bullet and numbered lists. But that's not all. With these new features, System Administrators can now add rich-text instructions to each form builder with ease, and enhance them with eye-catching images and clickable links.

![Instructions\_article.gif](/knowledgebase/images/img_10872525096733_1776895712.png)

## The result

The new text editor makes it easier than ever before to create instructions that are visually appealing and easy to navigate, ensuring a positive experience for end-users.

We're confident that once you start using our enhanced text editor in instructions, you'll wonder how you ever managed without it!

---

---
url: /knowledgebase/welcome-introduction-to-catalyst/in-application-help.md
---
# In Application Help

**Browse the sections below:**

* [Welcome To In Application Help](/knowledgebase/welcome-introduction-to-catalyst/in-application-help/welcome-to-in-application-help/)

---

---
url: /api/catalyst/resources/integrations.md
---
# Integrations

Integrations represent built-in third-party services (identity providers, document management systems, AI providers, etc.) that can be enabled and configured per tenant. The set of available integrations is fixed — the API does not support creating or deleting integrations, only enabling/disabling them and running provider-specific authorization flows.

# Integrations API

## GET /api/integrations/

Retrieves the integration list.

### Permissions

Requires `authentication` and `integrations.list` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/integrations/
Authorization: JWT access_token
```

### Response

| Key            | Type       | Notes                                                                                   |
|----------------|------------|-----------------------------------------------------------------------------------------|
| limit          | int        |                                                                                         |
| offset         | int        |                                                                                         |
| total\_count    | int        | Total number of integrations visible to the user (based on permissions).                |
| filtered\_count | int        | Number of integrations visible to the user (based on permissions) with filters applied. |
| next           | URL / null | Next page URL (null if there is no next page)                                           |
| previous       | URL / null | Previous page URL (null if there is no previous page)                                   |
| results        | Array      | Described in the next table.                                                            |

### Response `results` array

| Key               | Type          | Notes                                                                                                                                                                                              |
|-------------------|---------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| uuid              | uuid          |                                                                                                                                                                                                    |
| name              | string        | Max length 255.                                                                                                                                                                                    |
| type              | enum          | One of: `docu_sign`, `imanage`, `box_client_credentials`, `salesforce_client_credentials`, `microsoft_client_credentials`, `adobe_client_credentials`, `chatgpt_integration`, `openai_embeddings`, `amazon_bedrock`, `azure_openai`, `anthropic_claude`. |
| category          | enum          | One of: `business`, `ai_mcp`, `ai_sequencer`.                                                                                                                                                      |
| description       | string        |                                                                                                                                                                                                    |
| is\_enabled        | bool          | Whether the integration is enabled for the tenant. Only writable field on `PATCH`.                                                                                                                 |
| is\_active         | bool          | Whether the integration is active (enabled and successfully authenticated/configured).                                                                                                             |
| is\_system         | bool          | Whether the integration is system-managed.                                                                                                                                                         |
| created\_at        | datetime      |                                                                                                                                                                                                    |
| created\_by        | user / null   | `null` for system-seeded records.                                                                                                                                                                  |
| modified\_at       | datetime      |                                                                                                                                                                                                    |
| modified\_by       | user / null   |                                                                                                                                                                                                    |
| \_meta.permissions | Object        | Dict describing permissions.                                                                                                                                                                       |

### Response example

* Status `200 OK`
* Body

```json
{
    "limit": 100,
    "offset": 0,
    "filtered_count": 1,
    "total_count": 1,
    "next": null,
    "previous": null,
    "results": [
        {
            "uuid": "3b1c9a10-72e4-4c2a-9f4f-1a8f6a7d3f21",
            "name": "iManage",
            "type": "imanage",
            "category": "business",
            "description": "iManage document management integration.",
            "is_enabled": true,
            "is_active": true,
            "is_system": false,
            "created_at": "2022-08-22T09:30:04.640178+02:00",
            "created_by": {
                "id": 2,
                "first_name": "John",
                "last_name": "Smith",
                "username": "j.smith@autologyx.com",
                "company_name": "Autologyx",
                "is_deleted": false,
                "account_type": "full"
            },
            "modified_at": "2022-08-22T09:45:49.582526+02:00",
            "modified_by": {
                "id": 2,
                "first_name": "John",
                "last_name": "Smith",
                "username": "j.smith@autologyx.com",
                "company_name": "Autologyx",
                "is_deleted": false,
                "account_type": "full"
            },
            "_meta": {
                "permissions": {
                    "list": true,
                    "view": true,
                    "create": false,
                    "edit": true,
                    "delete": false
                }
            }
        }
    ]
}
```

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter | Predicates    | Example                                     |
|-----------|---------------|---------------------------------------------|
| category  | standard enum | {build}/api/integrations/?category=business |

### Errors

| Error                                | Response code    | Message                                                                             |
|--------------------------------------|------------------|-------------------------------------------------------------------------------------|
| Requesting user is not authenticated | 401 Unauthorized | "detail": "Authentication credentials were not provided."                           |
| Request from a non-allowlisted IP    | 403 Forbidden    | "detail": "You do not have permission to perform this action."                      |
| Insufficient permissions             | 403 Forbidden    | "detail": "You do not have permission to perform this action."                      |
| Unknown value for a filter           | 400 Bad Request  | "category": \["Select a valid choice. {value} is not one of the available choices."] |

---

---
url: /knowledgebase/release-notes/release-notes-1.13/integrations.md
---

# Integrations

We know that no matter how powerful one system is, real work happens across many tools: document management, eSignatures, communication platforms, and now AI. With this release, Catalyst gives you a clear and simple way to manage all those connections from one central spot. Everything stays in sync, and the most important processes happen exactly where they should: in Catalyst.

## Centralised integrations management

There’s now a dedicated space in Catalyst:
**System configuration → Integrations**

![Integrations 1.gif](../../../images2/zendesk_4893201090847_001_205249a9af80.gif)

From there, Super Admins can easily see which integrations are available and which ones are already active.

## Integration categories

The list is split into two categories:

* **Integrations:** tools your teams may already rely on, including:
  * iManage Cloud
  * DocuSign
  * Adobe Sign
  * Microsoft
  * Salesforce
  * Box
* **Applied AI:** AI providers such as:
  * OpenAI: GPT
  * OpenAI: Embeddings
  * Azure OpenAI
  * AWS Bedrock

## Requesting and enabling integrations

Need an integration that’s not yet active? You can request it directly from this screen. Our Professional Services team will take it from there and help you get set up.

Once it’s ready, turning it on or off is just a click away.

![Integrations 2.gif](../../../images2/zendesk_4893201090847_002_682a65ef834e.gif)

## What integrations enable

Each integration opens up new possibilities inside your workflows:

* Create Authentication Objects for services like iManage or Microsoft and use them in Sequencer’s API Call actors to securely pull documents from external systems or send files and data back to them, all as part of an automated process.
* Use Adobe Sign or DocuSign to send documents for signature directly from Catalyst, fully integrated into your process flows.
* Add AI where it makes the most impact, with provider-specific actors that let you classify, extract, summarise, and review content using OpenAI, Azure, or Bedrock.

## Why this update matters

Integrations have always been part of Catalyst, but until now, they’ve been tucked away in different places. With this update, there’s finally a clear, unified way to handle them, with the flexibility to scale, switch providers, or roll out new capabilities when you need them.

It also means less time coordinating across tools and more time designing the processes that matter. You control which systems connect and how they work together, while Catalyst takes care of the heavy lifting in the background.

This makes it easier to build automation that’s useful and easier to trust that everything’s running the way it should.

---

---
url: /knowledgebase/system-configuration/integrations.md
---

# Integrations

Modern business processes rarely happen in a single system.

Teams often work across document management platforms, eSignature tools, communication services, CRMs, and AI providers. Catalyst integrations help bring those systems together so your workflows, records, documents, and automation can operate from a central platform.

Go to:

**System Configuration** > **Integrations**

From here, Super admins can:

* view available integrations
* see which integrations are enabled
* manage integration availability
* request additional integrations by contacting your usual Autologyx contact
* configure integrations for use in workflows and automation

![Integrations page showing available integrations and Applied AI providers](/knowledgebase/images/sys-config-integrations-1.gif)

## Integration categories

The Integrations page is split into two main categories.

### Integrations

This section includes operational and business-system integrations such as:

* [iManage Cloud](/knowledgebase/system-configuration/integrations/imanage-cloud-integration/)
* DocuSign
* Adobe Sign
* Microsoft
* Salesforce
* Box

These integrations are commonly used for:

* document management
* eSignature workflows
* external system communication
* CRM integration
* document exchange and storage

### Applied AI

This section contains AI integrations and AI-enabled workflow capabilities.

Available providers include:

* [OpenAI: GPT](/knowledgebase/system-configuration/integrations/openai-gpt-integration/)
* [OpenAI: Embeddings](/knowledgebase/system-configuration/integrations/openai-embeddings-integration/)
* [Azure OpenAI](/knowledgebase/system-configuration/integrations/azure-openai-integration/)
* [AWS Bedrock](/knowledgebase/system-configuration/integrations/aws-bedrock-integration/)

These integrations support:

* summarisation
* extraction
* classification
* semantic search
* AI-assisted review
* workflow automation
* knowledge retrieval

## How integrations are used in Catalyst

Integrations can be used throughout Catalyst workflows and automation.

Examples include:

* creating Authentication Objects for external services
* using API Call actors in Sequencer
* sending documents for eSignature
* synchronising documents with external systems
* enriching workflows with AI-generated outputs
* retrieving documents or data from connected systems

## Requesting additional integrations

If an integration is not currently enabled for your environment, you can request it directly from the Integrations page.

Autologyx Professional Services will contact you to discuss:

* availability
* licensing
* implementation requirements
* onboarding and setup

## Things to remember

* Some integrations require additional licensing or feature enablement.
* Integration availability may vary between environments.
* Certain integrations require configured Authentication Objects before use.
* Access to integrations depends on user permissions and account type.

---

---
url: /api/monitoring-and-infrastructure/catalyst/integrations.md
---
# Integrations API

## GET /api/integrations/`uuid`/

Returns single integration by `uuid`.

### Permissions

Requires `authentication` and `SuperAdmin` permission.

### URL parameters

| Key                        | Type      | Notes |
|----------------------------|-----------|-------|
| uuid                       | uuid      |       |

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Location: /api/integrations/934ab882-0120-46bc-a8e0-fe901d298063/
Authorization: JWT access_token
```

### System integrations

System integrations are created by Autologyx and cannot be deleted.

### Response

| Key               | Type     | Notes                                                                                                    |
|-------------------|----------|----------------------------------------------------------------------------------------------------------|
| uuid              | uuid     | Unique identifier of given integration.                                                                  |
| name              | string   |                                                                                                          |
| type              | string   |                                                                                                          |
| description       | string   |                                                                                                          |
| is\_enabled        | bool     | User editable flag for enabling the integration to be used in the app by end users.                      |
| is\_active         | bool     | Only editable by the Admin, controls whether the integration can be configured on specific environments. |
| is\_system         | bool     |                                                                                                          |
| created\_at        | datetime |                                                                                                          |
| created\_by        | user     | `null` for system created                                                                                |
| modified\_at       | datetime |                                                                                                          |
| modified\_by       | user     | `null` for system created                                                                                |
| \_meta.permissions | Object   | Object describing permissions.                                                                           |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": <int>,
    "type": <string>,
    "name": <string>,
    "description": <string>,
    "is_enabled": <bool>,
    "is_active": <bool>,
    "is_system": <bool>,
    "created_at": <datetime>,
    "created_by": <user,
    "modified_at": <datetime>,
    "modified_by": <user>,
    "_meta": {
        "permissions": {
            "list": <bool>,
            "view": <bool>,
            "create": <bool>,
            "edit": <bool>,
            "delete": <bool>
        }
    }
}
```

### Response Example

```json
{
      "uuid": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
      "name": "iManage Cloud",
      "type": "imanage",
      "description": "",
      "is_enabled": false,
      "is_active": false,
      "is_system": true,
      "created_at": "2022-05-17T13:49:06.100636+02:00",
      "created_by": null, 
      "modified_at": "2022-05-17T13:49:37.246827+02:00",
      "modified_by": null,
      "_meta": {
        "permissions": {
          "list": true,
          "view": true,
          "edit": true,
          "delete": false,
          "create": true
        }
      }
    }
```

#### Available system integration

Integrations automatically created by the system are:

| Type                          | Name               |
|-------------------------------|--------------------|
| imanage                       | iManage Cloud      |
| docu\_sign                     | DocuSign           |
| box\_client\_credentials        | Box                |
| microsoft\_client\_credentials  | Microsoft          |
| salesforce\_client\_credentials | Salesforce         |
| adobe\_client\_credentials      | Adobe              |
| chatgpt\_integration           | OpenAI: GPT        |
| openai\_embeddings             | OpenAI: Embeddings |
| amazon\_bedrock                | AWS: Bedrock       |
| azure\_openai                  | Azure OpenAI       |

### Errors

| Error                                   | Response code      | Message                                                        |
|-----------------------------------------|--------------------|----------------------------------------------------------------|
| Requesting user is not authenticated    | 401 Unauthorized   | "detail": "Authentication credentials were not provided."      |
| Insufficient permissions                | 403 Forbidden      | "detail": "You do not have permission to perform this action." |
| Sequence with "id" does not exist       | 404 Not Found      | "detail": "Not found."                                         |

## PATCH /api/integrations/`uuid`/

Update single integration detected by `uuid`.

### Permissions

Requires `authentication` and `SuperAdmin` permission.

### URL parameters

| Key  | Type | Notes |
| ---- | ---- | ----- |
| uuid | uuid |       |

### Request

* Body parameters

| Key        | Type | Notes |
| ---------- | ---- | ----- |
| is\_enabled | bool |       |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key        | Type | Notes |
| ---------- | ---- | ----- |
| is\_enabled | bool |       |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": <int>,
    "type": <string>,
    "name": <string>,
    "description": <string>,
    "is_enabled": <bool>,
    "is_active": <bool>,
    "is_system": <bool>,
    "created_at": <datetime>,
    "created_by": <user,
    "modified_at": <datetime>,
    "modified_by": <user>,
    "_meta": {
        "permissions": {
            "list": <bool>,
            "view": <bool>,
            "create": <bool>,
            "edit": <bool>,
            "delete": <bool>
        }
    }
}
```

### Response Example

```json
{
  "uuid": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "name": "iManage Cloud integration",
  "type": "imanage",
  "description": "",
  "is_enabled": false,
  "is_active": false,
  "is_system": true,
  "created_at": "2022-05-17T13:49:06.100636+02:00",
  "created_by": null,
  "modified_at": "2022-05-17T13:49:37.246827+02:00",
  "modified_by": null,
  "_meta": {
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "delete": false,
      "create": true
    }
  }
}
```

### Errors

| Error                                     | Response code    | Message                                                                                       |
| ----------------------------------------- | ---------------- |-----------------------------------------------------------------------------------------------|
| Requesting user is not authenticated      | 401 Unauthorized | "detail": "Authentication credentials were not provided."                                     |
| is\_enabled is null                        | 400 Bad Request  | "is\_enabled": \["This field may not be null."]                                                 |
| is\_enabled is invalid format              | 400 Bad Request  | "is\_enabled": \["Must be a valid boolean."]                                                    |
| Attempting to enable inactive integration | 400 Bad Request  | "non\_field\_errors": \["This integration is not active. Please contact System Administrator."]  |
| Insufficient permissions                  | 403 Forbidden    | "detail": "You do not have permission to perform this action."                                |
| Integration with UUID does not exist      | 404 Not Found    | "detail": "Not found."                                                                        |

## GET /api/integrations/

Returns list of integrations.

### Permissions

Requires `authentication`.

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Location: /api/integrations/934ab882-0120-46bc-a8e0-fe901d298063/
Authorization: JWT access_token
```

### System integrations

List may contain system integrations, that are created by Autologyx.

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key               | Type     | Notes                                                                                                    |
|-------------------|----------|----------------------------------------------------------------------------------------------------------|
| uuid              | uuid     | Unique identifier of given integration.                                                                  |
| name              | string   |                                                                                                          |
| type              | string   |                                                                                                          |
| description       | string   |                                                                                                          |
| is\_enabled        | bool     | User editable flag for enabling the integration to be used in the app by end users.                      |
| is\_active         | bool     | Only editable by the Admin, controls whether the integration can be configured on specific environments. |
| is\_system         | bool     |                                                                                                          |
| created\_at        | datetime |                                                                                                          |
| created\_by        | user     | `null` for system created                                                                                |
| modified\_at       | datetime |                                                                                                          |
| modified\_by       | user     | `null` for system created                                                                                |
| \_meta.permissions | Object   | Object describing permissions.                                                                           |

### Available Types

| Type    | Description                                                                 |
|---------|-----------------------------------------------------------------------------|
| imanage | iManage integration.                                                        |

* Successful status `200 OK`
* Response body schema:

```json
{
    "limit": 100,
    "offset": 0,
    "filtered_count": 1,
    "total_count": 1,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": <int>,
            "type": <string>,
            "name": <string>,
            "description": <string>,
            "is_enabled": <bool>,
            "is_active": <bool>,
            "is_system": <bool>,
            "created_at": <datetime>,
            "created_by": <user,
            "modified_at": <datetime>,
            "modified_by": <user>,
            "_meta": {
                "permissions": {
                    "list": <bool>,
                    "view": <bool>,
                    "create": <bool>,
                    "edit": <bool>,
                    "delete": <bool>
                }
            }
        }
    ]
}  
```

### Response Example

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "uuid": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
      "name": "iManage Cloud integration",
      "type": "imanage",
      "description": "",
      "is_enabled": false,
      "is_active": false,
      "is_system": true,
      "created_at": "2022-05-17T13:49:06.100636+02:00",
      "created_by": null,
      "modified_at": "2022-05-17T13:49:37.246827+02:00",
      "modified_by": null,
      "_meta": {
        "permissions": {
          "list": true,
          "view": true,
          "edit": true,
          "delete": false,
          "create": true
        }
      }
    }
  ]
}
```

### Errors

| Error                                   | Response code      | Message                                                        |
|-----------------------------------------|--------------------|----------------------------------------------------------------|
| Requesting user is not authenticated    | 401 Unauthorized   | "detail": "Authentication credentials were not provided."      |
| Insufficient permissions                | 403 Forbidden      | "detail": "You do not have permission to perform this action." |

## POST /api/integrations/`uuid`/request-integration/

User can request the integration when it's inactive.
Attempting to request an already active integration will be silently ignored, and the request email will not be sent.

### Permissions

Requires `authentication` and `SuperAdmin` permission.

### URL parameters

| Key  | Type | Notes |
| ---- | ---- | ----- |
| uuid | uuid |       |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response

* Successful status `200 OK`
* Response body schema:

### Errors

| Error                                     | Response code    | Message                                                                                       |
| ----------------------------------------- | ---------------- |-----------------------------------------------------------------------------------------------|
| Requesting user is not authenticated      | 401 Unauthorized | "detail": "Authentication credentials were not provided."                                     |
| Insufficient permissions                  | 403 Forbidden    | "detail": "You do not have permission to perform this action."                                |
| Integration with UUID does not exist      | 404 Not Found    | "detail": "Not found."                                                                        |

## POST /api/integrations/`uuid`/authorize/

Retrieve the data necessary for displaying the iManage frame content with the user's personal iManage account.

If there is no iManage Personal Authentication object or iManage Personal Authentication object already created,
but it's not valid for a given user—calling this endpoint will:

* Return the data that would allow the user to be redirected to the login page:
  * status: "redirect\_uri"
  * details with the redirect\_uri field
  *

Assuming the user has an iManage Personal Authentication object already created, and it's valid—calling this
endpoint will return:

* status: authorized
* details with the following fields:
* customer\_id: (integer) the user's customer ID from iManage cloud
* user\_id: (string) the user ID from iManage cloud
* dialog\_token: (string) a short-lived token allowing to displaying the iManage frame for a given user

### Permissions

Requires `authentication` only.

### URL parameters

| Key  | Type | Notes |
| ---- | ---- | ----- |
| uuid | uuid |       |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### iManage Cloud integration Response - no valid access token

* Successful status `200 OK`
* Response body schema:

```json
{ 
  "status": "redirect_uri", 
  "details": { 
    "redirect_uri": "https://cloudimanage.com/<login_dialog_iManage_specific>" 
  } 
} 
```

| Key          | Type  | Notes                                                                                                                                                                                                                 |
|--------------|-------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| redirect\_uri | str   | The redirect\_uri includes a URL to the iManage login page. [Authorize user](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/add-login-auth-code-flow#authorize-user) |

### iManage Cloud integration Response - valid access token

* Successful status `200 OK`
* Response body schema:

```json
{ 
  "status": "authorized", 
  "details": { 
    "customer_id": <imanage_customer_id>, 
    "user_id": "<imanage_user_id>", 
    "dialog_token": "<imanage_dialog_token>",
    "app_id": <UUID>
  } 
} 
```

| Key          | Type    | Notes                                                                                                                                                          |
|--------------|---------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| customer\_id  | integer | The unique identifier of the iManage tenant (your organization's account).                                                                                     |
| user\_id      | string  | The unique username or ID of the individual user in the iManage system.                                                                                        |
| dialog\_token | string  | A short-lived JWT or token used to initiate a secure "dialog" or interaction with iManage APIs (usually in Web Client SDK or universal web view integrations). |
| app\_id       | string  | Application ID                                                                                                                                                 |

### Response Example

```json
{ 
  "status": "redirect_uri", 
  "details": { 
    "redirect_uri": "https://cloudimanage.com/auth/oauth2/authorize?client_id=123e4567-e89b-12d3-a456-426614174000&response_type=code&redirect_uri=https%3A%2F%2Fimanage-auth.autologyx.com&state=secure-random-state" 
  } 
} 
```

### Response Example for valid access token

```json
{ 
  "status": "authorized", 
  "details": { 
    "customer_id": 123, 
    "user_id": "TEST@TEST.TEST", 
    "dialog_token": "o-nxUvMqUGtdgq7Ye_lC57lRwJvxHbNNrZoNIZ814M4", 
    "app_id": "1c3b1624-0417-49e1-b855-c89c0c7a7de1",
  } 
} 
```

### Errors

| Error                                        | Response code     | Message                                                                                                                         |
|----------------------------------------------|-------------------|---------------------------------------------------------------------------------------------------------------------------------|
| iManage errors during user info receiving    | 400 Bad Request   | "detail": "Failed to get user info, response code: \<imanage\_response.stats\_code>" "error\_code": "IMANAGE\_USER\_INFO\_ERROR"       |
| iManage errors during dialog token receiving | 400 Bad Request   | "detail": "Failed to get dialog token, response code: \<imanage\_response.stats\_code>" "error\_code": "IMANAGE\_DIALOG\_TOKEN\_ERROR" |
| Requesting user is not authenticated         | 401 Unauthorized  | "detail": "Authentication credentials were not provided."                                                                       |
| Integration without related configuration    | 404 Not Found     | "detail": "Not found."                                                                                                          |
| Integration with UUID does not exist         | 404 Not Found     | "detail": "Not found."                                                                                                          |

## POST /api/integrations/`uuid`/callback/

Retrieve the data necessary for displaying the iManage frame content with the user's personal iManage account.

Any user can call the this endpoint to exchange code for an access token and retrieve the data that would allow users
to use the iManage cloud plugin.

### Permissions

Public access endpoint is secured only with an encrypted state parameter (contains request signature).

### URL parameters

| Key   | Type   | Notes |
|-------|--------|-------|
| uuid  | uuid   |       |

### Request

#### Body parameters

| Key   | Type   | Notes                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
|-------|--------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| code  | string | A temporary [authorization code](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/add-login-auth-code-flow#response) received from iManage OAuth that will be exchanged for an access token. Valid for a short time period and can only be used once when exchange it for tokens.                                                                                                                                |
| state | string | A secure encrypted JSON [authorization parameter](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/add-login-auth-code-flow#parameters) containing request signature and tenant information. Used to prevent CSRF attacks and validate the authenticity of the OAuth callback request. Generated when requesting [#POST /api/integrations/`uuid`/authorize/ ](#post-api-integrations-uuid-authorize) endpoint.   |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### iManage Cloud integration Response

* Successful status `200 OK`
* Response body schema:

```json
{ 
  "status": "authorized", 
  "details": { 
    "customer_id": 123, 
    "user_id": "TEST@TEST.TEST", 
    "dialog_token": "o-nxUvMqUGtdgq7Ye_lC57lRwJvxHbNNrZoNIZ814M4", 
  } 
} 
```

| Key              | Type | Notes                                                                                          |
|------------------|------|------------------------------------------------------------------------------------------------|
| customer\_id      | int  | Imanage customer identifier, collected from iManage /api endpoint                              |
| user\_id          | str  | Imanage user identifier, collected from iManage /api endpoint                                  |
| dialog\_token     | str  | Imanage temporary token, exchanged from iManage access token, used to load iManage UI plugins. |

### Response Example

```json
{ 
  "status": "authorized", 
  "details": { 
    "customer_id": 123, 
    "user_id": "TEST@TEST.TEST", 
    "dialog_token": "o-nxUvMqUGtdgq7Ye_lC57lRwJvxHbNNrZoNIZ814M4"
  } 
}
```

### Errors

| Error                                        | Response code   | Message                                                                                                                          |
|----------------------------------------------|-----------------|----------------------------------------------------------------------------------------------------------------------------------|
| iManage errors during user info receiving    | 400 Bad Request | "detail": "Failed to get user info, response code: \<imanage\_response.stats\_code>" "error\_code": "IMANAGE\_USER\_INFO\_ERROR"        |
| iManage errors during dialog token receiving | 400 Bad Request | "detail": "Failed to get dialog token, response code: \<imanage\_response.stats\_code>" "error\_code": "IMANAGE\_DIALOG\_TOKEN\_ERROR"  |
| iManage errors during access token receiving | 400 Bad Request | "detail": "Failed to get access token, response code: \<imanage\_response.stats\_code>" "error\_code": "IMANAGE\_ACCESS\_TOKEN\_ERROR"  |
| No code                                      | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                                                   |
| No state                                     | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                                                   |
| Integration with UUID does not exist         | 404 Not Found   | "detail": "Not found."                                                                                                           |

## POST /api/integrations/`uuid`/object-record-metadata/`record_id`/

User can add a JSON metadata for a particular Integration and Object Record.

### Permissions

Requires `authentication` and `object_record.edit` permission.

### URL parameters

| Key        | Type  | Notes             |
|------------|-------|-------------------|
| uuid       | uuid  | Integration uuid  |
| record\_id  | id    | Object Record id  |

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/integrations/`uuid`/object-record-metadata/`record_id`/

{
    "metadata_key": "some_value
} 
```

### Validations

* Body must be a valid JSON Object
* The max characters to be passed is 5000000.

### Response

* Successful status `201 Created`
* Response body schema:

```json
{
    "metadata_key": "some_value
} 
```

### Errors

| Error                                | Response code      | Message                                                                             |
|--------------------------------------|--------------------|-------------------------------------------------------------------------------------|
| Requesting user is not authenticated | 401 Unauthorized   | "detail": "Authentication credentials were not provided."                           |
| Insufficient permissions             | 403 Forbidden      | "detail": "You do not have permission to perform this action."                      |
| Integration with UUID does not exist | 404 Not Found      | "detail": "Not found."                                                              |
| Object Record with ID does not exist | 404 Not Found      | "detail": "Not found."                                                              |
| Body limit exceeded                  | 400 Bad Request    | "detail": \["Ensure this value has at most 5000000 characters (it has {body\_len})."] |
| Not a valid JSON                     | 400 Bad Request    | "detail": \["Value must be valid JSON object."]                                      |

## GET /api/integrations/`uuid`/object-record-metadata/`record_id`/

User can retrieve a JSON metadata for a particular Integration and Object Record.

### Permissions

Requires `authentication` and `object_record.view` permission.

### URL parameters

| Key        | Type  | Notes             |
|------------|-------|-------------------|
| uuid       | uuid  | Integration uuid  |
| record\_id  | id    | Object Record id  |

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response

* Successful status `200 OK`
* Response body schema:

```json
{
    "metadata_key": "some_value
} 
```

### Errors

| Error                                | Response code      | Message                                                                             |
|--------------------------------------|--------------------|-------------------------------------------------------------------------------------|
| Requesting user is not authenticated | 401 Unauthorized   | "detail": "Authentication credentials were not provided."                           |
| Insufficient permissions             | 403 Forbidden      | "detail": "You do not have permission to perform this action."                      |
| Integration with UUID does not exist | 404 Not Found      | "detail": "Not found."                                                              |
| Object Record with ID does not exist | 404 Not Found      | "detail": "Not found."                                                              |

---

---
url: >-
  /knowledgebase/workspace/working-with-relational-records/interacting-with-associated-child-records-via-the-parent.md
---

# Interacting with associated child records via the parent

This article explains how to do the following:

1. View summary details for the selected child record within a parent record.
2. Open the child records as a fly-out.
3. Recurse through child and grandchild records, etc. via the parent record.

## Prerequisites

It assumes that you have:

* used the Relational modeller to create parent/child relationships between your object classes ([creating the relational model](/knowledgebase/system-configuration/relational-modeller/creating-the-relational-model/))
* edited each parent object class in order to add the available child object classes into the create/edit view ([configuring relationships in object classes](/knowledgebase/system-configuration/object-class-relationships/configuring-relationships-in-object-classes/))
* records with associated child records in your system
* the appropriate permissions to view records in each of the object classes

## Relational model

For the purposes of this article, the relational model is shown below:

![Relational model showing Employee Management, Employees and Employment Contracts](/knowledgebase/images/workspace/interacting-child-records-1.png)

## View child record summary

Start with a record in the **Employees** object class which has a child object class called **Employee Contracts**.

In Workspace/Records filtered to the Employees object class, record ID 1704 is Sally Brown:

![Employees Records list showing Sally Brown](/knowledgebase/images/workspace/interacting-child-records-2.png)

**Note:** The sidebar has 4 possible tabs.

![Sidebar tabs available for the selected record](/knowledgebase/images/workspace/interacting-child-records-3.png)

Double clicking on this record or selecting **Open** in the **Actions** menu will open the record in the create/edit view which was configured in the object class.

![Employee record opened in create/edit view](/knowledgebase/images/workspace/interacting-child-records-4.png)

The Employment Contracts section in Sally Brown's record shows her two employment contract records.

When the user clicks once onto a child record, it will be highlighted in blue and a new tab called **Child record summary** will be available in the sidebar. This will provide the details for the summary of the child record as configured in that child object class Summary view.

| Selected child record | Child record summary |
| --- | --- |
| ![Employment Contract child record selected within the parent record](/knowledgebase/images/workspace/interacting-child-records-5.png) | ![Child record summary displayed in the sidebar](/knowledgebase/images/workspace/interacting-child-records-6.png) |

If the user clicks onto another child record, the **Child record summary** will update to show details for the newly selected child record.

The tab has an icon and text to ensure that the user can see this is a preview of the child record. The text is made up of: `Previewing <<object_class_name>> - <<Identifier>>`. That is the name of the child object class, ie Employment Contracts, and the data from the field on this class marked as the identifier.

![Child record summary tab showing preview text and icon](/knowledgebase/images/workspace/interacting-child-records-7.png)

As with all other tabs in the sidebar, the far top right-hand corner of the **Child record summary** tab has the clickable icon to allow this page to be opened in an external window.

If the child summary view has not been configured or it is disabled, the tab will show the following:

![Child record summary tab shown when the summary view is unavailable](/knowledgebase/images/workspace/interacting-child-records-8.png)

**Important:** All other tabs in the sidebar will remain in context of the parent record from which the child is accessed.

## Open child records

You can open the child record as a fly-out by double clicking on it or selecting **Open** in the **Actions** menu.

![Open action for a child record](/knowledgebase/images/workspace/interacting-child-records-9.png)

When the child record is opened, the summary tab will relate to the opened child record and there is no **Child record summary** tab in this example because records in the Employment Contracts class do not have children. All other tabs will update so that they also relate to the opened child record.

If the create/edit view has not been enabled for the child object class, the record will still "open" but with the display telling you that this view is disabled, as below:

![Disabled create/edit view message for a child record](/knowledgebase/images/workspace/interacting-child-records-10.png)

You can return to the parent record from the menu in the breadcrumbs at the top of the record. Alternatively, simply click the **X** in the top left-hand corner of the child record to close it.

## Recurse through child records

For this section, start at a record in the root parent object class - **Employee Management (HR)**. This object class is the parent of Employees and the grandparent of Employee Contracts. See the relational model above.

Record ID 1708, **All Employees**, contains 9 Employees' records. The child object class component will only ever display 5 records.

![Parent record showing child Employee records](/knowledgebase/images/workspace/interacting-child-records-11.png)

There are pagination controls which will allow you to click through further pages of 5 records at a time.

If you have several pages of associated child records, the child search control serves a dual purpose. It can be used to add new children to the parent record, and it can be used for finding an existing child.

Having found an existing child, the list is filtered to show only the selected record and the page controls become disabled.

If we select Sally Brown's employee record, the **Child record summary** will display information pertaining to this while the Summary view tab will relate to the parent record, ID 1708.

![Child record summary shown for Sally Brown while the parent Summary view remains selected](/knowledgebase/images/workspace/interacting-child-records-12.png)

If we double click on the child Employee record or select **Open** in the **Actions** menu, it will open as a fly-out in the create/edit view configured for that object class.

**Key difference:** This differs from the record we started with at the beginning of the article because, as it is a child record fly-out, it has the **X** in the top left-hand corner to close it and return to its parent record.

![Employee child record opened as a fly-out from the parent record](/knowledgebase/images/workspace/interacting-child-records-13.png)

From the Employee record, we can open an Employee Contracts child record by double clicking on it or selecting **Open** in the **Actions** menu.

From our original parent record ID 1708, we have now reached one of its grandchild records. The menu in the breadcrumbs will allow you navigate back to the Employee Contracts parent, Sally Brown, or grandparent record, All Employees.

![Grandchild Employment Contract record opened from the parent record hierarchy](/knowledgebase/images/workspace/interacting-child-records-14.png)

A user will be able to recurse from a root parent record to 5 levels deep as this is the maximum number of parent/child levels for any relationship.

## Things to remember

When recursing through child records:

1. the user will only be able to open one record on each level.
2. if the user navigates back to the parent, any open child/grandchild records of the parent record will automatically be closed.

---

---
url: >-
  /knowledgebase/system-configuration/sequence-actors/invalid-actors-and-best-practice.md
---

# Invalid Actors and Best Practice

## Introduction

Release 13.0 introduced an enhancement to the Sequencer: Actors with missing or invalid configuration now display a warning icon to indicate an issue.

For example, this can occur if an Actor depends on a field option that has been removed (such as a deleted single-select value).

![](../../../images2/zendesk_5341807826335_001_e9347c2939f2.png)

Update Record actor which has not been configured

This change also introduced a breaking behaviour in some workflows.

Actors marked as Invalid Actors are no longer processed by the Sequencer.

In most cases, this prevents unintended failures. However, some users were intentionally relying on invalid Actors to achieve specific outcomes.

This best practice document outlines the two most common reasons this occurred and describes the recommended approach going forward.

## 1. Reducing Complex Triggers

**Scenario**

When sequencing, Triggers can become extremely complex, sometimes involving multiple layers of nesting and dozens of conditions.

![](../../../images2/zendesk_5341807826335_002_089160f448bc.png)

Example of a Trigger so large it only fits on screen at 25% zoom

In cases where parallel workflows merge into a final step, users often need to apply the same complex Trigger logic in multiple places.

When there is no risk of the workflow triggering twice (see below), manually recreating identical complex Triggers can be time-consuming and error-prone.

**The old way**

Previously, some users would intentionally use an invalid **Update Record** Actor as a “Holding Bay” or merge point.

All parallel workflow branches would feed into this Actor using a simple When Actor completed Trigger. From there, the user could define a single complex Trigger to handle all possible paths before continuing to the next step.

Because the Update Record Actor had no valid configuration, it effectively acted as a junction without making any changes to the record.

![](../../../images2/zendesk_5341807826335_003_ea0145da8ea8.png)

**Best practice**

Autologyx supports copying and pasting Triggers, which is the recommended approach when complex Trigger logic needs to be reused across multiple workflow branches.

**To replicate an existing Trigger:**

1. Right-click the configured Trigger
2. Select Copy Trigger

   ![](../../../images2/zendesk_5341807826335_004_31ffea2cc784.png)

   Copy trigger
3. Right-click the target (grey) Trigger
4. Select Paste Trigger

![](../../../images2/zendesk_5341807826335_005_1cbb8106a751.png)

Paste trigger

This approach avoids manual errors when recreating large, nested conditions, saves time, and removes the need to rely on invalid Actors as workflow merge points.

**Best practice rule**

Keep Sequences small and modular wherever possible. Avoid introducing additional Actors when existing Trigger functionality, such as Copy/Paste, achieves the same outcome more cleanly.

## 2. Managing Race Conditions

**Scenario**

In sequencing, users sometimes build parallel workflow branches that must converge before the process can continue.

**Common examples include:**

* Finance, Legal, and Compliance must all approve a contract before it can be signed.
* KYC must approve a new client, and the Onboarding Team must upload a signed Letter of Engagement before the client can be created in the CRM.
* Multiple documents (e.g., 2–5) must be generated as part of a DocuSign envelope before it is sent.

In these cases, the workflows are dependent on each other and must synchronise at a specific point.

Unlike the scenario in 1. Reducing Complex Triggers, the merge step must ensure the next Actor is triggered only once. Otherwise, parallel completion can result in race conditions such as duplicate DocuSign envelopes, repeated CRM record creation, or other unintended side effects.

**The old way**

In some workflows, users would configure an invalid Update Record Actor as a central merge point for multiple parallel branches.

Each branch would feed into this “Holding Bay,” and the next Trigger would be designed to progress only once all parallel workflows had reached their required completion state (e.g., a Task completed, a document generated, or a field populated).

![](../../../images2/zendesk_5341807826335_006_17e33326392f.png)

This pattern was intended to ensure that only the final completing branch would trigger the next step.

However, in practice, this approach could still result in race conditions and unintended duplicate execution.

**Old way race conditions**

This approach helps reduce duplication of downstream Actors, but it does **not** reliably prevent duplicate triggering. In certain timing scenarios, it can still introduce a race condition where the “next step” runs more than once.

This occurs because parallel branches are evaluated independently, and Actor execution is processed through a queue.

**Example**

In this example, two parallel processes (A and B) must both complete before triggering a single API call.

Each branch generates a document, puts it in a field, and then converges into a shared “Holding Bay” before progressing.

![](../../../images2/zendesk_5341807826335_007_0e5c61d601ff.png)

* Actors 1 and 3 populate the Document Fields
* Actor 5 is the empty “Holding Bay” merge point
* Trigger 6 checks that both Document Fields (1 and 3) are populated before progressing to the API call

**Where the race condition occurs**

Each Actor is processed as a separate item in the execution queue.

Once Actor 1 completes, Trigger 2 is evaluated. If satisfied, Actor 5 enters the queue—even if branch B has not yet reached the same point.

**In the ideal sequence:**

1. Branch A reaches Trigger 6 first
2. The condition fails because branch B is not complete
3. Branch B reaches Trigger 6 second
4. The condition passes, and the API call runs once

However, a race condition occurs if Actor 3 completes before branch A has had a chance to “fail” Trigger 6.

**In that case:**

1. Branch A reaches Trigger 6 and now sees both documents present → it passes
2. Branch B also reaches Trigger 6 and also sees both documents present → it passes again
3. The result is that Trigger 6 fires multiple times, causing duplicate execution (e.g., multiple API calls)

**Key takeaway**

Even if parallel branches usually complete hours or days apart, any situation where one branch can finish before another branch has been evaluated creates a risk of duplicate triggering.

This is why invalid Actors cannot be used as a reliable synchronisation mechanism.

### Best practice 1: Sequential Processing

The simplest way to avoid this type of race condition is to avoid parallel execution entirely.

If processes A and B run sequentially rather than in parallel, the workflow cannot reach the merge point twice, and the API call will only trigger once.

Below is the same example as above but configured as a single sequential flow instead of two parallel branches.

![](../../../images2/zendesk_5341807826335_008_dc8cf140fa97.png)

This is often the easiest and most reliable way to prevent duplicate execution within a Sequence. Even if steps 1 and 3 are conceptually independent, they do not always need to be implemented as parallel branches.

**Best practice rule**

Avoid unnecessary parallel processing. When possible, prefer sequential execution, as it is more reliable, easier to debug, and safer for workflows where downstream steps must run only once.

### Best practice 2: Variables and Trigger Gates

Sequential processing is the simplest way to avoid race conditions, but it is not always practical. In some workflows, parallel execution is the more appropriate design, particularly when:

1. **Multiple manual interventions are independent**
   * For example, if two departments must approve a contract but neither depends on the other’s decision, forcing those approvals to happen one after the other can introduce unnecessary delays.
2. **Workflows include many conditional steps with multiple valid combinations**
   * For example, an onboarding process may require a variable set of documents depending on the customer: a Master Services Agreement, a Data Processing Agreement, a security questionnaire, or a regional compliance addendum. Any given customer may require only a subset of these documents.
   * In these cases, enforcing a strict sequential order becomes difficult, since later documents may still be required even when earlier ones are not. The alternative—building Trigger logic for every possible combination of required documents—quickly becomes unscalable as more conditional steps are added.

In these situations, the recommended approach is to use Local Variables together with Trigger Gates. This allows parallel branches to run independently while still ensuring that downstream steps execute only once, after all required work is complete.

**The overall structure** will look similar to the previous “Holding Bay” pattern, but with two key changes:

* The merge point is replaced with a Local Variable “Gate”
* A Local Variable is initialised at the start, before splitting into parallel branches

The numbered diagram below will be referenced throughout the next steps.

![](../../../images2/zendesk_5341807826335_009_f1a4a9f846e0.png)

**Step 1: Initialise the gate**

First, initialise a Local Variable at the start of the Sequence (“Build Gate”). This variable will be referenced by Triggers 2 and 3, so it must exist before the workflow splits into parallel branches. Use an easy-to-understand flag to represent whether the workflow is still “open” or has already progressed. A Boolean is often the simplest choice, but any consistent value works. In this example, we use a String variable named gate, and set its initial value to “open”.

![](../../../images2/zendesk_5341807826335_010_01c3fa927158.png)

**NB:** The term “gate” is used here as a metaphor for “closing the door behind you.” There is nothing special about the name itself, as long as the logic is applied consistently.

**Step 2: Configure the branch Triggers**

Triggers 2 and 3 are identical. These Triggers control when each parallel branch is allowed to progress.

Each Trigger can include whatever business logic is required for that branch but must also reference the gate variable.

At minimum, the Trigger should check that the Local Variable **gate** contains the value open.

![](../../../images2/zendesk_5341807826335_011_1a287f400aed.png)

**Step 3: Apply the same rule to every branch**

Trigger 3 is configured in exactly the same way as Trigger 2.

This rule applies to all parallel branches in the Sequence. Whether there are two branches or many, every branch must reference the same gate variable.

**Step 4: Close the gate when work is complete**

Using the same Local Variable created in Step 1, the next step is to “close” the gate once the required parallel work has been completed.

In this example, we update the variable using Jinja logic to check that all expected documents are present in their respective fields. If the conditions are met, the gate is set to **closed**.

If the conditions are not yet met, the Variable remains **open**.

![](../../../images2/zendesk_5341807826335_012_a95f8c6336bf.png)

**NB:** Local Variables cannot directly reference Task completion. If your parallel branches end in Tasks, ensure that the Triggers leading into your gate already require those Tasks to be complete. In that case, the gate variable can be set directly to closed without additional Jinja logic.

**Step 5: Trigger the downstream step only when closed**

Finally, the Trigger leading out of the gate should reference the same Local Variable and ensure that it has been set to “closed”. Only once the gate is closed should the workflow progress to the downstream step, such as an API call.

![](../../../images2/zendesk_5341807826335_013_ed3e6a88bcfb.png)

By following this pattern, we eliminate the race condition entirely. In the old approach, we relied on the assumption that only the final parallel branch could ever satisfy the merge Trigger. In practice, that assumption can fail due to queue timing.

With a gate variable in place, this risk is removed. The first branch to meet the completion conditions will progress, trigger the downstream step, and “close the gate” behind it. Any branch arriving shortly afterwards will still evaluate its Trigger but will find that the gate is no longer open and cannot progress.

As a reminder, the gate/door metaphor is for illustration only. In practice, this pattern is commonly implemented as an “all completed” flag, for example a Boolean that starts as false and is updated to true once all required work is complete. Whether you represent the state as true/false, open/closed, or 1/0 does not matter — consistency is what matters.

**Best practice rule**

Avoid relying on invalid Actors or timing assumptions to prevent duplicate execution. Where parallel branches must converge, use explicit gating via Local Variables and Triggers to ensure downstream steps run exactly once.

---

---
url: /knowledgebase/release-notes/release-notes-1.2/json-type-field.md
---

# JSON type field

Introducing a powerful new addition to the Autologyx platform: the JSON field.

With this latest update, JSON fields can be added to their classes and used in record forms.

**Beautify JSON data**\
When you enter data into a JSON field, simply click the beautify icon and watch as the data is automatically structured and formatted for easier readability. With this small but powerful addition, making sense of your data is now quicker and easier than ever before.

![Json\_article.gif](/knowledgebase/images/img_10872448938781_1776895711.png)

**Why use JSON fields?**\
JSON fields allow you to store complex data structures within a single field, making it easy to manage and analyze large amounts of data. Whether you're working with large datasets or just need a better way to organize your data, JSON fields provide a simple and effective solution.

Don’t miss out. Start exploring the power of JSON fields today and discover how it can help you with your data management processes and boost your productivity!

---

---
url: /knowledgebase/terminology.md
---
# Knowledgebase terminology index

This file is built from the saved terminology store.

## actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Sequencer, Sequences, Sequence canvas, API Call actor, Local Variable actor, actor configuration modal, API method

In the Autologyx platform, an **actor** is a configurable step in a Sequence that performs a specific action within a workflow, such as calling an API, setting a local variable, or invoking a dedicated AI capability like the OpenAI: GPT **actor**. Actors are added in the Sequencer by dragging them onto the Sequence canvas and then completing their settings in the **actor** configuration modal, where the behaviour of that step is defined. Dedicated actors are provided for common integrations and use cases, while generic patterns such as the API Call **actor** are used when a workflow needs to interact with external services that do not have a dedicated provider **actor**. Actors matter because they are the building blocks of Sequence design: they determine how data is processed, how systems are connected, and how each automated action is executed in a controlled workflow.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## actor configuration modal

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** actor, Authentication Object, generic API actors, Merge fields, Object Records, OpenAI Embedding Actors, OpenAI embeddings configuration modal, OpenAI: GPT or ChatGPT actor, Record ID

The **actor configuration modal** is the setup dialog in Autologyx used to configure an actor’s runtime settings before it is used in a workflow or integration. In the context of the OpenAI ChatGPT actor, this modal is where configuration admins and developers define the model, authentication, prompt, context, temperature, and test record, so the actor can be connected to the correct service and behave as intended when processing data. It is used when creating or updating AI-enabled actors and works alongside related platform concepts such as Authentication Objects, merge fields, Object Records, and Record IDs to supply credentials, dynamic inputs, and test data. This matters because the values entered in the modal directly control how the actor executes, what data it uses, and how reliably it can be validated before deployment.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## agentic workflows

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** AppliedAI, AppliedAI and the Sequencer, autonomous agents, co pilot agents, headless agents, human in the loop, Loop actors, API Call actor, Autologyx Catalyst, Autologyx MCP Build, Autologyx MCP Success, Autologyx MCP Work

**Agentic workflows** are workflow patterns in Autologyx where an AI assistant or autonomous agent works toward a defined goal by selecting from approved tools and executing process steps within configured boundaries. They are used in the Applied AI capabilities of the platform and are typically implemented alongside workflow components such as agents, Loop actors, API Call actors, and human-in-the-loop controls to coordinate automation with operational oversight. **Agentic workflows** matter because they enable more adaptive, outcome-driven automation than fixed step-by-step orchestration while still requiring platform governance, permissions, auditability, and clear ownership so configuration teams, integrators, and compliance stakeholders can deploy AI-enabled processes safely and consistently.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## AI and the Sequencer

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** AWS Bedrock, Bedrock actor, Sequencer, Sequences, deterministic Sequence logic, Model, Provider, Configurations

**AI and the Sequencer** is the Autologyx capability for incorporating AI services into Sequencer-driven workflows, allowing Sequence steps to call configured AI models while remaining part of the platform’s orchestration and deterministic Sequence logic. It is used when configuration admins, developers, and super admins set up providers, models, and actors such as the Bedrock actor so Sequences can use services delivered through platforms like AWS Bedrock. This matters because it defines how AI is connected to and governed within Autologyx: AI is not configured as a standalone workflow outside the Sequencer, but as an integrated execution option within Sequences, using approved provider and model combinations that align with the customer’s platform and cloud configuration.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)

## API Call actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Sequencer, Sequences, actor, AppliedAI, AppliedAI and the Sequencer

The **API Call actor** is a Sequencer actor in the Autologyx platform that sends outbound REST requests from a Sequence to external services, including AI endpoints, customer-controlled gateways, and privately hosted models where no native actor is available. It is configured within a Sequence to pass record data, extracted document text, prompts, instructions, and other structured inputs to an API, then receive JSON responses that can be stored on the source record or passed to later actors for further processing. This actor matters to configuration admins and developers because it provides a flexible integration pattern for connecting Catalyst workflows to supported and non-native AI services, private model infrastructure, and reusable automation designs without requiring a dedicated product-specific actor.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/)
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## API method

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Authentication Object, OpenAI: GPT actor, actor, ML and AI tab

In the Autologyx platform, an **API method** is the authentication method selected on an Authentication Object when a service connects to an external system by using that system’s API credentials rather than an interactive user sign-in flow. It is used during configuration by administrators and integrators setting up actors and service integrations, such as the OpenAI: GPT actor, where the Authentication Object must be configured with the **API method** to store and use the required API key. This matters because the chosen method determines how Autologyx authenticates outbound requests, enabling the platform to securely access external services and allowing integrations to run correctly within workflows and AI-driven automation.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)

## Applied AI

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Public AI Providers, The Sequencer, Embedding Model Actors, Autologyx Classification, Unrestricted, Public
* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/)

## AppliedAI

* **Mostly relevant to:** Configuration admins, Developers / Integrators, End-users
* **Closely related concepts:** Sequencer, AppliedAI and the Sequencer, agentic workflows, model agnostic orchestrator, API Call actor, MCP services

**AppliedAI** in Autologyx is the platform capability that embeds AI services into structured, governed Catalyst workflows, allowing organisations to understand, summarise, extract, and act on unstructured information within a controlled process rather than through a standalone tool. It is used in workflow design and execution, especially with the Sequencer, where defined workflow steps send structured requests to AI services, receive responses, and use those outputs in later steps as part of an agentic workflow orchestrated by Autologyx. **AppliedAI** is model agnostic and works alongside related platform components such as API Call actors and MCP services, while operating within Autologyx security, permissions, auditability, and hard-stop access controls. This matters to configuration admins, developers, integrators, and end-users because it enables AI-assisted automation at scale without giving up process control, policy alignment, transparency, or the predictable operation of business workflows.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/)
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## AppliedAI and the Sequencer

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** AppliedAI, Autologyx Catalyst, API Call actor, Loop actors, agentic workflows, autonomous agents, headless agents, human in the loop

**AppliedAI and the Sequencer**, also described as the Sequencer pattern, is the AppliedAI design pattern in Autologyx where Catalyst workflow automation initiates outbound requests to AI services, orchestrates each step of the interaction, and uses returned outputs within a controlled workflow. It is used in Catalyst processes that send structured prompts and record context to supported AI endpoints, including native integrations and API Call actor connections to external or privately hosted models, and it can be combined with Loop actors and reusable playbook-style Object Classes for repeated extraction, classification, or content-processing tasks. This pattern matters because it keeps AI activity inside human-designed, auditable business processes, allowing configuration admins and developers to control when AI is called, how responses are consumed in later steps, which services and models are used, and how governance, transparency, and access control are enforced across AI-driven workflow automation.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## approved agent

* **Mostly relevant to:** End-users, Configuration admins, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** Autologyx MCP Work, autonomous pattern, co pilot pattern, controlled autonomous workflows, Automatic Task, Autologyx MCP Customer Success

An **approved agent** is an AI assistant or agent that has been explicitly enabled within Autologyx to use MCP Work tools under the customer’s configured permissions, enabled capabilities, and governance controls. In the Autologyx platform, approved agents are used in MCP Work to participate directly in operational processes by working alongside users or within controlled autonomous workflows, including activities such as finding and reading records, updating structured data, creating related records, managing tasks, and generating documents where permitted. This matters because approval determines which AI assistants and agents are allowed to operate in the system of record, ensuring that operational actions are limited to authorised tools and configurations for end users, administrators, and compliance teams.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## asynchronous Object Record hierarchy creation process

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** check object records hierarchy creation, create object records hierarchy, child Object Record, child Object Class, create object record

The **asynchronous Object Record hierarchy creation process** is an Autologyx background operation that creates an Object Record together with its related child Object Records as a hierarchy without requiring the caller to wait for completion in the same request. It is used by developers and integrators through MCP Work tooling, where one tool starts the hierarchy creation and the companion check object records hierarchy creation tool is used to retrieve the process status after submission. This matters when integrating with Autologyx because creating parent and child Object Records as a single asynchronous process supports structured data onboarding at scale, allows long-running hierarchy creation to be monitored separately from the initial request, and helps external systems coordinate follow-up actions only after the hierarchy has finished processing.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## Auth Object

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Authentication Object, AWS Bedrock integration, Bedrock actor, Test Integration

An **Auth Object**, or Authentication Object, is the Autologyx configuration item used to supply the credentials and authentication method required when the platform connects to an external service. In the AWS Bedrock integration, the **Auth Object** is selected in the integration configuration to authenticate requests sent to AWS Bedrock, and it must be set up to use the customer’s approved AWS authentication approach. This matters to configuration admins and developers because the correct **Auth Object** is essential for establishing secure connectivity, enabling the integration to function, and ensuring the platform uses the intended access model when invoking external services.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)

## Authentication Object

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** actor, Test Integration, System Configuration Sequences

An **Authentication Object** is an Autologyx configuration item that stores the credentials and authentication settings used by the platform to connect securely to external services and APIs. It is selected in actor and integration configuration wherever an Auth Object field is shown, including OpenAI, Azure OpenAI, AWS Bedrock, privately hosted model connections, and related Test Integration or System Configuration Sequence setup steps. Authentication Objects matter because they provide a reusable, centrally managed way to supply approved API keys or cloud authentication details, helping administrators, super admins, and integrators standardise external connections, simplify configuration, and keep authentication separate from individual workflow or actor definitions.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## Autologyx Catalyst

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** AppliedAI, Sequencer, Sequences, OpenAI: GPT actor, API Call actor, actor, model agnostic orchestrator, agentic workflows, MCP services

**Autologyx Catalyst** is the core Autologyx platform environment that orchestrates workflow-driven processing, including AI-augmented automation through Sequencer-based workflows. In Catalyst, configuration admins, developers, and super admins use the Administration area, Sequence builder, actors, integrations, and API-based tooling to define how work is triggered, routed, processed, and audited. Within AppliedAI, Catalyst serves as the model-agnostic orchestrator: it remains responsible for the workflow, data model, permissions, routing, task creation, and audit trail while invoking AI services through native actors such as the OpenAI: GPT actor, API Call actors, and related integrations. This matters because Catalyst is the platform layer where organisations configure controlled, production-grade processes that combine business workflow automation with external AI services, hosted models, private endpoints, and reusable agentic or MCP-enabled patterns.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## Autologyx Classification

* **Mostly relevant to:** Information Security / Compliance / Analytics, Super Admins, Configuration admins
* **Closely related concepts:** Unrestricted, Public, Applied AI, Public AI Providers, Embedding Model Actors, API Call actor, Autologyx MCP Customer Success

**Autologyx Classification** is the platform’s content classification label shown in documentation and configuration contexts to indicate the handling category assigned to Autologyx material or capabilities. In the supplied Applied AI and MCP documentation, it is used as a page-level designation such as “Unrestricted, Public,” helping super admins, configuration admins, and compliance stakeholders identify whether information about features like Public AI Providers, Embedding Model Actors, API Call actors, and MCP services is approved for open sharing and standard use. This matters because the classification provides a clear governance signal for how platform information should be distributed, reviewed, and consumed when enabling integrations, documenting solutions, or managing security and compliance expectations.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/)
  * [`applied-ai/mcp-services/mcp-customer-success/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-customer-success/)

## Autologyx Classification: Unrestricted, Public

* **Mostly relevant to:** Information Security / Compliance / Analytics, Super Admins
* **Closely related concepts:** OpenAI: GPT or ChatGPT actor, OpenAI Embedding Actors, Authentication Object

**Autologyx Classification: Unrestricted, Public** is the platform’s data-handling classification for capabilities, providers, or configurations that are approved only for information intended to be openly shareable and not subject to internal, confidential, personal, or regulated handling controls. In Autologyx documentation and configuration guidance, this classification is shown on items such as public AI provider integrations, including OpenAI-related actors and embedding actors, to indicate the permitted sensitivity of data that can be sent to or processed by that component. This classification matters to Super Admins and compliance-focused users because it determines whether a feature is appropriate for a given use case, informs provider selection and authentication design, and helps ensure that workflows, prompts, documents, and outputs are aligned with organisational information security and governance requirements.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## Autologyx configuration experience

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** create object record, create object records hierarchy, check object records hierarchy creation
* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## Autologyx configuration team

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Privately hosted models, generic API integration capability, API Call actor, Authentication Object, Sequencer, Sequences

The **Autologyx configuration team** is the specialist group responsible for designing and implementing platform configuration required to deliver customer solutions in Autologyx, particularly where advanced integrations are involved. In documentation, the term is used in the context of privately hosted model integrations, where the **Autologyx configuration team** works jointly with the customer’s AI, data science, security, and cloud platform teams to define the integration design and agree production data flows. This matters to Configuration admins, Super Admins, and Developers or Integrators because these configurations directly affect how capabilities such as API-based model connections, authentication setup, API Call actors, Sequencer logic, and Sequences are structured and deployed within the platform.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)

## Autologyx environment

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** AWS Bedrock integration, Bedrock actor, AI and the Sequencer, Test Integration

An **Autologyx environment** is the specific platform instance in which organisation-level features, integrations, and controls are configured and made available for use. It is used by configuration administrators and Super Admins to enable capabilities such as the AWS Bedrock integration, define which external services can be accessed, and align platform behaviour with account, region, security, and governance requirements. In practice, whether components such as a Bedrock actor or AI-driven workflow pattern can be used in Sequencer depends on what has been enabled in the **Autologyx environment**. This matters because the environment determines the operational scope of the platform for a customer, controlling which integrations are available and ensuring workflows run within the organisation’s approved technical and compliance boundaries.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)

## Autologyx governance gateway

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics, Developers / Integrators
* **Closely related concepts:** MCP services, MCP enabled agent, MCP mappings, MCP tool catalogue, Autologyx MCP Work, Available MCP Work tools

The **Autologyx governance gateway** is the platform control layer used to govern how MCP-enabled agents access and use MCP services within Autologyx. It is used when configuring MCP integrations alongside Autologyx permissions, MCP mappings, user accounts, and user groups to define exactly what an agent can see and do. In practice, the governance gateway provides finer-grained control than connector-level restriction settings in the agent client, allowing administrators to enforce platform-level access rules and operational boundaries across available MCP Work tools and related services. This matters because it helps configuration, security, compliance, and integration teams ensure agent behaviour aligns with organisational policy, approved access models, and safe service exposure within the platform.

* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)

## Autologyx MCP Build

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** AppliedAI, AppliedAI and the Sequencer, Autologyx MCP Success, Autologyx MCP Work, Catalyst workflow automation, API Call actor, agentic workflows, autonomous agents, co pilot agents, headless agents, human in the loop, hard stop gated control

**Autologyx MCP Build** is the Autologyx platform capability area for AI-assisted Catalyst configuration, enabling supported services and agents to create and manage build components such as Object Classes, forms, Task Templates, users, groups, permissions, sequences, and related configuration assets. It is used in the AppliedAI context alongside Autologyx MCP Work and Autologyx MCP Success, extending MCP services from operational understanding into configuration and platform design activities. This matters to Configuration admins, Developers and Integrators, and Super Admins because it defines how AI can participate in building and maintaining Catalyst workflow automation while aligning with platform controls, agentic workflow patterns, and governed human-in-the-loop administration.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## Autologyx MCP Customer Success

* **Mostly relevant to:** Configuration admins, Super Admins, End-users
* **Closely related concepts:** Autologyx MCP Work

**Autologyx MCP Customer Success** is the MCP service in the Autologyx platform that provides product knowledge, configuration guidance, and solution design support for Autologyx implementations. It is used when configuration admins, Super Admins, and end-users need help understanding Autologyx concepts, selecting configuration patterns, structuring platform components, or applying implementation guidance during setup and adoption. Referenced throughout the MCP documentation as the destination for platform knowledge questions, it complements Autologyx MCP Work by focusing on how to design and configure solutions correctly, making it important for consistent platform setup, effective solution design, and faster user enablement.

* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-customer-success/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-customer-success/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## Autologyx MCP endpoint

* **Mostly relevant to:** Developers / Integrators, End-users
* **Closely related concepts:** MCP services, MCP enabled agent, MCP tool catalogue, Available MCP Work tools, MCP mappings, Autologyx MCP Work, Autologyx MCP Customer Success

The **Autologyx MCP endpoint**, also referred to as the **Autologyx MCP endpoint** URL or MCP endpoint, is the connection URL that external MCP-compatible clients use to connect to Autologyx. In the Autologyx platform, it is used when configuring a custom connector or creating a new app in supported clients so the client can sign in as a user and complete authorisation through Autologyx. This endpoint is a core part of enabling access to Autologyx MCP services, tools, and related MCP-enabled capabilities, because it defines where the client connects to start the integration and establish access to available Autologyx work through MCP.

* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)

## Autologyx MCP Success

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** AppliedAI, Autologyx MCP Build, Autologyx MCP Work

**Autologyx MCP Success** is the Applied AI capability in the Autologyx platform that provides Knowledgebase access together with design, planning, and configuration guidance. It is used where approved AI assistants support users in shaping solutions, answering platform questions, and guiding configuration activity, rather than working with live tasks or operational data. For configuration admins and Super Admins, MCP Success matters because it helps translate Autologyx best practice and Customer Success guidance into practical solution design decisions, making it easier to plan implementations, configure the platform effectively, and distinguish advisory support from the execution-focused role of Autologyx MCP Work.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## Autologyx MCP Work

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins, End-users
* **Closely related concepts:** Autologyx MCP Customer Success, Object Records, Manual Task, Automatic Task, Sequences, service account, autonomous pattern, co pilot pattern

**Autologyx MCP Work**, also called MCP Work, is the Autologyx MCP service and tool collection used by approved AI assistants, co-pilots, and autonomous agents to perform operational work against live Autologyx data and services. It is used in Applied AI and MCP-enabled workflows wherever agents need to interact with object records, tasks, documents, sequences, and processes, including reading and updating records, assigning and completing manual or automatic tasks, and generating documents through controlled access such as approved tools and service accounts. MCP Work matters because it extends live process execution inside Autologyx, allowing users and administrators to design agent patterns, permissions, audit controls, and safe write actions so agents can work alongside end-users or operate autonomously without being used for product configuration.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## Automatic Task

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Autologyx MCP Work, Manual Task, Object Records, child Object Record, parent Object Record

An **Automatic Task** in Autologyx is a task instance created from a Task Template and an Object Record, including through Autologyx MCP Work tools used by developers, integrators, and configuration administrators. It is used when the platform or an approved agent needs to create work directly against a specific record, including within parent and child Object Record structures, without relying on a user to manually create the task. Automatic Tasks matter because they let configured processes and integrations generate the right work item in the correct record context, helping ensure task creation is consistent with the selected template, aligned to the relevant business object, and available for downstream assignment, data capture, and task management in the platform.

* **Pages:**
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## autonomous agents

* **Mostly relevant to:** End-users, Configuration admins, Developers / Integrators
* **Closely related concepts:** co pilot agents, AppliedAI, agentic workflows, headless agents, human in the loop, Loop actors, AppliedAI and the Sequencer

**Autonomous agents** in Autologyx are AppliedAI operating components that use approved tools to act on live Autologyx data and services within structured workflows, rather than outside platform controls. They are used in AppliedAI-enabled processes and in Sequencer-driven interactions where the platform sends structured requests to AI services, receives responses, and applies those responses in later workflow steps under defined permissions and policies. For end-users, configuration admins, and developers, **autonomous agents** matter because they enable AI-driven work to be executed with governance, granular access control, auditability, hard-stop gating, and clear separation between advisory behaviour and actions that change live data, allowing organisations to automate work while retaining enterprise-grade control and transparency.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## autonomous pattern

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** Autologyx MCP Work, co pilot pattern, approved agent, Autologyx governance gateway, Available MCP Work tools, service account

An **autonomous pattern** in the Autologyx platform is an MCP usage pattern in which an agent is allowed to carry out a defined set of actions without requiring a user prompt for every step. It is used when designing and configuring Autologyx MCP Work integrations, especially when planning which available tools an agent can use, setting permissions, and applying governance controls through related platform components such as approved agents, service accounts, and the Autologyx governance gateway. This pattern matters because it changes how work is executed and controlled: autonomous patterns must be designed with narrower permissions, stronger governance, and careful risk assessment to ensure agents can act effectively within clearly defined operational boundaries.

* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## Available MCP Work tools

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Autologyx MCP Work, MCP tool catalogue, MCP services, MCP enabled agent, MCP mappings
* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)

## AWS Bedrock

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** AI and the Sequencer, Bedrock actor, Provider, Model, Sequencer, Sequences, Authentication Object, Configurations

**AWS Bedrock**, also called Amazon Bedrock or Bedrock, is the Amazon Web Services integration used in Autologyx when a Sequence needs to call a foundation model through AWS instead of a direct public provider integration. In the platform, it is used within AI and the Sequencer through the Bedrock actor, together with related configuration such as the selected provider and model, authentication objects, and environment configurations. It matters to configuration admins and developers because it lets Autologyx workflows use models made available through Bedrock while keeping AI access aligned with the customer’s AWS account, region, governance, security, and access controls, and it supports flexible model choice across multiple providers and model families enabled in the customer’s AWS environment.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)

## AWS Bedrock integration

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** AI and the Sequencer, Autologyx environment, Bedrock actor, Sequencer, Sequences, Test Integration

**AWS Bedrock integration** is the Autologyx platform capability that enables an environment to connect to Amazon Bedrock so AI-powered features can be configured and used within Sequences and the Sequencer. It is used during platform and environment setup, where configuration admins, super admins, and developers or integrators must ensure the integration is enabled before configuring Bedrock-related components such as a Bedrock actor or testing the connection through integration setup. This integration matters because it is the prerequisite that makes Amazon Bedrock available inside an Autologyx environment, allowing teams to use Bedrock-backed AI services as part of sequence design, execution, and applied AI configuration.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)

## Azure OpenAI actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Sequence actors, Sequencer, Sequences, Azure OpenAI configuration modal, Authentication Object, Sequence canvas

The **Azure OpenAI actor** is a Sequence actor in the Autologyx Sequencer that enables a workflow to call an OpenAI model through a customer’s Azure OpenAI endpoint instead of the public OpenAI API. It is used on the Sequence canvas when building AI-enabled Sequences, and is configured through the Azure OpenAI configuration modal with the required Azure connection and authentication details, typically alongside an Authentication Object. This actor matters to configuration admins and developers because it provides an enterprise-controlled route to GPT-style model access within Autologyx, aligning workflow automation with Azure-hosted networking, identity, monitoring, policy, regional, and governance requirements while allowing organisations to use approved Azure OpenAI deployments in their workflows.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)

## Azure OpenAI configuration modal

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Azure OpenAI actor, Authentication Object, Sequence actors, Sequencer, Sequences, Merge fields, Object Records, Record ID, Sequence canvas

The **Azure OpenAI configuration modal** is the settings dialog used to configure an Azure OpenAI actor in the Autologyx Sequencer. It is opened from the actor configuration on the Sequence canvas and is used by configuration admins and developers to define the Azure OpenAI endpoint, model type, model, authentication, prompt, context, temperature, and test record for the actor. This modal is important because it controls how the Sequence sends requests to Azure OpenAI, supports testing the actor against a record, and keeps credentials managed through an authentication object rather than exposing them directly in the actor configuration.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)

## Bedrock actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** AWS Bedrock, AI and the Sequencer, Sequencer, Sequences, Provider, Model, Authentication Object, Configurations

The **Bedrock actor** is the Sequencer component in Autologyx that connects a workflow to AWS Bedrock so AI model requests can be executed as part of a controlled sequence. It is used when configuring AI-enabled Sequences in the Sequencer, where administrators and integrators select a Bedrock provider and model, apply the required actor settings, and verify the connection before production use. The **Bedrock actor** groups available AWS Bedrock models by provider, including Amazon and third-party model families exposed through the customer’s AWS environment, so the exact options and settings depend on the selected provider and model. This matters because it is the configuration point that determines how Autologyx invokes AWS Bedrock within platform workflows, aligning model access, connection setup, and runtime behaviour with the customer’s AWS configuration.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)

## Catalyst workflow automation

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** API Call actor, AppliedAI, AppliedAI and the Sequencer

**Catalyst workflow automation** is the Autologyx workflow execution layer used to initiate outbound requests to AI services, orchestrate those interactions within a controlled process, and apply the returned results inside a running workflow. In practice, it is used in AppliedAI patterns such as AppliedAI and the Sequencer, where configuration admins and developers connect workflows to supported AI providers, private model endpoints, customer AI gateways, or custom endpoints through components such as the API Call actor. This matters because it lets teams embed AI-driven extraction, classification, text processing, document conversion, and reusable prompt-based tasks directly into operational workflows while keeping orchestration, control, and process execution inside the Autologyx platform.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## ChatGPT Actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** actor, native actor, OpenAI Embedding Actors, generic API actors, actor configuration modal, Merge fields, Sequence canvas

The **ChatGPT Actor**, shown in Autologyx as the OpenAI: GPT or **ChatGPT actor**, is a native Sequence actor used to send a prompt from a workflow to an OpenAI chat model and use the returned response within the Sequence. It is added to the Sequence canvas like other actors and configured in the actor configuration modal, where administrators or developers define the model, authentication, prompt, context, temperature, and test record. This actor is the standard starting point for language-focused automation tasks such as drafting, classification, summarisation, and language understanding in controlled workflows. It matters because it turns model output into usable workflow data that can be stored, transformed, or passed to later Sequence steps through merge fields and other downstream logic.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## check object records hierarchy creation

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** create object records hierarchy, create object record, get object record

**Check object records hierarchy creation** is an MCP Work tool in the Autologyx platform that returns the status of an asynchronous Object Record hierarchy creation process. It is used alongside create object records hierarchy to monitor whether a requested hierarchy build has completed and to support follow-on actions that depend on the new parent-child Object Record structure being available. This matters to developers and integrators because hierarchy creation does not complete immediately, so checking its status is essential when orchestrating integrations, sequencing automated work, and retrieving or updating the created records only after the hierarchy has been successfully created.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## child Object Class

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Object Classes, parent Object Class, Object Records, child Object Record, parent Object Record, Autologyx MCP Work

In the Autologyx platform, a **child Object Class** is an Object Class that is defined as a direct subordinate of a parent Object Class in the platform’s object hierarchy. This relationship is used in Autologyx MCP Work, where tools such as list object class children return the direct child Object Classes available for a specified parent Object Class, and list object class parents returns the corresponding direct parent Object Classes for a **child Object Class**. Child Object Classes matter to configuration admins and developers because they determine which object structures can be created under another object type, shaping valid parent-child hierarchies for Object Records and supporting correct configuration, integration logic, and hierarchy preparation workflows.

* **Pages:**
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## child Object Record

* **Mostly relevant to:** Configuration admins, Developers / Integrators, End-users
* **Closely related concepts:** Object Records, parent Object Record, Object Classes, parent Object Class, child Object Class, Autologyx MCP Work

A **child Object Record** is an Object Record that exists in a defined parent-child relationship under a parent Object Record, according to the platform’s Object Class structure. In Autologyx, child records are used to model related data and work items beneath a parent record, such as creating a parent record together with nested child records, finding which child records are linked to a parent, finding which parent records a child is linked to, and removing the relationship between parent and child records. This concept is used in record configuration and in MCP Work tools that navigate, validate, create, and manage related record structures. It matters because child Object Records determine how information is organised, which related record types can be created under a parent, and how agents, users, and integrations work with connected records in the platform.

* **Pages:**
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## co pilot agents

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** autonomous agents, AppliedAI, AppliedAI and the Sequencer, agentic workflows, headless agents, human in the loop, Loop actors, API Call actor, Autologyx MCP Build, Autologyx MCP Work, Autologyx MCP Success, Autologyx Catalyst

**Co pilot agents** are approved AI assistants in Autologyx AppliedAI that work alongside users inside structured workflows, using defined tools to interact with live Autologyx data and services under platform governance. They are used through MCP Work and the Sequencer to support co-pilot style experiences, including helping configuration users and Config Admins plan, architect, design, and build workflows and solutions with Autologyx technology, while drawing on sources such as the Autologyx Knowledgebase and Customer Success experience. **Co pilot agents** matter because they bring AI assistance into controlled operational processes rather than outside them, with auditability, granular permissions, hard-stop access controls, separation between guidance and live-data-changing actions, and optional human-in-the-loop steps so organisations can enable productive AI support without compromising security, control, or transparency.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## co pilot pattern

* **Mostly relevant to:** Developers / Integrators, End-users
* **Closely related concepts:** Autologyx MCP Work, autonomous pattern, approved agent, service account, Available MCP Work tools

A **co pilot pattern** is an MCP or MCP Work agent pattern in Autologyx where the agent operates alongside a named user rather than acting independently. It is used in Applied AI and MCP-based implementations, including Autologyx MCP Work, when an agent supports a person as they complete work and can pause to request user confirmation before specific actions continue. This pattern matters because it keeps the user directly involved in execution and decision points, making it a practical starting approach for configuring agent-assisted workflows where human oversight, user context, and controlled action progression are important.

* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## Configurations

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** AWS Bedrock, Bedrock actor, Model, Provider, AI and the Sequencer

In the Autologyx platform, **Configurations** are the settings used to define additional model-specific options for an AI provider integration. They are used in provider setup areas such as AWS Bedrock, where the **Configurations** section holds the parameters required to tailor how a selected model is used by the platform. This matters to configuration administrators and developers because these settings control the behavior and compatibility of the model within Autologyx, ensuring the provider, actor, and model are configured correctly for use with AI features in the Sequencer.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)

## controlled autonomous workflows

* **Mostly relevant to:** End-users, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** approved agent, Autologyx MCP Work, autonomous pattern, co pilot pattern

**Controlled autonomous workflows** are Autologyx workflows in which approved agents perform defined work within the platform autonomously under configured permissions, tool access, and risk controls, without requiring a user to act alongside them at each step. In practice, this term is used in the context of Autologyx MCP Work and solution design, where administrators and advanced designers decide how agents can operate, what tools they can use, and what governance boundaries apply. **Controlled autonomous workflows** matter because they let organisations extend automation beyond user-assisted co-pilot interactions while maintaining security, compliance, and operational control through deliberate configuration of permissions, approved agent behaviour, and oversight mechanisms.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## create object record

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** child Object Class, child Object Record, create object records hierarchy, asynchronous Object Record hierarchy creation process, check object records hierarchy creation

**Create object record** is an MCP Work tool in the Autologyx platform that creates a new Object Record, giving developers and integrators a programmatic way to add a single record to the object model used by a work solution. It is used in MCP-based integrations and automation when an external service or custom implementation needs to create an individual record directly, rather than creating a full parent-and-child structure in one operation. This matters because Object Records hold the structured business data that processes, services, and related records depend on, so using **create object record** correctly is a fundamental step when building integrations that populate or extend Autologyx object data.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## create object records hierarchy

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** asynchronous Object Record hierarchy creation process, check object records hierarchy creation, child Object Record, child Object Class, create object record

**Create object records hierarchy** is an MCP Work tool in the Autologyx platform that starts an asynchronous process to create a parent Object Record together with its nested child Object Records in a single hierarchy. It is used by developers, integrators, and configuration administrators when a business object must be created with its related child Object Classes and child Object Records as one structured operation rather than as separate record-creation steps. This matters because it provides a consistent way to establish complete object relationships from the outset, supports integrations and automated workflows that need to submit hierarchical data, and works with the corresponding hierarchy creation status check to manage processing that completes asynchronously.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## custom Object Class fields

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** field aliases, field slug, get object class, create object record, get object record

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## dedicated actors

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Autologyx Catalyst, AppliedAI, Sequencer, API Call actor, model agnostic orchestrator, MCP services

**Dedicated actors**, also called native AI actors, are platform-provided actors in Autologyx Catalyst that deliver native connectivity and configuration for commonly used AI providers within Sequencer-driven workflows. They are used when configuring AI interactions in the platform, offering a built-in setup experience instead of relying solely on generic integration patterns such as an API Call actor or external service orchestration. **Dedicated actors** matter because they simplify common provider integrations, reduce configuration effort for administrators and developers, and help standardize how AI services are invoked as part of workflow automation.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/)

## dedicated AI actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** generic API integration capability, API Call actor, Privately hosted models, Sequencer, Sequences, standard OpenAI, Azure OpenAI, or AWS Bedrock actors

A **dedicated AI actor**, also referred to as an AI actor, is a purpose-built actor in an Autologyx Sequence that connects directly to a supported AI service, such as the standard OpenAI, Azure OpenAI, or AWS Bedrock actors, rather than using the platform’s generic API integration capability. It is used when configuring Sequences in the Sequencer to invoke AI models through a packaged actor designed for that provider or service. This matters to configuration admins and developers because it determines how AI functionality is implemented in a workflow: supported services can be added through dedicated actors, while privately hosted or otherwise unsupported models are connected by using an API Call actor or other generic API integration approach instead.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)

## deterministic Sequence logic

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Sequencer, Sequences, AI and the Sequencer, API Call actor

**Deterministic Sequence logic** is the fixed, rule-based workflow logic configured in an Autologyx Sequence to control how steps run, how data is validated and transformed, and how downstream actions are triggered without variability in execution. It is used in Sequence design and integration scenarios, particularly when combining AI-driven steps with standard workflow automation, API Call actors, and structured outputs that must be parsed and acted on reliably. This matters because **deterministic Sequence logic** provides the predictable orchestration layer around non-deterministic model responses, helping configuration admins and developers enforce validation rules, route work consistently, and ensure later workflow steps operate on controlled, machine-usable data.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)

## document automation

* **Mostly relevant to:** End-users, Configuration admins, Developers / Integrators
* **Closely related concepts:** Autologyx MCP Work, document generation, document template

**Document automation** in the Autologyx platform is the capability used to create and manage documents as part of live operational work within an existing process. It is used alongside activities such as finding records, updating data, managing tasks, and navigating record relationships, and is exposed in areas such as Autologyx MCP Work where documents form part of the work being carried out. This matters because it lets end-users produce the required documents in context, while configuration admins and integrators can embed document-driven steps into controlled workflows that benefit from Autologyx data structures, permissions, and auditability.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## document generation

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** document template, Object Records, Autologyx MCP Work

**Document generation** in the Autologyx platform is the process of creating a document for an Object Record from a configured document template and then making the resulting generated document payload, metadata, status, and download information available through Autologyx MCP Work tools. It is used in agent-enabled workflows through the generate object record document, get object record document, and download object record document capabilities, allowing approved agents and integrations to start generation, monitor processing, and retrieve the finished output where permissions allow. This matters to developers, integrators, and configuration admins because it connects template-driven document production to record data and operational workflows, supports automated and human-reviewed communications and outputs, and requires correct tool enablement, permissions, and customer configuration to control how documents are produced and accessed.

* **Pages:**
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## document template

* **Mostly relevant to:** Configuration admins, Developers / Integrators, End-users
* **Closely related concepts:** Object Records, Object Classes, document generation, Autologyx MCP Work, Sequences

A **document template** in the Autologyx platform is a configured template used to generate documents for a specific Object Class and, in practice, for a specific Object Record. It is used in document generation features across the platform, including Sequences that apply a template as part of workflow automation and Autologyx MCP Work tools that search document templates, retrieve template details, and start document generation by supplying an Object Record ID and **Document Template** ID. Document templates matter because they connect platform data to repeatable document outputs, allowing configuration admins and integrators to define standardised generation behaviour and enabling end-users and approved agents to produce the correct document directly from the relevant record as part of operational work.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## document URL

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** document UUID, download object record document

A **document URL** in Autologyx is the URL returned in document metadata for a generated or completed document, used by integrations and MCP Work tools as the source from which the document UUID is extracted. It appears in tool outputs alongside processing status and other metadata, and it is a required intermediary when a workflow needs to download the file for a completed document, because the UUID from that URL is then supplied to the download object record document operation. This matters to developers and integrators because document retrieval depends on handling the **document URL** correctly: it links document generation output to the subsequent API call that fetches the actual file.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## document UUID

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** document URL, download object record document

In Autologyx, the **document UUID** is the unique identifier for a generated document instance and is used by developers and integrators when calling MCP Work tools that need to retrieve or download a specific document file. It is not entered manually as a business field; instead, it is extracted from the document URL returned in document metadata, then passed with related identifiers such as the Object Record ID and Document Template ID to the relevant service call. This matters because the **document UUID** is the key that links API operations to the exact document instance, ensuring that downstream automation, file retrieval, and integration workflows act on the correct completed document.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## download object record document

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** document generation, document URL, document UUID, create object record, create object records hierarchy, check object records hierarchy creation, asynchronous Object Record hierarchy creation process, child Object Record, child Object Class

In the Autologyx platform, **download object record document** is an MCP Work tool used to retrieve a generated document that belongs to an Object Record, including both the document file payload and its associated metadata. It is used by developers and integrators in workflows that generate documents from Object Records, typically after creating records or record hierarchies and obtaining the relevant document identifier or URL. This tool matters because it provides the final access step for consuming generated output in downstream systems, enabling integrations to collect, store, transmit, or present the exact document produced by an Autologyx process together with the metadata needed to identify and manage it correctly.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## Email Intake Object Class

* **Mostly relevant to:** Configuration admins
* **Closely related concepts:** Object Classes, OpenAI: GPT actor, actor
* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)

## Embedding Model Actors

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Applied AI, Public AI Providers, The Sequencer, Unrestricted, Public
* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/)

## field aliases

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Object Classes, Object Records, Autologyx MCP Work

**Field aliases** are the canonical key names used by Autologyx MCP Work to identify Object Class fields when creating, updating, or filtering Object Records. In MCP Work tools, field values are passed using these aliases rather than display labels, and the platform provides a tool to list the valid fields and aliases for a specific Object Class so the correct keys can be used. This matters to developers, integrators, and configuration admins because record operations depend on supplying valid aliases for the target Object Class; using the correct aliases ensures data is written to and read from the intended fields and supports reliable automation and integration behaviour.

* **Pages:**
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## field slug

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** create object record, Autologyx configuration experience

In the Autologyx platform, a **field slug** is the stable identifier used to reference a field in configuration-driven and integration contexts, rather than the field’s display label. It is used when defining or consuming create and update operations, including MCP Work tools, where tool aliases are normally derived from the **field slug** value without its prefix. Field slugs matter because they provide a consistent, implementation-level name for fields across configuration and automation, helping developers, integrators, and configuration administrators map data correctly, build reliable object record operations, and avoid ambiguity when display names change.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## generate object record document

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** document generation, document template, download object record document, document URL, document UUID, create object record

**Generate object record document** is an MCP Work tool in the Autologyx platform that starts document generation for a specific Object Record using a selected Document Template. It is used by developers and integrators when automating work that produces platform documents from record data, typically as part of a workflow or service interaction that creates, retrieves, or distributes generated outputs. This matters because it is the action that initiates creation of the document asset tied to a business record, forming the link between structured object data and the final generated file that can then be identified, accessed, or downloaded through related document URL or document UUID operations.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## generic API actors

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** actor, Authentication Object, OpenAI Embedding Actors, OpenAI embeddings configuration modal, OpenAI: GPT or ChatGPT actor

**Generic API actors** are Autologyx actors used to make direct HTTP API calls to external services when a native actor does not provide the required capability or level of control. In the platform, they are configured and used by administrators and developers within workflow and integration designs to call provider-specific endpoints directly, including advanced OpenAI endpoints that sit outside the standard OpenAI actor experience. This matters because **generic API actors** give integrators a flexible way to extend Autologyx with custom request handling, endpoint access, and provider features, while still operating within the platform’s actor-based automation model.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## generic API integration capability

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** API Call actor, Authentication Object, Privately hosted models, Sequencer, Sequences, structured responses

In Autologyx, the **generic API integration capability** is the platform pattern for connecting a Sequence to an external HTTP-based service without requiring a dedicated purpose-built actor. It is used within workflow design and configuration, typically through an API Call actor or a similar integration pattern, to send structured requests to an endpoint, authenticate using an Authentication Object where required, and consume the returned data later in the workflow. This capability is especially relevant when integrating privately hosted models or other external services that are not covered by a native Autologyx actor. It matters because it gives configuration admins and developers a flexible, reusable way to extend platform workflows, orchestrate external processing from the Sequencer, and bring structured responses back into Sequences for downstream automation.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)

## get document template

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** document template, document generation, document UUID, document URL, download object record document

**Get document template** is an MCP Work tool in the Autologyx platform that retrieves the details of a single Document Template. It is used by developers, integrators, and configuration administrators when they need to look up a template by its identifier and inspect the template definition that supports document generation in a workflow. This matters because Document Templates control how generated documents are structured and referenced, so being able to retrieve a specific template is essential for validating configuration, supporting integrations that depend on template metadata, and linking document generation processes to the correct template, document UUID, document URL, or related document download actions.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## get object class

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** child Object Class, Autologyx configuration experience

In the Autologyx platform, **get object class** is an MCP Work tool used to retrieve the details of a single Object Class, which is a core configuration element that defines a business object and its structure within the configuration experience. It is used by developers, integrators, and configuration administrators when they need to inspect the definition of a specific Object Class, including information relevant to related concepts such as child Object Class relationships. This matters because Object Classes underpin how data structures and configurable business objects are defined in Autologyx, so being able to retrieve an individual Object Class accurately supports configuration review, integration work, and administration tasks.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## get object record

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** create object record, child Object Record, download object record document, check object records hierarchy creation, create object records hierarchy

**Get object record** is an MCP Work tool in the Autologyx platform that retrieves the details of a single Object Record. It is used by developers and integrators when a workflow, service, or external integration needs to read the current data for a specific record in order to inspect its fields, confirm its state, or use that information in subsequent automation steps. This tool is part of the Object Record lifecycle alongside actions such as creating records, building record hierarchies, and retrieving Object Record document information. It matters because it provides the authoritative record-level data needed to drive process logic, validate outcomes, and connect Autologyx business objects with external systems.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## get object record document

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** download object record document, document UUID, document URL, document generation, create object record

**Get object record document** is an MCP Work tool used to retrieve the details of a generated Object Record document in the Autologyx platform. It returns the document’s metadata, current generation status, and download information, such as the document UUID and document URL, so developers and integrators can check whether document generation has completed and obtain the information needed to access the output. This tool is typically used after creating an object record or initiating document generation, and it matters because it provides the programmatic link between a platform record and the generated document that downstream services, integrations, or user-facing processes need to fetch and use.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## governance gateway

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics, Developers / Integrators
* **Closely related concepts:** MCP services, MCP enabled agent, Autologyx MCP endpoint, MCP mappings, MCP tool catalogue

The **governance gateway** in the Autologyx platform is the central control layer used with MCP services to determine what an MCP-enabled agent can access and do. It is used when configuring Autologyx MCP integrations alongside permissions, MCP mappings, user accounts, user groups, and the MCP tool catalogue, providing finer-grained control than connector-level restriction settings in the agent client alone. This matters because it allows configuration and security administrators to govern tool and data access consistently within Autologyx, helping ensure agents operate only within the actions, services, and visibility that the platform configuration explicitly allows.

* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)

## hard stop gated control

* **Mostly relevant to:** Information Security / Compliance / Analytics, Super Admins, Configuration admins
* **Closely related concepts:** AppliedAI, AppliedAI and the Sequencer, autonomous agents, headless agents, human in the loop, agentic workflows

**Hard stop gated control** is an AppliedAI governance mechanism in the Autologyx platform that enforces non-bypassable access boundaries for both agents and users at every level of the platform. It is used when configuring and operating AI-assisted activity, including co-pilot, autonomous, and headless agent patterns, to ensure access and actions are constrained by defined permissions and security policies. In practice, it works alongside granular permissions, human-in-the-loop controls, and the separation of read-only guidance from live data changes, so configuration admins and super admins can limit what can be seen or done by agent, instance, client, matter, or individual record. This matters because it provides enterprise-grade control over AppliedAI behaviour, helping organisations protect sensitive data, enforce compliance requirements, and maintain safe, governed agentic workflows.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## headless agents

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** AppliedAI, AppliedAI and the Sequencer, agentic workflows, autonomous agents, human in the loop, Loop actors, API Call actor, co pilot agents

In the Autologyx platform, **headless agents** are Applied AI–driven autonomous agents that perform tightly controlled work without direct user interaction when that operating model is enabled. They are used within Applied AI and related agentic workflow designs to execute defined tasks under configured permissions and control boundaries, typically for work that does not require a human-in-the-loop step. This matters to Configuration Admins, Developers, Integrators, and Super Admins because enabling and designing **headless agents** affects how work is automated, what permissions the agent can act under, and how safely autonomous activity is constrained within the platform.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## human in the loop

* **Mostly relevant to:** Information Security / Compliance / Analytics, Configuration admins, Super Admins
* **Closely related concepts:** AppliedAI, AppliedAI and the Sequencer, agentic workflows, autonomous agents, co pilot agents, headless agents, Loop actors

In the Autologyx platform, **human in the loop** describes a governance and workflow pattern in AppliedAI where a person is deliberately placed at defined decision points to review, approve, or complete steps before actions continue, especially when those actions could affect live data or process outcomes. It is used when configuring AI-assisted, co-pilot, or autonomous agent experiences and sequencing workflows so that important decisions include mandatory user intervention rather than running end to end without oversight. This matters because it lets Configuration Admins and Super Admins combine automation with enterprise control, applying hard-stop gates, permissions, and approval checkpoints to meet security, compliance, and operational requirements while keeping accountability for high-impact actions.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## human review task

* **Mostly relevant to:** Configuration admins, End-users, Information Security / Compliance / Analytics
* **Closely related concepts:** Sequencer, Sequences, Sequence canvas, actor

A **human review task** is a task created within an Autologyx Sequence to route work to a person for manual assessment before the workflow continues or a result is used. It is used on the Sequence canvas as a review gate, often after an actor such as an AI or Local Variable step has produced an output that requires validation, completion, or approval. Human review tasks are particularly important when responses are incomplete, unexpected, difficult to validate automatically, or intended for important decisions, external communications, or final record updates. For configuration admins, they provide a controlled way to design guardrails and exception handling into automated workflows; for end-users, they define where manual action is required; and for compliance, security, and analytics teams, they help ensure that high-impact or semantically generated outputs are subject to appropriate oversight.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## JSON variable

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Local Variable actor, OpenAI: GPT actor, actor, Merge fields

A **JSON variable** in the Autologyx platform is a variable type used to store structured data in valid JSON format so that multiple named values can be captured and reused as a single variable. It is configured when defining variable outputs for actors, including the OpenAI: GPT actor, where the variable name is set, the type is selected as JSON, the source is the actor response, and the value maps the JSON fields to include. JSON variables are primarily used by configuration administrators and developers or integrators when an actor returns structured content that needs to be preserved for downstream processing, mapping, or display. This matters because choosing the JSON type enables Autologyx to work with nested or multi-field output in a consistent format, making it easier to pass structured responses between actors and reference the data in platform configuration.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)

## list object class children

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** child Object Class, create object records hierarchy, check object records hierarchy creation, Autologyx configuration experience

In the Autologyx platform, **list object class children** is an MCP Work tool that returns the direct child Object Classes defined beneath a specified parent Object Class. It is used by developers, integrators, and configuration administrators when working with the Autologyx configuration experience to inspect and validate object hierarchies, especially when building or supporting create object records hierarchy and related hierarchy-checking operations. This matters because Object Class parent-child relationships determine how structured records are organised and created in the platform, so being able to retrieve child classes directly helps ensure configurations, integrations, and hierarchy-driven processes are aligned with the intended data model.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## list object class fields

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** child Object Class, create object record, create object records hierarchy, check object records hierarchy creation

**List object class fields** is an MCP Work tool in the Autologyx platform that returns the valid fields and field aliases defined for a specific Object Class. It is used by developers, integrators, and configuration administrators when building or configuring automations, integrations, and record-creation logic that interact with object data. This tool is especially important when working with related capabilities such as creating object records, creating object record hierarchies, or validating hierarchy creation, because it identifies the exact field names and supported aliases that must be used for the target Object Class. Using **list object class fields** helps ensure that object payloads and mappings align with the class definition, reducing configuration errors and enabling accurate object record handling across the platform.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## list object class parents

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** child Object Class, create object records hierarchy, asynchronous Object Record hierarchy creation process, check object records hierarchy creation

In the Autologyx platform, ****list object class parents**** is an MCP Work tool that returns the direct parent Object Classes for a specified child Object Class. It is used by developers, integrators, and configuration administrators when working with Object Class structures, especially where record hierarchies and parent-child relationships must be understood or validated. This tool is relevant during configuration and integration tasks that depend on the defined Object Class hierarchy, including creating object records in the correct hierarchy and supporting processes that create or check Object Record hierarchy relationships. It matters because it provides the authoritative parent-class lookup needed to navigate, configure, and troubleshoot Object Class inheritance and hierarchy-driven behavior in the platform.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## live operational work

* **Mostly relevant to:** Developers / Integrators, End-users
* **Closely related concepts:** Autologyx MCP Work, approved agent, co pilot pattern, autonomous pattern, controlled autonomous workflows

**Live operational work** in Autologyx is the execution of day-to-day work on active records and tasks within an existing process, rather than platform setup or product configuration. It is used in the context of Autologyx MCP Work, where approved AI assistants and agents support users with live operational activity such as finding records, reading and updating data, managing tasks, using document automation, navigating record relationships, and progressing work through controlled autonomous or co-pilot operating patterns. This matters because it defines the boundary for agentic action in the platform: MCP Work is designed to interact with production work safely and usefully, helping developers, integrators, and end-users understand when AI tools should be applied to operational execution instead of configuration changes.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## Local Variable actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** actor, Sequences, Sequencer, Sequence canvas, actor configuration modal, Merge fields

A **Local Variable actor** is a Sequencer actor used on the Sequence canvas to capture, store, and extract values from the output of another actor, such as an OpenAI or Azure OpenAI actor. It is configured in the actor configuration modal and is commonly placed after an actor that returns text or JSON so the response, or specific parts of it, can be saved as reusable values and referenced later through merge fields or subsequent workflow logic. This matters because it turns actor output into structured data the platform can reliably reuse for downstream steps such as updating records, routing the workflow, composing documents or messages, invoking further parsing, or preparing content for human review.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## lookup suffixes

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** field aliases, field slug, get object record, get object class

**Lookup suffixes** are field-specific filter operators appended to a field slug when querying records through Autologyx MCP Work tools, allowing developers and integrators to refine how a filter matches values for a given field type. They are used in tool requests that support filtering, including record retrieval operations such as get object record and get object class, and work alongside concepts such as field aliases and field slugs to target the correct data. **Lookup suffixes** matter because they control the behavior of comparisons in API and tool queries—for example, enabling exact matches, partial matches, range-style checks, or other supported field-type-specific lookups—so using the correct suffix is essential for returning the intended records and building reliable integrations.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## Loop Actor pattern

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Sequencer, AppliedAI, playbook functions, dedicated actors, API Call actor

The **Loop Actor pattern** is a Sequencer design pattern in Autologyx used to run the same operation repeatedly across a set of items and aggregate the results into a single flow. In the AppliedAI context, it is used when multiple playbook functions must be executed against the same source content: the Sequence repeats the AI request for each function and collects the outputs for downstream processing. This pattern matters to configuration admins and developers because it provides a structured way to orchestrate repeated actor execution without duplicating sequence logic, making multi-function AI processing easier to configure, maintain, and integrate with related components such as dedicated actors and API Call actors.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/)

## Loop actors

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** API Call actor, Object Classes, Sequencer, AppliedAI and the Sequencer

**Loop actors** are Sequencer actors in the Autologyx platform that execute a defined action repeatedly across a set of items, records, or task iterations within a workflow. They are used when configuring automation patterns that need the same logic applied multiple times, such as running reusable prompt functions with playbook-style Object Classes or performing repeated extraction and classification steps when integrating AI services through the API Call actor. **Loop actors** matter because they let configuration admins and developers structure scalable, reusable workflow logic, reduce duplication in playbook design, and reliably orchestrate batch-style processing across repeated workflow inputs.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/)
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## Manual Task

* **Mostly relevant to:** Developers / Integrators, Configuration admins, End-users
* **Closely related concepts:** Autologyx MCP Work, Object Records, Automatic Task

A **Manual Task** in the Autologyx platform is a user-performed work item created against an Object Record, typically through Autologyx MCP Work services or platform configuration, to capture a step that requires human action rather than automated execution. It is used wherever a process needs an assignee to review, complete, or progress work in the context of a specific record, linking that activity directly to the underlying business object. This matters because Manual Tasks provide a structured way to introduce human intervention into automated workflows, ensure work is tracked at record level, and enable developers, configuration admins, and end-users to coordinate operational steps alongside Automatic Tasks within a single process.

* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## MCP enabled agent

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** MCP services, MCP tool catalogue, Available MCP Work tools, Autologyx MCP Work, MCP mappings, Autologyx governance gateway
* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)

## MCP mappings

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** MCP services, MCP enabled agent, MCP tool catalogue, Autologyx governance gateway

**MCP mappings** are the Autologyx configuration controls that define how access to MCP services and tools is applied within the platform alongside the user account, user groups, and the standard Autologyx permission model. Used when setting up and governing MCP-enabled agents and their access to the MCP tool catalogue, **MCP mappings** form part of the access-control layer that determines what an agent can see and do. They matter because they let configuration and security administrators enforce structured, platform-level governance over external tool access, helping align agent behaviour with organisational permission, compliance, and governance requirements.

* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)

## MCP services

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Information Security / Compliance / Analytics
* **Closely related concepts:** AppliedAI, Sequencer, AppliedAI and the Sequencer, Autologyx governance gateway, Autologyx MCP Work, Autologyx MCP Build, agentic workflows, model agnostic orchestrator

**MCP services** are an AppliedAI pattern in the Autologyx platform that let approved AI assistants and agents connect to Autologyx through governed tools and APIs. They are used when the interaction starts outside Autologyx, with the assistant or agent initiating requests to read records, work with tasks, retrieve knowledge, or perform other controlled actions against enabled services such as MCP Work, with access constrained by the MCP service, platform permissions, and customer configuration. This matters to developers, configuration administrators, and security or compliance teams because **MCP services** define how external AI clients are connected to Autologyx, which service family is exposed for a given purpose, and how tool-level access is controlled to support secure, policy-aligned agentic workflows.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/)
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)

## MCP Success

* **Mostly relevant to:** End-users, Configuration admins
* **Closely related concepts:** AppliedAI, Autologyx MCP Build, Autologyx MCP Work, AppliedAI and the Sequencer, agentic workflows, co pilot agents, headless agents, autonomous agents, API Call actor

**MCP Success** is the Autologyx Applied AI capability that provides approved AI assistants with access to the Autologyx Knowledgebase and Customer Success guidance so they can help users plan, design, and configure effective solutions. It is used in guidance-led interactions across Applied AI, especially where users need product knowledge, design recommendations, implementation planning, and configuration support rather than execution against live work. **MCP Success** matters because it gives end-users and configuration administrators a controlled way to obtain platform-specific expertise inside Autologyx, and it is distinct from MCP Work: **MCP Success** supports knowledge, planning, and solution design, while MCP Work operates on live data and tasks.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## MCP tool catalogue

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** MCP enabled agent, MCP services, Available MCP Work tools, Autologyx MCP Work, MCP mappings

The **MCP tool catalogue** is the list of MCP tools available to an MCP enabled agent in the Autologyx platform, including descriptions of what each tool is used for. It is used within Autologyx MCP Work and related MCP services so the agent can identify the tools it has access to and select the correct one when completing a task. For developers, integrators, and configuration admins, the catalogue matters because it defines the operational capabilities exposed to the agent, supports correct tool selection and configuration, and provides the reference point for understanding which MCP-powered actions are available in a given implementation.

* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)

## MCP Work

* **Mostly relevant to:** Developers / Integrators, End-users
* **Closely related concepts:** create object record, create object records hierarchy, check object records hierarchy creation, download object record document, document generation

**MCP Work** is the Autologyx capability that exposes a controlled set of tools for approved AI assistants and agents to interact directly with live work in the platform. It is used in Applied AI scenarios where an assistant needs to perform operational actions such as creating object records, building or checking record hierarchies, downloading object record documents, or supporting document generation, while explicitly not providing access to Autologyx configuration tools. **MCP Work** matters because it connects AI-driven interactions to real platform activity, so access is governed through tool permissions and must be configured carefully to ensure agents can perform only the specific actions they are authorised to carry out.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## MCP Work tools

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** approved agent, Object Records, role based access model

**MCP Work tools**, also called MCP tools or the tool catalogue, are the set of Autologyx MCP Work capabilities that approved AI assistants and agents use to interact with live work in the Autologyx platform. They are documented in the MCP Work reference pages and are primarily used by developers, integrators, and configuration administrators who need to understand which actions an agent can perform, such as working with records and tasks. Access to these tools is controlled per agent, so an agent can only use the specific **MCP Work tools** it has been granted under the platform’s role-based access model. This matters because **MCP Work tools** enable real actions in Autologyx, making correct tool selection, permissions design, and governance essential when configuring safe and effective agent access.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## Merge fields

* **Mostly relevant to:** Configuration admins, Developers / Integrators, End-users
* **Closely related concepts:** Object Records, actor, Local Variable actor, Sequencer

**Merge fields** are placeholders and expressions used in Autologyx configuration to insert values from the record being processed into actor inputs and related text fields at runtime. They are used most visibly in Sequencer-based actor configurations such as OpenAI, Azure OpenAI, and AWS Bedrock prompts, messages, context, and value inputs, where static text is combined with record data, extracted document text, email content, or specific response attributes. **Merge fields** matter because they make prompts and integrations dynamic and record-specific, allowing configuration admins, developers, and end-users to tailor processing to each Object Record and to test configurations accurately by supplying a Record ID so the platform can resolve the referenced data.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## ML and AI tab

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** OpenAI: GPT actor, actor
* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)

## Model

* **Mostly relevant to:** Configuration admins
* **Closely related concepts:** AWS Bedrock, Bedrock actor, Provider, AI and the Sequencer

In Autologyx, a **Model** is the specific foundation **model** selected to process an AI request within a workflow, such as when a Sequence uses the AWS Bedrock integration to call a **model** through Amazon Web Services. Configuration admins choose the **model** as part of actor or integration setup, where it determines which provider-backed **model** family handles prompts and returns results to the Sequencer. This setting is used anywhere Autologyx supports configurable AI execution through a provider, and it matters because it directly controls the behaviour, compatibility, governance route, and regional availability of AI processing in the platform.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)

## model agnostic orchestrator

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** AppliedAI, Autologyx Catalyst, Sequencer, API Call actor, agentic workflows, AppliedAI and the Sequencer, MCP services

A **model agnostic orchestrator** in Autologyx is the platform role performed by Autologyx Catalyst and AppliedAI within the Sequencer, where Autologyx coordinates AI-augmented processing without being tied to a single underlying model provider or model type. It is used in agentic workflows and AI-enabled process design to route work between sequencing logic, AppliedAI capabilities, API Call actors, and connected services such as MCP services, allowing administrators and integrators to configure workflows that invoke different AI services through a consistent orchestration layer. This matters because it lets configuration admins, developers, and super admins design and evolve AI-driven automations with greater flexibility, provider independence, and maintainability while keeping orchestration, control, and process execution inside the Autologyx platform.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/)
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## native actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** actor, generic API actors, ChatGPT Actor, OpenAI Embedding Actors, actor configuration modal

In Autologyx, a **native actor**, also called a dedicated actor, is a built-in actor created for a specific external capability or provider and exposed through the platform as a purpose-designed integration rather than a fully generic API call. Native actors are used when configuring Sequence steps and actor settings, including provider-specific options such as the ChatGPT Actor or OpenAI Embedding Actors, and are managed through the actor configuration experience. They matter because they provide a simpler, more guided way to use supported services in the platform, but with a defined set of exposed endpoints and options; when a required endpoint, request option, or response pattern is not available in a **native actor**, administrators and integrators use generic API actors instead for direct control.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## Object Class ID

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** create object record, create object records hierarchy, check object records hierarchy creation, child Object Class, child Object Record

**Object Class ID** is the integer identifier for an object class in the Autologyx platform, used by record-focused tools and APIs to specify which class a new record belongs to, which parent or child class is being referenced in hierarchy creation, or which class should be inspected before working with its records. It is commonly required when using MCP Work tools such as creating object records, creating object record hierarchies, and checking hierarchy creation, and it is distinct from an Object Record ID, which identifies an individual record instance. This matters to developers, integrators, and configuration administrators because the correct **Object Class ID** determines the schema, available fields, templates, and relationships that the platform applies, ensuring records are created and processed against the intended class definition.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## Object Classes

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Object Records, Sequences, Sequencer, Autologyx Catalyst, child Object Class, child Object Record, field aliases

**Object Classes** are the core data-model definitions in the Autologyx platform that define a type of business record, its available fields and field aliases, and its parent-child relationships to other classes and records. They are used throughout Catalyst configuration and runtime activity: Sequences reference an Object Class to read and update record data, AI and API call patterns use **Object Classes** to supply prompt and context data, and playbook-style **Object Classes** can be used to store reusable workflow or prompt functions. **Object Classes** also underpin MCP Work interactions, where tools search classes, retrieve class details, inspect valid fields, and navigate child and parent Object Class structures before working with Object Records. They matter because they provide the structural foundation for forms, automation, integrations, and record handling, so configuring them correctly is essential for a usable data model, reliable workflow behaviour, and effective administration.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/)
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)

::: details Show 3 more pages

* [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
* [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)
* [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

:::

## Object Record document

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** download object record document, generate object record document, get object record, document UUID, create object record

An **Object Record document** in the Autologyx platform is a generated document associated with a specific Object Record, created from a Document Template and managed through MCP Work tools. It is used in developer and integration workflows that generate documents, retrieve their metadata and status, download the document payload, and search documents linked to an Object Record. This term matters because it represents the document output of an Object Record process, identified and handled through document-specific operations such as generation, retrieval, and download, enabling integrations to track document creation and access the resulting files and metadata reliably.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## Object Record hierarchy

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** asynchronous Object Record hierarchy creation process, check object records hierarchy creation, child Object Class, child Object Record, create object record, create object records hierarchy

**Object Record hierarchy** in the Autologyx platform is a structured set of related Object Records created as a parent record with one or more nested child Object Records, typically aligned to parent and child Object Classes. It is used in MCP Work tools that create object records hierarchy in a single asynchronous operation and in status-check tools that track completion of that hierarchy creation process. This matters to developers, integrators, and configuration admins because it enables complex business data structures to be created consistently in one request, preserves relationships between records from the point of creation, and supports automated workflows that depend on correctly linked parent and child records.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## Object Record ID

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** create object record, child Object Record, download object record document, check object records hierarchy creation, create object records hierarchy, asynchronous Object Record hierarchy creation process

**Object Record ID** is the unique identifier for a specific Object Record in the Autologyx platform and is used by tools and integrations to target an existing record for retrieval, update, document generation, document download, and relationship management. In MCP Work and related platform operations, it is commonly supplied as a required input on its own or alongside an Object Class ID, and it is also used when linking parent and child Object Records in hierarchy creation and other record-relationship actions. This identifier matters to developers and configuration admins because it ensures the correct record is addressed by automations and API-driven actions, and because many operations only succeed when the referenced record already exists and is visible to the calling agent or service.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## Object Records

* **Mostly relevant to:** Configuration admins, Developers / Integrators, End-users
* **Closely related concepts:** Sequences, Object Classes, Sequencer, Autologyx MCP Work, child Object Record, child Object Class

**Object Records** are the individual data records in Autologyx that hold the structured information for a business item or case within an Object Class, and they act as the system record that workflows, tasks, documents, integrations, and AI features work against. They are used throughout the platform in Sequences, user-facing processes, and MCP Work, where users and approved agents can find, read, create, update, relate, and manage records, including parent and child record structures and record-related documents. **Object Records** matter because they provide the live operational context for processing work: Sequence actors can collect data from a source record, use merge fields to tailor prompts or integrations to that specific record, store outputs back onto the record, and route downstream actions, while administrators and integrators rely on Object Class IDs, Object Record IDs, and field aliases to configure and automate record operations consistently.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

::: details Show 5 more pages

* [`applied-ai/index.md`](/knowledgebase/applied-ai/)
* [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)
* [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
* [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)
* [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

:::

## OpenAI

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Applied AI, Embedding Model Actors, Public Ai Providers, The Sequencer
* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/)

## OpenAI Embedding Actors

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** actor, generic API actors, OpenAI embeddings configuration modal, OpenAI: GPT or ChatGPT actor, Authentication Object

**OpenAI Embedding Actors** are Autologyx actors that call OpenAI embedding models to convert text into vector embeddings for use in workflows that need meaning-based search, comparison, matching, or retrieval. They are used in Applied AI and Sequencer configurations wherever record text must be transformed into a searchable representation, such as supporting semantic search, retrieval-augmented workflows, similarity detection across records, clauses, requests, or documents, and producing vector-ready output for downstream processing. Configuration is managed in the OpenAI embeddings configuration modal, where administrators and integrators define the model, authentication, input text, output format, dimensions, and test record. **OpenAI Embedding Actors** are distinct from OpenAI GPT or ChatGPT actors because they generate vector representations rather than conversational or generated text, which makes them essential when designing workflows that depend on embedding-based retrieval and comparison.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## OpenAI embeddings configuration modal

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** OpenAI Embedding Actors, actor configuration modal, Authentication Object, Merge fields, Object Records, Record ID, actor

The **OpenAI embeddings configuration modal** is the Autologyx actor configuration interface used to set up an OpenAI Embedding Actor. In this modal, configuration and Super Admin users define the embedding model, select the Authentication Object used to connect to OpenAI, specify the input text—often using merge fields from Object Records—choose the output format, set dimensions, and provide a test record such as a Record ID for validation. It is used when configuring applied AI workflows that generate embeddings through OpenAI, and it matters because these settings control how source record data is transformed into embedding output and ensure the actor is correctly connected, tested, and ready for use in the platform.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## OpenAI: GPT actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators, End-users
* **Closely related concepts:** Sequencer, Sequences, actor, AppliedAI, AppliedAI and the Sequencer, API Call actor, Authentication Object, Autologyx Catalyst

The **OpenAI: GPT actor** is an Applied AI actor in Autologyx Catalyst that adds ChatGPT-powered processing to a Sequence. Configuration admins and developers use it in the Sequence builder by dragging it onto the canvas from the ML and AI tab and connecting it to workflow triggers, with prompts configured dynamically through merge fields that pull data from records. It is available as a premium OpenAI integration enabled through subscription setup, and it is used wherever a workflow needs GPT-driven output as part of its automated steps. This matters because it allows organisations to embed AI-generated responses and prompt-based processing directly into business workflows, making Sequences more context-aware, flexible, and capable of handling tasks that depend on record-specific inputs.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## OpenAI: GPT or ChatGPT actor

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** actor, generic API actors, Authentication Object, OpenAI Embedding Actors, actor configuration modal, Merge fields

The **OpenAI: GPT or ChatGPT actor** is an Autologyx Sequence actor that sends a prompt to an OpenAI chat model and returns the model’s response for use within the workflow. It is used by adding the actor to a Sequence like any other actor, then configuring it in the actor configuration modal with the required model, Authentication Object, prompt, context, temperature, and test record; prompts can also incorporate Merge fields so the request is populated with workflow data. This actor is the standard starting point for language-based automation tasks such as understanding, drafting, classification, and summarisation, and it matters because its output can be stored, transformed, and passed to later Sequence steps to drive controlled, repeatable process automation.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## parent Object Class

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** child Object Class, Object Classes, Autologyx MCP Work

In the Autologyx platform, a **parent Object Class** is an Object Class that sits directly above another Object Class in the configured class hierarchy, defining the immediate parent-child relationship used when working with related records. This term is used in Autologyx MCP Work, particularly through the list object class parents tool, which returns the direct parent Object Classes for a specified child Object Class, and alongside the corresponding child lookup tools that navigate the hierarchy in the opposite direction. Parent Object Classes matter to Configuration admins, Developers / Integrators, and Super Admins because they are essential for understanding valid object relationships, navigating the platform’s data model, and ensuring integrations or automated processes use the correct class structure when identifying related records and creating or managing child records.

* **Pages:**
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## parent Object Record

* **Mostly relevant to:** End-users, Configuration admins, Developers / Integrators
* **Closely related concepts:** child Object Record, Object Records, parent Object Class, child Object Class, Object Classes, Autologyx MCP Work

A **parent Object Record** is the record at the top of an Object Record relationship in Autologyx, used to contain, organise, and link one or more child Object Records within a defined Object Class hierarchy. It is used in Autologyx MCP Work tools that create object record hierarchies, find child records linked to a parent record, find parent records linked to a child record, and remove parent-child relationships. For end-users, configuration admins, and developers or integrators, the **parent Object Record** matters because it defines the container record that child records sit under, drives how related records are structured and retrieved, and is a key input when configuring or automating hierarchical record creation and management across the platform.

* **Pages:**
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## playbook functions

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Object Classes, Object Records, AppliedAI, Sequencer

**Playbook functions**, also described as playbook style prompt functions, are reusable units of AI prompt logic used in Autologyx to run consistent extraction, classification, summarisation, and review tasks against a document or record. In practice, they are commonly stored on an Object Class so the same function definitions can be reused across processes, while a Sequence invokes them as part of an AppliedAI workflow. They are especially useful when prompt logic needs to be managed separately from Sequence design, such as in contract review where individual functions extract specific fields or checks like parties, term, governing law, liability caps, or missing clauses. Where several functions must be applied to the same source content, the Sequencer can run them repeatedly, for example through a Loop Actor pattern, and collect the outputs into structured record data or draft results for review. This matters to configuration admins and developers because **playbook functions** improve reuse, standardisation, and maintainability of AI-enabled automation.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/)

## playbook style Object Classes

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Object Classes, API Call actor, Sequencer

In Autologyx, **playbook style Object Classes** are Object Classes designed to encapsulate reusable playbook logic as callable functions, allowing common patterns such as AI prompt construction and related request handling to be defined once and reused across workflows. They are used in solution design alongside the Sequencer and actors such as API Call, where a process needs consistent, repeatable logic for outbound service interactions. This matters to configuration admins and developers because it improves maintainability, standardises implementation across playbooks, and reduces duplication when building integrations or reusable automation components.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/)

## Private Cloud Ai

* **Mostly relevant to:** Information Security / Compliance / Analytics, Super Admins, Configuration admins
* **Closely related concepts:** Applied AI, Autologyx Classification, The Sequencer, Unrestricted, Public
* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/)

## Privately hosted models

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** API Call actor, Authentication Object, generic API integration capability, Sequences, Sequencer, structured responses, deterministic Sequence logic

**Privately hosted models** are AI or machine learning services that Autologyx Sequences call when the model is hosted, managed, or controlled outside the platform’s standard OpenAI, Azure OpenAI, or AWS Bedrock actors. In Autologyx, they are used through the platform’s generic API integration capability and are typically configured by admins or integrators using authentication and API call components so Sequence and Sequencer logic can send data to customer-specific endpoints and consume structured responses. This approach supports a wide range of services, including large language models, specialist models, image or audio models, redaction services, named entity recognition, and AI gateways. **Privately hosted models** matter because they give organisations greater control over hosting, access, logging, routing, and data handling, while enabling model behaviour that is tailored to specific document types, terminology, risk taxonomies, clause libraries, intake categories, matter types, internal playbooks, and historic decision data.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)

## Provider

* **Mostly relevant to:** Configuration admins
* **Closely related concepts:** AWS Bedrock, Bedrock actor, Model, AI and the Sequencer, Configurations

In Autologyx, a **Provider** is the model vendor selection used in AI configuration fields such as the AWS Bedrock actor, where it determines which group of AI models is available in the Model field. For configuration admins, **Provider** is used when setting up Sequences to call models through AWS Bedrock, with options reflecting the model providers enabled in the customer’s AWS and Autologyx environment, such as Amazon, Anthropic, Meta, Mistral, or OpenAI. This matters because the selected **Provider** controls the model families users can choose from and helps align AI usage with the organisation’s AWS region, access controls, governance, and approved private-cloud integration settings.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)

## Public AI Providers

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Applied AI, The Sequencer, Embedding Model Actors, Unrestricted, Public
* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/)

## Record Fields

* **Mostly relevant to:** End-users, Configuration admins
* **Closely related concepts:** Merge fields, Record Properties, OpenAI: GPT actor, actor

**Record Fields** are mergeable placeholders that represent values held on a record in the Autologyx platform and can be inserted into configurable inputs where record-specific data is needed. They are used in places such as actor configuration, including prompt text in the OpenAI: GPT actor, where users can right-click to insert a field token such as {{record.field\ email\ from}} directly into the input. **Record Fields** matter because they let end-users and configuration admins dynamically pass data from the current record into automated steps, ensuring actors and workflow components use the correct contextual information for each transaction.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)

## record hierarchy creation

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Autologyx MCP Work, Object Records, child Object Record, Object Classes, child Object Class, parent Object Class

**Record hierarchy creation** is the Autologyx asynchronous process that creates a parent Object Record together with its nested child Object Records in a single hierarchy, typically aligned to the relevant parent and child Object Classes. It is used in Autologyx MCP Work services where integrations or platform configurations need to submit and then check the status of hierarchy creation as a background operation rather than creating each record individually. This matters because it enables developers and configuration administrators to build complete structured business objects efficiently, preserve parent-child relationships consistently, and manage long-running or bulk creation tasks through status-driven processing.

* **Pages:**
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)

## record hierarchy creation process

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** Autologyx MCP Work, child Object Record, child Object Class
* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## Record ID

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Merge fields, Object Records, Test Integration, actor

**Record ID** is the identifier of a specific Autologyx object record that you supply when testing configurations whose prompt, message, context, or input text contains merge fields. It is used in Test Integration and related test screens for AI and actor configurations, such as OpenAI, Azure OpenAI, AWS Bedrock, and embedding setups, so the platform can resolve merge fields against real record data during the test. This matters to configuration admins and developers because without a valid **Record ID**, any test that depends on record-backed values cannot evaluate the final populated input correctly, making it harder to validate prompts, outputs, and integration behaviour.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## Record Properties

* **Mostly relevant to:** Configuration admins
* **Closely related concepts:** Record Fields, Merge fields, OpenAI: GPT actor, actor

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)

## record relationships

* **Mostly relevant to:** End-users, Configuration admins, Developers / Integrators
* **Closely related concepts:** child Object Class, child Object Record, Autologyx MCP Work

**Record relationships** are the configured links between Autologyx records that define how parent and child records are connected within a process or case structure. In the platform, these relationships are used when users, administrators, and integrations need to navigate from one record to its related records, create related record structures, and work across connected data as part of live operational activity. They are especially relevant in capabilities such as Autologyx MCP Work, where approved tools can find records, read and update data, and move between parent and child **record relationships** to support end-to-end work. **Record relationships** matter because they organise information into meaningful business structures, enable downstream tasks and automation to operate in the correct context, and ensure that related work is handled consistently across the platform.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## record tool endpoints

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** create object record, create object records hierarchy, check object records hierarchy creation, child Object Record, child Object Class, download object record document, document generation, document template, document URL, document UUID, asynchronous Object Record hierarchy creation process, Autologyx configuration experience

**Record tool endpoints** are the MCP Work service endpoints in Autologyx that provide agent and integration access to Object Record operations, including inspecting the data model, locating and working with Object Records, managing parent-child record relationships, and using document automation features such as document generation and record document download. They are used within MCP Work tooling and are especially relevant when configuring or building integrations that create records, create record hierarchies, validate asynchronous hierarchy creation, and handle related documents through template-driven processes. These endpoints matter because they expose the core record-level actions needed to interact with business data in Autologyx in a structured, automatable way, supporting both operational workflows and configuration-driven solutions.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## record tools

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx MCP Work, Object Records, child Object Record, Object Classes, document generation, document template

**Record tools**, also described as Record tool endpoints, are the Autologyx MCP Work capabilities that let an approved agent search for, read, create, update, and relate Object Records, as well as work with documents associated with those records. They are used within the MCP Work service by developers and integrators who configure agent access to business data and record-driven actions across Object Classes, child Object Records, and document-related processes such as document generation from templates. **Record tools** matter because they provide the controlled integration surface through which agents interact with core Autologyx records and their documents, enabling automation that is consistent with the platform’s data model and operational workflows.

* **Pages:**
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## remove object record child

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** child Object Record, check object records hierarchy creation, create object record, create object records hierarchy, child Object Class

In the Autologyx platform, **remove object record child** is an MCP Work tool used to delete the parent-child relationship between two Object Records without describing any broader object creation or hierarchy-building action. It is used in integrations and configuration-driven automations wherever Object Record hierarchies are maintained, especially after records have been linked through hierarchy creation processes. This tool matters because Object Record relationships control how related business data is structured and navigated across the platform, so removing an incorrect or obsolete child link helps administrators and integrators keep object hierarchies accurate and aligned with the intended Object Class design and process behaviour.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## reusable prompt functions

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** API Call actor, playbook style Object Classes, Sequencer, Unrestricted, Public

**Reusable prompt functions** are playbook-style Object Classes in Autologyx that encapsulate prompt content and related request-building logic so it can be invoked consistently from Sequencer flows, typically through the API Call actor when integrating with external AI services. They are used by configuration admins and developers to centralise prompt definitions, standardise how prompts are assembled and passed in outbound REST requests, and support repeated use across multiple playbooks or loop-driven processing patterns. This matters because it improves maintainability, reduces duplication, and makes AI-enabled automations easier to update, govern, and reuse within configurations that are marked for broader access, such as Public or Unrestricted assets.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/)

## role based access model

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics, Developers / Integrators
* **Closely related concepts:** Autologyx MCP Work

The Autologyx **role based access model** is the platform’s standard authorisation framework that determines what a user, service account, process, or agent can see and do in Autologyx according to its assigned role. In the context of Autologyx MCP Work, it is used alongside tool exposure, account selection, and user context to enforce access boundaries, ensuring that agents and integrations only operate within the permissions granted by the platform. This matters when configuring MCP Work, service accounts, and agent-enabled processes because the **role based access model** provides the core security and governance layer that aligns platform actions with approved operational, compliance, and administrative access rules.

* **Pages:**
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## search document templates

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** document template, document generation, download object record document

**Search document templates** is an MCP Work tool in the Autologyx platform that retrieves the document templates available for a specific Object Class. It is used by developers and integrators when building automations, integrations, or AI-assisted workflows that need to identify which templates can be used for document generation in a given business context. This matters because document templates are tied to object types in the platform, and searching them programmatically allows a solution to select the correct template set before generating or downloading object record documents, helping ensure that downstream document-handling steps use the right template for the target record.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## search object classes

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** get object class, create object record, create object records hierarchy, check object records hierarchy creation, custom Object Class fields, field aliases, field slug, get object record

In the Autologyx platform, **search object classes** is an MCP Work tool used to find Object Class definitions that match supplied search criteria. It is used by developers, integrators, and configuration administrators when they need to identify the correct Object Class before working with object records, custom Object Class fields, field aliases, or field slugs, and before calling related operations such as get object class, create object record, or create object records hierarchy. This matters because Object Classes define the structure and type of records used in the platform, so being able to search for the right class is a key step in configuring integrations, selecting the correct schema, and ensuring downstream record creation and retrieval actions target the intended data model.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## search object record children

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** child Object Record, child Object Class, check object records hierarchy creation, create object records hierarchy

**Search object record children** is an MCP Work tool in the Autologyx platform that retrieves the child Object Records linked to a specified parent Object Record. It is used by developers and integrators when working with object hierarchies, especially in workflows, service integrations, or automation that need to inspect or process related records beneath a parent record. This tool matters because it provides a direct way to navigate structured Object Record relationships, supporting solutions that depend on parent-child data models such as hierarchy validation, record creation flows, and downstream actions that operate on child records.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## search object record documents

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** download object record document, document URL, document UUID, child Object Record

**Search object record documents** is an MCP Work tool in the Autologyx platform that searches the documents linked to an Object Record. It is used by developers and integrators when building automations or service integrations that need to find document content or document entries associated with a specific record before taking further action, such as retrieving a document by URL or UUID or working with documents held against child Object Records. This matters because Object Record documents are often the source files for workflow steps, decisions, and downstream processing, so being able to search them efficiently is a core part of implementing document-aware integrations and record-centric automation in Autologyx.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## Security, permissions, and governance

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** AppliedAI

**Security, permissions, and governance** in the Autologyx platform is the framework used to define, control, and audit who can access platform capabilities, what actions they can perform, and how those actions are governed across users, agents, instances, clients, matters, and individual records. It is used when configuring access models, setting granular permissions, enforcing guardrails, introducing human-in-the-loop controls, and separating read-only AI guidance from actions that can change live data, particularly for AppliedAI and other controlled automation scenarios. This matters because it gives configuration and super admin teams enterprise-grade control over access, attribution, policy enforcement, and activity oversight, helping ensure that AI-assisted and autonomous operations are secure, governed, and aligned with organisational compliance requirements.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)

## Sequence actors

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Sequences, Automatic Task, Manual Task, Autologyx MCP Work

**Sequence actors** are the executable components added to a Sequence in Autologyx to perform individual workflow steps, such as running automated actions or presenting work for manual completion. Used by configuration administrators and super admins when designing and maintaining Sequences in the Sequencer, an actor defines what happens at a specific point in the workflow and can represent capabilities such as AI-driven processing through actors like Azure OpenAI or work handled through related services such as Autologyx MCP Work. **Sequence actors** matter because they are the building blocks that control how a Sequence operates in practice, determining which tasks are automated, which require user input, and how processing is orchestrated across a case or business process.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## Sequence builder

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** actor, Autologyx Catalyst, Local Variable actor, Merge fields, OpenAI: GPT actor

**Sequence builder** is the design environment in Autologyx Catalyst where users create and configure a Sequence by adding actors to a canvas and arranging them to perform functions in response to triggers. It is used when building automation logic, including dragging actors such as the OpenAI: GPT actor onto the Sequence canvas and configuring how they interact with data and other components. The **Sequence builder** matters because it is the central workspace for defining how a process runs, making it essential for configuration admins who design automations and for end-users who work with the resulting process behaviour.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)

## Sequence canvas

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Sequencer, Sequences, actor, actor configuration modal, Local Variable actor, human review task, System Configuration Sequences

The **Sequence canvas** is the visual workspace in the Autologyx Sequencer where a Sequence is built and arranged by placing actors onto the workflow and connecting them at the required points in the process. It is used in Edit mode by configuration admins when designing or updating Sequences, including adding actors such as AI actors, Local Variable actors, and human review tasks, and positioning them in relation to triggers and other steps. The **Sequence canvas** matters because it is the primary surface for defining the structure, order, and flow of automated work in the platform, making it central to configuring how a business process runs from one action to the next.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## Sequencer

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** Sequences, API Call actor, actor, Sequence canvas, Merge fields, Authentication Object, deterministic Sequence logic, Local Variable actor

In Autologyx, the **Sequencer**, also referred to as a Sequence, is the workflow orchestration capability used to design and run controlled business processes by linking actors, triggers, data handling, and decision points on the Sequence canvas. It is used by configuration and technical administrators to define how records, tasks, integrations, and AI-enabled steps progress through a workflow, including sending structured requests through actors such as API Call, OpenAI, Azure OpenAI, or Bedrock, then storing and reusing returned values in later steps through merge fields, local variables, and deterministic Sequence logic. The **Sequencer** matters because it is the point at which business rules, external services, authentication, and automation are coordinated, allowing organisations to build governed, repeatable processes that keep Autologyx in control of workflow execution while extending the platform through integrations and model-agnostic AI services.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)

::: details Show 3 more pages

* [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)
* [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/)
* [`applied-ai/index.md`](/knowledgebase/applied-ai/)

:::

## Sequences

* **Mostly relevant to:** Configuration admins, Developers / Integrators, Super Admins
* **Closely related concepts:** Sequencer, actor, deterministic Sequence logic, Object Records, Object Classes, Autologyx MCP Work

In Autologyx, a Sequence is the configured workflow definition built in the Sequencer that orchestrates business process steps, invokes actors, and applies deterministic logic to data and events as work progresses. **Sequences** are used in Catalyst workflow automation to interact with Object Classes and Object Records, route and update work, create downstream actions, and, where required, send structured requests to AI services or other external endpoints through actors such as OpenAI, Azure OpenAI, AWS Bedrock, API Call, or Autologyx MCP Work integrations. For configuration admins, developers, integrators, and Super Admins, **Sequences** matter because they are the primary mechanism for turning process design into controlled execution: they determine when automation runs, what data is passed between steps, how external services are called, and how responses are stored or used to drive subsequent workflow behaviour under governance and platform control.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

::: details Show 4 more pages

* [`applied-ai/index.md`](/knowledgebase/applied-ai/)
* [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
* [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)
* [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

:::

## service account

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** Autologyx MCP Work, autonomous pattern, co pilot pattern

A **service account** in the Autologyx platform is a non-human account used to let an agent or automated capability act within Autologyx under a defined identity and permission set. It is used when configuring Autologyx MCP Work and related agent-enabled patterns to determine which records, Object Classes, task templates, documents, and actions the agent can access, create, update, or complete, and it sits alongside user-based identities as an execution context for automated work. Service accounts matter because they provide a controlled way to separate machine-driven activity from individual user accounts, apply least-privilege access, support auditing of tool calls and actions, and enable administrators, integrators, and security teams to approve, review, and remove automated access quickly and safely.

* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## standard OpenAI, Azure OpenAI, or AWS Bedrock actors

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Privately hosted models, dedicated AI actor, generic API integration capability, API Call actor, Authentication Object

**Standard OpenAI, Azure OpenAI, or AWS Bedrock actors** are the built-in Autologyx actor integrations used in Sequences to connect directly to supported AI services from OpenAI, Azure OpenAI, and AWS Bedrock. They are used when configuring Applied AI steps that call externally hosted foundation models through Autologyx’s native provider-specific connectors, rather than through privately hosted models or a generic API-based integration. This distinction matters because it determines how a model endpoint is connected in the platform, which configuration approach administrators and integrators should use, and when a privately hosted model, dedicated AI actor, or API Call actor is required instead of the standard provider actors.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)

## structured Autologyx data

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Object Records, Privately hosted models, dedicated AI actor, deterministic Sequence logic, Sequences, Sequencer

**Structured Autologyx data** is the platform’s native business data held and managed in defined records and workflow state, including the fields, metadata, documents, permissions, user task context, and integration outputs that Autologyx uses to run a process. It is used throughout Sequences, the Sequencer, Object Records, and AI-enabled workflows, especially where a dedicated AI actor or privately hosted model needs to consume platform data alongside deterministic Sequence logic. This matters to configuration admins and developers because **structured Autologyx data** provides the controlled, consistent inputs and process context needed to automate decisions, route work, invoke external or private models, and combine specialist model outputs with the governed workflow and record management capabilities of the Autologyx platform.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)

## structured outputs

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** AI and the Sequencer, AWS Bedrock, Bedrock actor, deterministic Sequence logic, Sequencer

**Structured outputs** are AI model responses returned in a defined data structure so Autologyx can use them directly in Sequence logic and workflow processing rather than treating them as free-form text. In the platform, they are used when integrating services such as AWS Bedrock through AI-related configuration and actor design, especially where a model’s response must be consumed as structured data by the Sequencer. **Structured outputs** matter because they enable deterministic processing of AI results for actions such as routing work, updating records, and creating tasks, making AI-driven steps reliable, configurable, and usable within standard Autologyx workflow automation.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)

## structured responses

* **Mostly relevant to:** Developers / Integrators, Configuration admins
* **Closely related concepts:** deterministic Sequence logic, API Call actor, Privately hosted models, Sequencer, Sequences, generic API integration capability

**Structured responses** are model or API outputs returned in a defined data structure, rather than as free-form text, so the Autologyx Sequencer can read, validate, and act on the result consistently. In the Autologyx platform, **structured responses** are used when integrating privately hosted models and other external services through capabilities such as the API Call actor and generic API integrations, where a Sequence expects specific fields or values to drive deterministic Sequence logic. This matters to developers, integrators, and configuration admins because **structured responses** make automation reliable: they allow Sequences to branch predictably, support validation of returned data, and simplify downstream processing in workflows that depend on exact, machine-readable outputs.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models/)

## System Configuration Sequences

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** Sequences, Sequencer, Sequence canvas, actor configuration modal
* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## system of record

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics, Configuration admins
* **Closely related concepts:** approved agent, Autologyx MCP Work, controlled autonomous workflows, autonomous pattern, co pilot pattern

In the Autologyx platform, the **system of record**, also described as the operational **system of record**, is the governed execution and activity context where work is performed, tracked, and controlled as part of live business operations. It is used in scenarios such as Autologyx MCP Work, where an approved agent is permitted to participate directly in that operational environment rather than working outside the platform’s managed workflow context. This matters to developers, integrators, configuration administrators, and compliance-focused teams because participation in the **system of record** ensures autonomous and co-pilot activities occur within the same controlled workflow framework, supporting consistent execution, oversight, and operational integrity.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## System prompt

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** AWS Bedrock, Bedrock actor, Provider, Model, AI and the Sequencer

A **system prompt** is a configuration field available for some provider and model combinations, including certain AWS Bedrock integrations in Autologyx, that sets the model’s high-level instructions before it processes a request. It is used when configuring AI behaviour in the platform to define the model’s role, tone, constraints, and required output format, such as acting as a specific assistant, returning valid JSON, using fixed categories, or applying review rules. System prompts matter because they shape how the model responds within an Autologyx workflow, helping configuration admins and integrators align AI output with business rules, downstream processing requirements, and the capabilities exposed by the selected provider and model.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)

## Task

* **Mostly relevant to:** End-users, Configuration admins, Developers / Integrators
* **Closely related concepts:** Object Classes, Object Records, Autologyx MCP Work, approved agent, Automatic Task, AppliedAI

A **Task** in the Autologyx platform is a workflow work item created within a process to represent an action that must be completed, assigned, reviewed, or progressed by a user, team, or approved agent. Tasks are used throughout live operational work alongside records, documents, notifications, and routing, and can be created or updated manually, automatically by process design, or through enabled MCP Work tools. In practice, Tasks are where operational steps are carried out and managed: they can be found, read, assigned, unassigned, completed, and updated as part of moving work through an existing process. This matters because Tasks provide the controlled execution layer for process work, linking human and agent activity to permissions, structured data, downstream workflow actions, and the platform audit trail.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## Task templates

* **Mostly relevant to:** Configuration admins, Developers / Integrators, End-users
* **Closely related concepts:** Automatic Task, Manual Task, Object Records, Sequences, Autologyx MCP Work

**Task templates** are reusable platform definitions for tasks in Autologyx that provide the configured blueprint used to create work items, including Automatic Tasks and related task actions against Object Records and within Sequences. They are used in workflow design and runtime operations, including AI-assisted and MCP Work capabilities that can search available **task templates**, retrieve template details, and create new Automatic Tasks from a selected template and Object Record. **Task templates** matter because they standardise how work is initiated and controlled across the platform, allowing configuration admins and integrators to define consistent task behaviour while ensuring users and approved agents create tasks only from authorised, governed templates.

* **Pages:**
  * [`applied-ai/index.md`](/knowledgebase/applied-ai/)
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## task tools

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** Autologyx MCP Work, Manual Task, Automatic Task

**Task tools**, also described as Task tool endpoints, are the Autologyx MCP Work capabilities that let an approved agent interact directly with Tasks in the platform. They are used within the MCP Work service to find, create, read, update, assign, unassign, save, and otherwise manage Tasks, providing the operational interface between an agent and Autologyx work items. This matters to developers and integrators because **task tools** define how approved automated agents can participate in task handling workflows, including working with Manual Tasks and Automatic Tasks, while ensuring task operations are performed through the platform’s supported task-management endpoints.

* **Pages:**
  * [`applied-ai/mcp-services/index.md`](/knowledgebase/applied-ai/mcp-services/)
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## tenant configuration

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** generic API actors, OpenAI embeddings configuration modal, OpenAI: GPT or ChatGPT actor

**Tenant configuration**, also described as the customer environment, is the set of tenant-specific settings and enabled capabilities that control how the Autologyx platform behaves for a particular customer instance. It is used by Configuration admins and Super Admins when setting up integrations, authentication, subscriptions, and feature availability, and it directly affects what options users can access in areas such as generic API actors and OpenAI-powered actors and configuration modals. **Tenant configuration** matters because it determines which models, settings, and integrations are available in a workflow, so these platform-level settings must be confirmed in the customer environment before configuring, publishing, or deploying solutions.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## Test Azure OpenAI

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Azure OpenAI actor, Azure OpenAI configuration modal, Merge fields, Object Records, Record ID, Sequence actors, Sequencer

**Test Azure OpenAI** is the validation action in the Azure OpenAI configuration modal that lets configuration admins and developers run the configured prompt and context against Azure OpenAI before saving the actor. It is used when setting up an Azure OpenAI actor in the Sequencer, especially where the prompt or context contains merge fields, in which case a Record ID must be provided so the test can resolve values from the relevant Object Record. This matters because it allows users to verify that the request is constructed correctly with representative record data before the actor is used in a live workflow, helping ensure the sequence behaves as intended.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/azure-openai/)

## Test embeddings

* **Mostly relevant to:** Configuration admins
* **Closely related concepts:** OpenAI Embedding Actors, OpenAI embeddings configuration modal, actor configuration modal, actor

**Test embeddings** is a validation action in the Autologyx OpenAI embeddings configuration flow that lets configuration admins verify an embeddings setup before saving it. It is used in the OpenAI embeddings configuration modal, alongside other actor configuration settings, to confirm that the configured provider details are accepted and the embeddings actor is ready to use in the platform. This matters because it helps admins catch configuration issues during setup, ensuring the actor can be saved with working settings and reducing errors when embeddings are used in downstream Autologyx processes.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## Test Integration

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** actor, actor configuration modal, Record ID, Merge fields, AI and the Sequencer

**Test Integration** is the action in an actor’s configuration that runs a test request using the current settings so you can validate the integration before saving or using it in a live workflow. It is used in the actor configuration modal for AI and Sequencer integrations such as OpenAI and AWS Bedrock, and when the prompt, message, or context includes merge fields, you enter a Record ID so Autologyx can resolve record data during the test. Running **Test Integration** confirms that the actor configuration can populate the input correctly, call the selected model or service, and return a usable response, making it an essential step for configuration admins and integrators when verifying setup, record-data mapping, and expected behaviour.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/aws-bedrock/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/)

## The Sequencer

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** Applied AI, Public AI Providers, Embedding Model Actors

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/)

## tool permissions

* **Mostly relevant to:** Developers / Integrators, Configuration admins, Super Admins
* **Closely related concepts:** Autologyx configuration experience

**Tool permissions** in Autologyx control which MCP Work tools an agent is allowed to use. They are used within the Applied AI and MCP Work configuration context to grant access to specific tools rather than exposing every available tool to every agent. This matters because **tool permissions** determine the functional scope of an agent, helping developers, configuration admins, and Super Admins ensure that each agent can perform only the actions it has been explicitly authorised to perform.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## transaction ID

* **Mostly relevant to:** Developers / Integrators
* **Closely related concepts:** check object records hierarchy creation, create object records hierarchy

In the Autologyx platform, a **transaction ID** is the unique identifier returned when an MCP Work tool starts a long-running operation, such as creating an object records hierarchy or checking object records hierarchy creation. It is used by developers and integrators as the required input to subsequent MCP Work status tools so the platform can retrieve and track the specific operation that was initiated. This matters because the **transaction ID** links the start request to its follow-up status calls, enabling correct monitoring of processing until the transaction reaches a completed or failed state.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## trigger

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** actor, OpenAI: GPT actor, Autologyx Catalyst

In the Autologyx platform, a **trigger** is the connection in a Sequence that causes one actor or object-class event to start the next step in the workflow. Triggers are used in the Autologyx Catalyst Sequence builder to link components on the canvas, such as connecting an Email Intake Object Class to an OpenAI: GPT actor or chaining one actor to another. For configuration admins and developers, triggers matter because they define the execution flow of an automation: they determine when an actor runs, how processing moves through the Sequence, and how each configured step is coordinated to deliver the intended workflow outcome.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)

## Unrestricted, Public

* **Mostly relevant to:** Information Security / Compliance / Analytics, Configuration admins, Super Admins
* **Closely related concepts:** Autologyx Classification, Applied AI, Public AI Providers, Autologyx MCP Customer Success

**Unrestricted, Public** is an Autologyx classification label that identifies documentation or platform content as approved for open sharing, with no internal handling restrictions. In the Autologyx platform and its documentation set, this classification is shown on pages such as Applied AI, public AI provider guidance, API call examples, and MCP service content to indicate that the material is suitable for general distribution and does not require controlled access. This matters to configuration admins, Super Admins, and compliance stakeholders because it provides a clear governance signal for how information can be used, shared, and referenced when configuring integrations, reviewing platform guidance, or publishing customer-facing material.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/embedding-model-actors/)
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/)
  * [`applied-ai/mcp-services/mcp-customer-success/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-customer-success/)

## user context

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators, Information Security / Compliance / Analytics
* **Closely related concepts:** Autologyx MCP Work, approved agent, controlled autonomous workflows, autonomous pattern

In the Autologyx platform, **user context** is the identity and permission scope under which an action, service, or approved agent operates, determining what platform resources and data it can access when work is performed. It is used in applied AI and MCP Work configurations as a control mechanism alongside exposed tools, the account used by the agent, and the platform’s role-based access model. **User context** matters because it defines the effective access boundary for controlled autonomous workflows, helping configuration admins, super admins, developers, and compliance stakeholders ensure that automated actions run with the correct level of authority, align with security policies, and are constrained to the intended operational scope.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/)

## user groups

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics, Developers / Integrators
* **Closely related concepts:** Autologyx governance gateway, MCP mappings, MCP services, MCP enabled agent

**User groups** are collections of Autologyx users used to manage access, task assignment, and operational control at scale. In the platform, **user groups** are configured alongside user accounts, permissions, MCP mappings, and governance gateway controls to determine what an MCP enabled agent can see and do, and they can also be used when assigning work to a group rather than an individual user. This matters because **user groups** provide a structured way to apply consistent access rules, support auditability, and align agent and user activity with organisational governance, security, and compliance requirements.

* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)

## variable

* **Mostly relevant to:** Configuration admins, End-users
* **Closely related concepts:** Local Variable actor, Merge fields, Record Fields, OpenAI: GPT actor, actor

A **variable**, including a JSON **variable**, is a named value created in an Autologyx sequence to store data so it can be reused by later actors and configuration steps. Variables are typically set with the Local **Variable** actor, where you define the **variable** name, choose its type, identify the source data, and map the value to be stored; for JSON variables, the stored value must be valid JSON. In practice, variables are used to capture outputs from actors such as the OpenAI: GPT actor and make that data available throughout the Sequencer, including for downstream processing and field selection. Variables matter because they provide a structured way to persist and pass data between actors, enabling dynamic, multi-step automations to use generated or extracted content reliably.

* **Pages:**
  * [`applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/index.md`](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor/)

## write actions

* **Mostly relevant to:** Developers / Integrators, Information Security / Compliance / Analytics, Configuration admins
* **Closely related concepts:** create object record, create object records hierarchy, download object record document, document generation

**Write actions** are Autologyx tools and operations that change platform data or relationships rather than simply reading information. In the Autologyx platform, this term is used in MCP Work tool documentation to identify actions such as creating, updating, assigning, unassigning, saving, generating, downloading, and removing relationships, including related operations such as creating object records, creating record hierarchies, changing task assignments, generating documents, and downloading record documents. This classification matters because **write actions** actively modify records, tasks, documents, or links between records, so developers, integrators, configuration administrators, and governance teams use it to understand which tools perform state-changing operations, what required inputs must be provided, and which actions require stronger control, review, and audit attention during configuration and use.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-work/available-mcp-work-tools/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-work/available-mcp-work-tools/)

## write tools

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics, Developers / Integrators
* **Closely related concepts:** MCP services, MCP enabled agent, MCP tool catalogue, Available MCP Work tools, Autologyx governance gateway, autonomous pattern, co pilot pattern, MCP mappings, Autologyx MCP Work

**Write tools**, also described as write actions, are MCP-enabled capabilities in the Autologyx platform that let an agent or workflow make changes in connected systems rather than only read data. They are used when configuring MCP services, defining tool access for MCP-enabled agents, and reviewing the MCP tool catalogue and Available MCP Work tools, especially for actions such as creating tasks, updating records, generating documents, and performing bulk actions. **Write tools** matter because they directly affect operational data and outcomes, so configuration admins, super admins, security and compliance teams, and developers must enable them deliberately, validate connection and permission settings, and ensure appropriate audit logging, governance, and monitoring controls are in place before they are used in co-pilot or autonomous patterns.

* **Pages:**
  * [`applied-ai/mcp-services/getting-started-with-mcp/index.md`](/knowledgebase/applied-ai/mcp-services/getting-started-with-mcp/)

## assignment rules

* **Mostly relevant to:** Configuration admins
* **Closely related concepts:** Automatic Task, Manual Task, Autologyx MCP Customer Success

INSUFFICIENT\_EVIDENCE

* **Pages:**
  * [`applied-ai/mcp-services/mcp-customer-success/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-customer-success/)

## cut list

* **Mostly relevant to:** Configuration admins, Super Admins, Developers / Integrators
* **Closely related concepts:** Autologyx MCP Customer Success, MCP enabled agent, Autologyx MCP Work, assignment rules, authentication objects, Automatic Task, Manual Task, document template, form sections, merge fields, Object Class, Autologyx classification

In Autologyx, a **cut list**, also called an implementation **cut list**, is a structured breakdown of the configuration and implementation items that need to be created, updated, or reviewed to deliver a solution from captured requirements. It is used in MCP Customer Success and related implementation planning workflows to turn unstructured client inputs into actionable build work, such as Object Classes, fields, parent and child relationships, form sections, task templates, Sequence logic, document templates, merge fields, integrations, authentication requirements, reporting fields, migration mappings, test scenarios, and client clarification points. A **cut list** matters because it gives configuration admins, Super Admins, and developers or integrators a clear, organized view of the platform changes required, and it can be grouped by phase, priority, dependency, or workstream to support solution design, delivery planning, and implementation control.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-customer-success/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-customer-success/)

## form sections

* **Mostly relevant to:** Configuration admins
* **Closely related concepts:** cut list, merge fields, document template, Manual Task

**Form sections** are the structural groupings used to organise fields within an Autologyx form, defining how information is laid out and presented to users on records and task-driven interfaces such as Manual Tasks. Configuration admins use **form sections** when designing or updating object class forms and related record views, alongside field placement decisions, to ensure the right data is captured in a clear and usable layout. **Form sections** matter because they directly affect form usability, data entry efficiency, and the consistency of information shown across the platform, and they are often planned as part of implementation cut lists together with fields, document templates, and merge field requirements.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-customer-success/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-customer-success/)

## parent and child record relationships

* **Mostly relevant to:** Configuration admins, Developers / Integrators
* **Closely related concepts:** cut list, Autologyx MCP Customer Success

In the Autologyx platform, **parent and child record relationships** define how one record is linked to one or more subordinate records in the data model, establishing a structured hierarchy between Object Classes. These relationships are used during solution design and platform configuration to model connected business entities, organise related work and information, and support how records are created, viewed, and managed across a process. They are commonly identified alongside Object Classes, fields, task templates, and form design when producing a cut list or implementation plan, including through Autologyx MCP Customer Success. For configuration admins and developers, these relationships matter because they shape the platform’s core record structure and directly influence usability, maintainability, and the overall fit of the configured solution to the client’s operational model.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-customer-success/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-customer-success/)

## record lifecycle

* **Mostly relevant to:** Configuration admins, Super Admins, Information Security / Compliance / Analytics
* **Closely related concepts:** assignment rules, authentication objects, Autologyx classification, Autologyx MCP Customer Success, Autologyx MCP Work, Automatic Task, cut list, document template, form sections, Manual Task, MCP enabled agent, merge fields

In the Autologyx platform, **record lifecycle** is the defined progression of an object record through its managed states from creation and ownership through updates, use in workflow, and eventual completion, closure, or retirement. It is used when designing and reviewing the platform data model, alongside object classes, fields, relationships, and ownership, and it also influences workflow triggers, task creation, reporting, governance, and migration planning. **Record lifecycle** matters because it determines how records are controlled over time, what actions and automations are allowed at each stage, how access and accountability are maintained, and how the platform supports operational, compliance, and analytics requirements.

* **Pages:**
  * [`applied-ai/mcp-services/mcp-customer-success/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-customer-success/)

## related record

* **Mostly relevant to:** Configuration admins, Super Admins
* **Closely related concepts:** form sections, merge fields, Manual Task, Automatic Task
* **Pages:**
  * [`applied-ai/mcp-services/mcp-customer-success/index.md`](/knowledgebase/applied-ai/mcp-services/mcp-customer-success/)

---

---
url: /knowledgebase/system-configuration/landing-page.md
---
# Landing Page

**Browse the sections below:**

* [How To Configure The Landing Page](/knowledgebase/system-configuration/landing-page/how-to-configure-the-landing-page/)
* [Welcome And Introduction To Catalyst](/knowledgebase/system-configuration/landing-page/welcome-and-introduction-to-catalyst/)

---

---
url: /knowledgebase/system-configuration/landing-page-and-theme.md
---
# Landing Page And Theme

**Note:** This section is currently empty or under construction.

---

---
url: >-
  /knowledgebase/record-and-task-forms/formbuilder-components/layout---sections-and-instructions.md
---

# Layout: Sections and Instructions

The **Sections** and **Instruction** components are found in the Form Builder side panel under **Layout**. Layout is the first section of the side panel in all form types except the form used to configure an Object Class Card View.

## Section

All components must be placed within a section. When a new form is created, the Form Builder automatically adds a section by default.

Adding sections allows you to organise a form into subject areas or divide large forms into smaller, more manageable parts.

Click a section header to configure it. The side panel then displays **Section Properties** and **Conditional Visibility** options.

In Card View, **Section Properties** are available, but **Conditional Visibility** is not because Card View supports only a single section.

### Section Properties

The example below shows the Section Properties panel from a Task Template.

![Section Properties panel](/knowledgebase/images/records-and-tasks/record-tasks-layout-sections-instr-1.png)

* **Label** – The text displayed in the section header. By default, this is set to *New Section 1* but can be changed as required.

* **Alias** – Automatically generated from the Label. This can be edited until the form is saved.

* **Show this section header** – Controls whether the section header is displayed. Fields and instructions within the section remain visible unless Conditional Visibility is used.

* **Columns** – Allows the section to be divided into columns. Available options depend on the area being configured:

  * Card View – 2 or 3 columns
  * Create and Edit View – 1, 2, or 3 columns
  * Summary View – 1 or 2 columns
  * Standalone Forms – 1, 2, or 3 columns
  * Task Templates – 1, 2, or 3 columns

* **Column ratios** – Available ratios depend on the number of columns selected. For example, two columns can use ratios such as 50:50 or 25:75.

* **Spacing around the fields (px)** – Controls the space around components. The default value is 10 pixels and can be increased up to 30.

* **Spacing within the fields (px)** – Controls the space between components. The default value is 10 pixels and can be increased up to 30.

| Default spacing around and within fields | Spacing around and within fields increased to 30 pixels |
| --- | --- |
| ![Default section spacing](/knowledgebase/images/records-and-tasks/record-tasks-layout-sections-instr-2.png) | ![Section spacing increased to 30 pixels](/knowledgebase/images/records-and-tasks/record-tasks-layout-sections-instr-3.png) |

### Conditional Visibility

Conditional Visibility allows you to change the behaviour of a form by showing or hiding sections based on values entered or selected by the user.

This functionality uses Conditional Logic.

For more information, see the article on Conditional Logic in forms.

### Managing Sections

#### Moving sections

Sections can be moved by dragging them up or down the canvas.

It is often easier to collapse a section before moving it. The collapse/expand icon appears immediately to the left of the section label.

#### Removing sections

Sections can be removed from the canvas by clicking the **X** in the top-right corner of the section header.

You will only be asked to confirm the action if the section contains other components, such as instructions or fields.

A form must always contain at least one section, so it is not possible to remove all sections from a form.

![Removing a section](/knowledgebase/images/records-and-tasks/record-tasks-layout-sections-instr-4.png)

#### Removing columns from sections

Columns can be removed by reducing the number of columns configured for the section.

If any column contains components, a confirmation dialog appears asking which column should be removed.

![Removing a column from a section](/knowledgebase/images/records-and-tasks/record-tasks-layout-sections-instr-5.png)

Select the appropriate column. The selected column is highlighted in blue and the **Remove** button becomes available.

## Instruction Component

The **Instruction** component can be placed anywhere within a section.

It is useful for:

* providing guidance on completing a form
* displaying reminders or important information
* explaining data requirements
* providing examples of data structures or syntax

Drag and drop the Instruction component into the required position on the form.

Click the component to open the **Instruction Properties** panel.

![Instruction Properties panel](/knowledgebase/images/records-and-tasks/record-tasks-layout-sections-instr-6.png)

The Instruction Properties panel contains formatting controls and a multi-line text editor.

| Configuring the component | How it appears in Preview and on the form |
| --- | --- |
| ![Instruction component configuration panel](/knowledgebase/images/records-and-tasks/record-tasks-layout-sections-instr-7.png) | ![Instruction component displayed on the form](/knowledgebase/images/records-and-tasks/record-tasks-layout-sections-instr-8.png) |

After previewing the form, simply click the Instruction component again to make further changes.

An Instruction component can be removed by clicking the **X** in the top-right corner. No confirmation is required and the component is removed immediately.

## Things to remember

1. There is no limit to the number of components that can be added to a section, except in an Object Class Card View, which is limited to 15 fields.
2. A form must always contain at least one section.
3. Conditional Visibility can be used to show or hide sections based on user input.
4. Instruction components are useful for guidance, examples, and contextual information.
5. Column layouts and spacing settings can be adjusted at any time.

As you approach the Card View field limit, the following warning is displayed:

![Card View field limit warning](/knowledgebase/images/records-and-tasks/record-tasks-layout-sections-instr-10.png)

---

---
url: /api/catalyst/resources/limits.md
---
# Limits

This documentation provides information about API for system limits.

# API

## GET /api/limits/

### Permissions

Requires `authentication` and `SuperAdmin` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/limits/
```

### Response

| Key                           | Type     | Notes                                               |
|-------------------------------|----------|-----------------------------------------------------|
| object\_classes                | object   | Count and limits of object classes.                 |
| task\_group\_templates          | object   | Count and limits of task group templates.           |
| task\_templates                | object   | Count and limits of task templates.                 |
| sequences                     | object   | Count and limits of sequences.                      |
| user\_groups                   | object   | Count and limits of user groups.                    |
| roles                         | object   | Count and limits of roles.                          |
| single\_sign\_on\_configurations | object   | Count and limits of single sign-on configurations.  |
| authentication\_objects        | object   | Count and limits of authentication objects.         |
| custom\_components             | object   | Count and limits of custom components.              |
| additional\_limits             | object   | Additional limits for which count is not available. |

#### Individual response objects

| Key   | Type     | Notes                                    |
|-------|----------|------------------------------------------|
| count | int      | The current number of objects.           |
| limit | int      | The maximum permitted number of objects. |

#### Response `additional_limits` object

| Key                                                | Type     | Notes                                                                  |
|----------------------------------------------------|----------|------------------------------------------------------------------------|
| object\_class\_fields                                | int      | Limit of fields per object class.                                      |
| object\_records\_per\_object\_class                    | int      | Limit of records per object class.                                     |
| user\_group\_members                                 | int      | Limit of user group members.                                           |
| object\_record\_owners                               | int      | Limit of object record owners.                                         |
| object\_class\_owners                                | int      | Limit of object class owners.                                          |
| object\_class\_permission\_sets                       | int      | Limit of permission sets per object class.                             |
| object\_class\_permission\_set\_assignees\_users        | int      | Limit of users as assignees per permission set in object class.        |
| object\_class\_permission\_set\_assignees\_user\_groups  | int      | Limit of user groups as assignees per permission set in object class . |
| task\_assignees\_users                               | int      | Limit of of users as default task assignees.                           |
| task\_assignees\_user\_groups                         | int      | Limit of of user groups as default task assignees.                     |
| user\_group\_owners                                  | int      | Limit of user group owners.                                            |
| object\_class\_forms                                 | int      | Limit of standalone forms per object class.                            |
| records\_permission\_sets                            | int      | Limit of record permission sets.                                       |
| object\_record\_permission\_set\_assignees\_users       | int      | Limit of users as assignees in object record permission sets.          |
| object\_record\_permission\_set\_assignees\_user\_groups | int      | Limit of user groups as assignees in object record permission sets.    |
| object\_class\_document\_templates                    | int      | Limit of document templates per object class.                          |
| ui\_configs                                         | int      | Limit of UI configurations.                                            |
| object\_relations\_children                          | int      | Limit of children in object relations.                                 |
| object\_relations\_depth                             | int      | Limit of depth in object relations.                                    |
| object\_relations\_top\_parents                       | int      | Limit of top-level parents in object relations.                        |
| user\_preferences                                   | int      | Limit of user preferences.                                             |
| public\_files                                       | int      | Limit of public files.                                                 |
| user\_group\_permission\_sets                         | int      | Limit of user group permission sets per group.                         |
| users\_group\_permission\_set\_assignees\_users         | int      | Limit of users as assignees per permission set per user group.         |
| users\_group\_permission\_set\_assignees\_user\_groups   | int      | Limit of user groups as assignees per permission set per user group.   |

* Successful status `200 OK`
* Response body schema

```json
{
  "object_classes": {
    "count": "<int>",
    "limit": "<int>"
  },
  "task_group_templates": {
    "count": "<int>",
    "limit": "<int>"
  },
  "task_templates": {
    "count": "<int>",
    "limit": "<int>"
  },
  "sequences": {
    "count": "<int>",
    "limit": "<int>"
  },
  "user_groups": {
    "count": "<int>",
    "limit": "<int>"
  },
  "roles": {
    "count": "<int>",
    "limit": "<int>"
  },
  "single_sign_on_configurations": {
    "count": "<int>",
    "limit": "<int>"
  },
  "authentication_objects": {
    "count": "<int>",
    "limit": "<int>"
  },
  "custom_components": {
    "count": "<int>",
    "limit": "<int>"
  },
  "additional_limits": {
    "object_class_fields": "<int>",
    "object_records_per_object_class": "<int>",
    "user_group_members": "<int>",
    "object_record_owners": "<int>",
    "object_class_owners": "<int>",
    "object_class_permission_sets": "<int>",
    "object_class_permission_set_assignees_users": "<int>",
    "object_class_permission_set_assignees_user_groups": "<int>",
    "task_assignees_users": "<int>",
    "task_assignees_user_groups": "<int>",
    "user_group_owners": "<int>",
    "object_class_forms": "<int>",
    "records_permission_sets": "<int>",
    "object_record_permission_set_assignees_users": "<int>",
    "object_record_permission_set_assignees_user_groups": "<int>",
    "object_class_document_templates": "<int>",
    "ui_configs": "<int>",
    "object_relations_children": "<int>",
    "object_relations_depth": "<int>",
    "object_relations_top_parents": "<int>",
    "user_preferences": "<int>",
    "public_files": "<int>",
    "user_group_permission_sets": "<int>",
    "users_group_permission_set_assignees_users": "<int>",
    "users_group_permission_set_assignees_user_groups": "<int>"
  }
}
```

### Errors

Standard validation errors.

---

---
url: >-
  /knowledgebase/finding-your-way-around/ui-and-navigation/list-page-filter-editor.md
---

# List page filter editor

Most list pages have a **filter editor**. You can use it to find rows that match specific conditions, which is especially useful when a list contains many items.

For example, you can filter long lists such as Task templates to show only the rows that match the values you need.

## Open the filter editor

The **filter editor** icon appears in the top-left corner of the list page, below the list name and to the right of the **+ Create** button.

![Filter editor icon on a list page](/knowledgebase/images/fywa-ui-list-1.png)

When you hover over the filter editor icon, an onscreen message is displayed.

![Tooltip shown when hovering over the filter editor icon](/knowledgebase/images/fywa-ui-list-2.png)

Click the filter editor icon to open the filter panel. The panel opens in the side stack to the right of the main content area.

The filter editor opens with a blank field that prompts you to **Select** a field. This list usually contains most of the column headers from the list page. Some columns, such as **Description** and **Actions**, are not included.

![Filter editor panel prompting the user to select a field](/knowledgebase/images/fywa-ui-list-3.png)

## Add a filter condition

To define a filter, select an option in the first field.

A second field is displayed, prompting you to select an operator. The available operators depend on the field you selected.

In the example below, **Name** is a mandatory text field, so operators such as **Is empty** and **Is not empty** are not shown.

![Filter editor showing operators available for the Name field](/knowledgebase/images/fywa-ui-list-4.png)

After you choose an operator, a third field is displayed so you can enter or select the value to filter by.

In this example, the operator is **is exactly**, so the third field prompts the user to **Enter text**.

![Filter editor showing an is exactly condition](/knowledgebase/images/fywa-ui-list-5.png)

In this example, the user is looking for an Object class called **Claimants**. After entering the value, click **Apply filter** to reduce the list to matching results.

![Filtered Object classes list showing the Claimants result](/knowledgebase/images/fywa-ui-list-6.png)

## Use multiple filters

You can use multiple filters to narrow the results further.

Each filter condition is applied in addition to the others. This means a row must satisfy all conditions in the filter editor before it appears in the results.

In the example below, the user is looking for Object classes related to contracts. The additional field is **Created by**. The operator **is equal to** allows the user to select one user.

![Filter editor showing an is equal to condition for Created by](/knowledgebase/images/fywa-ui-list-7.png)

The two results both include **contract** in the Object class **Name** and were created by Sean.

In the example below, the filter editor has been used on the Task templates list. The filter conditions are:

* **Created by** uses the operator **is one of**, with two users selected.
* **Task creation mechanism** uses the operator **is equal to**, with the value set to **Automatic**.
* **Task type** uses the operator **is equal to**, with the value set to Update object record type.

The list is filtered to one matching record.

![Task templates list filtered to one result](/knowledgebase/images/fywa-ui-list-8.png)

## View filtered results

When a filter is applied, the number of filtered results is displayed under the list page name.

The page navigation also shows a **Filtered results** control. If the filter panel is closed, clicking this control opens it again.

![List page showing the Filtered results control](/knowledgebase/images/fywa-ui-list-9.png)

Click the **X** next to **Filtered results** to clear the filter.

If the filter panel is open, it remains open and resets to a blank condition so you can start again.

If the applied filter returns no matching records, an onscreen message confirms that no records were found.

![List page showing no filtered results found](/knowledgebase/images/fywa-ui-list-11.png)

## Use operator-specific inputs

Some operators display different input fields depending on the selected field and expected value type.

For example, if you select the **is between** operator, the filter editor shows value fields that match the field type. A date field such as **Created** shows date inputs, while a numeric field such as **ID** shows number inputs.

![Filter editor showing from and to date fields](/knowledgebase/images/fywa-ui-list-12.png)

![Filter editor showing from and to number fields](/knowledgebase/images/fywa-ui-list-13.png)

## Remove filters

You can remove individual filter conditions at any time. You can also add other conditions to refine the results further.

To clear all filter conditions, click **Remove all** at the bottom of the filter panel.

A confirmation modal is displayed.

![Confirmation modal for removing all filter conditions](/knowledgebase/images/fywa-ui-list-14.png)

Click **Cancel** to keep the filter conditions.

Click **Remove** to clear the conditions. The filter panel remains open, but returns to a blank state. The list is shown in full again, subject to any page controls that are still in place.

## Things to remember

1. Only fields that have not already been used in the filter editor appear as options for additional conditions.
2. The button to add another condition is only active when the current condition is fully defined.
3. Second and subsequent conditions are added to the top of the filter editor.
4. The **Apply filter** button is only enabled when all conditions are fully defined.
5. If filters have been applied and the filter editor is closed, the filters are saved and reappear when the filter editor is next opened.

---

---
url: /knowledgebase/finding-your-way-around/ui-and-navigation/list-pages.md
---

# List pages

List pages are used throughout Catalyst to display and manage records, tasks, configuration items, and other system objects.

This article explains the common controls and features available on most list pages.

![List page showing common controls and navigation features](/knowledgebase/images/img_4410170126097_1776895725.png)

1. **List name**
2. **Number of records** in the list
3. **Button** used to create a new record
4. **Filter editor**
5. **Column configuration**
6. **Page navigation**
7. **Current page**
8. **Number of results per page**

To provide more detail about these controls, starting at the top left-hand side of the page, most list pages contain the following items:

**List name**

**Results** - shows either the total number of items in the list or, when a filter is applied, the number of matching results out of the total.

![List name and results count](/knowledgebase/images/fywa/fywa-list-pages-1.png)

**+ Create** - opens the form required to create a new item.

![Create button](/knowledgebase/images/fywa/fywa-list-pages-2.png)

**[Filter editor](/knowledgebase/finding-your-way-around/ui-and-navigation/list-page-filter-editor/)**

![Filter editor button](/knowledgebase/images/fywa/fywa-list-pages-3.png)

**[Column configuration](/knowledgebase/finding-your-way-around/ui-and-navigation/column-configuration-on-list-pages/)**

![Column configuration button](/knowledgebase/images/fywa/fywa-list-pages-4.png)

## Page controls

Moving horizontally across the page to the right are the **page controls**. These allow you to set the number of rows displayed per page: 10, 25, 50, 100, or All. Selecting **All** enables infinite scrolling.

If you change this setting, paging is reset to the first page.

You can configure different numbers of rows per page for each list page, and these settings are retained for future visits.

You can move between pages using the **First page**, **Previous page**, **Next page**, and **Last page** controls. These controls are disabled when they are not applicable. For example, **Last page** is disabled when you are already viewing the final page.

![Page controls](/knowledgebase/images/img_4410170126097_1776895726.png)

## Main content area

The main content area of the page is made up of column headers and list items.

All list pages contain the following columns:

* **ID** - a number automatically assigned to each new item or object when it is created. ID numbers are unique within the context of a list.
* **Name** - user-defined text.
* **Created** - a date and time stamp automatically applied when an item or object is created.
* **Last Edited** - a date and time stamp automatically applied when an item or object is modified. On the Users list, this column is replaced by **Last Logged In**.
* **Actions** - a kebab menu containing actions that vary depending on the list page and the user's role permissions.

The **ID** column can be repositioned but appears furthest left by default. The **Actions** column always appears furthest right.

List pages also contain additional columns depending on the type of information being displayed.

| **List page** | **Other column headers** | **Description** | **Object Classes** | **Created By** | **Last Edited By** |
| --- | --- | --- | --- | --- | --- |
| Records | X | X | Yes | X | X |
| Tasks | CompletedCompleted ByRecordTask TypeTemplateStatusDue Date | X | X | X | X |
| Object classes | # RecordsOwners | Yes | X | Yes | Yes |
| Task templates | # Tasks CreatedLast Task CreatedTask TypeTask Creation Mechanism | Yes | X | Yes | X |
| Task group templates | # Of Task Templates | Yes | Yes | X | X |
| Sequences | StateAPI Actor Names# Of API ActorsTask Group Templates | Yes | Yes | X | X |
| Users | UsernameRolesAccount TypeLast Logged In | X | X | X | X |
| Roles | X | Yes | X | Yes | Yes |
| User Groups | # Members# Owners | Yes | X | Yes | Yes |
| Single sign-on settings | ProviderEnabledAuto User Creation | X | X | Yes | Yes |
| Authentication objects | ProviderUsage | Yes | X | Yes | Yes |

## Selecting and opening items

Clicking a row in the list selects that item. If the side panel is open, the details shown update to reflect the current selection.

Double-clicking a row opens the item in **Edit mode**, provided the user has permission to edit it.

A selected row is highlighted, while other rows retain the standard alternating row colours.

![Table showing a selected row](/knowledgebase/images/img_4410170126097_1776895727.png)

## Sorting and resizing columns

Some column headers allow the list to be sorted alphabetically, numerically, ascending, or descending. Where available, click the column header to change the sort order.

When sorting is changed, paging is reset to the first page.

Sorting preferences are retained for future visits.

The width of visible columns can be increased or reduced by dragging the right edge of the column header.

## Scrolling

All list pages support both vertical and horizontal scrolling when more rows or columns are available than can be displayed on screen.

Column headers and page controls remain visible while scrolling vertically, making it easier to navigate large lists.

---

---
url: /knowledgebase/system-configuration/apis-and-variables/local-variable-actor.md
---

# Local Variable Actor

## What does the Local Variable Actor do?

The Local Variable Actor is used to evaluate logic and store data for use within a Sequence.

It can:

* Execute Jinja expressions
* Traverse relational data (parent/child records)
* Store values for reuse later in the Sequence

Local Variables do not update records or Trigger events. They are used purely for in-Sequence data processing and decision-making.

## How do I use the Local Variable Actor?

### 1. Add the Actor to your Sequence

![image (9).png](../../../images2/zendesk_5636687746847_001_671eb7c84dd5.png)

From the Actors panel (1) on the left-hand side, drag and drop the Local Variable Actor into your Sequence (2).

### 2. Configure the Actor

![](../../../images2/zendesk_5636687746847_002_abf87b01561a.png)

Right click the Local Variable and select Configure.

Within the configuration panel, you will define your Variable using the following fields:

* **Name** – the identifier for your Variable
* **Type** – the data type (eg. String)
* **Source** – where the value is derived from (eg. static value or another Actor)
* **Value** – the expression used to set the Variable (which may include Jinja)

### 3. Define the Variable

#### 3.1 Name

You can either define a new Variable, or select an existing Variable to update, for example if the Variable is recalculated later in the Sequence as with [**“Gate” Variables**](/knowledgebase/system-configuration/sequence-actors/invalid-actors-and-best-practice/).

To create a new Variable, click **Add**.

![](../../../images2/zendesk_5636687746847_003_66dd1f94796d.png)

To update an existing Variable, click **Select**:

![](../../../images2/zendesk_5636687746847_004_838bbb1f2004.png)

*Note: Variable names must be lowercase and contain no spaces. If you include capital letters or spaces, the system will automatically correct them.*

#### 3.2 Type

Local Variables support the following data types: String, Integer, Decimal, Boolean, Date, Date/Time, JSON, and Document.

When using Jinja logic, the output must match the selected data type. If it does not, the Variable will fail and prevent subsequent Triggers from activating.

**Common issue:** whitespace can be a source of problems. For example:

* A line break is not a valid character for a Date field
* A space is not a valid Boolean value

For more information on managing whitespace in Jinja, see [**Controlling Whitespace in Jinja**](/knowledgebase/system-configuration/merge-fields/controlling-whitespace-in-jinja-and-why-it-matters/).

#### 3.3 Source

Local Variables can have different sources depending on the preceding Actor and Trigger type.

**Available sources:**

* Static Value
* Document Picker
* API Call Output
* Loop Item

![](../../../images2/zendesk_5636687746847_005_f02158ebd3ff.png)

##### Static Value

This option is available in all cases. It allows you to reference data from the current record, including any Local Variable already created within the Sequence, or its relational model using merge fields or Jinja logic.

##### Document Picker

If the Local Variable follows a [**Document Picker**](/knowledgebase/system-configuration/sequence-actors/document-picker-actor/), it can reference the selected document.

*Note: This is only possible if a single document object is selected by the picker.*\
*The data type for this Variable is always Document.*

##### API Call Output

If the Local Variable follows an API Call Actor, it can use the API response as its source.

* If the Value field is left blank, the entire API Response will be stored in the Variable (consider data validation when doing this)
* Alternatively, you can reference specific parts of the response using {{output}} and Jinja expressions

For example, to return the number of items in a response:

```jinja
{{output.data | length}}
```

![](../../../images2/zendesk_5636687746847_006_761e7a10b1ce.png)

##### Loop Item

This option is only available if the Local Variable follows a Loop Actor and uses the Trigger "Loop Item Processed” (rather than “Actor Completed”).

The Local Variable will store the value of the current iteration in the Loop.

![](../../../images2/zendesk_5636687746847_007_e6c67faf16ed.png)

This allows you to reference the current item directly, without needing to manage indexes or track loop positions manually.

#### 3.4 Example—Using Different Sources for the Same Variable

A Local Variable can be redefined by multiple Actors throughout a Sequence. While the **Type must remain consistent**, the **Source can vary** depending on the workflow path.

In this example, the Sequence is adding an Owner to a record in a third-party system using an Owner Code. There are two possible paths depending on whether the owner already exists.

![](../../../images2/zendesk_5636687746847_008_0d1dcffcd6a0.png)

The Variable owner\_code is always defined as a String, but its source differs depending on the scenario:

##### Existing Owner

If the owner already exists, the Variable is set using a Static Value, referencing a field on the Autologyx Record.

```jinja
{{record.field\_owner\_code}}
```

![](../../../images2/zendesk_5636687746847_009_55fbaf404dd9.png)

##### New Owner

If a new owner needs to be created, the Variable is set using the API Call Output.

```jinja
{{output.OwnerCode}}
```

![](../../../images2/zendesk_5636687746847_010_51a86d7d9f80.png)

This approach allows the same Variable to be reused across different branches of the Sequence, while ensuring consistent data structure and simplifying downstream logic.

#### 3.5 Value

The Value field determines what is stored in the Variable.

This can be:

* A static value (eg. setting a Variable to true to indicate a Sequence has previously run for a record)
* A dynamic value generated using Jinja logic, merge fields, or a combination of both

The value can range from very simple expressions to more complex logic. For example, it may be a single Boolean value or a more advanced Jinja expression.

*Note: if you are using complex logic, follow general software engineering best practices. Autologyx builds do not have unlimited memory, and inefficiently written Variables can affect performance. In particular, avoid unnecessarily complex or deeply nested logic over large datasets, as this can significantly increase processing time and memory usage.*

#### 3.6 Test the Variable (Optional)

You can test your Local Variable configuration before running the sequence.

Enter a **Record ID** and click **Test Variable**:

![Test Variable](../../../images2/zendesk_5636687746847_011_59d674977c35.png) ![](../../../images2/zendesk_5636687746847_012_eb698257b036.png)

This allows you to preview the value the variable would return if the sequence were triggered for that record.

This is particularly useful when working with:

* Jinja expressions
* API responses
* Complex logic

Testing helps ensure your variable returns the expected value before it is used in downstream actors.

### 4. Rename the Actor (Best Practice)

By default, most Actors are labelled using their Actor type (eg. “Local Variable”). In Sequences with many Variables, this can make navigation difficult.

To improve clarity, it is best practice to give each Local Variable a meaningful name that reflects its purpose.

Right-click the Actor and select **Properties**:

![](../../../images2/zendesk_5636687746847_013_0577ea608a61.png)

Update the **Name** field to something descriptive:

![](../../../images2/zendesk_5636687746847_014_e0cd8298b3ef.png)

## How are Local Variables used?

Once defined, Local Variables can be referenced in downstream Actors using Jinja:

```jinja
{{ variables.bid\_cost }}
```

**Common use cases include:**

* Supplying values to Send Message Actors
* Driving conditions in Triggers
* Feeding into API calls
* Avoiding repeated calculations

## Important behaviour and platform nuances

**Local Variables:**

* Cannot directly update records
* Do not persist across Sequences
* Do not appear in activity logs

Local Variables also do not exist until the Sequence reaches the Actor where they are first defined.

**Trigger implication:** if a Trigger checks whether a Variable **equals** or **does not equal** a value, it will never run if the Variable has not yet been created.

Instead, you should check whether the Variable “**Is Empty**” or “**Is Not Empty**”.

## Execution timing

Variables are evaluated at the moment the Actor runs.

They will not automatically update if:

* The Record changes later
* Another Sequence modifies data afterward

---

---
url: >-
  /knowledgebase/applied-ai/mcp-services/mcp-work/mcp-work-configuration/manage-mcp-connectors.md
---
# Manage MCP connectors

You can create and maintain MCP connectors for AI/MCP integrations from **System configuration** > **Integrations**. This article explains how to view connectors, create and edit a connector, copy its connection details, reset its Client Secret, and delete a connector.

## When to use this

Use these steps when you need to add an MCP connector for an AI integration, update an existing connector, retrieve its URL or Client ID, rotate its Client Secret, or remove a connector that is no longer required.

## Before you start

MCP capabilities must be enabled for your Autologyx environment. If MCP capabilities are not enabled, contact your account manager.

Super Admins are the intended connector managers and you will need access to **System configuration** > **Integrations** and permission to manage MCP connectors.

## View MCP connectors

1. Go to **System configuration** > **Integrations**.
2. Open the connectors configuration for the required AI/MCP integration.
3. The **MCP connectors** page lists the connector **ID**, **Name**, **Status**, and **Actions**.
4. You can sort the list by **ID** or **Name**.

![MCP connectors list showing connector details and Actions menus](../../../../../images/View_MCP_connectors.png)

## Create an MCP connector

1. From the **MCP connectors** page, click **Create**.
2. Enter a **Name**. The name is required and must be unique.
3. Optionally enter a **Description**.
4. Set the **Enabled** toggle as required. It is enabled by default in the supplied acceptance criteria.
5. Click **Save**.

![Create MCP connector form showing the name, description, Enabled toggle and Object classes selection](../../../../../images/Create_MCP_connector.png)

If the name is already in use, Autologyx displays the standard duplicate-name error and does not create the connector. Change the name before trying to save again.

After a connector is created, Autologyx displays its generated connection details, including its URL, OAuth Client ID, and OAuth Client Secret. Copy the Client Secret at this point because its plain-text value is not available again after the modal is closed.

![MCP connector created modal showing URL, OAuth Client ID, OAuth Client Secret and copy controls](../../../../../images/integration-oauth-url-fields.png)

If you leave the create page after entering a name or description, the standard unsaved-changes flow applies.

## Edit an MCP connector

1. On the **MCP connectors** page, open the connector's **Actions** menu and select **Edit**.
2. Update the connector **Name**, **Description**, or **Enabled** state.
3. Review the **Configuration** area. The connector URL and OAuth Client ID are read-only. The Client Secret is obscured.
4. Click **Save** to apply your changes, or **Cancel** to leave them unchanged.

The standard duplicate-name handling also applies when renaming an existing connector.

## Copy the connector URL or Client ID

On the connector's edit page, use the copy control beside the connector URL or OAuth Client ID to copy that value to the clipboard.

## Reset the Client Secret

Resetting a Client Secret immediately invalidates the current secret. Any integration still using the old value stops working until it is updated.

1. Open the connector's edit page.
2. In the **Configuration** area, use the reset control beside **OAuth Client Secret**.
3. Review the confirmation message and click **Reset**.
4. Copy the new Client Secret from the confirmation modal before closing it.
5. Update any external system that uses the connector with the new secret.

The reset is applied immediately and is independent of the page's **Save** button or any other unsaved edits. After the new-secret modal is closed, the plain-text Client Secret is no longer accessible in the UI.

## Delete an MCP connector

1. On the **MCP connectors** page, open the connector's **Actions** menu.
2. Select **Delete**.
3. Review the confirmation dialog.
4. Click **Delete** to permanently remove the connector, or **Cancel** to keep it.

Deleting a connector removes it from the connectors list and from the Object Class permissions UI where it was previously available.

## Things to remember

* Connector names must be unique.
* The generated Client Secret is a one-time value. Store it securely when it is displayed.
* Resetting a Client Secret invalidates the old value immediately.
* Deleting an MCP connector cannot be undone.

## Useful info

1. You can associate Object Classes with a connector when creating it or later from its edit page.
2. Associated connectors can then appear in the **Applied AI** control when permissions are configured for those Object Classes.

---

---
url: >-
  /knowledgebase/system-configuration/about-system-configuration/managing-authentication-methods-by-user-account-type.md
---

# Managing authentication methods by user account type

As of version **11.2.0**, Catalyst introduces support for configuring and enforcing authentication methods per user account type via API. This allows administrators to define whether a given user group is allowed to authenticate using passwords, Single Sign-On (SSO), or both.

This feature is especially useful in security-conscious environments where access rules need to be explicitly enforced, for example, allowing only SSO for external users while retaining password-based login for internal teams.

## Configuration via API

Authorised users (those with the `standard_authentication.edit` permission) can define which authentication method is permitted for each account type by calling:

```
PATCH /api/security/
```

with the following payload schema:

```
{
  "authentication_method": {
    "external": "sso|password|any",
    "internal": "sso|password|any",
    "full": "sso|password|any",
    "super_admin": "sso|password|any"
  }
}
```

**Accepted keys (user account types)**

* `external` – External users (e.g., clients, partners)
* `internal` – Internal staff accounts (if used)
* `full` – Config Admin users
* `super_admin` – Accounts with full platform access

Only the keys provided in the payload are updated. Omitted user types retain their existing settings.

**Accepted values (authentication methods)**

* `any` – Both password login and SSO are permitted
* `password` – Only username + password login is permitted
* `sso` – Only SSO login (e.g., Okta) is permitted

To view the current configuration, users with the `standard_authentication.view` permission can call:

```
GET /api/security/
```

## Authentication enforcement logic

**Authentication enforcement**

Catalyst enforces your authentication rules immediately upon login attempts and during password reset processes. Users attempting to access the platform through unauthorised methods receive clear feedback:

```
"detail": "This user account is not allowed to log in using login and password."
```

```
"detail": "This user account is not allowed to log in using Single Sign-On."
```

This prevents users from bypassing login restrictions through external identity providers when their access is meant to be limited to password authentication only, such as in the case of Super admin or Config admin users in regulated environments.

**Password reset enforcement**

The enforcement rules also extend to all password reset actions, including:

* Sending a password reset email
* Setting a new password with a token
* Accessing the reset password form via tokenised links

This comprehensive approach prevents SSO-only users from circumventing authentication policies through password recovery channels, maintaining the integrity of your security framework.

**Important:** Before setting any authentication method to `"sso"`, ensure that Single Sign-On is properly configured and tested. Setting SSO as the only authentication method without proper configuration will lock users out of the system.

Administrators now have granular control over authentication pathways, enabling security policies that match the specific access requirements of different user groups within your organisation.

---

---
url: >-
  /knowledgebase/system-configuration/working-with-document-templates/manual-generation-of-a-document-from-a-template.md
---

# Manual generation of a document from a template

Having created a document template with manual generation enabled, the template name will appear in the **Templates** tab of the side panel for each record in the object class.

![Screenshot 2024-01-15 at 22.22.18.png](/knowledgebase/images/img_16114629981981_1776895851.png)

![Screenshot 2024-01-15 at 20.32.50.png](/knowledgebase/images/img_16114629981981_1776895851.png)

## Actions menu options

The template has an **Actions** menu with two options:

![Screenshot 2024-01-15 at 20.46.29.png](/knowledgebase/images/img_16114629981981_1776895852.png)

### Generate and download document

If you select **Generate and download document**, the template will be generated for that record.

Once downloaded, the icon for successful download will be displayed in the status field.

However, if for any reason the document cannot be generated, the status will remain blank. If this happens, you will need to check your template for incorrect merges or IF Statements, etc.

![Screenshot 2024-01-15 at 20.56.03.png](/knowledgebase/images/img_16114629981981_1776895852.png)

### Generate and save to field

If you select **Generate and save to field**, you will be presented with a list of the **Document** type fields in the **Object class**.

![Screenshot 2024-01-15 at 22.26.37.png](/knowledgebase/images/img_16114629981981_1776895852.png)

Scroll to the required field and click it. Then click **Select field**.

The document will be generated, downloaded, and saved to the field. On the record, the document will be shown in the field as below:

|  |  |
| --- | --- |
| Screenshot 2024-01-15 at 22.31.05.png | Screenshot 2024-01-15 at 22.30.52.png |

## Repeat manual generation

Manual generation of a document from a template can be repeated any number of times. This feature is particularly useful if record data is constantly changing and updated documents are required at irregular intervals.

---

---
url: /api/catalyst/resources/mcp/mcp-connector-object-classes.md
---
# MCP Connector Object Classes

This document describes the API for managing associations between an MCP Connector and Object Classes.

An [MCP Connector](./mcp-connectors) is a registered external client of the MCP server. Object Classes can be
associated with a connector so that they are available for permission configuration for the connector.

> :information\_source: In the scope of this story, associating or disassociating Object Classes with a connector
> does **not** affect user access through MCP. That behaviour is a separate, future story.

All endpoints are nested under a connector (nested routers) and use the standard limit/offset pagination,
sorting and filtering mechanisms.

## Permissions

| Endpoint                                                | Permission                                        |
|---------------------------------------------------------|---------------------------------------------------|
| POST `/api/mcp/connectors/{connector_id}/object-classes/`    | Super Admin only                             |
| OPTIONS `/api/mcp/connectors/{connector_id}/object-classes/` | Any authenticated user                       |
| GET `/api/mcp/connectors/{connector_id}/object-classes/`     | Super Admin only                             |
| DELETE `/api/mcp/connectors/{connector_id}/object-classes/`  | Super Admin only                             |

These permissions are not manageable via Roles.

## POST /api/mcp/connectors/`connector_id`/object-classes/

Associates one or more Object Classes with the MCP Connector.
Batch operation - accepts a list of Object Class IDs.

### Permissions

Requires `authentication` and the User must be a Super Admin.

### URL parameters

| Key          | Type | Notes             |
|--------------|------|-------------------|
| connector\_id | int  | MCP Connector ID  |

### Request example

* Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

### Body

The request body is a JSON array of Object Class IDs.

```json
[<object_class_id>, <object_class_id>, ...]
```

### Behaviour

* Up to `100` Object Class IDs can be sent in a single request.
  The limit can be obtained via `OPTIONS /api/mcp/connectors/{connector_id}/object-classes/`.
* Object Classes already associated with the connector are silently accepted without an error or a warning.
* Duplicate IDs in the payload are de-duplicated - each Object Class appears at most once in the response.
* The operation is idempotent.

### Validations

* Body must be a non-empty JSON list.
* Each item must be an integer.
* Each item must be the ID of an existing Object Class.
* Maximum number of items: `100`.

### Sample request body

POST /api/mcp/connectors/`connector_id`/object-classes/

```json
[12, 7, 30]
```

### Response

The response is a **flat (non-paginated)** array containing both the newly associated and the already
associated Object Classes from the request payload. Object Classes previously associated with the connector
but not present in the payload are **not** returned.

The array is sorted by `id` ascending.

| Key  | Type   | Notes             |
|------|--------|-------------------|
| id   | int    | Object Class ID   |
| name | string | Object Class name |

* Successful status `201 Created`
* Response body:

```json
[
    {
        "id": 7,
        "name": "Contract"
    },
    {
        "id": 12,
        "name": "Invoice"
    }
]
```

### Errors

| Error                                             | Response code    | Message                                                          |
|---------------------------------------------------|------------------|-----------------------------------------------------------------|
| List of IDs is empty                              | 400 Bad Request  | "detail": \["This list may not be empty."]                       |
| List of IDs is not provided                       | 400 Bad Request  | "detail": \["This field is required."]                           |
| Request body is not a list                        | 400 Bad Request  | "detail": \["Expected a list of items but got type "{type}"."] |
| List contains values other than integers          | 400 Bad Request  | "detail": \["Incorrect type. Expected pk value, received {type}."] |
| Object Class with the given ID does not exist     | 400 Bad Request  | "detail": \["Invalid pk "{object\_class\_id}" - object does not exist."] |
| More than 100 items sent in the request body      | 400 Bad Request  | "detail": \["Up to 100 items allowed."]                          |
| Not authenticated                                 | 401 Unauthorized | "detail": "Authentication credentials were not provided."       |
| Caller is not a Super Admin                       | 403 Forbidden    | "detail": "You do not have permission to perform this action."  |
| `connector_id` does not exist                     | 404 Not Found    |                                                                 |

## OPTIONS /api/mcp/connectors/`connector_id`/object-classes/

Returns machine-readable metadata for the batch association endpoint.

### Permissions

Requires `authentication` only.

### URL parameters

| Key          | Type | Notes             |
|--------------|------|-------------------|
| connector\_id | int  | MCP Connector ID  |

### Request example

* Headers

```
Request Method: OPTIONS
Content-Type: application/json
Authorization: JWT access_token
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "batch": {
        "type": "set",
        "required": true,
        "autocomplete": "/api/object-classes/autocomplete/?text__icontains="
    },
    "restrictions": {
        "limit_items_in_batch": 100
    }
}
```

## GET /api/mcp/connectors/`connector_id`/object-classes/

Returns the list of Object Classes associated with the MCP Connector.

### Permissions

Requires `authentication` and the User must be a Super Admin.

### URL parameters

| Key          | Type | Notes             |
|--------------|------|-------------------|
| connector\_id | int  | MCP Connector ID  |

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key            | Type       | Notes                                                        |
|----------------|------------|--------------------------------------------------------------|
| limit          | int        |                                                              |
| offset         | int        |                                                              |
| total\_count    | int        | Total number of Object Classes associated with the connector. |
| filtered\_count | int        | Number of associated Object Classes with filters applied.    |
| next           | URL / null | Next page URL (null if there is no next page)                |
| previous       | URL / null | Previous page URL (null if there is no previous page)        |
| results        | Array      | Described in the next table.                                 |

#### Response `results` array

| Key  | Type   | Notes             |
|------|--------|-------------------|
| id   | int    | Object Class ID   |
| name | string | Object Class name |

Results are sorted by `id` ascending by default.

### Response example

* Status `200 OK`
* Body

```json
{
    "limit": 100,
    "offset": 0,
    "filtered_count": 2,
    "total_count": 2,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": 7,
            "name": "Contract"
        },
        {
            "id": 12,
            "name": "Invoice"
        }
    ]
}
```

### Sorting

| Parameter | Example                                                                | Notes          |
|-----------|-----------------------------------------------------------------------|----------------|
| id        | {build}/api/mcp/connectors/{connector\_id}/object-classes/?ordering=id   | Ascending      |
| id        | {build}/api/mcp/connectors/{connector\_id}/object-classes/?ordering=-id  | Descending (-) |
| name      | {build}/api/mcp/connectors/{connector\_id}/object-classes/?ordering=name | Ascending      |
| name      | {build}/api/mcp/connectors/{connector\_id}/object-classes/?ordering=-name | Descending (-) |

### Filtering

| Parameter | Predicates      | Example                                                                       |
|-----------|-----------------|-------------------------------------------------------------------------------|
| id        | standard numeric | {build}/api/mcp/connectors/{connector\_id}/object-classes/?id\_\_gt=10           |
| name      | standard string  | {build}/api/mcp/connectors/{connector\_id}/object-classes/?name\_\_icontains=foo |

Standard numeric predicates for `id`: `=`, `gt`, `gte`, `lt`, `lte`, `range` (e.g. `id`, `id__gt`, `id__lt`, `id__range`).
Standard string predicates for `name`: `=`, `iexact`, `contains`, `icontains`, `startswith`, `istartswith`, `endswith`, `iendswith` (e.g. `name`, `name__icontains`, `name__istartswith`).

### Errors

| Error                        | Response code    | Message                                                        |
|------------------------------|------------------|----------------------------------------------------------------|
| Not authenticated            | 401 Unauthorized | "detail": "Authentication credentials were not provided."      |
| Caller is not a Super Admin  | 403 Forbidden    | "detail": "You do not have permission to perform this action." |
| `connector_id` does not exist | 404 Not Found    |                                                                |

## DELETE /api/mcp/connectors/`connector_id`/object-classes/

Disassociates one or more Object Classes from the MCP Connector.
Batch operation - accepts a list of Object Class IDs.

### Permissions

Requires `authentication` and the User must be a Super Admin.

### URL parameters

| Key          | Type | Notes             |
|--------------|------|-------------------|
| connector\_id | int  | MCP Connector ID  |

### Request example

* Headers

```
Request Method: DELETE
Content-Type: application/json
Authorization: JWT access_token
```

### Body

The request body is a JSON array of Object Class IDs.

```json
[<object_class_id>, <object_class_id>, ...]
```

### Behaviour

* Up to `100` Object Class IDs can be sent in a single request.
* Object Classes not currently associated with the connector are silently accepted without an error or a warning.
* The operation is idempotent.

### Validations

* Body must be a non-empty JSON list.
* Each item must be an integer.
* Each item must be the ID of an existing Object Class.
* Maximum number of items: `100`.

### Sample request body

DELETE /api/mcp/connectors/`connector_id`/object-classes/

```json
[12, 34, 56]
```

### Response

* Successful status `204 No Content`
* The response has no body.

### Errors

| Error                                             | Response code    | Message                                                          |
|---------------------------------------------------|------------------|-----------------------------------------------------------------|
| List of IDs is empty                              | 400 Bad Request  | "detail": \["This list may not be empty."]                       |
| List of IDs is not provided                       | 400 Bad Request  | "detail": \["This field is required."]                           |
| Request body is not a list                        | 400 Bad Request  | "detail": \["Expected a list of items but got type "{type}"."] |
| List contains values other than integers          | 400 Bad Request  | "detail": \["Incorrect type. Expected pk value, received {type}."] |
| Object Class with the given ID does not exist     | 400 Bad Request  | "detail": \["Invalid pk "{object\_class\_id}" - object does not exist."] |
| More than 100 items sent in the request body      | 400 Bad Request  | "detail": \["Up to 100 items allowed."]                          |
| Not authenticated                                 | 401 Unauthorized | "detail": "Authentication credentials were not provided."       |
| Caller is not a Super Admin                       | 403 Forbidden    | "detail": "You do not have permission to perform this action."  |
| `connector_id` does not exist                     | 404 Not Found    |                                                                 |

## DELETE /api/mcp/connectors/`connector_id`/object-classes/`object_class_id`/

This method is **not supported**. Disassociation is performed exclusively via the batch
`DELETE /api/mcp/connectors/{connector_id}/object-classes/` endpoint described above.

Calling `DELETE` on a single Object Class detail route returns `405 Method Not Allowed`.

| Error             | Response code          | Message                                          |
|-------------------|------------------------|--------------------------------------------------|
| Method not allowed | 405 Method Not Allowed | "detail": "Method "DELETE" not allowed."       |

---

---
url: /api/catalyst/resources/mcp/mcp-connectors.md
---
# MCP Connectors

This document describes API for MCP Connectors.

## Permissions

To manage MCP Connectors a following permissions will be used.

| Permission | Manageable via Roles | Description        |
|------------|----------------------|--------------------|
| list       | false                | Allow list         |
| view       | false                | Allow view details |
| create     | false                | Allow create       |
| edit       | false                | Allow edit         |
| delete     | false                | Allow delete       |

Permissions are not manageable. Only Super Admins are granted these permissions,
except for `list`, which is available to all authenticated users.

## POST /api/mcp/connectors/

Creates MCP Connector.

### Permissions

Requires `authentication` and `mcp_connectors.create` permission.

### Request example

* Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

### Body

| Key           | Type   | Required | Notes                                  |
|---------------|--------|----------|----------------------------------------|
| name          | string | True     |                                        |
| integration   | uuid   | True     | UUID of an existing AI MCP integration |
| description   | string | False    |                                        |
| is\_enabled    | bool   | False    |                                        |
| allowed\_tools | Array  | False    | Array of tools names                   |

### Validations

* name
  * Is required
  * Max length: 100
  * Is unique
* integration
  * Is required
  * is UUID of an existing AI MCP integration
* Maximum number of MCP Connectors: 100.

### Sample request body

POST /api/mcp/connectors/

```json
{
    "name": "Claude - analytics",
    "integration": "a982601a-36c9-4735-9746-d251ae84ed71",
    "description": "A connector for Claude agents preparing analytics reports",
    "is_enabled": true,
    "allowed_tools": ["search_object_classes", "get_object_record_document"]
}

```

### Response

* Successful status `201 Created`
* Response body:

```json
{
    "id": 16,
    "name": "Claude - analytics",
    "integration": "a982601a-36c9-4735-9746-d251ae84ed71",
    "description": "A connector for Claude agents preparing analytics reports",
    "is_enabled": true,
    "status": "enabled",
    "server_url": "https://acme.autologyx.com/mcp?connector=16",
    "client_id": "<client_id>",
    "client_secret": "<client_secret>",
    "created_at": "2026-07-14T11:26:32.751496+03:00",
    "created_by": {
        "id": 1,
        "first_name": "John",
        "last_name": "Smith",
        "username": "j.smith@autologyx.com",
        "company_name": "Autologyx",
        "is_deleted": false
    },
    "modified_at": "2026-07-14T11:26:32.751520+03:00",
    "modified_by": {
        "id": 1,
        "first_name": "John",
        "last_name": "Smith",
        "username": "j.smith@autologyx.com",
        "company_name": "Autologyx",
        "is_deleted": false
    },
    "_meta": {
        "permissions": {
            "list": true,
            "create": true,
            "view": true,
            "edit": true,
            "delete": true
        }
    },
    "allowed_tools": ["search_object_classes", "get_object_record_document"]
}
```

**⚠️ Warning:** Because the `client_secret` is stored securely on the server as a hashed value,
it is returned only once, immediately after the POST request.
It cannot be recovered later, so it must be captured and stored by the user for later use.

### Errors

Non-standard validation errors.

| Error                     | Response code   | Message                                                      |
|---------------------------|-----------------|--------------------------------------------------------------|
| Integration is not AI MCP | 400 Bad Request | "integration": \["{uuid} is not a valid AI MCP integration."] |

## PATCH /api/mcp/connectors/`connector_id`/

Updates MCP Connector.

### Permissions

Requires `authentication` and `mcp_connectors.edit` permission.

### Request example

* Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

### Body

| Key            | Type   | Notes                 |
|----------------|--------|-----------------------|
| name           | string |                       |
| description    | string |                       |
| is\_enabled     | bool   |                       |
| allowed\_tools  | Array  | Array of tools names  |

### Validations

* name
  * Max length: 100
  * Is unique
* description
  * Max length: 500

### Sample request body

PATCH /api/mcp/connectors/`connector_id`/

```json
{
    "name": "Claude - analytics",
    "description": "A connector for Claude agents preparing analytics reports",
    "is_enabled": true,
    "allowed_tools": ["search_object_classes"]
}

```

### Response

* Successful status `200 Ok`
* Response body:

```json
{
    "id": 16,
    "name": "Claude - analytics",
    "integration": "a982601a-36c9-4735-9746-d251ae84ed71",
    "description": "A connector for Claude agents preparing analytics reports",
    "is_enabled": true,
    "status": "enabled",
    "server_url": "https://acme.autologyx.com/mcp?connector=16",
    "client_id": "<client_id>",
    "created_at": "2026-07-14T11:26:32.751496+03:00",
    "created_by": {
        "id": 1,
        "first_name": "John",
        "last_name": "Smith",
        "username": "j.smith@autologyx.com",
        "company_name": "Autologyx",
        "is_deleted": false
    },
    "modified_at": "2026-07-14T11:50:31.851520+03:00",
    "modified_by": {
        "id": 1,
        "first_name": "John",
        "last_name": "Smith",
        "username": "j.smith@autologyx.com",
        "company_name": "Autologyx",
        "is_deleted": false
    },
    "_meta": {
        "permissions": {
            "list": true,
            "create": true,
            "view": true,
            "edit": true,
            "delete": true
        }
    },
    "allowed_tools": ["search_object_classes"]
}
```

### Errors

Standard validation errors.

## GET  /api/mcp/connectors/

Returns list of MCP Connectors.

### Permissions

Requires `authentication`.

### Request example

#### Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

#### Response `results` array

| Key               | Type     | Notes                         |
|-------------------|----------|-------------------------------|
| id                | int      |                               |
| name              | string   |                               |
| description       | string   |                               |
| integration       | UUID     |                               |
| is\_enabled        | bool     |                               |
| status            | enum     | Values: enabled, disabled     |
| created\_at        | datetime |                               |
| created\_by        | user     |                               |
| modified\_at       | datetime |                               |
| modified\_by       | user     |                               |
| \_meta.permissions | Object   | Dict describing permissions.  |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 20,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 5,
      "name": "Claude connector",
      "description": "The connector for Claude agents"
      "integration": "87138c1b-ac83-4588-9be0-aa092e7753b0",
      "is_enabled": true,
      "status": "enabled",
      "created_at": "2026-07-12T11:21:51.877690+02:00",
      "created_by": <user>,
      "modified_at": "2026-07-14T11:11:31.127734+02:00",
      "modified_by": <user>,
      "_meta": {
        "permissions": {
            "list": true,
            "view": true,
            "edit": true,
            "create": true,
            "delete": true,
        }
      }
    }
  ]
}
```

### Sorting

| Parameter   | Example                                               | Notes          |
|-------------|-------------------------------------------------------|----------------|
| id          | {build}/api/mcp/connectors/?ordering=id           | Ascending      |
| id          | {build}/api/mcp/connectors/?ordering=-id          | Descending (-) |
| name        | {build}/api/mcp/connectors/?ordering=name         | Ascending      |
| name        | {build}/api/mcp/connectors/?ordering=-name        | Descending (-) |
| created\_at  | {build}/api/mcp/connectors/?ordering=created\_at   | Ascending      |
| created\_at  | {build}/api/mcp/connectors/?ordering=-created\_at  | Descending (-) |
| modified\_at | {build}/api/mcp/connectors/?ordering=modified\_at  | Ascending      |
| modified\_at | {build}/api/mcp/connectors/?ordering=-modified\_at | Descending (-) |

### Filtering

| Parameter   | Predicates        | Example                                                              |
|-------------|-------------------|----------------------------------------------------------------------|
| id          | =                 | {build}/api/mcp/connectors/?id=9                                     |
| name        | standard string   | {build}/api/mcp/connectors/?name\_\_icontains=foobar                   |
| integration | =, in             | {build}/api/mcp/connectors/?integration\_\_in=uuid1,uuid2              |
| is\_enabled  | standard bool     | {build}/api/mcp/connectors/?is\_enabled=true                          |\
| created\_at  | standard datetime | {build}/api/mcp/connectors/?created\_at\_\_gte=2022-01-01               |
| created\_by  | standard set      | {build}/api/mcp/connectors/?created\_by\_\_in=123,234,345               |
| modified\_at | standard datetime | {build}/api/mcp/connectors/?modified\_at\_\_range=2022-01-01,2022-01-31 |
| modified\_by | standard set      | {build}/api/mcp/connectors/?modified\_by=123                          |

### Errors

| Error                | Response code     | Message                                                    |
|----------------------|-------------------|------------------------------------------------------------|
| Not authenticated    | 401 Unauthorized  | "detail": "Authentication credentials were not provided."  |

## GET /api/mcp/connectors/`connector_id`/

Retrieves the MCP Connector details.

### Permissions

Requires `authentication` and `mcp_connectors.view` permission.

### URL parameters

| Key           | Type | Notes                           |
|---------------|------|---------------------------------|
| connector\_id  | int  | 	                               |

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key                | Type     | Notes                                   |
|--------------------|----------|-----------------------------------------|
| id                 | int      | Automatically generated by the backend. |
| name               | string   |                                         |
| description        | string   |                                         |
| integration        | UUID     |                                         |
| is\_enabled         | bool     |                                         |
| status             | enum     | Values: enabled, disabled               |
| server\_url         | string   |                                         |
| client\_id          | string   |                                         |
| created\_at         | datetime |                                         |
| created\_by         | user     |                                         |
| modified\_at        | datetime |                                         |
| modified\_by        | user     |                                         |
| \_meta.permissions | Object   | Object describing permissions.          |
| allowed\_tools      | Array    | Array of allowed tools names.           |

### Response example

* Status `200 OK`
* Body

```json
{
  "id": 5,
  "name": "Claude connector",
  "description": "The connector for Claude agents",
  "integration": "87138c1b-ac83-4588-9be0-aa092e7753b0",
  "is_enabled": true,
  "status": "enabled",
  "created_at": "2026-07-12T11:21:51.877690+02:00",
  "created_by": <user>,
  "modified_at": "2026-07-14T11:11:31.127734+02:00",
  "modified_by": <user>,
  "_meta": {
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "create": true,
      "delete": true,
    }
  },
  "allowed_tools": ["search_object_classes"]
}
```

## DELETE /api/mcp/connectors/`connector_id`/

Remove a MCP Connector.

### Permissions

Requires `authentication` and `mcp_connectors.delete` permission.

### Request example

* Headers

```
Request Method: DELETE
Location: /api/mcp/connectors/1/
Authorization: JWT access_token
```

### Response example

* Status `204 No Content`
* Body

### Errors

| Error                    | Response code | Message                                                        |
|--------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Connector does not exist | 404 Forbidden | "detail": "Not found"                                          |

## POST /api/mcp/connectors/`connector_id`/reset-client-secret/

Resets client secret for the MCP Connector.

### Permissions

Requires `authentication` and the User must be a Super Admin.

### URL parameters

| Key           | Type | Notes                           |
|---------------|------|---------------------------------|
| connector\_id  | int  | 	                               |

### Request example

* Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key                | Type     | Notes                                     |
|--------------------|----------|-------------------------------------------|
| id                 | int      |    |
| name               | string   |                                           |
| server\_url         | string   |                                           |
| client\_id          | string   |                                           |
| client\_secret      | string   |                                           |

### Response example

* Status `200 OK`
* Body

```json
{
    "id": 16,
    "name": "Claude connector",
    "server_url": "https://acme.autologyx.com/mcp?connector=16",
    "client_id": "<client_id>",
    "client_secret": "<client_secret>"
}
```

## OPTIONS /api/mcp/connectors/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> OPTIONS /api/mcp/connectors/

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "name",
                "type": "string",
                "predicates": [
                    "exact",
                    "iexact",
                    "contains",
                    "icontains",
                    "startswith",
                    "istartswith",
                    "endswith",
                    "iendswith"
                ],
                "sort_ok": true
            },
            {
                "alias": "integration",
                "type": "uuid",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false
            },
            {
                "alias": "description",
                "type": "string",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "is_enabled",
                "type": "bool",
                "predicates": [
                    "exact"
                ],
                "sort_ok": false
            },
            {
                "alias": "status",
                "type": "enum",
                "predicates": [],
                "sort_ok": false,
                "values": [
                    {
                        "value": "enabled",
                        "text": "enabled"
                    },
                    {
                        "value": "disabled",
                        "text": "disabled"
                    }
                ]
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "modified_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "modified_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            }
        ]
    },
    "details": {
        "schema": [
            {
                "alias": "name",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "min_length",
                        "length": 1
                    },
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "description",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 500
                    }
                ]
            },
            {
                "alias": "is_enabled",
                "type": "bool",
                "required": false
            },
            {
                "alias": "integration",
                "type": "uuid",
                "required": true
            },
            {
              "alias": "allowed_tools",
              "type": "set",
              "required": false
            }
        ]
    },
    "restrictions": {
        "limit_items": 100
    }
}
```

---

---
url: /api/mcp-standards.md
---
# MCP Standards

This page defines the platform-wide standards used when exposing Autologyx functionality through Model Context Protocol (MCP) servers.

These standards exist to ensure that MCP tools are predictable, discoverable, and consistently interpreted by AI agents.

Unlike traditional APIs, MCP tools are selected dynamically by AI models. Tool definitions must therefore be optimised primarily for agent understanding rather than human presentation.

The standards described below are based on Autologyx MCP implementations generated from Django REST Framework APIs.

## Why standards matter

AI agents select tools based on:

* tool name
* tool description
* input schema
* descriptions of input attributes
* argument structure

Consistent standards improve:

* tool discoverability
* tool selection accuracy
* agent reliability
* interoperability across MCP clients

***

## General principles

MCP tools are designed primarily for AI agents.

Users should express intent naturally:

> Create an Object Record for customer John Smith.

rather than:

> Use create\_object\_record.

The agent is responsible for selecting the appropriate tool.

For this reason, tool definitions should prioritise:

1. Clear names
2. Accurate descriptions
3. Complete schemas
4. Meaningful attribute descriptions
5. Predictable argument structure

The optional `title` field may improve presentation but should not be relied upon for tool selection.

***

## Tool naming

### Naming convention

Tool names should:

* use lowercase letters
* use snake\_case
* be action-oriented
* remain stable over time

Recommended format:

```text
<action>_<resource>
```

Examples:

```text
search_object_classes
get_object_class
create_object_record
update_object_record
assign_task_to_users
```

### MCP title attribute

The MCP `title` attribute may be used for human-friendly presentation.

Example:

```json
{
  "name": "search_object_classes",
  "title": "Search Object Classes"
}
```

However, MCP clients and AI models may ignore the `title` attribute when selecting tools.

Tool discovery and selection should therefore rely primarily on:

* `name`
* `description`
* `inputSchema`

The `title` attribute should be treated as optional presentation metadata.

***

## Tool descriptions

Tool descriptions are one of the most important factors affecting tool selection.

Descriptions should clearly explain:

* what the tool does
* when it should be used
* what kind of result it returns

### General guidelines

Descriptions should:

* start with a verb
* be concise
* avoid implementation details where possible
* focus on business purpose rather than technical implementation

Good examples:

```text
Search Object Classes matching given criteria.
Get a single Object Class's details.
Create a new Object Record.
Assign a Task to one or more users.
```

Poor examples:

```text
Tool for searching.
API endpoint wrapper.
Calls backend service.
```

### Complex tools

If correct usage of a tool requires additional context or instructions, the description should provide sufficient guidance for the AI agent.

Examples may include:

* prerequisites before calling the tool
* required data sources for specific parameters
* follow-up actions after execution
* interpretation of response values

Tool descriptions should contain enough information for an AI agent to use the tool correctly without relying on external documentation.

***

## Tool call structure

Autologyx MCP tools are called using the standard MCP `tools/call` method.

The request should contain:

* `method` — always `tools/call`
* `params.name` — the tool name
* `params.arguments` — tool arguments

Example:

```json
{
  "method": "tools/call",
  "params": {
    "name": "search_object_classes",
    "arguments": {
      "_alx_claimed_model": ""
    }
  }
}
```

### Arguments object

Tool arguments should follow a predictable structure.

The `arguments` object may contain:

| Attribute | Purpose |
|----------|---------|
| `kwargs` | Path or URL-style parameters identifying a specific resource or context |
| `body` | Request payload sent to the underlying API operation |
| `_alx_claimed_model` | Audit attribute identifying the AI model executing the tool call |

Not every tool requires both `kwargs` and `body`.

Read-only detail tools usually require `kwargs`.

Example:

```json
{
  "method": "tools/call",
  "params": {
    "name": "get_object_class",
    "arguments": {
      "kwargs": {
        "pk": 3
      },
      "_alx_claimed_model": ""
    }
  }
}
```

Mutation tools usually require `body`.

Example:

```json
{
  "method": "tools/call",
  "params": {
    "name": "assign_task_to_users",
    "arguments": {
      "body": {
        "task": 1,
        "users": [
          1,
          2
        ]
      },
      "_alx_claimed_model": ""
    }
  }
}
```

***

## Input attribute descriptions

Every input attribute should include a meaningful description.

Attribute descriptions help the AI agent understand:

* the purpose of the field
* expected values
* business meaning
* validation expectations

Good examples:

```text
Primary key of the Object Class.
Identifier of the Task.
List of user IDs assigned to the Task.
Request payload used to update the Object Record.
```

Poor examples:

```text
Name.
Value.
Field.
Data.
```

Descriptions should explain the meaning of the attribute rather than simply repeating its name.

### Common argument descriptions

The following descriptions should be used consistently where applicable.

| Attribute | Description |
|----------|-------------|
| `kwargs` | Path or context parameters required to execute the tool. |
| `body` | Request payload passed to the underlying API operation. |
| `pk` | Primary key of the target resource. |
| `_alx_claimed_model` | Exact identifier of the AI model executing the tool call, used for audit and compliance. |

***

## Audit attributes

Some tools require additional audit information.

Autologyx MCP tools may require the `_alx_claimed_model` argument.

This attribute is used for:

* auditability
* traceability
* compliance
* operational diagnostics

The `_alx_claimed_model` attribute should be included in the tool schema when required.

Example:

```json
{
  "_alx_claimed_model": ""
}
```

The value should identify the AI model executing the tool call. If the model identifier is not available, the caller should follow the behaviour described in the tool schema.

***

## Error messages

MCP tools should return errors using a consistent structure.

### Error indicator

Tool responses should use the `isError` attribute to indicate whether execution failed.

Example:

```json
{
  "isError": true,
  "content": [
    {
      "type": "text",
      "text": "Error executing tool: ..."
    }
  ]
}
```

When execution succeeds:

```json
{
  "isError": false
}
```

or the attribute may be omitted depending on the MCP implementation.

### Error content

Error details should be returned within the `content` collection.

The `content` collection should contain one or more objects with:

* `type`
* `text`

Example:

```json
{
  "content": [
    {
      "type": "text",
      "text": "Error executing tool: {'detail': [ErrorDetail(string='Stage stage_1 is completed. Owner cannot be changed.', code='invalid')]}"
    }
  ],
  "isError": true
}
```

### REST API errors

When an MCP tool wraps a REST API endpoint, validation and business errors should be propagated from the underlying API whenever possible.

In such cases, the REST API error is returned inside the MCP `content[].text` field.

This helps maintain consistency between REST and MCP integrations and ensures that the same validation rules are exposed through both interfaces.

***

## Tool grouping

Autologyx does not currently define MCP tool grouping standards.

The MCP ecosystem currently provides limited and inconsistent support for tool grouping across clients and AI models.

***

## Relationship with REST APIs

Where MCP tools are generated from Django REST Framework endpoints, MCP definitions should remain consistent with the underlying API.

This includes:

* naming conventions
* validation behaviour
* schema definitions
* permission rules
* error messages

Whenever possible, MCP metadata should be derived from the same serializers and endpoint definitions used by the REST API to reduce duplication and prevent inconsistencies.

---

---
url: /api/catalyst/resources/mcp/mcp-tools.md
---
# MCP Tools

This document describes API for MCP Tools.

## GET  /api/mcp/tools/

Returns list of available MCP Tools.

### Permissions

Requires `authentication`.

### Request example

#### Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

#### Response `results` array

| Key               | Type     | Notes |
|-------------------|----------|-------|
| name              | string   |       |
| title             | string   |       |
| vendor            | string   |       |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 20,
  "next": null,
  "previous": null,
  "results": [
    {
      "name": "search_object_classes",
      "title": "Search Object Classes",
      "vendor": "Autologyx"
    }
  ]
}
```

### Sorting

Not supported

### Filtering

| Parameter   | Predicates        | Example                                     |
|-------------|-------------------|---------------------------------------------|
| vendor      | =, in             | {build}/api/mcp/tools/?vendor\_\_in=Autologyx |

### Errors

| Error                | Response code     | Message                                                    |
|----------------------|-------------------|------------------------------------------------------------|
| Not authenticated    | 401 Unauthorized  | "detail": "Authentication credentials were not provided."  |

---

---
url: /knowledgebase/applied-ai/mcp-services/mcp-work/mcp-work-configuration.md
---
# MCP Work configuration

Use these guides to configure MCP Work, including MCP connectors, permissions, Object Class access, and AI and MCP integrations.

## Configuration guides

* [Manage MCP connectors](/knowledgebase/applied-ai/mcp-services/mcp-work/mcp-work-configuration/manage-mcp-connectors/)
* [Associate MCP connectors with Object Classes](/knowledgebase/applied-ai/mcp-services/mcp-work/mcp-work-configuration/associate-mcp-connectors-with-object-classes/)
* [Configure MCP connector permissions](/knowledgebase/applied-ai/mcp-services/mcp-work/mcp-work-configuration/configure-mcp-connector-permissions/)
* [Configure AI and MCP integrations](/knowledgebase/applied-ai/mcp-services/mcp-work/mcp-work-configuration/configure-ai-and-mcp-integrations/)

---

---
url: /knowledgebase/system-configuration/merge-fields.md
---
# Merge Fields

\*\*Browse the sections below: \*\*

* [Document Assembly Using the .docx Merge Field](/knowledgebase/system-configuration/merge-fields/document-assembly-using-the-.docx-merge-field/)
* [Conditional Logic](/knowledgebase/system-configuration/merge-fields/conditional-logic/)
* [Configuration And Use Of The Image Merge Field](/knowledgebase/system-configuration/merge-fields/configuration-and-use-of-the-image-merge-field/)
* [Controlling Whitespace In Jinja And Why It Matters](/knowledgebase/system-configuration/merge-fields/controlling-whitespace-in-jinja-and-why-it-matters/)
* [Field Types And Formatting](/knowledgebase/system-configuration/merge-fields/field-types-and-formatting/)
* [Record Properties](/knowledgebase/system-configuration/merge-fields/record-properties/)
* [Syntax For Merge Fields](/knowledgebase/system-configuration/merge-fields/syntax-for-merge-fields/)
* [Understanding Namespace In Jinja2 For Document Templates](/knowledgebase/system-configuration/merge-fields/understanding-namespace-in-jinja2-for-document-templates/)
* [Users And Groups](/knowledgebase/system-configuration/merge-fields/users-and-groups/)

---

---
url: /api/merge-fields/resources/custom-filters.md
---
# Merge fields Custom Filters

Custom filters are **specialized functions** that allow advanced manipulation of merge field values. They extend the basic merge field functionality by providing domain-specific operations for date/time manipulation, image processing, and content rendering.

Custom filters are organized into several functional areas:

## 📅 Date and Time Manipulation

The `shift_datetime` filter provides powerful date and time manipulation capabilities:

#### Syntax

```jinja
{{ value|shift_datetime(years=None, months=None, days=None, hours=None, minutes=None, seconds=None, business_days=False) }}
```

#### ⚙️ Parameters

* **`value`** - Reference date/time from which new date/time is calculated
* **`years`** - Number of years to shift (integer, positive/negative)
* **`months`** - Number of months to shift (integer, positive/negative)
* **`days`** - Number of days to shift (integer, positive/negative)
* **`hours`** - Number of hours to shift (integer, positive/negative)
* **`minutes`** - Number of minutes to shift (integer, positive/negative)
* **`seconds`** - Number of seconds to shift (integer, positive/negative)
* **`business_days`** - When `True` with `days`, excludes weekends (boolean)

#### 📥 Input Value Formats

The `value` parameter accepts:

* **ISO date/time string**: `"2023-12-25T14:30:00+02:00"`
* **ISO date string**: `"2023-12-25"` (time defaults to `00:00:00`)
* **Date/time merge field**: `{{ record.created_at }}`
* **Date merge field**: `{{ record.created_at.date() }}`
* **New line to HTML&#x20;**: `{{ record.string_field_with_new_line }}`
* **Converts JSON string into the python object**: `{{ record.string_field_with_json }}`

#### 💡 Examples

```jinja
{{ current_date|shift_datetime(days=30) }}
{{ record.start_date|shift_datetime(years=-2, months=-6) }}
{{ current_date|shift_datetime(days=5, business_days=True) }}
{{ "2023-01-15T09:00:00"|shift_datetime(months=3, days=10, hours=2) }}
{{ record.string_field_with_new_line|nl2br }}
{{ record.string_field_with_json|fromjson }}
```

#### 🌍 Availability

* Document Templates
* Send Message Actor
* Variable Actor
* API Call Actor

::: tip Output Format
📝 The `shift_datetime` filter always returns date in ISO format as local time (without timezone): `"YYYY-MM-DD hh:mm:ss"`
:::

## 🖼️ Image Processing

Custom filters for handling images in document fields provide embedded image functionality with dimension control.

#### 🔗 Basic Image Embedding

```jinja
{{ record.field_<alias>[index].embedded }}
```

* **`&lt;alias&gt;`** - Document field's alias
* **`[index]`** - Mandatory array index (0-99, as fields can contain up to 100 attachments)
* **`embedded`** - Special property for image embedding

#### 🎨 Supported Image Formats

* **PNG**
* **GIF**
* **JPEG/JPG**

#### 📏 Dimension Control Filters

Control image dimensions using custom filters:

```jinja
{{ record.field_image[0].embedded|img_width(150)|img_height(100) }}
```

* **`img_width(size)`** - Set image width in millimeters
* **`img_height(size)`** - Set image height in millimeters
* **`size`** - Dimension in millimeters (integer)

#### 🎯 Examples

```jinja
{{ record.field_photos[0].embedded }}
{{ record.field_logo[0].embedded|img_width(200) }}
{{ record.field_banner[1].embedded|img_width(300)|img_height(150) }}
{% for i in range(10) %} {{ record.field_gallery[i].embedded|img_width(100) }} {% endfor %}
```

#### 📐 Ratio Preservation Rules

* **No dimensions specified**: Original ratio preserved
* **One dimension specified**: Ratio preserved, other dimension calculated
* **Both dimensions specified**: Ratio **not** preserved, exact dimensions applied

#### ⚠️ Error Handling

* **Non-image files**: Return empty string (silently ignored)
* **Unsupported formats**: Return empty string (silently ignored)
* **Missing index**: Return empty string
* **Invalid parameters**: Standard Jinja filter error handling

## 📄 DOCX embedding

Custom filters for handling .docx files in document fields provide embedded document functionality with preserved formatting.

#### 🔗 Basic DOCX Embedding

```jinja
{{ record.field_<alias>[index].embedded }}
```

* **`&lt;alias&gt;`** - Document field's alias
* **`[index]`** - Mandatory array index (0-99, as fields can contain up to 100 attachments)
* **`embedded`** - Special property for document embedding

#### Supported Formats

* **DOCX** (Microsoft Word OpenXML format)

⚠️ Other file formats are ignored and return an empty string.

#### Examples

```jinja
{{ record.field_contract[0].embedded }}
{{p record.field_appendix[1].embedded.inline }}
{% for i in range(5) %} {{ record.field_documents[i].embedded }} {% endfor %}
```

#### 📝 Formatting Preservation

* Inserted .docx documents retain their original formatting (styles, headings, fonts).
* No manual overrides or filter-based formatting changes are available.
* Merging is powered by the docxtpl library.

#### Merge Syntax Variants

Two syntaxes are supported, with slightly different behaviors:

* Standard merge syntax (consistent with image embedding)

```jinja
{{ record.field_<alias>[index].embedded }}
```

* Paragraph-replacement syntax (docxtpl standard)

```jinja
{{p record.field_<alias>[index].embedded.inline }}
```

Replaces the entire paragraph with the merged document content.

#### 📌 Behavioral difference

Template:

```text
This is example line in document.
Second line, where document should be merged {{ record.field_doc[0].embedded }}.
```

* Result using

```jinja
{{ record.field_<alias>[index].embedded }}
```

```text
This is example line in document.
Second line, where document should be merged
[Content of merged document].
```

* Result using

```jinja
{{p record.field_doc[0].embedded.inline }}
```

```text
This is example line in document.
[Content of merged document]
```

#### ⚠️ Error Handling

* **Non-DOCX files**: Return empty string (silently ignored)
* **Unsupported formats**: Return empty string (silently ignored)
* **Missing index**: Return empty string
* **Invalid parameters**: Standard Jinja filter error handling

## 📝 Merge Field Rendering

The `render_merge_fields` filter enables **dynamic merge field processing** within string content, allowing nested merge fields to be resolved and rendered at runtime.

#### 🎯 Purpose

This filter processes merge fields that are stored as **content within other fields**, enabling dynamic template rendering where merge field references are embedded in text values.

#### 📝 Syntax

```jinja
{{ record.field_name|render_merge_fields }}
```

#### 🌍 Availability

The filter is supported in all features that allow merge fields:

* **API Call Actor**
* **Send Message Actor**
* **All AI Actors**
* **Local Variable Actor**
* **Document Templates**

#### ⚙️ How It Works

When a merge field with `render_merge_fields` filter is processed:

1. **Retrieves** the content of the field
2. **Identifies** any merge fields within that content
3. **Replaces** nested merge fields with their actual values
4. **Returns** the fully rendered string

#### 💡 Complete Example

**Database field content** (`record.field_prompt`):

```text
Generate a professional legal contract clause based on the following terms and conditions fields:
- Payment Terms {{record.field_payment_terms}}
- Acceptance Clause {{record.field_acceptance_clause}}
- Duration {{record.field_duration}}
- Effective Date {{record.field_effective_date}} Ensure the clause is structured formally, aligns with standard legal practices, and accounts for potential risk mitigation. Use clear, precise legal language.

```

**Template usage**:

```jinja
{{record.field_prompt|render_merge_fields}}
```

**Rendered output**:

```text
Generate a professional legal contract clause based on the following terms and conditions fields:
- Payment Terms Net 30 Days: (Payment is due within 30 days from the invoice date.)
- Acceptance Clause Acceptance pending
- Duration 01/05/2027
- Effective Date 15/04/2025 Ensure the clause is structured formally, aligns with standard legal practices, and accounts for potential risk mitigation. Use clear, precise legal language.
```

#### 🔗 Supported Merge Field Types

The filter supports all standard merge field types:

* **Basic fields**: `{{record.field_name}}`
* **Relational fields**: `{{record.related_records_1.0.field_name}}`
* **System fields**: `{{admin_first_name}}`
* **Constants**: `{{constants.API_URL}}`

#### ⚠️ Processing Rules

* **Single-level processing**: Non-recursive to prevent infinite loops
* **Second-level limitation**: Using `|render_merge_fields` inside nested content returns the raw string
* **Field type restriction**: Only works with string field types
* **Non-string fields**: Filter is ignored, returns original field value

#### 🚫 Error Handling

* **Invalid nested merge fields**: Return empty string (standard handling)
* **Non-supported filters**: Standard merge field error returned
* **Non-string field types**: Filter ignored, original value returned

#### 🎯 Use Cases

```jinja
{{ record.email_template|render_merge_fields }}
{{ record.ai_prompt_template|render_merge_fields }}
{{ record.api_request_template|render_merge_fields }}
{{ record.contract_template|render_merge_fields }}
```

::: warning Recursion Prevention
🔄 The filter processes only **one level** of merge fields to prevent infinite loops. Nested `render_merge_fields` calls will return the raw string value.
:::

::: tip Dynamic Templates
✨ This filter is particularly powerful for creating **dynamic templates** where the template structure itself is stored in database fields and can be modified by users.
:::

## 🔧 Usage Contexts

Custom filters are available in:

* **Document Templates** (Templates panel)
* **Sequence Actors**: Send Message, Variable, API Call
* **Doc Auto Actor** (for image embedding)
* **Standard document generation workflows**

::: warning Index Requirement
⚠️ Image merge fields **require** the `[index]` parameter. Omitting it will return an empty string.
:::

::: tip Template Integration
🎨 Image merge fields integrate seamlessly with the Templates panel for standard document generation workflows.
:::

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.8/microsoft-authentication-object.md
---

# Microsoft authentication object

Turn your data into insights and action with Catalyst's Microsoft integration. Access to your Microsoft account data is streamlined through the Authentication client credentials flow.

To harness the data from your Microsoft account, all it takes is the creation of an Authentication object. This object becomes a key part of any carefully crafted sequence utilising API calls.

## Configuration

**Set up the authentication object** by selecting "Microsoft oAuth 2.0 (Client Credentials flow)" from the list of providers, then configure the fields required for authentication.

**Required fields**

* **Tenant**: the directory tenant from which you seek permission.
* **Client ID**: the application's Client ID.
* **Client Secret**: the client secret generated for your app in the app registration portal.
* **Scope**: the identifier (app ID URI) of the desired resource, suffixed with ".default." For example, if your resource is the Microsoft Graph, the scope would be <https://graph.microsoft.com/.default>.

![Microsoft CC 1.gif](/knowledgebase/images/img_16323323772829_1776895657.png)

## Testing and usage

**Test the Authentication object** to ensure the input data is accurate before incorporating it into your sequences featuring Microsoft APIs.

From automating document workflows to enhancing collaboration, this integration opens up a world where data flows effortlessly, unencumbered by silos or barriers. Discover the power of Microsoft integration and take your digital environment to the next level!

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.11/microsoft-oauth-in-outbound-mail-setup.md
---

# Microsoft oAuth in outbound mail setup

## Overview

Email authentication is evolving, and we're making sure you are always prepared for the latest advancements.

To ensure continued support for secure email authentication, we are introducing **Microsoft Office 365 Exchange (Graph) with OAuth 2.0** as a new option in **Outbound Mail Setup**.

Unlike traditional SMTP-based authentication, this method leverages the Microsoft Graph API, which is more secure, modern, and recommended by Microsoft. Unlike SMTP, which relies on direct email submission via a mail server, Microsoft Graph enables better access control, improved security policies, and enhanced monitoring capabilities.

This update comes in response to Microsoft's deprecation of Basic Authentication, ensuring that users can transition to a more secure and future-proof authentication mechanism.

## New outbound mail option

The new and recommended option under **"What kind of mail service are you using?"** is **Microsoft Office 365 Exchange (Graph) with OAuth 2.0**.

When selecting **Microsoft Office 365 Exchange (Graph) with OAuth 2.0**, users must choose an existing **Microsoft Client Credentials Authentication Object** in the system. Additionally, the corresponding Azure environment must be properly configured to allow email sending.

**Detailed setup instructions:** [Configuring Outbound mail setup with Microsoft client credentials](../../../administration/communication/configuring-outbound-mail-setup-with-microsoft-client-credentials/index.md)

## Standard configuration fields

Regardless of the selected mail service, users will still configure the following standard fields:

* **Host and Port** – Defines the mail server connection details.
* **TLS** – Enables encryption for secure email transmission.
* **Username** – Used for identification in email headers.
* **From email address** – The sender’s email address.
* **Backend failure alerts email address** – An email address for receiving notifications about delivery failures.

## Testing and validation

Before saving the configuration, users can test the setup to ensure proper authentication and email functionality.

![MSGraph\_article.gif](/knowledgebase/images/img_4703042456991_1776895614.png)

## Outcome

By transitioning to **Microsoft Graph**, clients gain access to a more secure and resilient email solution, fully aligned with Microsoft's latest authentication standards. This update ensures a smooth migration away from Basic Authentication while strengthening security and compliance measures for outbound email services.

---

---
url: >-
  /api/monitoring-and-infrastructure/catalyst/authentication/microsoft-sso-obo.md
---
# Microsoft SSO OAuth2 On Behalf On

This technical design describes implementation and API for integration external systems like Office Add-ins with this application.
[Microsoft SSO OAuth2 On Behalf On](https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow) method will be used.

# API

::: danger Important
For security reasons, we should ensure that not supported generic endpoints cannot be accessed – they are not working.
:::

## POST /single-sign-on/login/ms-obo/

### Permissions

Requires `access_token` in request header.

### Request

* Headers

```
Content-Type: application/json
Authorization: access_token
```

| Key           | Type     | Notes                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
|---------------|----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| access\_token  | string   | Generally, this token represents any token "A" used in [Microsoft SSO OAuth2 On Behalf On](https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow) authorization flow.  In this feature, the token obtained by [Office auth token](https://learn.microsoft.com/en-us/javascript/api/office/office.auth?view=common-js-preview#office-office-auth-getaccesstoken-member\(1\)) will be handled. `access_token` obtained in Office Add-ins is sended to the ALX Catalyst. ALX Catalyst will use it and check in Azure to authorize access to self-resources.  |

### Response

| Key           | Type     | Notes                          |
|---------------|----------|--------------------------------|
| access\_token  | string   | JWT `access_token`.            |
| refresh\_token | string   | JWT `refresh_token`.            |

* Successful status `200 OK`
* Response body schema:

```json
{
    "access_token": "token",
    "refresh_token": "token",
}
```

### Errors

| Error                                                                     | Response code    | Message                                                          |
|---------------------------------------------------------------------------|------------------|------------------------------------------------------------------|
| MS identity token is not provided in the Authorization header             | 401 Unauthorized | {'detail': 'Authentication credentials were not provided.'}      |
| MS identity token is invalid (the Microsoft Identity platform rejects it) | 403 Forbidden    | {'detail': 'You do not have permission to perform this action.'} |
| No registered or active user in ALX Catalyst                              | 403 Forbidden    | {'detail': 'You do not have permission to perform this action.'} |

---

---
url: /api/monitoring-and-infrastructure.md
---

# 🔒 Monitoring and Infrastructure (restricted)

This section contains API documentation for operational, infrastructure, and restricted-use endpoints that are not part of the main general-purpose Catalyst integration surface.

These pages are separated from the main API documentation to make the supported external API surface clearer, while still documenting endpoints and behaviors that are relevant for internal platform support, controlled operational use, and restricted technical workflows.

## 📚 What this section covers

The pages in this area typically relate to one or more of the following:

* platform monitoring and operational visibility
* restricted or internal-use API resources
* infrastructure-oriented endpoints
* system-level or service-level technical behaviors
* endpoints that are not intended as part of the normal public integration surface

## 🧩 Why this section is separate

The main API documentation is intended to help developers, integrators, and technical users work with the supported Catalyst APIs and related technical features.

This restricted section exists so that:

* general integration documentation remains focused and easier to navigate
* operational or internal-facing endpoints are clearly separated
* readers can distinguish between broadly supported API surfaces and more restricted technical resources
* documentation for internal or controlled-use endpoints still has a structured home

::: warning
The pages in this section should be treated as restricted technical documentation.

They may describe internal, operational, non-general-purpose, or otherwise controlled endpoints and behaviors that are not intended to be used in the same way as the main supported API surface.
:::

## 🔗 Sections in this area

### Catalyst

* [Integrations](/api/monitoring-and-infrastructure/catalyst/integrations)
* [Sequences](/api/monitoring-and-infrastructure/catalyst/sequences)
* [Microsoft SSO OBO](/api/monitoring-and-infrastructure/catalyst/authentication/microsoft-sso-obo)

### WebSockets

* [Object Records](/api/websockets/resources/object-records)

## 🧭 Notes

::: info
Healthcheck and version endpoints remain documented in their main API sections because they are useful as service-level reference points and do not need to be moved into the restricted area.
:::

::: tip
Use the main API sections for supported service documentation, and use this section when you specifically need infrastructure, operational, or restricted technical reference material.
:::

---

---
url: >-
  /knowledgebase/system-configuration/working-with-document-templates/ms-word-add-in---configuration.md
---

# MS Word add-in - configuration

Document templates in Catalyst are created from Word documents.

In order to help you create complex documents and easily manage merging data from records in multi-leveled relationships, we have developed an Add-In which can be used in the Microsoft Word application. This has been specially designed to help eliminate manual entry and therefore errors too.

## Prerequisites for Word Add-In configuration

**There are 3 things you will need to set up the Word Add-In configuration:**

1. Access to the Autologyx Domain you wish to configure with sufficient permissions to configure Single sign-on settings.

   This means you will have a user account of the Super Admin type or a Standard account type with a Role which has Single Sign-On create and edit permissions enabled.

![Screenshot 2024-02-08 at 12.48.11.png](../../../images2/zendesk_11721025596701_001_450634becd45.png)

2. Access to the Microsoft Azure Domain Admin, with permissions to create (and edit) new Enterprise Applications. This is usually a specialist role within your IT team.

3. Access to your Microsoft 365 admin center, with permissions to allow you to upload custom add-ins. Again, this may need to be done by your IT team.

The upload relates to a manifest file (xml) which contains the details for where the source code of the Add-in is downloaded from, and the ID of the Enterprise Application Registration on the domain, as shown below.

![Screenshot 2024-02-08 at 19.47.29.png](../../../images2/zendesk_11721025596701_002_aaa74f7fd162.png)

## Generate the manifest file with the Enterprise Application Registration ID

**The following steps show what must be done to get the Enterprise Application Registration ID embedded into the manifest file.**

1. In your Autologyx system, navigate to Administration/ Single sign-on settings and click the +Create button. In the Settings section, slide the radio button to "Enable Catalyst Word add-in support".

![Screenshot 2024-02-08 at 16.03.43.png](../../../images2/zendesk_11721025596701_003_7dbe088910df.png)

2. In Azure, go through the steps to create the registration entry. [CLICK HERE](/knowledgebase/administration/communication/how-do-i-configure-single-sign-on-for-users/) for an article which explains how to configure User Single Sign-on authentication. The steps to get the Application (client) ID, Directory (tenant) ID and Client secret are included.

3. Enter these details and **SAVE**. You will be taken to the Single Sign-on settings list.

4. Edit your new entry and the **Redirect / Callback URI** and **Logout URL** will have auto-populated. You will also see that the manifest file has been generated as a link so you can download it.

![Screenshot 2024-02-08 at 16.12.47.png](../../../images2/zendesk_11721025596701_004_410f1f947c2c.png)

5. Click the link provided to download the manifest file. The **Application (client) ID** will have been embedded in this file. This is important because it tells the manifest file which registration object to connect to on the Azure domain.

## Complete the required permissions in the Azure Registration

**Follow these steps to complete the required permissions in the Azure Registration:**

1. Go to the Word Add-in Registration in Azure/ Properties, click "**Application registration**".

![Screenshot 2024-02-08 at 17.03.36.png](../../../images2/zendesk_11721025596701_005_989dfaace351.png)

2. In the left-hand menu, click "**Token configuration**". You need to add claims for the Token type IDs for email. Click "Add optional claim", which will open a panel on the right-hand side.

3. Under **Token type**, click **ID**. Select the required claims and click **Add**. Azure system administrators will be familiar with this process.

![](../../../images2/zendesk_11721025596701_006_a3db5ffe5634.png)

4. You will be prompted to add API permissions. Click this option in the left-hand navigation menu.

   **The three API endpoints which require delegated permissions are:**

   * email
   * User.Read
   * User.Read.All

   These are also required when setting up User Single Sign-on authentication. Again, a detailed explanation of the configuration of these permissions is given [HERE.](/knowledgebase/administration/communication/how-do-i-configure-single-sign-on-for-users/)

![Screenshot 2024-02-08 at 17.20.35.png](../../../images2/zendesk_11721025596701_007_b07307c62719.png)

Because these permissions overlap, you could have one Registration entry in your Azure Directory for both User Single Sign-on and the Word Add-in, if preferred. However, separate Registrations are likely to be easier to manage and provide more flexibility.

5. In the left-hand navigation menu, click "**Expose an API**". At the top of this page is a field called "Application ID URI". Here you must enter the URL which Catalyst exposes to Azure together with the Application (client) ID. The format of the entry for this is:

**api://office-addin.autologyx.com/application(client)id**

Also, this URL can be found in the **manifest.xml** file downloaded earlier from the Catalyst application when creating an Authentication Object:

![](../../../images2/zendesk_11721025596701_008_c032c75069bb.png)

6. Further down this page you have a link to add a scope. Click this and a panel will open to the right. Give the scope the name **openid** and ensure the **Admins only** option is enabled and then enable the scope itself.

![](../../../images2/zendesk_11721025596701_009_ff304827f674.png)

7. Finally, on this same page, you must grant the client application. This is one of those Microsoft secret source things which isn't particularly obvious.

   This grants any Word application which is "talking" to the registration entry permission to be a client to the entry.

   Under "**Authorized client applications**", click "**Add a client application**". In the panel which opens on the right you must put in a uuid which pre-authorises Microsoft endpoints. This can be found in Microsoft's documentation as shown in the second of the two screenshots immediately below:

   **For the Microsoft Office application the Client ID is:** **ea5a67f6-b6f3-4338-b240-c655ddc3cc8e**

![](../../../images2/zendesk_11721025596701_010_f04d4f9272d5.png)

A link to Microsoft's own documentation is provided here: <https://learn.microsoft.com/en-us/office/dev/add-ins/develop/register-sso-add-in-aad-v2>

![Screenshot 2024-02-21 at 19.01.23.png](../../../images2/zendesk_11721025596701_011_d56d9ffc988a.png)

## Add the manifest file to your Microsoft Admin Center

**Follow these steps to add the manifest file to your Microsoft Admin Center:**

1. Sign in to your **Microsoft Admin Center**. In the left-hand menu, click "Show all".

![Screenshot 2024-02-08 at 19.15.54.png](../../../images2/zendesk_11721025596701_012_08e9b34ee891.png)

2. From there, click Settings/ Integrated apps. There is an option for "**Upload custom apps**".

![Screenshot 2024-02-08 at 19.18.02.png](../../../images2/zendesk_11721025596701_013_b76d2200238a.png)

3. In "**App type**", choose "**Office Add-in**". In "**Choose how to upload app**", select "**Upload manifest file(.xml) from device**" and upload the file you downloaded from the link in your Catalyst application.

![Screenshot 2024-02-08 at 19.25.45.png](../../../images2/zendesk_11721025596701_014_a3d44b6efd93.png)

4. Decide which users would have the Word Add-in available:

![](../../../images2/zendesk_11721025596701_015_1970a7343c31.png)

5. Accept permissions:

![](../../../images2/zendesk_11721025596701_016_4b50ccbfbc5e.png)

## Insert the Add-in in Microsoft Word

1. Open Word and create a new document. In the main menu, select "Insert". Go to My Add-ins/ Admin Managed and you should see the Catalyst Word Add in.

![Screenshot 2024-02-08 at 21.33.30.png](../../../images2/zendesk_11721025596701_017_cea2f60520e9.png)

![Screenshot 2024-02-08 at 19.33.07.png](../../../images2/zendesk_11721025596701_018_b73ea3cc15d7.png)

![Screenshot 2024-02-08 at 19.33.39.png](../../../images2/zendesk_11721025596701_019_0e3ba78de690.png)

2. Select this and click Add. The Add-in will then be visible at the far right of the Home menu.

![Screenshot 2024-02-08 at 19.37.13.png](../../../images2/zendesk_11721025596701_020_6b4d842cb050.png)

3. In the **Catalyst domain** enter the domain only, without the https prefix, for example: catalyst-staging.autologyx.com

4. In order for users to be able to select Object record fields, they should have **at least** the **View** permission enabled:

![](../../../images2/zendesk_11721025596701_021_e4a68021a35a.png)

A separate article will be made available to explain how to use the Word Add-in.

## Useful info

1. Only Word documents with a .docx file extension can be used as a document template.

2. Up to 25 SSO configurations can be created in your Catalyst application.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.11/multipart-data-support-in-api-call-actor.md
---

# Multipart data support in API Call actor

Our new Multipart Data support for the API Call actor arrives just in time to solve one of your biggest integration headaches. This powerful addition lets you send diverse content types - text parameters and file attachments in a single, well-structured request to services like DocuSign, without writing a single line of custom code.

**Multipart data** allows you to send different types of content in a single request. This is essential for APIs that require both structured data and file uploads, such as document signing platforms, media processing services, or form submissions.

## Configuration

When configuring an API Call actor with the POST method, you’ll now see an additional option: **Multipart Data**. Selecting this opens a dedicated **Multipart Configuration** section, where you can define multiple parts of the request.

![Multipart1\_main.gif](../../../images2/zendesk_4720293751711_001_b7540aa5871e.gif)

### Key configuration details

* Each request part can be either **Text** or **File**.
* The default setup includes two parts, but you can add or remove parts as needed.
* **Text parts** allow you to specify metadata (e.g., “documentId” for DocuSign).
* **File parts** let you attach documents from the connected Document Picker.
* Each part is automatically structured with **Content-Disposition** and optional **Content-Type** fields.

## Request parts

Each part in a multipart request follows a structured format:

### Text parts

* **Content-Disposition** (required): This defines how the data should be treated in the request. It’s pre-filled with `form-data; name=""`, where you must specify the parameter name required by the target API. Ensure that 'name' is specified in Content-Disposition. You can also add custom attributes required by the target service, such as ‘documentId’ for DocuSign compatibility.
* **Content-Type** (optional): Specifies the type of content being sent. This is empty by default but can be set if needed.
* **Body** (required): The actual text content being sent. This is where you define values like metadata, IDs, or descriptions.

![Multipart2\_main.gif](../../../images2/zendesk_4720293751711_002_6311c15223bf.gif)

### File parts

* **Content-Disposition** (required): Similar to text parts, but includes `filename=""` to indicate a file is being sent.
* **File** (required): You must select a file from the connected Document Picker. Only one file can be sent per field, and if multiple files exist, the most recently uploaded one is used.

![Multipart3\_main.gif](../../../images2/zendesk_4720293751711_003_b397728967e1.gif)

## Managing multipart requests

Adding new parts is simple - just click the **"+"** button. You can freely rearrange, remove, and modify parts without losing configuration. The system ensures that only valid multipart requests can be saved, and you can test the request before finalising the setup.

![Multipart4\_main.gif](../../../images2/zendesk_4720293751711_004_14c3415c200c.gif)

**Part order and file selection**

The API Call actor maintains the correct order of parts in the request, ensuring seamless integration with external providers. If multiple files are available for a document field, the most recently uploaded file is used automatically.

This new feature expands API Call actor capabilities, making it easier to work with services like DocuSign, media uploads, and other APIs requiring multipart data. By providing meticulous control over request composition whilst ensuring provider compliance, multipart data support represents a significant advancement in Catalyst's integration capabilities.

---

---
url: /knowledgebase/finding-your-way-around/my-account.md
---
# My Account

Browse the sections below in **My account**:

* [What'S In My Account](/knowledgebase/finding-your-way-around/my-account/what's-in-my-account/)
* [What Can I Edit In My Account And What Effect Will This Have](/knowledgebase/finding-your-way-around/my-account/what-can-i-edit-in-my-account-and-what-effect-will-this-have/)

---

---
url: /knowledgebase/system-configuration/sequences/navigation-and-menus.md
---

# Navigation and Menus

When you go into the Edit design option of the Sequence Actions menu for the first time, you will be presented with a blank workflow. Before you start building your Sequence, it is useful to familiarise yourself with the navigation and menus.

## Sequence-specific menu

On the left-hand side, you'll find the **Sequence-specific menu**. This consists of the following sections:

### Actors

There are 4 Actors:

|  |  |
| --- | --- |
| mceclip0.png | **API call** - this actor allows us to integrate with third party systems. It is used to send and receive data. In ALX we also use API calls to copy data from one Object class to another. In order for ALX to send data to a third party system it must have the required endpoints and authentication model to allow the autologyx system to consume them. This will allow data to be passed between the systems. |

|  |  |
| --- | --- |
| mceclip1.png | **Local variable** -variables are used to store information to be referenced and utilised in the ALX platform. This can be for:   - Storing static values like a URL that can be populated into a target field - Merging data into messages and document templates - Extracting data from an API call with a JSON payload return |

|  |  |
| --- | --- |
| mceclip2.png | **Send message** - here you can configure a bespoke email to be sent to one or more recipients. These are useful throughout the workflow in order to keep everyone updated. |

|  |  |
| --- | --- |
| mceclip3.png | **Update record** - used to update Object record fields to certain values. The value can be extracted from a variable on the Sequence. |

Actors can be clicked on and dragged onto the workflow area of the Sequence when you need them. When you right-click on the Actor, you will be able to configure it as required.

### Sequences

If there are any Sequences which have been configured for the same Object class and which have the starting condition **When Sequence activated**, their Names will appear here. Again, you simply need to click and drag onto the workflow and connect when required.

### Task templates

These will be Task templates which have the **Task creation mechanism** set to **Automatic**. Task templates of the Task type **Update object records** will be filtered to those where your Sequence Object class was selected in the template.

### Task group templates

Again, these will be filtered only to the relevant Object class if they contain Task group templates of the **Update object records** type. Task group templates which are not limited in this way will appear in the menu of Sequences for all Object classes.

## Horizontal action menu

The **horizontal menu** across the top contains the following action buttons.

*It is worth spending a little time getting to know the menu functions before you start building your Sequence.*

### Clear

Only enabled when, in Edit mode, you have made changes to the Sequence. This will clear all the changes since the Sequence was last saved. You will be presented with a confirmation modal as shown:

|  |  |
| --- | --- |
| If you select OK the changes made since the last Save will be removed.  If you select Cancel the modal will close and changes will persist. | mceclip4.png |

### Edit

When you select **Edit design** in the Actions menu of a Sequence, you are taken to the design screen. However, the Sequence will be in Save mode. In order to make changes, you must click **Edit** to be taken into Edit mode. When a change has been made, the **Save** button will become enabled.

### Group/Ungroup

This feature allows you to click on the workflow and drag your cursor over several objects, thereby selecting them, as shown on the left. Click **Group** and you will be presented with a modal in which to Name the Group, as shown on the right:

|  |  |
| --- | --- |
| mceclip5.png | mceclip6.png  If you select OK the objects will be grouped as shown below.  If you select Cancel the grouping modal will close and no changes will be made. |

![mceclip7.png](/knowledgebase/images/img_6256838009757_1776895987.png)

Click **Ungroup** to remove the grouping. Grouping is useful from a UI perspective in that you can put your Workflow into subject-specific sections which are easier to follow. It also allows you to create a number of Tasks at one time without having to put them in a Task template.

### Undo/Redo

This feature allows you to undo or redo the changes made since the last Save.

### Zoom In/Zoom Out

To decrease/increase the size of the workflow space by making the placed objects increase/decrease in size.

### Reset Zoom

This will return the frame size back to the default.

### Delete

This button is disabled until an object is selected. Click **Delete** to remove the selected object from the Sequence workflow.

### Navigator

This tool is particularly useful when you have a very long or very wide workflow on the Sequence. Click **Navigator** and an “Outline” modal appears on the top right-hand side of the workspace. Click, drag and drop the blue outline into the position on the Sequence you wish to view/work on. Click **Zoom Actual** to return to the default layout.

### Save

This button is disabled until a change is made when the User switches to Edit mode.

|  |  |
| --- | --- |
| When a Sequence is successfully saved the Saved modal will display.  You must click OK before you can enter Edit mode again and make further changes. | mceclip8.png |

---

---
url: /knowledgebase/release-notes/release-notes-1.13/new-ai-models-in-sequencer.md
---

# New AI models in Sequencer

We’ve broadened the set of AI engines you can pick from inside Sequencer. This update introduces a new Amazon Bedrock provider and a range of fresh models. Now you have more options to match a model to a real-world legal or business task - from fast, high-volume tagging to deep, long-document reasoning, and to weave those capabilities directly into your automated processes.

![New AI 3.gif](/knowledgebase/images/img_4900549916575_1776895591.png)

## What’s new in the AWS Bedrock actor

We’ve added OpenAI as a Bedrock provider and extended our models to suit different workloads and price/performance profiles.

**You can now pick from:**

* **Claude 3.7 Sonnet:** excels at long-context reasoning and structured summaries; useful for processing long contracts and multi-document bundles where context across pages matters.
* **OpenAI: gpt-oss-20b and gpt-oss-120b:** open-source style models accessible through AWS Bedrock actor for teams that want the particular trade-offs of these OSS-weighted models.

**These Bedrock options** let teams balance throughput and nuance: use Sonnet or gpt-oss-120b where context and structure are primary concerns; pick gpt-oss-20b for lower-cost, high-volume steps.

## What’s new in the OpenAI: GPT actor

Separately, the OpenAI: GPT actor has been extended with the latest GPT family models, so you can keep using the OpenAI stack directly inside Sequencer.

**New additions include:**

* o3 family (o3, o3-deep-research, o3-pro)
* o4-mini and its deep-research variant
* GPT-4.1
* GPT-5 family (GPT-5, GPT-5 mini, GPT-5 nano)

**These options** give you a clear trade-off ladder: lighter models for high-throughput prompts and prototypes, fuller models for nuanced drafting, and deep-research variants where extra factual recall or creativity is needed.

On the Catalyst, that means you can, for example, call a compact o4-mini for quick clause normalisation across many records, then escalate a subset to GPT-4.1 or GPT-5 for polished client-facing summaries or legal drafting.

## How this affects real workflows

Think of a typical due diligence pipeline: incoming vendor contracts are bulk-ingested and automatically classified; documents with risky indemnities are flagged; priority files are summarised and routed to senior counsel; routine items are filed automatically and linked to the right matters.

With more models in the toolbox, you assign each step the most appropriate engine: cheaper, fast models for mass triage; richer, longer-context models for final review; and tie the outputs into the rest of your automation: record creation, task assignment, DocuSign or iManage actions, and audit logging.

**Orchestration is where the gain is felt:** you don’t need a single “one-size-fits-all” model. You build a sequenced flow that sends the right work to the right model and then continues the process without human handoffs unless review is required. That keeps turnaround times down and provides consistent, auditable outputs.

## Picking the right model

**Choose between capability and cost:**

* Use larger, long-context models (Claude Sonnet, GPT-4.1 / GPT-5) where nuance, accuracy and multi-document context are vital, for example, drafting precedent clauses or extracting complex obligations from contracts.
* Use the new OSS models on Bedrock if you want the specific characteristics they offer and the convenience of Bedrock integration.

We keep standard controls available in Sequencer: select the model, set parameters like temperature or max tokens, and pick the Authentication Object to use for requests. As always, you should test a new model on a small sample of real inputs to confirm output style and accuracy before scaling it into production.

**In summary:** this update widens the palette for building applied AI into legal operations: more models, more price/performance choices, and more ways to embed machine-assisted reasoning and extraction into your established processes. Pick the right engine for each job, stitch them together in Sequencer, and keep the work moving with consistent, auditable results.

---

---
url: /knowledgebase/release-notes.md
---
# New at Autologyx

## Sections

* [Release Notes 1.20](/knowledgebase/release-notes/release-notes-1.20/)
* [Release Notes 1.16](/knowledgebase/release-notes/release-notes-1.16/)
* [Release Notes 1.14](/knowledgebase/release-notes/release-notes-1.14/)
* [Release notes 1.13](/knowledgebase/release-notes/release-notes-1.13/)
* [Release notes 1.12](/knowledgebase/release-notes/release-notes-1.12/)
* [Release notes 1.11](/knowledgebase/release-notes/release-notes-1.11/)
* [Release notes 1.10](/knowledgebase/release-notes/release-notes-1.10/)
* [Release notes 1.9](/knowledgebase/release-notes/release-notes-1.9/)
* [Release notes 1.8](/knowledgebase/release-notes/release-notes-1.8/)
* [Release notes 1.6](/knowledgebase/release-notes/release-notes-1.6/)
* [Release notes 1.5](/knowledgebase/release-notes/release-notes-1.5/)
* [Release notes 1.3](/knowledgebase/release-notes/release-notes-1.3/)
* [Release notes 1.2](/knowledgebase/release-notes/release-notes-1.2/)

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.9/new-jinja-filters-for-date-and-time-manipulations.md
---

# New Jinja filters for date and time manipulations

With this latest rollout, we're introducing a collection of Jinja filters designed to redefine how you approach document generation and sequencing. These new filters provide enhanced functionality, allowing users to manipulate dates and times and perform advanced calculations effortlessly.

**Below is a summary of each filter and how it can benefit your workflow.**

## 1. Filter for testing date range

Perfect for checking if a document was created within a specific period or verifying if a task deadline falls within a project timeline.

**Syntax:** {{ value is in\_date\_range(start\_date, end\_date) }}

|  |  |  |
| --- | --- | --- |
| **Operation** | **Example** | **Output** |
| Determining if a date falls between two given dates | {{ "2024-01-11" is in\_date\_range("2024-01-10", "2024-01-18") }} | True |

## 2. Filter for calculating the number of days between dates

Ideal for determining the duration between two given dates, for example calculating the interval between contract signing and renewal dates.

**Syntax:** {{ value|delta\_days(comparison\_date, business\_days=False) }}

|  |  |  |
| --- | --- | --- |
| **Operation** | **Example** | **Output** |
| Calculating the number of days between dates | {{ "2024-04-12"|delta\_days("2024-04-13", business\_days=False) }} | 2 |
| Calculating the number of business days between dates | {{ "2024-04-12"|delta\_days("2024-04-13", business\_days=True) }} | 1 |

***Note**: when determining the number of days between dates, the calculation encompasses both the initial and final dates. It's important to note the method employed in calculating business days between dates. In instances where the start and end dates coincide, such as {{ "2024-04-12"|delta\_days("2024-04-12", business\_days=True) }}, the resulting output is 1.*

## 3. Filter for time manipulations

Convenient for adjusting appointment times for timezone differences or scheduling reminders by adding minutes or hours to specific timestamps.

**Syntax:** {{ value|shift\_time(hours=None, minutes=None, seconds=None) }}

|  |  |  |
| --- | --- | --- |
| **Operation** | **Example** | **Output** |
| Adding seconds to a time | {{ "12:30:00"|shift\_time(seconds=15) }} | 12:30:15 |
| Adding minutes to a time | {{ "12:30:00"|shift\_time(minutes=10) }} | 12:40:00 |
| Adding hours to a time | {{ "12:30:00"|shift\_time(hours=4) }} | 16:30:00 |
| Adding time to a time | {{ "12:30:00"|shift\_time(hours=4, minutes=10, seconds=15) }} | 16:40:15 |
| Subtracting seconds from a time | {{ "12:30:00"|shift\_time(seconds=-15) }} | 12:29:45 |
| Subtracting minutes from a time | {{ "12:30:00"|shift\_time(minutes=-10) }} | 12:20:00 |
| Subtracting hours from a time | {{ "12:30:00"|shift\_time(hours=-4) }} | 08:30:00 |
| Subtracting time from a time | {{ "12:30:00"|shift\_time(hours=-4, minutes=-10, seconds=-15) }} | 08:19:45 |

## 4. Filter for date/time manipulations

Useful for projecting delivery dates by adding business days to order creation timestamps or calculating deadlines by shifting dates forward or backwards based on task dependencies.

**Syntax:** {{ value|shift\_datetime(years=None, months=None, days=None, hours=None, minutes=None, seconds=None, business\_days=False) }}

|  |  |  |
| --- | --- | --- |
| **Operation** | **Example** | **Output** |
| Adding seconds to a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(seconds=15) }} | 2024-01-11 12:30:15 |
| Adding minutes to a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(minutes=10) }} | 2024-01-11 12:40:00 |
| Adding hours to a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(hours=4) }} | 2024-01-11 16:30:00 |
| Adding time to a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(hours=4, minutes=10, seconds=15) }} | 2024-01-11 16:40:15 |
| Adding days to a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(days=7) }} | 2024-01-18 12:30:00 |
| Adding business days to a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(days=7, business\_days=True) }} | 2024-01-22 12:30:00 |
| Adding months to a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(months=3) }} | 2024-04-11 12:30:00 |
| Adding years to a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(years=2) }} | 2026-01-11 12:30:00 |
| Subtracting seconds from a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(seconds=-15) }} | 2024-01-11 12:29:45 |
| Subtracting minutes from a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(minutes=-10) }} | 2024-01-11 12:20:00 |
| Subtracting hours from a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(hours=-4) }} | 2024-01-11 08:30:00 |
| Subtracting time from a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(hours=-4, minutes=-10, seconds=-15) }} | 2024-01-11 08:19:45 |
| Subtracting days from a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(days=-7) }} | 2024-01-04 12:30:00 |
| Subtracting business days from a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(days=-7, business\_days=True) }} | 2024-01-02 12:30:00 |
| Subtracting months from a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(months=-3) }} | 2023-10-11 12:30:00 |
| Subtracting years from a datetime | {{ "2024-01-11 12:30:00"|shift\_datetime(years=-2) }} | 2022-01-11 12:30:00 |
| Mixed operations | {{ "2024-01-11 12:30:00"|shift\_datetime(years=1, months=-2, days=8, hours=4, minutes=-10, seconds=-15) }} | 2024-11-19 16:19:45 |

## 5. Filter for date manipulations

Perfect for adjusting project timelines by adding or subtracting days from milestone dates or shifting event dates based on business days to accommodate working schedules.

**Syntax:** {{ value|shift\_date(years=None, months=None, days=None, business\_days=False) }}

|  |  |  |
| --- | --- | --- |
| **Operation** | **Example** | **Output** |
| Adding days to a date | {{ "2024-01-11"|shift\_date(days=7) }} | 2024-01-18 |
| Adding business days to a date | {{ "2024-01-11"|shift\_date(days=7, business\_days=True) }} | 2024-01-22 |
| Adding months to a date | {{ "2024-01-11"|shift\_date(months=3) }} | 2024-04-11 |
| Adding years to a date | {{ "2024-01-11"|shift\_date(years=2) }} | 2026-01-11 |
| Subtracting days from a date | {{ "2024-01-11"|shift\_date(days=-7) }} | 2024-01-04 |
| Subtracting business days from a date | {{ "2024-01-11"|shift\_date(days=-7, business\_days=True) }} | 2024-01-02 |
| Subtracting months from a date | {{ "2024-01-11"|shift\_date(months=-3) }} | 2023-10-11 |
| Subtracting years from a date | {{ "2024-01-11"|shift\_date(years=-2) }} | 2022-01-11 |
| Mixed operations | {{ "2024-01-11"|shift\_date(years=1, months=-2, days=8) }} | 2024-11-19 |

## Why this matters

Empower your documents with these new Jinja filters. Imagine automatically calculating contract renewal dates, verifying document creation timestamps for legal compliance, or adjusting court filing deadlines based on business days - all with a few lines of code. These filters translate to real benefits: reduced errors in critical documents, improved efficiency by automating date calculations, and greater flexibility in adapting documents to specific case requirements.

Get started with these new Jinja filters and unlock a new level of efficiency in your document generation!

---

---
url: /knowledgebase/release-notes/release-notes-1.3/new-template-merge-fields.md
---

# New template & merge fields

We've integrated Jinja merge fields across the entire Autologyx platform, and we're confident you'll love it. Why Jinja, you ask? It's a modern and designer-friendly templating language for Python, well known for its simplicity and flexibility. And the best part? It's going to make your work a whole lot easier.

![Jinja\_articles.gif](/knowledgebase/images/img_11644432738589_1776895693.png)

**Creating and managing templates** has never been easier. With Jinja, you can effortlessly insert dynamic content into your document templates, making them more adaptable to your needs.

**More powerful data handling** is also now available in our send email actor, API calls, and local variables. With Jinja merge fields, you can now juggle your data like a pro, leading to more precise and effective communication.

**Standardisation across the platform** is the cherry on top. We're standardising the use of merge fields across our platform. No more switching between different syntaxes or formats — with Jinja, it's one language for all.

We're excited about this update and confident that it will significantly enhance your Autologyx experience. As always, we're here to support you through this transition, and look forward to your feedback!

---

---
url: /knowledgebase/release-notes/release-notes-1.8/new-user-account-types.md
---

# New user account types

Driven by the desire for better user management, we've introduced dedicated Internal and External users account types in Catalyst, coupled with a revitalised User Interface, designed to empower users with greater clarity and control.

**At a glance:** The centrepiece of this UI overhaul lies in the breakdown of each user account type, now distinctly outlined with its specific functionalities and limitations.

![New users.gif](/knowledgebase/images/img_16323734941725_1776895660.png)

## User account types

* **1-Time Completion Users:** Users granted access solely for completing one-time tasks, without login privileges.
* **Internal Users:** A novel user type with access to system functionalities based on permissions but ineligible for role assignment.
* **External Users:** Tailored for external partners, Catalyst introduces the External User type. These users gain system access based on granted permissions, ensuring their access is limited to specific functionalities aligned with external collaboration needs.
* **Config Admin:** Users with standard system access, coupled with the ability to assume specific roles, such as creating Object Classes or sequences.
* **Super Admin:** Users with omnipotent access to all system resources, empowered to execute any permissible action.

## User limits and counts

**Additionally,** each user type is now associated with a distinct user limit, communicated through a user count.

This provides real-time insights into the number of users you can create for each account type. It not only helps you stay within the prescribed limits but also ensures optimal utilisation of available resources.

More than just a visual refresh, the UI transformation fosters an intuitive and efficient user management experience. With this delineation, we believe managing users in Catalyst provides clarity, control, and efficiency in user administration.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.10/new-autologyx-catalyst-1.10-release-notes.md
---

# New Autologyx Catalyst 1.10 release notes

Our new release brings a breadth of new capability to our platform and premium additional capabilities, from our new **Applied AI** suite of tools, improved **analytics and reporting** capabilities, improved **user group management and access control**, a new Record Access actor, and loads of bug fixes and enhancements.

## Applied AI

We have stated many times we are a process and workflow automation company, however the rise of AI can not be ignored.

Introducing our new **Applied AI** capabilities, which are designed to bring cutting-edge generative AI capabilities directly into your workflows and processes, offering tools that make advanced automation accessible and actionable.

We want you to be able to access the models you need, so we have introduced the integration of **OpenAI’s ChatGPT** and access to many other models like Claude, Titan and Llama through our partnership with **Amazon Bedrock**.

With the introduction of embeddings into the Sequencer, we’re introducing tools that simplify complex processes, adapt to your unique needs, and drive meaningful results. Months of careful development have resulted in features that bring precision, flexibility, and intelligence to every step of your business operations.

## Analytics and reporting

Our latest release introduces a new **Analytics and reporting** capability, a game-changer for data-driven organisations.

By seamlessly combining operational data from the Resource Database with historical insights from the History Events Database, this feature provides a unified, high-performance foundation for advanced analytics.

## User group management and access control

We've extensively improved **user group management** by integrating the capability into User-Type fields, Class Permission Sets, and Record Permission Sets via API. Manual user management becomes a thing of the past.

Assigning tasks has never been easier, thanks to the ability to assign entire groups, and our new Sequencer actor simplifies record access control, all from one centralised hub.

We’ve revolutionised how user visibility is managed throughout the platform - everything now revolves around User Groups. From assigning responsibilities to controlling access, these updates give you precise control, ensuring the right people have access to the right information.

## Learn more

But don’t just take our word for it. This is a complex and powerful update that deserves a deeper dive.

Check out our detailed articles where we break down these features and show you how to make the most of them.

|  |  |  |
| --- | --- | --- |
| Line\_1.png | | |
| **OpenAI: GPT integration** February 2025  Added.png    Integrate the power of **OpenAI GPT** directly into your workflows with our new Sequencer actor. This feature allows you to generate AI-driven responses tailored to your specific needs - whether summarising data, generating content, or automating repetitive tasks. Customise prompts and parameters easily, and store results for use across your processes. |  | GPT.gif  [Explore GPT-driven automation>](/knowledgebase/release-notes/release-notes-1.10/openai-gpt-integration/) |
| Line\_1.png | | |
| **OpenAI: Embeddings integration** February 2025  Added.png    Introducing **OpenAI Embeddings** in Sequencer - ideal for semantic search and context-aware automations. Use embeddings to find similar records, retrieve relevant information, or power smarter decision-making processes. With flexible setup options, you can seamlessly incorporate these capabilities into your workflows while keeping everything aligned with your data. |  | Embeddings.gif  [Discover semantic search>](/knowledgebase/release-notes/release-notes-1.10/openai-embeddings-integration/) |
| Line\_1.png | | |
| **Analytics Database** February 2025  Added.png    Welcome to the future of data insights! With our **Analytics Database**, you can seamlessly merge operational and historical data in one place. Dive deep into every aspect of your operations, optimize processes, monitor tasks, and uncover risks before they escalate. |  | Clickhouse2.gif  [Gain insights with Analytics Database >](/knowledgebase/release-notes/release-notes-1.10/analytics-database/) |
| Line\_1.png | | |
| **Users and groups visibility control** February 2025  Added.png    Our latest update focuses on tightening and streamlining how **list permissions** control visibility and interaction with users and groups. This update not only improves security but also adds a layer of operational efficiency for large organisations, especially when access to sensitive data must be strictly managed. |  | Group perm sets.gif  [Learn more about the new permissions>](/knowledgebase/release-notes/release-notes-1.10/users-and-groups-visibility-control/) |
| Line\_1.png | | |
| **Groups in User type Class fields** February 2025  Added.png    With this major update, **User Groups are now available in User-Type Class fields**, including for the first time in task forms. This enhancement redefines how you assign and select users and groups, offering unprecedented flexibility across your records and tasks. Tailor every form to fit unique workflows, ensuring smarter, more dynamic user management. |  | User type class field.gif  [Start configuring the updated Class field >](/knowledgebase/release-notes/release-notes-1.10/groups-in-user-type-class-fields/) |
| Line\_1.png | | |
| **Groups in User type fields** February 2025  Added.png     We've enhanced user selection with an advanced control that now allows **choosing not only individual users but also entire groups and even members** within those groups. This new level of flexibility simplifies complex workflows by providing more selection options in every field where users are involved. |  | User type field.gif  [See how new user selection can simplify workflows >](/knowledgebase/release-notes/release-notes-1.10/groups-in-user-type-fields/) |
| Line\_1.png | | |
| **Groups as Task assignees** February 2025  Added.png     Simplify task management by assigning entire User Groups at once. With this feature, **distribute tasks effortlessly across teams**, enhancing collaboration and reducing manual workload. Assigning tasks has never been more efficient or flexible. |  | Groups as task assignees.gif  [Assign tasks faster with group-based workflows >](/knowledgebase/release-notes/release-notes-1.10/groups-as-task-assignees/) |
| Line\_1.png | | |
| **Groups in Class Permission Sets** February 2025  Added.png    Take your permission management to the next level by adding **Groups to Class Permission Sets**. Whether assigning permissions to object classes, object records, or tasks, this feature lets you define how groups interact with critical data, ensuring precise control and robust access management across the board. |  | Groups in Class permission sets.gif  [Manage permissions at scale with groups >](/knowledgebase/release-notes/release-notes-1.10/groups-in-class-permission-sets/) |
| Line\_1.png | | |
| **API for Groups in Record Permission Sets** February 2025  Added.png     Expand your automation potential with our **API for assigning Groups to Record Permission Sets**. This enhancement empowers your automated workflows to manage group-level permissions for records, ensuring scalable and secure access control across large datasets. |  | API record permission sets.gif  [Boost automation with new API >](/knowledgebase/release-notes/release-notes-1.10/api-for-groups-in-record-permission-sets/) |
| Line 1.png | | |
| **Record Access actor** February 2025  Added.png     Our new **Record Access Actor** gives you complete control over record access and ownership. Assign groups, users, or user-type field values to both Record Permission Sets and record ownership from one centralised point in the Sequencer. |  | Record access actor.gif  [Explore how Record Access Actor enhances control >](/knowledgebase/release-notes/release-notes-1.10/record-access-actor/) |
| Line 1.png | | |
| **Bug fixes and improvements** February 2025  Fixed.png     With **over 100 bugs** addressed, this release significantly improves platform stability and performance. Alongside UI and backend optimisations, we've implemented enhancements to streamline daily tasks, making your work more efficient and intuitive. |  | Something went wrong.gif  [Take a look at the latest improvements >](/knowledgebase/release-notes/release-notes-1.10/bug-fixes-and-improvements/) |
| Line\_1.png | | |

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.11/new-autologyx-catalyst-1.11-release-notes.md
---

# New Autologyx Catalyst 1.11 release notes

AI is no longer a futuristic concept but a necessity for businesses striving to automate, optimise, and stay ahead of the curve. This release takes AI-driven automation to the next level, giving you more power, flexibility, and control over how intelligence is embedded into your workflows.

**Highlights**

* Our most configurable actor yet: AWS Bedrock integration - supporting a vast array of AI providers and models to suit every business need.
* For those leveraging OpenAI models via Microsoft Azure, we’ve introduced a dedicated **Azure AI actor** - fully supporting the latest **GPT** and **Embeddings** models for more secure and enterprise-ready AI interactions.
* Beyond AI, we’ve added additional authentication flows, expanded outbound email settings, introduced new API endpoints, and delivered customer requested features such as delayed account activation - giving your organisation **more integration options and greater control** over system access.

**This is a release packed with innovation** - so dive into the details and explore how these features can elevate your operations.

|  |  |  |
| --- | --- | --- |
| Line\_1.png | | |
| **AWS: Bedrock integration** April 2025  Added.png    Our new AWS Bedrock integration brings together AI models from **Amazon, Anthropic, Meta,** and **Mistral** into a single actor, letting you choose the perfect AI brain for each specific task. This flexibility means you can match workflows to ideal AI partners and fine-tune every parameter for intelligent automation tailored to your requirements. |  | Bedrock\_main.gif  [Discover AWS Bedrock integration >](/knowledgebase/release-notes/release-notes-1.11/aws-bedrock-integration/) |
| Line\_1.png | | |
| **Azure OpenAI integration** April 2025  Added.png    The Azure OpenAI Actor brings OpenAI's most advanced models directly into your Catalyst workflows, including **GPT-4o, GPT-3.5 Turbo**, and the breakthrough o1 series. This enterprise-ready integration lets you harness AI for everything from document drafting to knowledge retrieval while maintaining your security standards through **Azure**. |  | AzureOpenAI\_main.gif  [Explore Azure OpenAI integration>](/knowledgebase/release-notes/release-notes-1.11/azure-openai-integration/) |
| Line\_1.png | | |
| **WebSockets for Elements** April 2025  Added.png    Stay connected with **WebSockets**, bringing real-time data synchronisation to your solutions. This enhancement connects your custom front-end Elements with the underlying data and will instantly reflect changes, giving financial, legal and other time-sensitive operations the up-to-the-second data they need. |  | Sockets\_main.gif  [Learn about WebSockets >](/knowledgebase/release-notes/release-notes-1.11/websockets/) |
| Line\_1.png | | |
| **ROPC flow Authentication Objects** April 2025  Added.png    Enhance authentication security with **ROPC Flow for Objects**. This feature enables seamless authorisation for service-to-service communication while maintaining strict access controls. Ideal for backend processes requiring direct authentication without user interaction. |  | ROPC\_main.gif  [Understand ROPC Flow Authentication >](/knowledgebase/release-notes/release-notes-1.11/ropc-flow-authentication-objects/) |
| Line\_1.png | | |
| **Microsoft OAuth in outbound mail setup** April 2025  Added.png    As Microsoft phases out Basic Authentication, we've introduced **Microsoft Office 365 Exchange (Graph)** with OAuth 2.0 for outbound mail. This modern approach transforms your email authentication from the ageing SMTP model to Microsoft's recommended Graph API, bringing enhanced security, granular access control, and robust monitoring to your email infrastructure. |  | Outbound\_main.gif  [Set up Microsoft OAuth for Outbound Mail >](/knowledgebase/release-notes/release-notes-1.11/microsoft-oauth-in-outbound-mail-setup/) |
| Line\_1.png | | |
| **Multipart data support in API Call actor** April 2025  Added.png     Handle complex API requests effortlessly with our new **Multipart Data Support** in the API Call actor. Now you can send structured data, including file uploads and multi-part payloads, in a single request -perfect for integrating with external services requiring richer data exchanges. |  | Multipart\_main.gif [Use Multipart Data in API Calls >](/knowledgebase/release-notes/release-notes-1.11/multipart-data-support-in-api-call-actor/) |
| Line\_1.png | | |
| **Delayed account activation** April 2025  Added.png     Take control of your user onboarding with **delayed account activation**. This feature lets you create accounts now but activate them precisely when it makes sense for your organisation. It brings order to the user activation timeline, ensuring proper configurations before granting access and creating cohesive onboarding experiences for entire departments. |  | Delayed\_main.gif  [Control account activation timing >](/knowledgebase/release-notes/release-notes-1.11/delayed-account-activation/) |
| Line\_1.png | | |
| **Hierarchical records creation endpoints** April 2025  Added.png    Create records and **relationships in a single API request**! This game-changing feature allows hierarchical record creation in one go, eliminating the need for multiple requests. Perfect for legal, financial, and structured data applications, improving efficiency and consistency. |  | hierarchical\_main.gif  [Simplify hierarchical record creation >](/knowledgebase/release-notes/release-notes-1.11/hierarchical-records-creation-endpoints/) |
| Line 1.png | | |
| **Bug fixes and improvements** April 2025  Fixed.png     This update brings **critical security enhancements, performance optimisations, and the introduction of Constants -** a powerful way to manage environment-specific values without manual updates. Your workflows are now faster, more secure, and easier to maintain than ever before. |  | Screenshot\_1.png  [See what’s new >](/knowledgebase/release-notes/release-notes-1.11/bug-fixes-and-improvements/) |
| Line\_1.png | | |

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.12/new-autologyx-catalyst-1.12-release-notes.md
---

# NEW\* Autologyx Catalyst 1.12 release notes

We know how important **performance, security, and long-term stability** are to our clients, especially in industries where every second counts and data privacy is non-negotiable. That’s why this release focuses heavily on **upgrading our entire frontend technology stack** and our **backend runtime**, modernising core packages and eliminating legacy dependencies to give you a faster and more secure experience end to end.

Over the past weeks, we’ve modernised and cleaned up **over 40 core frontend packages** and our build tooling.

## **The most impactful changes include**

* **Upgraded to React 18**
* **Redux 5 + Redux Toolkit**
* **Modernised routing**
* **Introduced React Query**
* **Removed legacy dependencies** (e.g., reactstrap, react-select)
* **Resolved dozens of known CVEs**
* **Migrated to Node 22 + TypeScript 5**
* **Upgraded our Python to 3.12** to leverage the newest security patches, performance improvements and compatibility with modern libraries

## **What this means in practice**

By upgrading our frontend engine, backend runtime, and dropping legacy baggage, we’ve cleared the path for faster feature development, more robust performance under pressure, and fewer unexpected bugs. Everyday actions like switching views, submitting forms, or working with high-volume data now happen with less friction and greater consistency.

**Behind the scenes,** our development team can now move faster and with more confidence. These upgrades give us access to the latest tooling, better testing capabilities, and a future-proof foundation, making it easier to deliver improvements that are both impactful and secure.

## **What you should expect**

**You won’t see a redesigned interface or flashy new feature here, and that’s exactly the point.** This was a behind-the-scenes investment in long-term stability, security, and speed. For teams operating in high-stakes, compliance-heavy environments, it means peace of mind: every package we depend on is actively maintained, auditable, and secure by today’s standards.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.13/new-autologyx-catalyst-1.13-release-notes.md
---

# NEW\* Autologyx Catalyst 1.13 release notes

January 2026

**New year. New models. New actors.**\
This release is all about orchestration, automation and AI that gets real work done.

## Integrations

**Added**

A new central space lets you manage all third-party integrations - see what’s active and what needs setup, from AI providers to tools like DocuSign or Adobe. Everything connected, finally in one place.

![Feature demo](../../../images2/zendesk_4891772298911_001_f9f10b73f03b.gif)

\[Explore your integration hub

> ]\(/knowledgebase/release-notes/release-notes-1.13/integrations/)

## IManage integration

**Added**

The new iManage Cloud integration lets you search, pick, and use your documents directly in workflows - no coding required. A faster way to connect DMS with real automation.

![Feature demo](../../../images2/zendesk_4891772298911_002_33f8f880c524.gif)

\[Connect documents like never before

> ]\(/knowledgebase/release-notes/release-notes-1.13/imanage-integration/)

## File upload component

**Added**

Upload a ZIP file and instantly generate multiple records: each file becomes a document attached to a new record. An efficient way to batch content into your workspace.

![Feature demo](../../../images2/zendesk_4891772298911_003_3280ffc99d90.gif)

\[Turn ZIPs into records

> ]\(/knowledgebase/release-notes/release-notes-1.13/file-upload-component/)

## New AI models in Sequencer

**Updated**

More engines. Sharper workflows. From DeepSeek to GPT-5, pick the right model for every step and orchestrate your legal automation like never before.

![Feature demo](../../../images2/zendesk_4891772298911_004_ed1f4164897f.gif)

\[Discover the models

> ]\(/knowledgebase/release-notes/release-notes-1.13/new-ai-models-in-sequencer/)

## The Loop actor

**Added**

The Loop actor makes it easy to process arrays, JSON, or files - one item at a time, no code needed. Ideal for automating bulk actions cleanly.

![Feature demo](../../../images2/zendesk_4891772298911_005_bb8447629626.gif)

\[Learn how looping works

> ]\(/knowledgebase/release-notes/release-notes-1.13/the-loop-actor/)

## Dynamic document assembly with .docx merge fields

**Improved**

You can now embed full .docx files into document templates using a single merge field. Perfect for dynamic clause insertion with full formatting control.

![Feature demo](../../../images2/zendesk_4891772298911_006_df70c60e57cb.gif)

\[Build smart documents

> ]\(/knowledgebase/release-notes/release-notes-1.13/dynamic-document-assembly-with-.docx-merge-fields/)

## Delete option in the Set Task actor

**Improved**

New delete options in the Set Task actor give you control over which tasks get cleaned up: outstanding, completed, or just the latest one. Less clutter, smarter task handling.

![Feature demo](../../../images2/zendesk_4891772298911_007_5976ab665430.gif)

\[Review the task delete options

> ]\(/knowledgebase/release-notes/release-notes-1.13/delete-option-in-set-task-actor/)

## Authentication object changes

**Improved**

Expiry notifications and usage panels help prevent broken workflows or missed renewals. Auth objects are now safer to manage and harder to misuse.

![Feature demo](../../../images2/zendesk_4891772298911_008_2402a5f7c7aa.gif)

\[Check what’s changed

> ]\(/knowledgebase/release-notes/release-notes-1.13/authentication-object-changes/)

## Bug fixes and improvements

**Fixed**

Security, stability, and smart UX tweaks - Trivy patches, antivirus scanning, improved Constants, unlimited docs, and more. The small fixes that make a big difference.

![Feature demo](../../../images2/zendesk_4891772298911_009_a96608bd3b9d.gif)

\[Discover what’s smoother, faster, safer

> ]\(/knowledgebase/release-notes/release-notes-1.13/bug-fixes-and-improvements/)

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.14/new-autologyx-catalyst-1.14-release-notes.md
---

# NEW\* Autologyx Catalyst 1.14 release notes

**May 2026**

This release introduces enhancements to text editing, UI consistency, document handling, and Sequencer capabilities, alongside improvements to APIs, real-time updates, and error handling.

## User Experience & Interface Improvements

* **Enhanced text field options**
  * Introducing Markdown as an option in text fields across:
    * Create/Edit forms
    * Standalone forms
    * Self-contained tasks
    * “Update record” tasks
  * Increased flexibility for formatting content across the platform

* **Improved form usability**
  * Full-width textboxes in Object Class forms
  * Increased max height for multiline text fields in display forms

* **Refined UI consistency**
  * Enhancements across the Catalyst UI for a more cohesive look and feel

![Feature demo](../../../images2/zendesk_5582558576415_001_29026f3621f3.png)

[Find out more>](/knowledgebase/release-notes/release-notes-1.14/user-experience-interface-improvements/)

## Real-Time & Workflow Improvements

* **Sequencer enhancements**
  * New context menu items in Sequencer

* **New merge fields**
  * Introduced new merge fields:
    * {{ loop\_item }} for local variables
    * {{ loop\_counter }} in Sequencer
  * Extended user-type merge fields to return User Group members

* **Real-time updates**
  * Real-time updates for Task Lists using WebSockets

[Find out how to use these features>](/knowledgebase/release-notes/release-notes-1.14/real-time-workflow-improvements/)

## Document & Records Enhancements

* **Document display and filtering**
  * Improved “File name” display on tables and records
  * Added ability to filter Object Records by document type fields

* **API enhancement**
  * GET /api/object-records/files/ now returns document metadata

![Feature demo](../../../images2/zendesk_5582558576415_002_cf7d320e3ba2.png)

[Check out these enhancements>](/knowledgebase/release-notes/release-notes-1.14/document-records-enhancements/)

## Authentication & Security

* **Authentication support updates**
  * Enhanced OPTIONS /api/security/ to support authentication method management
  * Updated authentication object expiry notification email template

[Making it all secure!>](/knowledgebase/release-notes/release-notes-1.14/authentication-security/)

## Integrations

We recently introduced iManage Cloud integration in records, which lets you search, select, and use your documents without leaving Catalyst.

* Added a modal for non-authenticated users prompting them to log in to iManage to access documents
* Login once to retain access across all records

![iManage Cloud connection modal](../../../images2/zendesk_5582558576415_003_bedf50a9086b.png)

[Access iManage from your Record>](/knowledgebase/release-notes/release-notes-1.13/imanage-integration/)

## Error Handling & Reliability

* **More precise error messages** when:
  * Creating sequences without sufficient permissions
  * Handling JSON path errors in Loop actors

* **Improved error reporting** when removing Object Class relations used in:
  * Sequences
  * Document Templates

\[Easy to understand error messaging

> ]\(/knowledgebase/release-notes/release-notes-1.14/error-handling-reliability/)

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.2/new-autologyx-catalyst-1.2-release-notes.md
---

# New Autologyx Catalyst 1.2 release notes

We've been busy behind the scenes, making **Autologyx Catalyst** faster, smarter, and more intuitive than ever before.

**With the 1.2 release, you can enjoy:**

* **Lightning-fast performance**
* **Improved data management**
* **Powerful new features** for admins and your business users of the platform

Whether you're implementing a relational data model for your use cases, improving the user experience by streamlining your task delegation, or leveraging any of the many new features in the platform, **Autologyx** has got you covered.

Step into the future of workflow automation and experience the power of **Autologyx Catalyst** today!

|  |  |  |
| --- | --- | --- |
| Line\_1.png | | |
| **Relational modeller** May 10, 2023  Added.png     The Relational modeller allows you to easily establish relationships between individual object classes, enabling smoother workflow and better data organisation. Start using it today and enjoy a more integrated and efficient platform. |  | Relational\_main.gif  [Learn how to create relations >](/knowledgebase/release-notes/release-notes-1.2/relational-modeller/) |
| Line\_1.png | | |
| **Present child records**  May 10, 2023  Added.png    After creating relations between object classes with our Relational modeller, the child object classes can now be added to record forms. This new functionality makes it even easier to manage and organize your data on the Autologyx Catalyst platform. Try it out and see the difference it can make in your workflow! |  | Children\_main.gif  [Check how to organise your data >](/knowledgebase/release-notes/release-notes-1.2/present-child-records/) |
| Line\_1.png | | |
| **Relation Lookup** May 10, 2023  Added.png     Unleash the full potential of your automation sequences with Relation Lookup, our latest addition to Autologyx Catalyst. Learn how this dynamic new actor empowers you to effortlessly find and manage children or parent records, paving the way for seamless automation and enhanced productivity. |  | Relation\_Lookup\_main.gif  [Gain insights into Relation Lookup >](/knowledgebase/release-notes/release-notes-1.2/relation-lookup/) |
| Line\_1.png | | |
| **Sequence Runner** May 10, 2023  Added.png   It's time to step into the fast lane and experience a new era of streamlined workflows with the Sequence Runner by your side. With the power to trigger sequences for children or parent records, you will optimise any complex process. |  | Sequence\_runner\_main.gif  [Be the first to run sequences >](/knowledgebase/release-notes/release-notes-1.2/sequence-runner/) |
| Line\_1.png | | |
| **Improved breadcrumbs** May 10, 2023  Added.png     We've given our breadcrumbs a makeover making them even more functional and user-friendly. With the possibility to create relations, it's more important than ever to know exactly where you are in the process. Let's dive in and see how our new breadcrumbs can help you navigate your way around and stay on track. |  | Breadcrumbs\_main.gif  [Get the full scoop on breadcrumbs>](/knowledgebase/release-notes/release-notes-1.2/improved-breadcrumbs/) |
| Line\_1.png | | |
| **Tasks for one-time completion users** May 10, 2023  Added.png    Tasks can now be assigned to a new type of user in the system, one-time completion users! This new update allows for more flexibility in task delegation and completion which allows for a more efficient workflow, helping you get more done in less time. |  | 1TCtasks\_main.gif [Explore one-time completion users in tasks >](/knowledgebase/release-notes/release-notes-1.2/tasks-for-one---time-completion-users/) |
| Line\_1.png | | |
| **Click-to-Call on Autologyx** May 10, 2023  Added.png     With Click-to-Call, you can now call the numbers saved on your records directly from your browser, making it easier than ever to stay connected with contacts saved in a record. |  | Click-to-call\_main.gif   [See how to Click-to-Call >](/knowledgebase/release-notes/release-notes-1.2/click-to-call-on-autologyx/) |
|  |
| Line\_1.png | | |
| **JSON type field** May 10, 2023  Added.png    Get ready to revolutionise your data management with our latest update! JSON-type fields are now available in forms. This means you can easily capture complex data structures and store them as part of your records and integrate them into your workflows. |  | JSON\_main.gif  [Take a closer look at the JSON type of field >](/knowledgebase/release-notes/release-notes-1.2/json-type-field/) |
| Line\_1.png | | |
| **Improved instructions editor** May 10, 2023  Added.png    Provide clearer instructions with improved formatting options! The new controls give you greater flexibility and creative control over the content, allowing you to create instructions that are clear, engaging, and easy to follow. Elevate your instruction game to the next level with Autologyx! |  | CKEeditor\_main.gif  [Find out about the new formatting options >](/knowledgebase/release-notes/release-notes-1.2/improved-instructions-editor/) |
| Line\_1.png | | |
| **Bug fixes and improvements** May 10, 2023  Fixed.png    As with all releases we've spent time focusing on performance, minor enhancements and importantly bug fixes. You'll hopefully see improvements on performance and will see some of your requested minor enhancements in the product. |  | Fixed\_main.gif  [Discover the new Autologyx experience >](/knowledgebase/release-notes/release-notes-1.2/bug-fixes-and-improvements/) |

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.3/new-autologyx-catalyst-1.3-release-notes.md
---

# New autologyx catalyst 1.3 release notes

Hot on the heels of our 1.2 release [\[NEW\* Autologyx Catalyst 1.2 release notes\]](/knowledgebase/release-notes/release-notes-1.2/new-autologyx-catalyst-1.2-release-notes/), we're bringing more updates to our Catalyst platform!

## **Document automation updates**

Document Automation has been at the heart of what we do here at Autologyx, and the new Catalyst Word Add-in delivers a seamless experience when turning your flat documents into dynamic templates which are able to be leveraged within your workflows.

We've implemented a new templating language across the platform that is accessible within the document automation templates and, importantly, within the Sequencer, ensuring consistency throughout your workflow.

## **Workspace and usability improvements**

We've enhanced the user experience of the collaborative workspace by creating 'User Type Fields' and enabling the ability to easily sort your records list based on key field types, making it easier to manage your work.

We've also worked hard and continued to make bug fixes and deliver additional minor enhancements and improvements.

**Check out our latest release** packed with new features and improvements.

|  |  |  |
| --- | --- | --- |
| Line\_1.png | | |
| **Catalyst Word Add-in** June 30, 2023  Added.png    Catalyst Word Add-in by Autologyx is the missing puzzle piece for effortless document creation. Wave goodbye to the hassle of manual data merging and enter a new chapter of productivity as you combine data and compose flawless documents based on your object class fields and advanced functions. |  | Addin\_main.gif  [More on dynamic documents creation>](/knowledgebase/release-notes/release-notes-1.3/catalyst-word-add-in/) |
| Line\_1.png | | |
| **New template & merge fields** June 30, 2023  Added.png   Autologyx has integrated Jinja merge fields across its platform, making workflows smoother and enhancing productivity. This update simplifies document template creation, supercharges the functionality of the send email actor, API calls, and local variables, and ensures a consistent user experience. |  | Jinja\_main.gif  [Meet Jinja now >](/knowledgebase/release-notes/release-notes-1.3/new-template-merge-fields/) |
| Line\_1.png | | |
| **User type fields** June 30, 2023  Added.png     The key to efficient user management, task allocation and improved collaboration can be found within the User Type Field! Managing users becomes effortless and collaboration reaches new heights. Don't miss out on this essential feature that unlocks a world of possibilities for your business. |  | Users\_main.gif[Master user management >](/knowledgebase/release-notes/release-notes-1.3/user-type-field/) |
| Line\_1.png | | |
| **Sorting records** June 30, 2023  Added.png     You'll love having this feature in your tool belt the next time you're faced with a disorganised records list. The sorting feature allows you to effortlessly arrange your data based on different field types, providing time-saving organisation and clarity to your workflow. |  | Sorting\_main.gif  [How to organise your records list >](/knowledgebase/release-notes/release-notes-1.3/sorting-records/) |
| Line\_1.png | | |
| **Bug fixes and improvements** June 30, 2023  Fixed.png   We are back with a fresh round of bug fixes and improvements, designed to elevate your user experience and platform efficiency. From addressing navigation issues to accelerating the list view and fine-tuning triggers in the Sequencer, we've ensured your Autologyx journey is even more seamless. |  | BUGS\_main.gif  [See the full range of updates now >](/knowledgebase/release-notes/release-notes-1.3/bug-fixes-and-improvements/) |

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.5/new-autologyx-catalyst-1.5-release-notes.md
---

# New Autologyx Catalyst 1.5 release notes

Our latest product release 1.5 is concentrated on a number of strategic themes.

**Intelligent work:** We're extending our powerful document automation tools and delivering document intelligence with our integration with Zuva.ai.

**Ecosystem:** We're also broadening our 'ecosystem' theme with the introduction of Elements and other key integrations.

The integration of Zuva into our system as a premium add-on will provide our clients the ability to upload and extract key terms and provisions from their contracts. We've enhanced our document automation capabilities by adding a new 'in context' manual document creation tool from with a record in the platform. We've also added relational support and made several enhancements to our Word add-in template designer.

**Workflow and integration enhancements:** We have added a number of enhancements to the Sequencer, our workflow design canvas. We've improved document handling within the platform, a new API (bearer token) generic authentication object, which introduces a secure method to design your own integrations. We've also added two new actors to help manage tasks, with both a create task actor and a new assign task actor in the tool.

**Elements:** Elements is a tool designed to allow our customers, our client value team and our partners to design and load third party web-parts into the Catalyst platform. The elements tool will enable teams to produce charts, lists, and websites directly on our platform interacting with the underlying platform data.

We're looking forward to getting these great enhancements into our customers hands ASAP. Get in touch to find out more.

|  |  |  |
| --- | --- | --- |
| Line\_1.png | | |
| **Elements**  October 16, 2023  Added.png    Autologyx is delivering even more flexibility with Elements, allowing our clients or our partners to integrate third-party content right into the platform. Whether it's widgets, diagrams, or interactive graphics, you can display them all with ease. A full management framework allows Elements to be configured and installed with ease, opening up a world of possibilities to extend your workflow solutions. |  | Elements\_main.gif  [Discover Elements >](/knowledgebase/release-notes/release-notes-1.5/elements/) |
| Line\_1.png | | |
| **Manual document automation** October 16, 2023  Added.png     Within the context of any record, you can now surface any document automation templates using the new sidebar. Extending our document automation use case in this way enables quick document generation for selected records and seamless document saving to specific fields, streamlining your business processes with efficient automation capabilities. |  | Templates\_main.gif  [Explore the Templates panel >](/knowledgebase/release-notes/release-notes-1.5/templates-panel/) |
| Line\_1.png | | |
| **Relational support in Word Add-in** October 16, 2023  Added.png     Our document automation word add-in just got a significant upgrade with relational support. Now, you can insert fields in your documents not only from the selected object class but also from any object class within the relational model. This super charges your document automation potential and delivers a whole new level of maturity and complexity. |  | Relational\_main.gif  [More on the Catalyst Add-in >](/knowledgebase/release-notes/release-notes-1.5/relational-support-in-word-add-in/) |
| Line\_1.png | | |
| **Document handling in Sequencer** October 16, 2023  Added.png     We've supercharged the Sequencer with binary and multipart document support. Now, you can select documents from the field and use them in any way you need, from emailing to integrating with other processes! The Sequencer is now more powerful and versatile than ever. |  | DocumentsSequencer\_main.gif  [Uncover the new capabilities of Sequencer >](/knowledgebase/release-notes/release-notes-1.5/documents-in-sequencer/) |
| Line\_1.png | | |
| **Authentication Objects - API Keys** October 16, 2023  Added.png     Introducing Authorization Object API Keys, a new feature that lets you manage and generate API keys securely. This feature enhances control and authentication, making it easier than ever to integrate with external systems. It's just another way we're making Autologyx more user-friendly and efficient. |  | APIKeys\_main.gif  [Get to know API Keys >](/knowledgebase/release-notes/release-notes-1.5/authentication-objects---api-keys/) |
| Line\_1.png | | |
| **Create task actor** October 16, 2023  Added.png     Simplify task management and boost efficiency within the Sequencer. The new Create task actor makes task creation effortless and time-saving. Upgrade now to experience the power of Create task and unlock a world of possibilities for your task automation needs. |  | Create task\_main.gif  [Start working with Create task actor >](/knowledgebase/release-notes/release-notes-1.5/create-task-actor/) |
| Line\_1.png | | |
| **Task assignment actor** October 16, 2023  Added.png     Discover the cutting-edge Task assignment actor - the newest addition to our Sequencer. With easy drag-and-drop functionality and customizable task assignees, this powerful feature empowers Sequence designers to optimize their processes. |  | TaskAssignment\_main.gif  [Test the Task assignment actor >](/knowledgebase/release-notes/release-notes-1.5/task-assignment-actor/) |
| Line\_1.png | | |

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.6/new-autologyx-catalyst-1.6-release-notes.md
---

# New Autologyx Catalyst 1.6 release notes

At Autologyx, we're dedicated to improving and simplifying our customers integration options. With the 1.6 release, we're introducing innovative features to extend your workflows and enhance control over data.

## What's new in 1.6

**iManage integration improvements**

Our newly refactored iManage authentication object allows administrators to create new iManage Authentication objects linking your workflow to your iManage libraries.

Expand your processes by connecting your document repositories within the Sequencer to interact with your files and folders.

**Data handling improvements**

In response to your data needs, we've introduced a new type of Variable - JSON, providing a solution for storing large amounts of data.

**Form enhancements**

Additionally, we've enhanced Standalone forms and added a highly anticipated read-only option for fields.

## Explore the improvements below

Let's dive into the details of each new improvement!

|  |  |  |
| --- | --- | --- |
| Line\_1.png | | |
| **iManage Authentication object** December 7, 2023  Added.png    We have refactored our dedicated iManage Authentication object, streamlining the secure connection between iManage accounts and Catalyst. This allows administrators to configure integration between Autologyx and iManage libraries. |  | iManagemain.gif  [Find out more >](/knowledgebase/release-notes/release-notes-1.6/imanage-authentication-objects/) |
| Line\_1.png | | |
| **Sequencer file download** December 7, 2023  Added.png     Leveraging the well-established API Call actor, you can seamlessly download files from any source. With a single authentication process, specify the desired file location, empowering you to utilise the downloaded files according to your needs. |  | Sequencefiledownload\_main.gif  [Start using enhanced API Call actor >](/knowledgebase/release-notes/release-notes-1.6/sequencer-file-download/) |
| Line\_1.png | | |
| **“Relationship created” trigger in Sequencer** December 7, 2023  Added.png     The new "Relationship Created" trigger, now supported in sequences, checks if a relationship was established between parent and child records. Utilise this trigger to initiate subsequent actions within the sequence based on this criterion, enhancing your workflow automation. |  | RelationshipCreated\_main.gif  [Optimise your workflow with the new trigger >](/knowledgebase/release-notes/release-notes-1.6/“relationship-created”-trigger-in-sequencer/) |
| Line\_1.png | | |
| **The new type of variable – JSON type** December 7, 2023  Added.png     Now, you can effortlessly store vast volumes of data, providing flexibility and efficiency in managing complex information structures. JSON variables open doors to a wide array of possibilities for data manipulation and analysis. |  | JSONVariable\_main.gif  [Take a look at the new variable type >](/knowledgebase/release-notes/release-notes-1.6/the-new-type-of-variable-–-json-type/) |
| Line\_1.png | | |
| **Redirect URL on Standalone forms** December 7, 2023  Added.png     Enhance user experience with the Redirect URL feature on Standalone forms. Guide users seamlessly to a designated destination after completing the form, whether it's a specific website or another standalone form. Tailor user journeys to optimize engagement and interaction. |  | RedirectURL\_main.gif  [Tailor user experience >](/knowledgebase/release-notes/release-notes-1.6/redirect-url-on-standalone-forms/) |
| Line\_1.png | | |
| **Read-only fields** December 7, 2023  Added.png     In display form design, the new Read-Only option offers control and precision. Specify certain fields as read-only for end-users, ensuring data integrity while allowing sequences to make necessary changes. |  | ReadOnly\_main.gif  [Control data with read-only option >](/knowledgebase/release-notes/release-notes-1.6/read-only-fields/) |
| Line\_1.png | | |

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.8/new-autologyx-catalyst-1.8-release-notes.md
---

# New Autologyx Catalyst 1.8 release notes

Catalyst is constantly evolving to provide you with the best solutions. In version 1.8, we focused on innovations that will streamline your work and give you even greater control.

## Highlights in this release

* **Optimise your workflows** with easy document management, precise control over group visibility, and improved file download and upload.
* **Gain deeper insights into your data** with customisable ClickHouse views.
* **Increase control over user management** with new account types and flexible configuration options.

**Read on** to learn more about what’s new in the 1.8 release.

|  |  |  |
| --- | --- | --- |
| Line\_1.png | | |
| **Microsoft authentication object** February 26th, 2024  Added.png    Connecting Microsoft and Catalyst has never been simpler! By leveraging Microsoft Authentication Object integration with client credentials flow, we have opened the door to seamless business processes between Catalyst and your Microsoft account. |  | Microsoft CC\_main.gif  [Dive into the integration >](/knowledgebase/release-notes/release-notes-1.8/microsoft-authentication-object/) |
| Line\_1.png | | |
| **iManage in API Call actor** February 26th, 2024  Added.png     Our integration with iManage just got a lot more powerful. Integrate sequences to download files from your iManage account or effortlessly upload them to designated locations, eliminating the need for external tools, all thanks to Catalyst's iManage API Call Actor! |  | iManage API Call\_main.gif  [Enhance document workflows >](/knowledgebase/release-notes/release-notes-1.8/imanage-in-api-call-actor/) |
| Line\_1.png | | |
| **New user account types** February 26th, 2024  Added.png     We've expanded our range of account types and revamped the user creation UI. Our new Internal and External user types give you the power to categorise your users with greater precision and flexibility, making it easier to manage your users and their access. |  | New users\_main.gif  [Explore the new user account types >](/knowledgebase/release-notes/release-notes-1.8/new-user-account-types/) |
| Line\_1.png | | |
| **User group permissions** February 26th, 2024  Added.png     Gain granular control over group visibility across various Catalyst areas with our newly enhanced User Group Permissions feature. When crafting a group, dictate who gains access to view the group across diverse system areas. |  | User group permissions\_main.gif  [See more on group permissions >](/knowledgebase/release-notes/release-notes-1.8/user-group-permissions/) |
| Line\_1.png | | |
| **Image merge fields** February 26th, 2024  Added.png     Transition away from static documents! Our merge fields have advanced with dedicated image merge fields. Effortlessly integrate images into your documents, whether in templates or sequences and witness a dynamic shift in your content. |  | image merge field\_main.gif  [Uncover the picture-perfect perks now>](/knowledgebase/release-notes/release-notes-1.8/image-merge-fields/) |
| Line\_1.png | | |
| **Database views** February 26th, 2024  Added.png     Gain a deeper understanding of your data: ClickHouse Views give you the power to explore your data from different angles, helping you to identify patterns and trends that you might not have noticed otherwise.  Customise snapshots of your data, including historical records, to power your daily workflows and business analyses. |  | Clickhouse views\_main.gif  [Navigate your data with tailored views>](/knowledgebase/release-notes/release-notes-1.8/database-views/) |
| Line\_1.png | | |
| **Bug fixes and improvements** February 26th, 2024  Fixed.png     We've spruced up the API Call test log, making debugging a breeze by beautifying responses. Standalone forms get a power boost with elements and dynamic submit button control. These are just a taste of the additional improvements we've packed into this release! |  | Bug fixes and improvements\_main.gif  [Check out the nifty updates >](/knowledgebase/release-notes/release-notes-1.8/bug-fixes-and-improvements/) |
| Line\_1.png | | |

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.9/new-autologyx-catalyst-1.9-release-notes.md
---

# New autologyx catalyst 1.9 release notes

Evolving the core experience of **Catalyst** takes centre stage again in the **1.9 release**.

## **Integration improvements**

Building upon the success of our core integration framework capabilities, our latest **authentication objects** feature improves the ease at which you can integrate your existing systems, introducing the integration of well-known providers and many custom integrations.

## **Document handling and collaboration**

The introduction of our new document viewer improves document handling and collaboration. The document viewer panel allows you to view documents directly within Catalyst, streamlining your workflow and saving you valuable time by not having to download documents.

## **Process engine enhancements**

The power of the process engine has also been improved, with the introduction of new Jinja merge fields, adding new filters tailored for users who need to perform calculations on date and time fields.

## **Additional updates**

And that's just scratching the surface! In addition to these exciting new features, we've upgraded Django to the latest version and implemented several enhancements to our APIs, ensuring that Catalyst remains at the forefront of innovation and usability.

**Ready to learn more?** Explore these new features and see how they can help you achieve your goals.

|  |  |  |
| --- | --- | --- |
| Line\_1.png | | |
| **New integrations. New potential** May 2024  Added.png    We've been hard at work to simplify the creation of new Authentication objects the foundation of our integration framework. We can offer new integration with best in class providers like Adobe, Salesforce, and Box. Plus, for those with unique configurations, we've introduced the Generic oAuth 2.0 template, enabling seamless connection via client credentials with virtually any provider! |  | Auth\_object\_intro.gif  [Learn how to configure oAuth 2.0 >](/knowledgebase/release-notes/release-notes-1.9/authentication-objects/) |
| Line\_1.png | | |
| **Document viewer** May 2024  Added.png     Improving our document handling experiences we're thrilled to introduce the document viewer panel. This new panel provides insights into documents within records or tasks - eliminating the need for downloading and opening them natively. |  | Viewer\_main.gif  [View the documents in a new panel>](/knowledgebase/release-notes/release-notes-1.9/viewer-panel/) |
| Line\_1.png | | |
| **New Jinja filters for date and time manipulations** May 2024  Added.png     Jinja filters are now equipped to calculate days between dates and manipulate date and time data with precision. Whether streamlining workflows, scheduling tasks, or generating reports, our Jinja filters empower users to optimise efficiency and accuracy. |  | Jinja filters\_main.gif  [Master your calculations with new filters>](/knowledgebase/release-notes/release-notes-1.9/new-jinja-filters-for-date-and-time-manipulations/) |
| Line\_1.png | | |
| **API for delaying user account activation** May 2024  Added.png     Introducing our expanded APIs for user creation and editing, now featuring the new "delay\_activation" parameter. When set to true, this option creates a user without immediately sending an activation email. With this enhancement, you gain full control over user activation, empowering you to decide precisely when to send activation emails. |  | API\_users\_main.gif  [See how to use API-powered activation delays>](/knowledgebase/release-notes/release-notes-1.9/api-for-delaying-user-account-activation/) |
| Line\_1.png | | |
| **Bug fixes and improvements** May 2024  Fixed.png     This release focuses on three key areas to make things more stable, user-friendly, and secure. We upgraded Django to version 4.2 LTS, giving our entire system a sturdier base for future improvements. We have fixed over 25 bugs across the user interface and Sequencer, ensuring a smoother experience. We implemented a history database backup solution, adding an extra layer of security to your data. |  | fixes\_main.gif  [Discover performance & stability boosts >](/knowledgebase/release-notes/release-notes-1.9/bug-fixes-and-improvements/) |
| Line\_1.png | | |

---

---
url: >-
  /knowledgebase/system-configuration/object-classes/object-class-field-types-uses-and-attributes.md
---

# Object class field types: uses and attributes

All Object class fields must have:

* a **Label**; this is the field name
* an **Alias**; this is used for distinguishing the field in data and analytics ie for reporting purposes; it is also used in merge fields and in API requests and responses
* a **Type**; this will determine how it is presented and what data can be captured in it

## Field types summary

There are a number of different types of field which can be configured. These can be summarised as follows:

* **Text** - Essentially a freeform field which will allow the User to enter alpha numeric values and symbols. This field type is useful for capturing undefined data but not recommended for use in management reports. Validation allows you to specify a maximum character length.
* **Integer** - Used to capture data in whole numbers. Note that zero at the start of a number will be removed so this field type is not recommended for capturing bank account numbers or phone numbers (we have a Phone field type for that). Validation allows you to set a Minimum and Maximum value.
* **Decimal** - Used to capture numbers with a decimal place. Note however, that zeros after a decimal place are removed. Validation allows you to set a Minimum and Maximum value.
* **Checkbox** - A useful field type for capturing acknowledgement, affirmation, confirmation or acceptance of statements. Examples: “Acceptance of Terms”, “I dispute the amount shown on the claim form”, “Consent to act as Director”, "Worked for us previously”.
* **Single select** - Used to present a list of options from which only one must be chosen eg Term, Sector and Status or any other data with pre-determined options. You can choose to present this list as radio buttons or a dropdown list.
* **Multi select** - Similar to Single select but presents a checkbox list of options from which more than one selection can be made. Used to capture information such as "Risks", "Pre-existing conditions", "Equipment" or more than one option from any list of choices. Validation allows you to set Minimum and Maximum selections allowed.
* **Email** - Used to record email addresses. Catalyst will look for email address format (<prefix@domain.xx>) eg no spaces, including an @ symbol, dot (.), etc. A unique value can be forced in the context of the Object class.
* **Phone** - Used to record telephone numbers but these do not have to be in phone format (ie with the preceding country code, without the initial 0 and without spaces). Again, a unique value can be forced in the context of the Object class.
* **Date** - Used to record dates. A calendar is presented to the user from which a date can be selected. Alternatively, the date can be typed into the field. A Today option is provided which will populate today's date.
* **Date/Time** - Records date and times together in one field. Useful for appointments, events, etc. A Now option is provided which will populate today's date/current time. 12 and 24 hour clock formats are available depending on the User's preferences.
* **Time** - Used to record time in either 12 hour format with AM and PM options or 24 hour format, depending on the User's preferences. Has a "Now" feature which will record the current time.

|  |  |
| --- | --- |
| A time field presents in 24 hour format when the User's language preference is English (UK):  ![current\_time.jpg](../../../images2/zendesk_5965716856861_001_3303600b0ac3.jpg) | A time field presents in 12 hour format with AM and PM options when the User's language preference is English (USA):  ![mceclip0.png](../../../images2/zendesk_5965716856861_002_41cebcfc2d2c.png) |

* **Document** - Used to upload documents. A maximum of 100 files can be uploaded to one document field. In the field configuration you can set the maximum number of files allowed. Initially in the upload view the maximum number of files will be shown and as files are uploaded to the field the number will count down.

|  |  |
| --- | --- |
| ![mceclip2.png](../../../images2/zendesk_5965716856861_003_22131d064f63.png) | ![mceclip3.png](../../../images2/zendesk_5965716856861_004_fb4a70710903.png) |

* **User** - This field can be configured to include up to 100 individual users and 10 user groups (each of which can contain up to 1,000,000 users). Users with a 1-time completion account can be added.

## Configure the User field

To configure the User field, click into the field in the Selection Options section.

The Users tab is displayed as the default. Users will be listed in alphabetical order by First Name.

![](../../../images2/zendesk_5965716856861_005_f42ea2d8e67c.png)

|  |  |
| --- | --- |
| If you stay on the default "User" tab, you will be able to select the required users by clicking on their tile(s).  They will be marked as "Already selected".  Screenshot 2025-01-30 at ![17.36.35.png](../../../images2/zendesk_5965716856861_006_23d2603642aa.png)  Click out of the modal. The avatars of the first five added users appear followed by a generic avatar for additional users. When this icon is clicked, the details of those users will be displayed.  Screenshot 2025-01-30 at ![17.45.28.png](../../../images2/zendesk_5965716856861_007_54d52b5d14fc.png)  Alongside the avatars, an Edit link is provided. Clicking this will allow you to remove any users added in error.  Screenshot 2025-01-30 at ![17.51.52.png](../../../images2/zendesk_5965716856861_008_6d8c38afd86c.png)  The Minimum and Maximum selections can be set to restrict the number of selections on the record create/edit forms. | If you move to the User groups tab, you can select up to 10 User groups by clicking on their tile(s).  They will be marked as "Already selected".  Screenshot 2025-01-30 at ![17.59.42.png](../../../images2/zendesk_5965716856861_009_766b4e2b6d69.png)   Click out of the modal. The user group avatars will be displayed to the far left ie before the individual user avatars.  Screenshot 2025-01-30 at ![18.07.56.png](../../../images2/zendesk_5965716856861_010_a967a17b33a5.png)     If the Edit link is clicked, the user groups will be at the top of the list. Again, any added in error can be removed.  When you select User Groups in a Class User Field, you need to decide how end users will interact with them. You can enable one or both of these options:   - **Allow Syncing Group Members**: Selecting this option means that end users can choose the entire group as a single entity. The group’s members will be automatically synchronised whenever the group is utilised, ensuring that no one is left out. - **Allow Selecting Individual Members**: With this option, end users can select specific members from the group, providing more granular control over who is in selected.   Again, the minimum and maximum number of groups allowed for selection can be set. |

Click **Add** to save the field configuration. A green success toast message will confirm the save and the field will be added to the top of the Fields tab on the Object class.

**On the create/edit record forms**, the Minimum and Maximum selections allowed is shown for both groups and users.

![](../../../images2/zendesk_5965716856861_011_ed8421d30650.png)

When the end User clicks into the field they can type to search for a user or group, or scroll down the list and click on users/groups to select them.

![](../../../images2/zendesk_5965716856861_012_c2e24206a55c.png)

Having made selections, if these do not match the minimum requirements, the on-screen validation will show this and the Save button will remain disabled.

![](../../../images2/zendesk_5965716856861_013_5261a2d52112.png)

If user group selection was configured on the field with "**Allow syncing group members**" enabled, and the end User selects a group, a second model will display as below. Enable **Sync group members**.

![](../../../images2/zendesk_5965716856861_014_62c92e849070.png)

|  |  |
| --- | --- |
| This will select all members of the group and the synced icon will appear on the user group tile. | ![Screenshot 2025-02-05 at 17.50.07.png](../../../images2/zendesk_5965716856861_015_972516733f9a.png) |

The icons of selected user groups will appear to the left of individual user icons on the record field.

![](../../../images2/zendesk_5965716856861_016_73400ff7c10a.png)

If user group selection was configured on the field with "**Allow selecting individual members**" enabled and "Allow Syncing Group Members" was disabled, when a user group is selected, the end User will be able to select individual members from the group.

![](../../../images2/zendesk_5965716856861_017_ab2b79ed8087.png)

The avatars of these users will appear as they normally would for any individual user.

![](../../../images2/zendesk_5965716856861_018_9de26f554e72.png)

If a User has been selected on a Record form and is subsequently deleted from the system their avatar will be removed and replaced by the +1 avatar which when clicked on will show the ID of the deleted User.

Following deletion of a User who had been one of the available selections in a User field, the Edit field mode will show a warning to inform the Administrator that a User has been deleted.

|  |  |  |
| --- | --- | --- |
| ![Screenshot 2024-06-12 at 12.39.37.png](../../../images2/zendesk_5965716856861_019_70ba8c039369.png) | ![Screenshot 2024-06-12 at 12.40.12.png](../../../images2/zendesk_5965716856861_020_9fd4f4a899b1.png) | ![Screenshot 2024-06-12 at 12.52.35.png](../../../images2/zendesk_5965716856861_021_de5d5e9f3b04.png) |

* **URL** - Used to capture URLs for websites, forms, etc. This field has front-end validation which means that the form will not save if the entry does not contain the correct format.

![Screenshot 2024-06-11 at 20.31.40.png](../../../images2/zendesk_5965716856861_022_6e8d21971f9b.png)

|  |  |
| --- | --- |
| In record edit mode, card view and summary view, the URL field presents as a clickable link. The page will open in a new tab on your browser. | ![Screenshot 2024-06-11 at 20.36.59.png](../../../images2/zendesk_5965716856861_023_c62f6769cbf7.png) |

* **JSON** - Allows you to store complex data structures within a single field. On the record form the field displays with a beauty JSON icon which will format it making the data easier to read.

![Json\_article.gif](../../../images2/zendesk_5965716856861_024_2904055a1218.gif)

## Field attributes overview

The below table provides an overview of field attributes for each each field type.

|  |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- |
| **Field type** | **Has options** | **Default Value can be set** | **Force unique value** | **Min/Max input** | **Use as Identifier** |
| **Text** | X | X | Y | Y | Y |
| **Integer** | X | Y | Y | Y | Y |
| **Decimal** | X | Y | Y | Y | X |
| **Checkbox** | X | X | X | X | X |
| **Single Select** | Y | Y | X | X | X |
| **Multi Select** | Y | X | X | Y | X |
| **Email** | X | X | Y | X | Y |
| **Phone** | X | X | Y | X | Y |
| **Date** | X | X | X | X | Y |
| **Date/Time** | X | X | X | X | Y |
| **Time** | X | X | X | X | X |
| **Document** | X | X | X | Y | X |
| **User** | Y | X | X | Y | X |
| **URL** | X | X | X | X | Y |
| **JSON** | X | X | X | X | X |

## Further notes

**Default value** - this allows you to present a default or suggested value in the field when used on Record forms and views.

|  |  |
| --- | --- |
| ![default\_value.jpg](../../../images2/zendesk_5965716856861_025_333ceaee03bd.jpg) | In the case of a Single select field, the radio button for the default option will be selected/populated.  default\_value\_2.jpg    default\_popuated.jpg |

**Unique value** - enabling this feature will ensure that no two Records in the Object class can have the same value in the field. It acts as a de-duplication tool. If a User enters a value which already exists on another Record and tries to Create/Save the Record an error is shown against the field and the Duplicate values warning modal is displayed:

|  |  |
| --- | --- |
| ![mceclip3.png](../../../images2/zendesk_5965716856861_028_1d4710edac9d.png) | ![mceclip4.png](../../../images2/zendesk_5965716856861_029_744f3010ae6f.png) |

**Min/Max input** will differ dependent on the field type. So for instance, in a Text field this relates to the number of allowed characters, in a Multi select field to the Minimum and Maximum number of selections allowed, and in a Document field to the maximum number of files allowed.

**Identifier** - only one field in an Object class can be used as the identifier. If no field is given this property the Autologyx ID Number will automatically be used as such.

![identifier.png](../../../images2/zendesk_5965716856861_030_a4cf5fccd44b.png)

The field marked Identifier will be shown in the:

* Summary view

|  |  |
| --- | --- |
| - top left hand corner of the card view | ![card\_view\_identifier.png](../../../images2/zendesk_5965716856861_031_a2004de9f77f.png) |
| - top of the Tasks, Templates, Activity log and Record access panels | ![record\_panel\_identifier.png](../../../images2/zendesk_5965716856861_032_ca09489df0b4.png) |

## Useful info

1. Single and Multi select fields can contain up to 100 options.
2. The maximum number of characters a field Label may contain is 100.
3. The maximum number of characters a field Alias may contain is 50.

---

---
url: /api/catalyst/resources/object-classes/object-class-forms.md
---
# Object Class Forms

Object Class forms are used for **viewing**, **creating**, and **updating** Object Records.

Since forms are used by Autologyx frontend, they are defined there as well. Autologyx backend provides merely
**storage** and **access** to forms. It does not validate them. It does not used them in the application backend logic.

Object Class forms can be **integrated** with the Autologyx frontend application, or they can be used as **standalone**
pages. The distinction is solely on the frontend and hence it has no impact on the backend / API implementation.

For now, each Object Class form is associated with one Object Class (this may change with the introduction of class
relations).

In the current scope this document describes only **standalone forms for creating Object Records**. It will expand as
needed.

### Permissions

Permissions for Standalone Forms can be checked

| Context        | Endpoint                              | Location                               | Available perms                            |
|----------------|---------------------------------------|----------------------------------------|--------------------------------------------|
| Any Class      | `GET /api/users/permissions/`         | `object_class_forms`                   | `list`                                     |
| Specific Class | `GET /api/object-classes/{class_id}/` | `_meta.permissions.object_class_forms` | `list`, `view`, `edit`, `create`, `delete` |

### References

* [Object Classes](/api/catalyst/resources/object-classes/object-classes)
* [Object Records](/api/catalyst/resources/object-records/object-records)

# Object Class Forms API

## POST /api/object-class-forms/

Creates new form for a given Object Class.

### Permissions

Requires `authentication` and `object_class_forms.create` permission which is `true` if `edit` perm is enabled for Object Class for which the form is being created.

### Required parameters

| Key                 | Type   | Notes                                                                                 |
|---------------------|--------|---------------------------------------------------------------------------------------|
| name                | string | Unique (case insensitive) for the given Object Class. Max length = 100 (configurable) |
| object\_class        | int    | 	                                                                                     |
| type                | enum   | For now, only "create" value is allowed.                                              |
| configuration       | json   | 	                                                                                     |

### Optional parameters

| Key                  | Type   | Notes                                                 |
|----------------------|--------|-------------------------------------------------------|
| is\_enabled           | bool   | Set to "false" if omitted.                            |
| custom\_components    | set    | Custom Components ids used in form configuration.     |

### Request example

* Headers

```
Request Method: POST
Location: /api/object-class-forms/
Authorization: JWT access_token
```

```json
{
  "name": "Simple form",
  "object_class": 235,
  "type": "create",
  "is_enabled": true,
  "configuration": <json>,
  "custom_components": [1, 2, 3]
} 
```

### Response

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| uuid              | uuid     | Automatically generated by the backend. |
| name              | string   | 	                                       |
| object\_class      | int      | 	                                       |
| type              | enum     | For now, only "create" is supported.    |
| is\_enabled        | bool     | 	                                       |
| created\_at        | datetime | 	                                       |
| created\_by        | user     | 	                                       |
| modified\_at       | datetime | 	                                       |
| modified\_by       | user     | 	                                       |
| \_meta.labels      | Object   | "object\_class": {class name}            |
| \_meta.permissions | Object   | Dict describing permissions.            |

* Status `201 CREATED`
* Body

```json
{
  "uuid": "966ab882-0120-46bc-a8e0-fe901d298063",
  "name": "Simple form",
  "object_class": 235,
  "type": "create",
  "is_enabled": true,
  "created_at": "2021-08-12T11:21:51.877690+02:00",
  "created_by": <user>,
  "modified_at": "2021-09-14T11:11:31.127734+02:00",
  "modified_by": <user>,
  "_meta": {
    "labels": {
      "object_class": "Simple matter"
    },
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "create": true,
      "delete": true,
      "object_records": {
        "create": true
      }
    }
  }
} 
```

### Restriction

1. Maximum length of form name = 100 characters.

### Errors

| Error                                            | Response code     | Message                                                                                |
|--------------------------------------------------|-------------------|----------------------------------------------------------------------------------------|
| "name" is missing                                | 400 Bad Request   | "name": \[ "This field is required." ]                                                |
| "name" is empty string                           | 400 Bad Request   | "name": \[ "This field may not be blank." ]                                           |
| "name" is null                                   | 400 Bad Request   | "name": \[ "This field may not be null." ]                                            |
| "name" has > 100 chars                           | 400 Bad Request   | "name": \[ "Ensure this field has no more than 100 characters." ]                     |
| "name" is not unique                             | 400 Bad Request   | "name": \[ "This field must be unique." ]                                             |
| "object\_class" is missing                        | 400 Bad Request   | "object\_class": \[ "This field is required." ]                                        |
| "object\_class" is null                           | 400 Bad Request   | "object\_class": \[ "This field may not be null." ]                                    |
| "object\_class" is not int                        | 400 Bad Request   | "object\_class": \[ "Incorrect type. Expected pk value, received {type}." ]            |
| Class with "object\_class" does not exist         | 400 Bad Request   | "object\_class": \[ "Invalid pk \\"{value}\\" - object class does not exist." ]        |
| User has not perm "edit" to given "object\_class" | 400 Bad Request   | "object\_class": \[ "You do not have permission to use this object class." ]           |
| "type" is missing                                | 400 Bad Request   | "type": \[ "This field is required." ]                                                |
| "type" is null                                   | 400 Bad Request   | "type": \[ "This field may not be null." ]                                            |
| "type" is not "create"                           | 400 Bad Request   | "type": \[ "\\"{value}\\" is not a valid choice." ]                                   |
| "configuration" is missing                       | 400 Bad Request   | "configuration": \[ "This field is required." ]                                       |
| "configuration" is null                          | 400 Bad Request   | "configuration": \[ "This field may not be null." ]                                   |
| Number of components > 100                       | 400 Bad Request   | "detail": \["Ensure this list has at most 100 items."]                                |
| custom\_components.component missing              | 400 Bad Request   | "custom\_components": {"component": \["This field is required."]}                      |
| custom\_components.component is empty             | 400 Bad Request   | "custom\_components": {"component": \["This field may not be blank."]}                 |
| custom\_components.component is null              | 400 Bad Request   | "custom\_components": {"component": \["This field may not be null."]}                  |
| custom\_components.component doesn't exists       | 400 Bad Request   | "custom\_components": {"component": \["Invalid pk "99900" - object does not exist."]}|
| custom\_components.component is not enabled       | 400 Bad Request   | "custom\_components": \["Custom component 1 - object not enabled.",]                   |
| Max 100 forms per class exceeded                 | 400 Bad Request   | "detail": \[ "Limit of 100 standalone forms for the class has been exceeded." ]       |
| Insufficient permissions                         | 403 Forbidden     | "detail": "You do not have permission to perform this action."                         |

## GET /api/object-class-forms/

Lists Object Class forms based on query parameters and caller permissions.

### Permissions

Requires `authentication` and `object_class_forms.list` permission which is `true` for all authenticated users.

Response contains only the forms for which the caller has `object_class.view` permission for the associated class.

### Request example

* Headers

```
Request Method: GET
Location: /api/object-class-forms/
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key               | Type     | Notes                                                                           |
|-------------------|----------|---------------------------------------------------------------------------------|
| uuid              | uuid     | 	                                                                               |
| name              | string   | 	                                                                               |
| object\_class      | int      | 	                                                                               |
| type              | enum     | Values: create, update, summary, list, etc. For now only `create` is supported. |
| is\_enabled        | bool     | 	                                                                               |
| created\_at        | datetime | 	                                                                               |
| created\_by        | user     | 	                                                                               |
| modified\_at       | datetime | 	                                                                               |
| modified\_by       | user     | 	                                                                               |
| \_meta.labels      | Object   | "object\_class": {class name}                                                    |
| \_meta.permissions | Object   | Dict describing permissions.                                                    |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 20,
  "next": null,
  "previous": null,
  "results": [
    {
      "uuid": "966ab882-0120-46bc-a8e0-fe901d298063",
      "name": "Simple form",
      "object_class": 235,
      "type": "create",
      "is_enabled": true,
      "created_at": "2021-08-12T11:21:51.877690+02:00",
      "created_by": <user>,
      "modified_at": "2021-09-14T11:11:31.127734+02:00",
      "modified_by": <user>,
      "_meta": {
        "labels": {
          "object_class": "Simple matter"
        },
        "permissions": {
            "list": true,
            "view": true,
            "edit": true,
            "create": true,
            "delete": true,
            "object_records": {
              "list": true,
              "view": true,
              "edit": true,
              "create": true,
              "delete": true
            }
        }
      }
    }
  ]
}
```

### Sorting

| Parameter       | Example                                               | Notes          |
|-----------------|-------------------------------------------------------|----------------|
| name            | {build}/api/object-class-forms/?ordering=name         | Ascending      |
| name            | {build}/api/object-class-forms/?ordering=-name        | Descending (-) |
| created\_at      | {build}/api/object-class-forms/?ordering=created\_at   | Ascending      |
| created\_at      | {build}/api/object-class-forms/?ordering=-created\_at  | Descending (-) |
| modified\_at     | {build}/api/object-class-forms/?ordering=modified\_at  | Ascending      |
| modified\_at     | {build}/api/object-class-forms/?ordering=-modified\_at | Descending (-) |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter    | Predicates        | Example                                                                   |
|--------------|-------------------|---------------------------------------------------------------------------|
| uuid         | =                 | {build}/api/object-class-forms/?uuid=f02bfc83-4342-495d-b092-f1e082f33abb |
| name         | standard string   | {build}/api/object-class-forms/?name\_\_icontains=foobar                    |
| object\_class | standard set      | {build}/api/object-class-forms/?object\_class\_\_in=3,33,333                 |
| type         | standard enum     | {build}/api/object-class-forms/?type\_\_in=create                           |
| is\_enabled   | standard Boolean  | {build}/api/object-class-forms/?is\_enabled=true                           |
| created\_at   | standard datetime | {build}/api/object-class-forms/?created\_at\_\_gte=2022-01-01                |
| created\_by   | standard set      | {build}/api/object-class-forms/?created\_by\_\_in=123,234,345                |
| modified\_at  | standard datetime | {build}/api/object-class-forms/?modified\_at\_\_range=2022-01-01,2022-01-31  |
| modified\_by  | standard set      | {build}/api/object-class-forms/?modified\_by=123                           |

### Errors

| Error                         | Response code   | Message                                                                             |
|-------------------------------|-----------------|-------------------------------------------------------------------------------------|
| Wrong ordering value          | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."] |

## GET /api/object-class-forms/`form_uuid`/

Retrieves the form.

### Permissions

Requires `authentication` and `object_class_forms.view` permission which is `true` if `view` perm is enabled for Object Class for which the form is being created.

### URL parameters

| Key                      | Type     | Notes                           |
|--------------------------|----------|---------------------------------|
| uuid                     | uuid     | 	                               |

### Request example

* Headers

```
Request Method: GET
Location: /api/object-class-forms/966ab882-0120-46bc-a8e0-fe901d298063/
Authorization: JWT access_token
```

### Response

| Key                      | Type     | Notes                        |
|--------------------------|----------|------------------------------|
| uuid                     | uuid     | 	                            |
| name                     | string   | 	                            |
| object\_class             | int      | 	                            |
| type                     | enum     | 	                            |
| is\_enabled               | bool     | 	                            |
| created\_at               | datetime | 	                            |
| created\_by               | user     | 	                            |
| modified\_at              | datetime | 	                            |
| modified\_by              | user     | 	                            |
| \_meta.labels             | Object   | "object\_class": {class name} |
| \_meta.permissions        | Object   | Dict describing permissions  |

### Response example

* Status `200 OK`
* Body

```json
{
  "uuid": "966ab882-0120-46bc-a8e0-fe901d298063",
  "name": "Simple form",
  "object_class": 235,
  "type": "create",
  "is_enabled": true,
  "created_at": "2021-08-12T11:21:51.877690+02:00",
  "created_by": <user>,
  "modified_at": "2021-09-14T11:11:31.127734+02:00",
  "modified_by": <user>,
  "_meta": {
    "labels": {
      "object_class": "Simple matter"
    },
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "create": true,
      "delete": true,
      "object_records": {
        "create": true
      }
    }
  }
}
```

### Errors

| Error                           | Response code | Message                                                        |
|---------------------------------|---------------|----------------------------------------------------------------|
| Form with "uuid" does not exist | 404 Not Found | "detail": "Not found."                                         |
| Insufficient permissions        | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## PATCH /api/object-class-forms/`form_uuid`/

Update the form.

### Permissions

Requires `authentication` and `object_class_forms.edit` permission which is `true` if `edit` perm is enabled for Object Class for which the form is being created.

### Allowed parameters

| Key                  | Type   | Notes                                                                                 |
|----------------------|--------|---------------------------------------------------------------------------------------|
| name                 | string | Unique (case insensitive) for the given Object Class. Max length = 100 (configurable) |
| is\_enabled           | bool   | 	                                                                                     |
| configuration        | json   | 	                                                                                     |
| custom\_components    | set    | Custom Components ids used in form configuration.                                     |

Any parameter not listed above are silently ignored if passed.

### Request example

* Headers

```
Request Method: PATCH
Location: /api/object-class-forms/966ab882-0120-46bc-a8e0-fe901d298063/
Authorization: JWT access_token
```

* Body

```json
{
  "name": "Simple form - modified",
  "is_enabled": false,
  "custom_components": [1, 2, 3],
}
```

### Response

| Key                   | Type     | Notes                            |
|-----------------------|----------|----------------------------------|
| uuid                  | uuid     | 	                                |
| name                  | string   | 	                                |
| object\_class          | int      | 	                                |
| type                  | enum     | 	                                |
| is\_enabled            | bool     | 	                                |
| created\_at            | datetime | 	                                |
| created\_by            | user     | 	                                |
| modified\_at           | datetime | 	                                |
| modified\_by           | user     | 	                                |
| \_meta.labels          | Object   | "object\_class": {class name}     |
| \_meta.permissions     | Object   | "object\_records": {permissions}  |

### Response example

* Status `200 OK`
* Body

```json
{
  "uuid": "966ab882-0120-46bc-a8e0-fe901d298063",
  "name": "Simple form",
  "object_class": 235,
  "type": "create",
  "is_enabled": true,
  "created_at": "2021-08-12T11:21:51.877690+02:00",
  "created_by": <user>,
  "modified_at": "2021-09-14T11:11:31.127734+02:00",
  "modified_by": <user>,
  "_meta": {
    "labels": {
      "object_class": "Simple matter"
    },
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "create": true,
      "delete": true,
      "object_records": {
        "create": true
      }
    }
  } 
```

### Errors

| Error                                      | Response code     | Message                                                                                |
|--------------------------------------------|-------------------|----------------------------------------------------------------------------------------|
| Form with "uuid" does not exist            | 404 Not Found     | "uuid": \[ "Invalid pk "{value}" - form does not exist." ]                          |
| "name" is empty string                     | 400 Bad Request   | "name": \[ "This field may not be blank." ]                                           |
| "name" is null                             | 400 Bad Request   | "name": \[ "This field may not be null." ]                                            |
| "name" has > 100 chars                     | 400 Bad Request   | "name": \[ "Ensure this field has no more than 100 characters." ]                     |
| "name" is not unique                       | 400 Bad Request   | "name": \[ "This field must be unique." ]                                             |
| "configuration" is null                    | 400 Bad Request   | "configuration": \[ "This field may not be null." ]                                   |
| Number of components > 100                 | 400 Bad Request   | "detail": \["Ensure this list has at most 100 items."]                                |
| custom\_components.component missing        | 400 Bad Request   | "custom\_components": {"component": \["This field is required."]}                      |
| custom\_components.component is empty       | 400 Bad Request   | "custom\_components": {"component": \["This field may not be blank."]}                 |
| custom\_components.component is null        | 400 Bad Request   | "custom\_components": {"component": \["This field may not be null."]}                  |
| custom\_components.component doesn't exists | 400 Bad Request   | "custom\_components": {"component": \["Invalid pk "99900" - object does not exist."]}|
| custom\_components.component is not enabled | 400 Bad Request   | "custom\_components": \["Custom component 1 - object not enabled.",]                   |
| Insufficient permissions                   | 403 Forbidden     | "detail": "You do not have permission to perform this action."                         |

## DELETE /api/object-class-forms/`form_uuid`/

Deletes the form.

### Permissions

Requires `authentication` and `object_class_forms.delete` permission which is `true` if `edit` perm is enabled for Object Class for which the form is being created.

### Request example

* Headers

```
Request Method: DELETE
Location: /api/object-class-forms/966ab882-0120-46bc-a8e0-fe901d298063/
Authorization: JWT access_token
```

### Response example

* Status `204 No Content`
* Body

### Errors

| Error                           | Response code | Message                                                         |
|---------------------------------|---------------|-----------------------------------------------------------------|
| Form with "uuid" does not exist | 404 Not Found | "detail": "Not found."                                          |
| Insufficient permissions        | 403 Forbidden | "detail": "You do not have permission to perform this action."  |

## OPTIONS  /api/object-class-forms/

### Permissions

Requires authentication only.

### Request example

* Headers

```
Request Method: OPTIONS
Location: /api/object-class-forms/
```

### Response example

* Status `200 OK`
* Body

```json
{
  "list": {
    "columns": [
      {
        "alias": "uuid",
        "type": "uuid",
        "predicates": [
          "exact"
        ],
        "sort_ok": false
      },     
      {
        "alias": "name",
        "type": "string",
        "predicates": [
          "exact",
          "iexact",
          "contains",
          "icontains",
          "startswith",
          "istartswith",
          "endswith",
          "iendswith"
        ],
        "sort_ok": true
      },
      {
        "alias": "is_enabled",
        "type": "bool",
        "predicates": [
          "exact"
        ],
        "sort_ok": false
      },
      {
        "alias": "created_at",
        "type": "datetime",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range"
        ],
        "sort_ok": true
      },
      {
        "alias": "created_by",
        "type": "user",
        "predicates": [
          "exact",
          "in"
        ],
        "sort_ok": false,
        "autocomplete": "/api/users/autocomplete/?text__icontains="
      },
      {
        "alias": "modified_at",
        "type": "datetime",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range"
        ],
        "sort_ok": true
      },
      {
        "alias": "modified_by",
        "type": "user",
        "predicates": [
          "exact",
          "in"
        ],
        "sort_ok": false,
        "autocomplete": "/api/users/autocomplete/?text__icontains="
      }
    ]
  },
  "details": {
    "schema": [
      {
        "alias": "name",
        "type": "string",
        "required": true,
        "validators": [
          {
            "type": "max_length",
            "length": 100
          }
        ]
      },
      {
        "alias": "type",
        "type": "enum",
        "required": true,
        "validators": [
          {
            "value": "create",
            "text": "Create Object Record"
          }
        ]
      },
      {
        "alias": "is_enabled",
        "type": "bool",
        "required": false
      }
    ]
  },
  "restrictions": {
    "limit_items_in_object_class": 100
  }
} 
```

---

---
url: /api/catalyst/resources/object-classes/object-class-mcp-connectors.md
---
# Object Class MCP Connectors

This document describes the API for retrieving the [MCP Connectors](../mcp/mcp-connectors) associated with an
Object Class.

An MCP Connector is a registered external client of the MCP server. Object Classes can be associated with a
connector so that they are available for permission configuration for the connector. This endpoint lists the
connectors associated with a selected Object Class.

> :information\_source: In the scope of this story, associating Object Classes with a connector does **not** affect
> user access through MCP. That behaviour is a separate, future story.

The endpoint is nested under an Object Class (nested routers) and uses the standard limit/offset pagination,
sorting and filtering mechanisms.

## Permissions

| Endpoint                                                | Permission                                                    |
|---------------------------------------------------------|--------------------------------------------------------------|
| GET `/api/object-classes/{class_id}/mcp-connectors/`    | `view` permission for the Object Class `class_id`            |

The caller must have the `view` permission for the Object Class `class_id`, either globally on the
`object_classes` resource or per-object. The `list` permission alone (without `view`) is not sufficient.

## GET /api/object-classes/`class_id`/mcp-connectors/

Returns the list of MCP Connectors associated with the Object Class.

### Permissions

Requires `authentication` and `object_classes.view` permission for the Object Class `class_id`.

### URL parameters

| Key      | Type | Notes           |
|----------|------|-----------------|
| class\_id | int  | Object Class ID |

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key            | Type       | Notes                                                           |
|----------------|------------|-----------------------------------------------------------------|
| limit          | int        |                                                                 |
| offset         | int        |                                                                 |
| total\_count    | int        | Total number of MCP Connectors associated with the Object Class. |
| filtered\_count | int        | Number of associated MCP Connectors with filters applied.       |
| next           | URL / null | Next page URL (null if there is no next page)                   |
| previous       | URL / null | Previous page URL (null if there is no previous page)           |
| results        | Array      | Described in the next table.                                    |

#### Response `results` array

| Key                       | Type   | Notes                |
|---------------------------|--------|----------------------|
| id                        | int    | MCP Connector ID     |
| name                      | string | MCP Connector name   |
| integration               | uuid   | Integration ID       |
| \_meta.labels.integration  | Object  | Integration details  |

Results are sorted by `id` ascending by default.

### Response example

* Status `200 OK`
* Body

```json
{
    "limit": 100,
    "offset": 0,
    "filtered_count": 2,
    "total_count": 2,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": 5,
            "name": "Claude connector",
            "integration": "b08cec76-030b-494c-b987-0692a9946892",
            "_meta": {
                "labels": {
                    "integration": {
                        "name": "Claude",
                        "type": "anthropic_claude",
                        "category": "ai_mcp"
                    }
                }
            }
        },
        {
            "id": 16,
            "name": "Claude - analytics",
            "integration": "b08cec76-030b-494c-b987-0692a9946892",
            "_meta": {
                "labels": {
                    "integration": {
                        "name": "Claude",
                        "type": "anthropic_claude",
                        "category": "ai_mcp"
                    }
                }
            }
        }
    ]
}
```

### Sorting

| Parameter | Example                                                              | Notes          |
|-----------|---------------------------------------------------------------------|----------------|
| id        | {build}/api/object-classes/{class\_id}/mcp-connectors/?ordering=id     | Ascending      |
| id        | {build}/api/object-classes/{class\_id}/mcp-connectors/?ordering=-id    | Descending (-) |
| name      | {build}/api/object-classes/{class\_id}/mcp-connectors/?ordering=name   | Ascending      |
| name      | {build}/api/object-classes/{class\_id}/mcp-connectors/?ordering=-name  | Descending (-) |

### Filtering

| Parameter | Predicates      | Example                                                                     |
|-----------|-----------------|-----------------------------------------------------------------------------|
| id        | standard numeric | {build}/api/object-classes/{class\_id}/mcp-connectors/?id\_\_gt=10             |
| name      | standard string  | {build}/api/object-classes/{class\_id}/mcp-connectors/?name\_\_icontains=foo   |

Standard numeric predicates for `id`: `=`, `gt`, `gte`, `lt`, `lte`, `range` (e.g. `id`, `id__gt`, `id__lt`, `id__range`).
Standard string predicates for `name`: `=`, `iexact`, `contains`, `icontains`, `startswith`, `istartswith`, `endswith`, `iendswith` (e.g. `name`, `name__icontains`, `name__istartswith`).

### Errors

| Error                                            | Response code    | Message                                                        |
|--------------------------------------------------|------------------|----------------------------------------------------------------|
| Not authenticated                                | 401 Unauthorized | "detail": "Authentication credentials were not provided."      |
| Caller lacks `view` permission for the Object Class | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| `class_id` does not exist                        | 404 Not Found    |                                                                |

---

---
url: /api/catalyst/resources/object-classes/object-class-owners.md
---
# Object Class Owners

This documentation describes API for Object Class Owners.

# Object Class Owners API

## POST /api/object-classes/`class_id`/owners/

Creates Object Class Owner relations.

### Permissions

Requires `authentication` and any of

1. `object_classes.edit_owners` permission
2. Object Class Ownership

### URL parameters

| Key      | Notes           |
|----------|-----------------|
| class\_id | Object Class id |

### Request example

* Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

### Body

| Key | Type | Required | Notes          |
|-----|------|----------|----------------|
| -   | list | True     | Owner ids list |

### Validations

* Maximum number of Owners per specific Object Class: 100.
* Maximum number of Owners in batch: 100.
* User is validated by account type, `one_time_completion` account cannot be owner.

### Sample request body

POST /api/object-classes/1/owners/

```json

[25]

```

### Response

| Key        | Type     | Notes                                     |
|------------|----------|-------------------------------------------|
| id         | int      | Automatically generated by the backend. 	 |
| name       | string   |                                           |
| user       | user     |                                           |
| created\_at | datetime |                                           |
| created\_by | user     |                                           |

* Response `user` and `created_by` object

| Key          | Type   | Notes                                     |
|--------------|--------|-------------------------------------------|
| id           | int    | Automatically generated by the backend. 	 |
| username     | string |                                           |
| first\_name   | string |                                           |
| last\_name    | string |                                           |
| account\_type | string |                                           |
| company\_name | string |                                           |
| is\_deleted   | bool   |                                           |

* Successful status 201 Created
* Response body schema

```json
{
  "id": 876,
  "user":
  {
    "id": 25,
    "first_name": "John",
    "last_name": "Smith",
    "username": "john.smith@autologyx.com",
    "company_name": "",
    "is_deleted": false,
    "account_type": "super_admin"
  },
  "created_at": "2023-07-17T12:56:54.161206+02:00",
  "created_by":
  {
    "id": 655,
    "first_name": "Ann",
    "last_name": "Jackson",
    "username": "ann.jackson@autologyx.com",
    "company_name": "",
    "is_deleted": false,
    "account_type": "super_admin"
  }
}

```

### Errors

| Cause                                                                                      | Response code      | Message                                                                                                      |
|--------------------------------------------------------------------------------------------|--------------------|--------------------------------------------------------------------------------------------------------------|
| class\_id is invalid                                                                        | 404 Not Found      |                                                                                                              |
| list contains item of wrong type                                                           | 400 Bad Request    | "detail": \["Incorrect type. Expected pk value, received str."]                                               |
| list in body is empty                                                                      | 400 Bad Request    | "detail": \["This list may not be empty."]                                                                    |
| owner has wrong type                                                                       | 400 Bad Request    | "detail": \["1 Time Completion account cannot be owner."]                                                     |
| batch size is above the limit                                                              | 400 Bad Request    | "detail": \["Up to 100 items allowed."]                                                                       |
| object record owners is above the limit                                                    | 400 Bad Request    | "detail": \["Limit of 100 Object Record Owners has been exceeded."]                                           |
| Request user does not have "users.list" permission for some users passed in the payload    | 400 Bad Request    | “detail”: \["You do not have permission to assign user "{user\_id}" as an owner of class "{class\_id}"."]       |
| insufficient permissions	                                                                  | 403 Forbidden      | "detail": "You do not have permission to perform this action."                                               |

## GET /api/object-classes/`class_id`/owners/

Returns list of Object Class Owners.

### Permissions

Requires any of permissions

1. `object_classes.view` permission (for individual Object Class)
2. Object Class Ownership

### URL parameters

| Key      | Notes            |
|----------|------------------|
| class\_id | Object Class id  |

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

### Response `results` array

| Key        | Type     | Notes                                     |
|------------|----------|-------------------------------------------|
| id         | int      | Automatically generated by the backend. 	 |
| user       | object   |                                           |
| created\_at | datetime |                                           |
| created\_by | user     |                                           |

* Successful status `200 OK`
* Response body schema

```json
{
  "limit":50,
  "offset":0,
  "filtered_count":1,
  "total_count":1,
  "next":null,
  "previous":null,
  "results":[
    {
      "id":22,
      "created_at":"2023-07-10T09:28:27.679165+02:00",
      "created_by": 
        {
         "id":42,
          "first_name":"John",
          "last_name":"Smith",
          "username":"john.smith@example.test",
          "company_name":"autologyx",
          "is_deleted":false
        },
      "user":
        {
          "id":641,
          "first_name":"sample first name",
          "last_name":"sample last name",
          "username":"test.autologyx@example.test",
          "company_name":"autologyx",
          "is_deleted":false
        }
    }]}

```

### Errors

| Cause                        | Response code   | Message                                                        |
|------------------------------|-----------------|----------------------------------------------------------------|
| class\_id is invalid          | 404 Not Found   |                                                                |
| Insufficient permissions	    | 403 Forbidden   | "detail": "You do not have permission to perform this action." |

## GET /api/object-classes/`class_id`/owners/`owner_id`/

Returns a single Object Class Owner.

### Permissions

Requires any of permissions

1. `object_classes.view` permission (for individual Object Class)
2. Object Class Ownership

### URL parameters

| Key      | Notes            |
|----------|------------------|
| class\_id | Object Class id  |
| owner\_id | Object Owner id  |

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key        | Type     | Notes                                     |
|------------|----------|-------------------------------------------|
| id         | int      | Automatically generated by the backend. 	 |
| user       | object   |                                           |
| created\_at | datetime |                                           |
| created\_by | user     |                                           |

* Successful status `200 OK`
* Response body schema

```json
{
  "id": 22,
  "created_at": "2023-07-10T09:28:27.679165+02:00",
  "created_by": {
    "id": 42,
    "first_name": "John",
    "last_name": "Smith",
    "username": "john.smith@example.test",
    "company_name": "autologyx",
    "is_deleted": false
  },
  "user": {
    "id": 641,
    "first_name": "sample first name",
    "last_name": "sample last name",
    "username": "test.autologyx@example.test",
    "company_name": "autologyx",
    "is_deleted": false
  }
}
```

### Errors

| Cause                     | Response code   | Message                                                        |
|---------------------------|-----------------|----------------------------------------------------------------|
| class\_id is invalid       | 404 Not Found   |                                                                |
| owner\_id is invalid       | 404 Not Found   |                                                                |
| Insufficient permissions	 | 403 Forbidden   | "detail": "You do not have permission to perform this action." |

## DELETE /api/object-classes/`class_id`/owners/`onwer_id`/

Delete a single Object Class Owner.

### Permissions

Requires any of permissions

1. `object_classes.edit_owners` permission
2. Object Class Ownership

### URL parameters

| Key       | Notes            |
|-----------|------------------|
| class\_id  | Object Class id  |
| owner\_id  | Object Owner id  |

### Request example

* Headers

```
Request Method: DELETE
Content-Type: application/json
Authorization: JWT access_token
```

### Response

* Successful status `204 No Content`

### Errors

| Cause                       | Response code   | Message                                                        |
|-----------------------------|-----------------|----------------------------------------------------------------|
| class\_id is invalid         | 404 Not Found   |                                                                |
| owner\_id is invalid         | 404 Not Found   |                                                                |
| Insufficient permissions	   | 403 Forbidden   | "detail": "You do not have permission to perform this action." |

## OPTIONS /api/object-classes/`class_id`/owners/

### Permissions

Requires `authentication` only.

### URL parameters

| Key       | Notes            |
|-----------|------------------|
| class\_id  | Object Class id  |

### Request example

* Headers

```
Request Method: DELETE
Content-Type: application/json
Authorization: JWT access_token
```

### Response example

* Status `200 OK`
* Body

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "user",
                "type": "user",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [],
                "sort_ok": false
            }
        ]
    },
    "batch": {
        "type": "set",
        "required": true,
        "autocomplete": "/api/users/autocomplete/?account_type!=one_time_completion&text__icontains="
    },
    "restrictions": {
        "limit_items": 100,
        "limit_items_in_batch": 100
    }
}
```

---

---
url: /knowledgebase/system-configuration/object-class-relationships.md
---
# Object Class Relationships

**Browse the sections below:**

* [Configuring Relationships In Object Classes](/knowledgebase/system-configuration/object-class-relationships/configuring-relationships-in-object-classes/)

---

---
url: /api/catalyst/resources/object-classes/object-classes.md
---
# Object Classes

This technical design describes implementation and API for Object Classes.

## POST /api/object-classes/

Creates object class.

### Permissions

Requires `authentication` and `object_classes.create` permission.

### Request

* Body parameters

| Key                   | Type   | Notes                                       |
|-----------------------|--------|---------------------------------------------|
| name                  | string |                                             |
| description           | string |                                             |
| display\_configuration | Json   | UI configuration                            |
| custom\_components     | Json   | Custom Components used in UI configuration. |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/object-classes/

{
    "name": "class_name",
    "description": "Some class description",
    "display_configuration": {"key": "value"},
    "custom_components": [
      {"component_id": 1, "used_in": "object_class_create_forms" }, 
      {"component_id": 2, "used_in": "object_class_summary_forms" }
    ]
}
```

### Validations

* name
  * is string
  * is required
  * is unique
  * max length is 100
  * first sign of name must be a letter.
* description
  * is string
  * is optional
  * max length is 500
* display\_configuration
  * is a Json
  * is optional
  * has not duplicated keys
* custom\_components
  * is a Json
  * is optional
  * component\_id
    * is integer
    * is required
    * is a valid component id
  * used\_in
    * is string
    * is required
    * is a valid form type

### Restrictions

* Up to 10000 Object Classes can be added, limit is configurable per build.

### Response

| Key                   | Type     | Notes                                                           |
|-----------------------|----------|-----------------------------------------------------------------|
| id                    | pk       | Automatically generated by the backend.                         |
| name                  | string   | Name of the object class                                        |
| description           | string   | Description of the object class                                 |
| identifier            | Object   | Object record identifier                                        |
| display\_configuration | Json     | Object class UI configuration                                   |
| created\_at            | datetime |                                                                 |
| created\_by            | user     |                                                                 |
| modified\_at           | datetime |                                                                 |
| modified\_by           | user     |                                                                 |
| record\_count          | int      | Number of records for a given Object Class                      |
| object\_models         | Array    | List of Object Models ids in which a given class is used        |
| \_meta.permissions     | Object   | Object describing permissions.                                  |

### Response `identifier` object

| Key            | Type   | Notes      |
|----------------|--------|------------|
| id             | pk     |            |
| label          | string |            |
| alias          | string |            |
| type           | enum   | Field type |
| is\_unique      | bool   |            |
| is\_identifier  | bool   |            |
| has\_duplicates | bool   |            |
| order          | int    |            |
| extras         | Json   |            |

* Successful status `201 Created`
* Response body:

```json
{
    "id": 18,
    "name": "class_name",
    "description": "Some class description",
    "identifier": {
        "id": null,
        "label": "ALX ID",
        "alias": "id",
        "type": "int",
        "is_unique": false,
        "is_identifier": false,
        "has_duplicates": false,
        "order": null,
        "extras": {}
    },
    "display_configuration": {
        "key": "value"
    },
    "created_at": "2023-08-23T14:52:14.172073+02:00",
    "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_at": "2023-08-23T14:52:14.172098+02:00",
    "modified_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "record_count": 0,
    "object_models": [],
    "_meta": {
        "permissions": {
            "list": true,
            "view": true,
            "create": true,
            "edit": true,
            "delete": true,
            "edit_owners": true,
            "edit_perm_sets": true,
            "object_records": {
                "create": true
            },
            "object_class_forms": {
                "list": true,
                "view": true,
                "edit": true,
                "create": true,
                "delete": true
            }
        }
    }
}
```

### Errors

| Cause                                      | Response status code | Response message                                                                       |
|--------------------------------------------|----------------------|----------------------------------------------------------------------------------------|
| name missing                               | 400 Bad Request      | "name": \["This field is required."]                                                  |
| name is empty                              | 400 Bad Request      | "name": \[ "This field may not be blank." ]                                           |
| name is null                               | 400 Bad Request      | "name": \[ "This field may not be null." ]                                            |
| name not unique                            | 400 Bad Request      | "name": \["This field must be unique."]                                               |
| name too long                              | 400 Bad Request      | "name": \["Ensure this field has no more than 100 characters."]                       |
| first sign not a letter                    | 400 Bad Request      | "name": \["First sign of name must be a letter."]                                     |
| description too long                       | 400 Bad Request      | "description": \["Ensure this field has no more than 500 characters."]                |
| description is null                        | 400 Bad Request      | "description": \["This field may not be null."]                                       |
| key is duplicated                          | 400 Bad Request      | "display\_configuration": \["JSON key "key" is duplicated."]                         |
| template\_file is null                      | 400 Bad Request      | "template\_file": \[ "This field may not be null." ]                                   |
| template\_file not docx                     | 400 Bad Request      | "template\_file": \["Invalid file type."]                                              |
| custom\_components.component missing        | 400 Bad Request      | "custom\_components": {"component": \["This field is required."]}                      |
| custom\_components.component is empty       | 400 Bad Request      | "custom\_components": {"component": \["This field may not be blank."]}                 |
| custom\_components.component is null        | 400 Bad Request      | "custom\_components": {"component": \["This field may not be null."]}                  |
| custom\_components.component doesn't exists | 400 Bad Request      | "custom\_components": {"component": \["Invalid pk "99900" - object does not exist."]}|
| Insufficient permissions                   | 403 Forbidden        | "detail": "You do not have permission to perform this action."                         |

## OPTIONS /api/object-classes/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Request Method: OPTIONS
Content-Type: application/json
Location: /api/object-classes/
Authorization: JWT access_token
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "name",
                "type": "string",
                "predicates": [
                    "exact",
                    "iexact",
                    "contains",
                    "icontains",
                    "startswith",
                    "istartswith",
                    "endswith",
                    "iendswith"
                ],
                "sort_ok": true
            },
            {
                "alias": "description",
                "type": "string",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "modified_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "modified_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "owners",
                "type": "owners",
                "predicates": [
                    "exact",
                    "in",
                    "isnull"
                ],
                "sort_ok": false
            },
            {
                "alias": "record_count",
                "type": "int",
                "predicates": [],
                "sort_ok": false
            }
        ]
    },
    "details": {
        "schema": [
            {
                "alias": "name",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "min_length",
                        "length": 1
                    },
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "description",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 500
                    }
                ]
            }
        ]
    },
    "restrictions": {
        "limit_items": 10000
    }
}
```

## GET /api/object-classes/

Returns list of Object Classes.

### Permissions

Requires `authentication` and `object_classes.list` permission.

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Location: /api/object-classes/
Authorization: JWT access_token
```

### Response

| Key               | Type   | Notes                                                                              |
|-------------------|--------|------------------------------------------------------------------------------------|
| limit             | int    |                                                                                    |
| offset            | int    |                                                                                    |
| total\_count       | int    | Total number of results visible to the user (based on permissions).                |
| filtered\_count    | int    | Number of results visible to the user (based on permissions) with filters applied. |
| next              | url    | Next page URL (null if there is no next page)                                      |
| previous          | url    | Previous page URL (null if there is no previous page)                              |
| results           | Array  | List of results. Described in the next table.                                      |

### Response `results` array

| Key                   | Type     | Notes                                      |
|-----------------------|----------|--------------------------------------------|
| id                    | pk       | Automatically generated by the backend.    |
| name                  | string   | Name of the object class                   |
| description           | string   | Description of the object class            |
| created\_at            | datetime |                                            |
| created\_by            | user     |                                            |
| modified\_at           | datetime |                                            |
| modified\_by           | user     |                                            |
| record\_count          | int      | Number of records for a given Object Class |
| has\_system\_fields     | bool     |                                            |
| owners                | Object   |                                            |
| \_meta.permissions     | Object   |                                            |

### Response `owners` object

| Key          | Type | Notes      |
|--------------|------|------------|
| total\_number | int  |            |
| first        | user |            |

* Successful status `200 OK`
* Response body schema

```json
{
    "limit": 50,
    "offset": 0,
    "filtered_count": 2,
    "total_count": 2,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": 17,
            "name": "123456",
            "description": "",
            "created_at": "2022-11-10T14:32:14.645313+01:00",
            "created_by": {
                "id": 2,
                "first_name": "ALX",
                "last_name": "Developer",
                "username": "alx.dev@autologyx.com",
                "company_name": "",
                "is_deleted": false,
                "account_type": "super_admin"
            },
            "modified_at": "2022-11-10T14:32:14.645340+01:00",
            "modified_by": {
                "id": 2,
                "first_name": "ALX",
                "last_name": "Developer",
                "username": "alx.dev@autologyx.com",
                "company_name": "",
                "is_deleted": false,
                "account_type": "super_admin"
            },
            "has_system_fields": false,
            "owners": {
                "total_number": 1,
                "first": {
                    "id": 2,
                    "first_name": "ALX",
                    "last_name": "Developer",
                    "username": "alx.dev@autologyx.com",
                    "company_name": "",
                    "is_deleted": false,
                    "account_type": "super_admin"
                }
            },
            "record_count": 0,
            "_meta": {
                "permissions": {
                    "list": true,
                    "view": true,
                    "create": true,
                    "edit": true,
                    "delete": true,
                    "edit_owners": true,
                    "edit_perm_sets": true
                }
            }
        },
        {
            "id": 18,
            "name": "class_name",
            "description": "Some class description",
            "created_at": "2023-08-23T14:52:14.172073+02:00",
            "created_by": {
                "id": 2,
                "first_name": "ALX",
                "last_name": "Developer",
                "username": "alx.dev@autologyx.com",
                "company_name": "",
                "is_deleted": false,
                "account_type": "super_admin"
            },
            "modified_at": "2023-08-23T14:52:14.172098+02:00",
            "modified_by": {
                "id": 2,
                "first_name": "ALX",
                "last_name": "Developer",
                "username": "alx.dev@autologyx.com",
                "company_name": "",
                "is_deleted": false,
                "account_type": "super_admin"
            },
            "has_system_fields": true,
            "owners": {
                "total_number": 1,
                "first": {
                    "id": 2,
                    "first_name": "ALX",
                    "last_name": "Developer",
                    "username": "alx.dev@autologyx.com",
                    "company_name": "",
                    "is_deleted": false,
                    "account_type": "super_admin"
                }
            },
            "record_count": 10,
            "_meta": {
                "permissions": {
                    "list": true,
                    "view": true,
                    "create": true,
                    "edit": true,
                    "delete": true,
                    "edit_owners": true,
                    "edit_perm_sets": true
                }
            }
        }
    ]
}
```

### Sorting

| Parameter     | Example                                    | Notes          |
|---------------|--------------------------------------------|----------------|
| id            | /api/object-classes/?ordering=id           | Ascending      |
| id            | /api/object-classes/?ordering=-id          | Descending (-) |
| name          | /api/object-classes/?ordering=name         | Ascending      |
| name          | /api/object-classes/?ordering=-name        | Descending (-) |
| created\_at    | /api/object-classes/?ordering=created\_at   | Ascending      |
| created\_at    | /api/object-classes/?ordering=-created\_at  | Descending (-) |
| modified\_at   | /api/object-classes/?ordering=modified\_at  | Ascending      |
| modified\_at   | /api/object-classes/?ordering=-modified\_at | Descending (-) |

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter   | Type     |
|-------------|----------|
| id          | int      |
| name        | string   |
| created\_at  | datetime |
| created\_by  | user     |
| modified\_at | datetime |
| modified\_by | user     |
| owners      | user     |

## GET /api/object-classes/`id`

Returns single Object Class by `id`.

### Permissions

Requires `authentication` and `object_classes.view` permission.

### URL parameters

| Key                      | Type     | Notes |
|--------------------------|----------|-------|
| id                       | id       |       |

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Location: /api/object-classes/18/
Authorization: JWT access_token
```

### Response

| Key                   | Type     | Notes                                                    |
|-----------------------|----------|----------------------------------------------------------|
| id                    | pk       | Automatically generated by the backend.                  |
| name                  | string   | Name of the object class                                 |
| description           | string   | Description of the object class                          |
| identifier            | Object   | Object record identifier                                 |
| display\_configuration | Json     | Object class UI configuration                            |
| created\_at            | datetime |                                                          |
| created\_by            | user     |                                                          |
| modified\_at           | datetime |                                                          |
| modified\_by           | user     |                                                          |
| record\_count          | int      | Number of records for a given Object Class               |
| object\_models         | Array    | List of Object Models ids in which a given class is used |
| has\_system\_fields     | bool     |                                                          |
| \_meta.permissions     | Object   | Object describing permissions.                           |

### Response `identifier` object

| Key            | Type   | Notes      |
|----------------|--------|------------|
| id             | pk     |            |
| label          | string |            |
| alias          | string |            |
| type           | enum   | Field type |
| is\_unique      | bool   |            |
| is\_identifier  | bool   |            |
| has\_duplicates | bool   |            |
| order          | int    |            |
| description    | string |            |
| extras         | Json   |            |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": 18,
    "name": "class_name",
    "description": "Some class description",
    "identifier": {
        "id": null,
        "label": "ALX ID",
        "alias": "id",
        "type": "int",
        "is_unique": false,
        "is_identifier": false,
        "has_duplicates": false,
        "order": null,
        "description": "",
        "extras": {}
    },
    "display_configuration": {
        "key": "value"
    },
    "created_at": "2023-08-23T14:52:14.172073+02:00",
    "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_at": "2023-08-23T14:52:14.172098+02:00",
    "modified_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "has_system_fields": false,
    "record_count": 0,
    "object_models": [],
    "_meta": {
        "permissions": {
            "list": true,
            "view": true,
            "create": true,
            "edit": true,
            "delete": true,
            "edit_owners": true,
            "edit_perm_sets": true,
            "object_records": {
                "create": true
            },
            "object_class_forms": {
                "list": true,
                "view": true,
                "edit": true,
                "create": true,
                "delete": true
            }
        }
    }
}
```

### Errors

| Error                             | Response code | Message                                                        |
|-----------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions          | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Sequence with "id" does not exist | 404 Not Found | "detail": "Not found."                                         |

## PATCH /api/object-classes/`id`/

Updates single Object Class.

### Permissions

Requires `authentication` and `sobject_classes.edit` permission.

### Allowed parameters

| Key                   | Type   | Notes                                        |
|-----------------------|--------|----------------------------------------------|
| name                  | string |                                              |
| description           | string |                                              |
| display\_configuration | Json   | UI configuration                             |
| custom\_components     | Json   | Custom Components used in UI configuration.  |

Any parameter not listed above are silently ignored if passed.

### Request

* Headers

```
Request Method: PATCH
Content-Type: application/json
Location: /api/object-classes/1/
Authorization: JWT access_token
```

* Sample request body

```json
{
    "name": "class_name",
    "description": "Some class description",
    "display_configuration": {"key": "value"},
    "custom_components": [
      {"component_id": 1, "used_in": "object_class_create_forms }, 
      {"component_id": 2, "used_in": "object_class_summary_forms }
    ]
}
```

### Response

| Key                   | Type     | Notes                                                         |
|-----------------------|----------|---------------------------------------------------------------|
| id                    | pk       | Automatically generated by the backend.                       |
| name                  | string   | Name of the object class                                      |
| description           | string   | Description of the object class                               |
| identifier            | Object   | Object record identifier                                      |
| display\_configuration | Json     | Object class UI configuration                                 |
| created\_at            | datetime |                                                               |
| created\_by            | user     |                                                               |
| modified\_at           | datetime |                                                               |
| modified\_by           | user     |                                                               |
| record\_count          | int      | Number of records for a given Object Class                    |
| object\_models         | Array    | List of Object Models ids in which a given class is used      |
| \_meta.permissions     | Object   | Object describing permissions.                                |

### Response `identifier` object

| Key            | Type   | Notes      |
|----------------|--------|------------|
| id             | pk     |            |
| label          | string |            |
| alias          | string |            |
| type           | enum   | Field type |
| is\_unique      | bool   |            |
| is\_identifier  | bool   |            |
| has\_duplicates | bool   |            |
| order          | int    |            |
| extras         | Json   |            |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": 1,
    "name": "class_name",
    "description": "Some class description",
    "identifier": {
        "id": null,
        "label": "ALX ID",
        "alias": "id",
        "type": "int",
        "is_unique": false,
        "is_identifier": false,
        "has_duplicates": false,
        "order": null,
        "extras": {}
    },
    "display_configuration": {
        "key": "value"
    },
    "created_at": "2023-08-23T14:52:14.172073+02:00",
    "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_at": "2023-08-23T14:52:14.172098+02:00",
    "modified_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "record_count": 0,
    "object_models": [],
    "_meta": {
        "permissions": {
            "list": true,
            "view": true,
            "create": true,
            "edit": true,
            "delete": true,
            "edit_owners": true,
            "edit_perm_sets": true,
            "object_records": {
                "create": true
            },
            "object_class_forms": {
                "list": true,
                "view": true,
                "edit": true,
                "create": true,
                "delete": true
            }
        }
    }
}
```

### Errors

| Cause                                      | Response status code | Response message                                                                       |
|--------------------------------------------|----------------------|----------------------------------------------------------------------------------------|
| name missing                               | 400 Bad Request      | "name": \["This field is required."]                                                  |
| name is empty                              | 400 Bad Request      | "name": \[ "This field may not be blank." ]                                           |
| name is null                               | 400 Bad Request      | "name": \[ "This field may not be null." ]                                            |
| name not unique                            | 400 Bad Request      | "name": \["This field must be unique."]                                               |
| name too long                              | 400 Bad Request      | "name": \["Ensure this field has no more than 100 characters."]                       |
| first sign not a letter                    | 400 Bad Request      | "name": \["First sign of name must be a letter."]                                     |
| description too long                       | 400 Bad Request      | "description": \["Ensure this field has no more than 500 characters."]                |
| description is null                        | 400 Bad Request      | "description": \["This field may not be null."]                                       |
| key is duplicated                          | 400 Bad Request      | "display\_configuration": \["JSON key "key" is duplicated."]                         |
| template\_file is null                      | 400 Bad Request      | "template\_file": \[ "This field may not be null." ]                                   |
| template\_file not docx                     | 400 Bad Request      | "template\_file": \["Invalid file type."]                                              |
| custom\_components.component missing        | 400 Bad Request      | "custom\_components": {"component": \["This field is required."]}                      |
| custom\_components.component is empty       | 400 Bad Request      | "custom\_components": {"component": \["This field may not be blank."]}                 |
| custom\_components.component is null        | 400 Bad Request      | "custom\_components": {"component": \["This field may not be null."]}                  |
| custom\_components.component doesn't exists | 400 Bad Request      | "custom\_components": {"component": \["Invalid pk "99900" - object does not exist."]}|
| Insufficient permissions                   | 403 Forbidden        | "detail": "You do not have permission to perform this action."                         |

## DELETE /api/object-classes/`object_class_id`/

Remove a Object Class with checking if no used anywhere.

### Permissions

Requires `authentication` and `object_class.delete` permission.

### Request example

* Headers

```
Request Method: DELETE
Location: /api/object-classes/1/
Authorization: JWT access_token
```

### Response example

* Status `204 No Content`
* Body

### Errors

| Error                        | Response code | Message                                                        |
|------------------------------|---------------|----------------------------------------------------------------|
| Object class in use          | 400 Forbidden | "detail": "Class is in use by Sequences."                      |
| Insufficient permissions     | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Task template does not exist | 404 Forbidden | "detail": "Not found"                                          |

## GET /api/object-classes/autocomplete/

List of Object Classes based on query parameters for autocomplete widgets.

### Permissions

Requires `authentication` and `object_classes.list` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/object-classes/autocomplete/
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        |                                                                                  |
| offset            | int        |                                                                                  |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key          | Type       | Notes                                                                                        |
|--------------|------------|----------------------------------------------------------------------------------------------|
| value        | int        | Object Class ID                                                                              |
| text         | str        | Object Class name                                                                            |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 20,
  "next": null,
  "previous": null,
  "results": [
    {
      "value": 12,
      "tesst": "Some class name"
    }
  ]
}
```

### Sorting

| Parameter   | Example                                        | Notes          |
|-------------|------------------------------------------------|----------------|
| name        | {build}/api/object-classes/?ordering=name      | Ascending      |
| name        | {build}/api/object-classes/?ordering=-name     | Descending (-) |
| text        | {build}/api/object-classes/?ordering=text      | Ascending      |
| text        | {build}/api/object-classes/?ordering=-text     | Descending (-) |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter    | Predicates        | Example                                              | Values   |
|--------------|-------------------|------------------------------------------------------|----------|
| text         | standard string   | {build}/api/object-classes/?text\_\_icontains=template |          |

### Errors

| Error                         | Response code   | Message                                                                                         |
|-------------------------------|-----------------|-------------------------------------------------------------------------------------------------|
| Wrong ordering value          | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."]             |

## GET /api/object-classes/autocomplete/owned/

List of Object Classes owned by user based on query parameters for autocomplete widgets.

### Permissions

Requires `authentication` and `object_classes.list` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/object-classes/autocomplete/owned/
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        |                                                                                  |
| offset            | int        |                                                                                  |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key          | Type       | Notes                                                                                        |
|--------------|------------|----------------------------------------------------------------------------------------------|
| value        | int        | Object Class ID                                                                              |
| text         | str        | Object Class name                                                                            |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 20,
  "next": null,
  "previous": null,
  "results": [
    {
      "value": 12,
      "tesst": "Some class name"
    }
  ]
}
```

### Sorting

| Parameter   | Example                                        | Notes          |
|-------------|------------------------------------------------|----------------|
| name        | {build}/api/object-classes/?ordering=name      | Ascending      |
| name        | {build}/api/object-classes/?ordering=-name     | Descending (-) |
| text        | {build}/api/object-classes/?ordering=text      | Ascending      |
| text        | {build}/api/object-classes/?ordering=-text     | Descending (-) |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter    | Predicates        | Example                                              | Values   |
|--------------|-------------------|------------------------------------------------------|----------|
| text         | standard string   | {build}/api/object-classes/?text\_\_icontains=template |          |

### Errors

| Error                         | Response code   | Message                                                                                         |
|-------------------------------|-----------------|-------------------------------------------------------------------------------------------------|
| Wrong ordering value          | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."]             |

## GET /api/object-classes/`object_class_id`/usage/

### Permissions

Requires `authentication` and `object_class.view` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/object-classes/1/usage/
Authorization: JWT access_token
```

### Response

| Key                         | Type       | Notes                           |
|-----------------------------|------------|---------------------------------|
| num\_of\_records              | int        |                                 |
| sequences                   | array      |                                 |
| num\_of\_sequences            | int        |                                 |
| task\_group\_templates        | array      |                                 |
| num\_of\_task\_group\_templates | int        |                                 |
| task\_templates              | array      |                                 |
| num\_of\_task\_templates       | int        |                                 |
| object\_models               | array      |                                 |
| num\_of\_object\_models        | int        |                                 |
| num\_of\_upload\_components        | int        |                                 |

### Response `sequences` array

| Key          | Type       | Notes                                          |
|--------------|------------|------------------------------------------------|
| id           | int        | Sequence id                                    |
| name         | str        | Name of sequence                               |

### Response `task_group_templates` array

| Key          | Type       | Notes                       |
|--------------|------------|-----------------------------|
| id           | int        | Task Group Template id      |
| name         | str        | Name of Task Group Template |

### Response `task_templates` array

| Key          | Type       | Notes                 |
|--------------|------------|-----------------------|
| id           | int        | Task Template id      |
| name         | str        | Name of Task Template |

### Response `object_models` array

| Key          | Type       | Notes                 |
|--------------|------------|-----------------------|
| id           | int        | Object Model id       |
| name         | str        | Name of Object Model  |

### Response example

* Status `200 OK`
* Body

```json
{
    "num_of_records": 0,
    "sequences": [
        {
            "id": 1,
            "name": "sequence1"
        },
        {
            "id": 7,
            "name": "sequence_test"
        }
    ],
    "num_of_sequences": 2,
    "task_group_templates": [],
    "num_of_task_group_templates": 0,
    "task_templates": [],
    "num_of_task_templates": 0,
    "object_models": [
        {
            "id": 17,
            "name": "some_name"
        }
    ],
    "num_of_object_models": 1,
    "num_of_upload_components": 1
}
```

### Errors

| Error                         | Response code   | Message                                                            |
|-------------------------------|-----------------|--------------------------------------------------------------------|
| `id` is invalid               | 404 Bad Request | 'detail': "Not found."                                             |
| Unauthorized API call         | 403 Bad Request | 'detail': "You do not have permission to perform this action."     |

## POST /api/object-classes/`object_class_id`/fields/

Creates object class field.

### Permissions

Requires `authentication` and `object_classes.edit` permission.

### Request

* Body general parameters

| Key           | Type   | Notes                                       |
|---------------|--------|---------------------------------------------|
| alias         | string |                                             |
| type          | enum   |                                             |
| label         | string |                                             |
| is\_identifier | bool   |                                             |
| is\_unique     | bool   | Field value is unique in Object Class scope |
| is\_system     | bool   |                                             |
| order         | int    |                                             |
| description   | string |                                             |

* Additional body parameters for `int` type

| Key           | Type | Notes |
|---------------|------|-------|
| default\_value | int  |       |
| min\_value     | int  |       |
| max\_value     | int  |       |

* Additional body parameters for `float` type

| Key           | Type  | Notes |
|---------------|-------|-------|
| default\_value | float |       |
| min\_value     | float |       |
| max\_value     | float |       |

* Additional body parameters for `bool` type

| Key             | Type  | Notes |
|-----------------|-------|-------|
| required\_value  | bool  |       |

* Additional body parameters for `string` type

| Key         | Type | Notes |
|-------------|------|-------|
| max\_length  | int  |       |

* Additional body parameters for `enum` type

| Key           | Type   | Notes |
|---------------|--------|-------|
| options       | enum   |       |
| default\_value | string |       |

* Additional body parameters for `set` type

| Key        | Type | Notes |
|------------|------|-------|
| options    | enum |       |
| min\_values | int  |       |
| max\_values | int  |       |

* Additional body parameters for `document` type

| Key               | Type | Notes |
|-------------------|------|-------|
| max\_num\_of\_files  | enum |       |

* Additional body parameters for `user` type

| Key                     | Type | Notes |
|-------------------------|------|-------|
| options                 | enum |       |
| min\_users\_values        | int  |       |
| max\_users\_values        | int  |       |
| min\_groups\_values       | int  |       |
| max\_groups\_values       | int  |       |
| allow\_sync              | bool |       |
| allow\_members\_selection | bool |       |

* * Parameter `options` array

| Key         | Type | Notes |
|-------------|------|-------|
| users       | list |       |
| user\_groups | list |       |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/object-classes/1/fields/

{
    "alias": "some_field",
    "type": "int",
    "min_value": 4,
    "label": "field description",
    "is_identifier": false,
    "order": 3
}
```

### Validations

* General

- alias
  * is string
  * is required
  * is not null
  * is not blank
  * is unique in the Object Class scope
  * max length is 50
  * first sign is not `_`
- type
  * is one of: `int`, `float`, `bool`, `string`, `enum`, `set`, `email`, `phone`, `date`, `time`, `datetime`, `url`, `json`, `document`, `user`
  * is required
- label
  * is string
  * is required
  * is not null
  * is not blank
  * is unique in the Object Class scope
  * max length is 100
- is\_identifier
  * is bool
- is\_unique
  * is bool
- is\_system
  * is bool
- order
  * is int
  * is greater or equal 0
- description
  * is string
  * is not null
  * max length is 500

* `int` type

- default\_value
  * is int
  * is between `min_value` and `max_value`
- max\_value
  * is int
  * is greater or equal than `min_value`
- min\_value
  * is int
  * is less or equal than `max_value`

* `float` type

- default\_value
  * is float
  * is between `min_value` and `max_value`
- max\_value
  * is float
  * is greater or equal than `min_value`
- min\_value
  * is float
  * is less or equal than `max_value`

* `bool` type

- required\_value
  * is bool

* `string` type

- max\_length
  * is int
  * is less or equal than `255` if `is_identifier` is true
  * is less or equal `5000`
  * is greater than 1

* `enum` type

- options
  * is list
  * is not empty
  * is not null
  * list values are unique
  * number of items is less or equal than 100
- default\_value
- is one of the options

* `set` type

- options
  * is list
  * is not empty
  * is not null
  * list values are unique
  * number of items is less or equal than 100
- min\_values
- is int
- is greater or equal than `max_values`
- is greater or equal than numer of options
- max\_values
- is int
- is less or equal than `min_values`
- is greater or equal than numer of options

* `document` type

- max\_num\_of\_files
  * is required
  * is greater or equal than `1`
  * is less or equal than `100`

* `user` type

- options
  * is dict
  * is not empty
  * is not null
  * contains only `users` and `user_groups` keys
- min\_users\_values
- is int
- is greater or equal than `max_users_values`
- is greater or equal than numer of options
- max\_users\_values
- is int
- is less or equal than `min_users_values`
- is greater or equal than numer of options
- min\_groups\_values
- is int
- is greater or equal than `max_groups_values`
- is greater or equal than numer of options
- max\_groups\_values
- is int
- is less or equal than `min_groups_values`
- is greater or equal than numer of options
- allow\_sync
  * is bool
- allow\_members\_selection
  * is bool

### Restrictions

* Up to 2000 Fields can be added per given Object Class, limit is configurable per build.

### Response

* General keys

| Key            | Type  | Notes                         |
|----------------|-------|-------------------------------|
| id             | int   |                               |
| label          | str   |                               |
| type           | str   |                               |
| alias          | str   |                               |
| is\_unique      | bool  |                               |
| is\_identifier  | bool  |                               |
| is\_system           | bool  |                               |
| has\_duplicates | bool  |                               |
| extras         | array |                               |
| order          | int   |                               |
| description    | str   |                               |
| \_meta          | array | only for `user` type fields   |

### Response `_meta` array

| Key                         | Type     | Notes                                                                                  |
|-----------------------------|----------|----------------------------------------------------------------------------------------|
| is\_min\_users\_fulfilled      | bool     | Determine if the current User Type field configuration meets the minimum requirements  |
| users                       | array    | Users representation array                                                             |
| user\_groups                 | array    | User Groups representation array                                                       |

* Additional keys depends on field type and are described in `Validators` section

* Successful status `201 Created`

* Response body:

```json
{
    "id": 18,
    "label": "field description",
    "alias": "some_field",
    "type": "int",
    "is_unique": false,
    "is_identifier": false,
    "is_system": false,
    "has_duplicates": false,
    "order": 3,
    "description": "",
    "extras": {
        "default_value": null,
        "min_value": 4,
        "max_value": null
    },
    "default_value": null,
    "min_value": 4,
    "max_value": null
}
```

### Errors

| Cause                                                 | Response status code | Response message                                                                                                                                                            |
|-------------------------------------------------------|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| alias missing                                         | 400 Bad Request      | "alias": \["This field is required."]                                                                                                                                      |
| alias is empty                                        | 400 Bad Request      | "alias": \[ "This field may not be blank." ]                                                                                                                               |
| alias is null                                         | 400 Bad Request      | "alias": \[ "This field may not be null." ]                                                                                                                                |
| alias not unique                                      | 400 Bad Request      | "alias": \["This field must be unique."]                                                                                                                                   |
| alias too long                                        | 400 Bad Request      | "alias": \["Ensure this field has no more than 50 characters."]                                                                                                            |
| alias invalid name                                    | 400 Bad Request      | "alias": \["Object Field of alias \_ cannot be set."]                                                                                                                       |
| type  missing                                         | 400 Bad Request      | "type": \["This field is required."]                                                                                                                                       |
| type  invalid choice                                  | 400 Bad Request      | "type": \[""aaa" is not a valid choice."]                                                                                                                                |
| label missing                                         | 400 Bad Request      | "label": \["This field is required."]                                                                                                                                      |
| label is empty                                        | 400 Bad Request      | "label": \[ "This field may not be blank." ]                                                                                                                               |
| label is null                                         | 400 Bad Request      | "label": \[ "This field may not be null." ]                                                                                                                                |
| label not unique                                      | 400 Bad Request      | "label": \["This field must be unique."]                                                                                                                                   |
| label too long                                        | 400 Bad Request      | "label": \["Ensure this field has no more than 100 characters."]                                                                                                           |
| order invalid                                         | 400 Bad Request      | "order": \["Ensure this value is greater than or equal to 0.'"]                                                                                                            |
| description is null                                   | 400 Bad Request      | "description": \["This field may not be null."]                                                                                                                            |
| description too long                                  | 400 Bad Request      | "description": \["Ensure this field has no more than 500 characters."]                                                                                                     |
| options is empty                                      | 400 Bad Request      | "options": \["This list may not be empty."]                                                                                                                                |
| options is null                                       | 400 Bad Request      | "options": \["This field may not be null."]                                                                                                                                |
| options is required                                   | 400 Bad Request      | "options": \["This field is required."]                                                                                                                                    |
| options is blank                                      | 400 Bad Request      | "options": \["This list may not be blank."]                                                                                                                                |
| option too long                                       | 400 Bad Request      | "options": \["Ensure this field has no more than 100 characters."]                                                                                                         |
| options not unique                                    | 400 Bad Request      | "options": \["Ensure options are unique."]                                                                                                                                 |
| options required for user                             | 400 Bad Request      | "options": \["At least one users or user groups must be selected."]                                                                                                        |
| options required for user invalid type                | 400 Bad Request      | "options": \["Expected a dictionary of items but got type "type"."]                                                                                                      |
| options for user null                                 | 400 Bad Request      | "options": \["This field may not be null."]                                                                                                                                |
| options for user required                             | 400 Bad Request      | "options": \["This field is required."]                                                                                                                                    |
| user\_groups options for user greater than 10          | 400 Bad Request      | "options": {"user\_groups": \["Ensure this list has at most 10 items."]}                                                                                                    |
| users insufficient permissions                        | 400 Bad Request      | "options": {"users": \["You do not have permission to select user "user\_id" as a user-type field option."]}                                                              |
| user\_groups insufficient permissions                  | 400 Bad Request      | "options": {"user\_groups": \["You do not have permission to select user group "group\_id" as a user-type field option."]}                                                 |
| user\_groups options for user bool params required     | 400 Bad Request      | "options": \["At least one of allow\_sync or allow\_members\_selection must be set to true when group IDs are provided."]                                                     |
| user\_groups options for user bool params values       | 400 Bad Request      | "options": \["allow\_sync and allow\_members\_selection parameters can only be set to true when group IDs are provided."]                                                     |
| default\_value invalid                                 | 400 Bad Request      | "default\_value": \["The default value should be one of options."]                                                                                                          |
| max\_value invalid                                     | 400 Bad Request      | "max\_value": \["A valid integer is required."]                                                                                                                             |
| min\_value invalid                                     | 400 Bad Request      | "min\_value": \["A valid integer is required."]                                                                                                                             |
| max\_value < min\_value                                 | 400 Bad Request      | "detail": \["Max value cannot be smaller than min value."]                                                                                                                 |
| max\_users\_value invalid                               | 400 Bad Request      | "max\_users\_value": \["A valid integer is required."]                                                                                                                       |
| min\_users\_value invalid                               | 400 Bad Request      | "min\_users\_value": \["A valid integer is required."]                                                                                                                       |
| max\_users\_value < min\_users\_value                     | 400 Bad Request      | "detail": \["Users max value cannot be smaller than min value."]                                                                                                           |
| max\_users\_value and min\_users\_value with conditions   | 400 Bad Request      | "options": \["min\_users\_values and max\_users\_values can be specified only when user IDs are provided or group IDs are provided with allow\_members\_selection set to true."] |
| max\_groups\_value invalid                              | 400 Bad Request      | "max\_groups\_value": \["A valid integer is required."]                                                                                                                      |
| min\_groups\_value invalid                              | 400 Bad Request      | "min\_groups\_value": \["A valid integer is required."]                                                                                                                      |
| max\_groups\_value < min\_groups\_value                   | 400 Bad Request      | "detail": \["Groups max value cannot be smaller than min value."]                                                                                                          |
| max\_groups\_value and min\_groups\_value with allow\_sync | 400 Bad Request      | "options": \["min\_groups\_values and max\_groups\_values can be passed only when allow\_sync is set to true."]                                                                 |
| default\_value < min\_value                             | 400 Bad Request      | "detail": \["Default value cannot be smaller than min value."]                                                                                                             |
| default\_value > max\_value                             | 400 Bad Request      | "detail": \["Default value cannot be bigger than max value."]                                                                                                              |
| required\_value invalid                                | 400 Bad Request      | "required\_value": \["Only boolean or null values are allowed."]                                                                                                            |
| max\_num\_of\_files is required                          | 400 Bad Request      | "max\_num\_of\_files": \["This field is required."]                                                                                                                           |
| max\_num\_of\_files is null                              | 400 Bad Request      | "max\_num\_of\_files": \["This field may not be null."]                                                                                                                       |
| max\_num\_of\_files invalid type                         | 400 Bad Request      | "max\_num\_of\_files": \["A valid integer is required."]                                                                                                                      |
| max\_num\_of\_files invalid valuer                       | 400 Bad Request      | "max\_num\_of\_files": \["Ensure this value is greater than or equal to 1."]                                                                                                  |
| max\_length is null                                    | 400 Bad Request      | "max\_length": \["This field may not be null."]                                                                                                                             |
| max\_length invalid                                    | 400 Bad Request      | "max\_length": \["A valid integer is required."]                                                                                                                            |
| is\_identifier forbidden type                          | 400 Bad Request      | "is\_identifier": \["Object Field of type "type" cannot be set as identifier."]                                                                                           |
| allow\_sync is set to null                             | 400 Bad Request      | "allow\_sync": \["This field may not be null."]                                                                                                                             |
| allow\_members\_selection is set to null                | 400 Bad Request      | "allow\_members\_selection": \["This field may not be null."]                                                                                                                |
| Insufficient permissions                              | 403 Forbidden        | "detail": "You do not have permission to perform this action."                                                                                                              |

## PATCH /api/object-classes/`object_class_id`/fields/`id or alias`/

Updates single Object Field identified by either `id` or `alias`.

### Permissions

Requires `authentication` and `object_classes.edit` permission.

### Allowed parameters

* Body general parameters

| Key           | Type   | Notes                                       |
|---------------|--------|---------------------------------------------|
| label         | string |                                             |
| is\_identifier | bool   |                                             |
| is\_unique     | bool   | Field value is unique in Object Class scope |
| is\_system     | bool   |                                             |
| order         | int    |                                             |
| description   | string |                                             |

* Additional body parameters for `int` type

| Key           | Type | Notes |
|---------------|------|-------|
| default\_value | int  |       |
| min\_value     | int  |       |
| max\_value     | int  |       |

* Additional body parameters for `float` type

| Key           | Type  | Notes |
|---------------|-------|-------|
| default\_value | float |       |
| min\_value     | float |       |
| max\_value     | float |       |

* Additional body parameters for `bool` type

| Key             | Type  | Notes |
|-----------------|-------|-------|
| required\_value  | bool  |       |

* Additional body parameters for `string` type

| Key         | Type | Notes |
|-------------|------|-------|
| max\_length  | int  |       |

* Additional body parameters for `enum` type

| Key           | Type   | Notes |
|---------------|--------|-------|
| options       | enum   |       |
| default\_value | string |       |

* Additional body parameters for `set` type

| Key        | Type | Notes |
|------------|------|-------|
| options    | enum |       |
| min\_values | int  |       |
| max\_values | int  |       |

* Additional body parameters for `document` type

| Key               | Type | Notes |
|-------------------|------|-------|
| max\_num\_of\_files  | enum |       |

* Additional body parameters for `user` type

| Key                     | Type | Notes |
|-------------------------|------|-------|
| options                 | enum |       |
| min\_users\_values        | int  |       |
| max\_users\_values        | int  |       |
| min\_groups\_values       | int  |       |
| max\_groups\_values       | int  |       |
| allow\_sync              | bool |       |
| allow\_members\_selection | bool |       |

* * Parameter `options` array

| Key         | Type | Notes |
|-------------|------|-------|
| users       | list |       |
| user\_groups | list |       |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
PATCH /api/object-classes/1/fields/1/

{
    "min_value": 4,
    "label": "field description",
    "is_identifier": false,
    "order": 3
}
```

### Validations

* General

- label
  * is string
  * is required
  * is not null
  * is not blank
  * is unique in the Object Class scope
  * max length is 100
- is\_identifier
  * is bool
- is\_unique
  * is bool
- is\_system
  * is bool
  * cannot be changed from true
  * if set to true, only name and description can be changed
- order
  * is int
  * is greater or equal 0
- description
  * is string
  * is not null
  * max length is 500

* `int` type

- default\_value
  * is int
  * is between `min_value` and `max_value`
- max\_value
  * is int
  * is greater or equal than `min_value`
- min\_value
  * is int
  * is less or equal than `max_value`

* `float` type

- default\_value
  * is float
  * is between `min_value` and `max_value`
- max\_value
  * is float
  * is greater or equal than `min_value`
- min\_value
  * is float
  * is less or equal than `max_value`

* `bool` type

- required\_value
  * is bool

* `string` type

- max\_length
  * is int
  * is less or equal than `255` if `is_identifier` is true
  * is less or equal `5000`
  * is greater than 1

* `enum` type

- options
  * is list
  * is not empty
  * is not null
  * list values are unique
  * number of items is less or equal than 100
- default\_value
- is one of the options

* `set` type

- options
  * is list
  * is not empty
  * is not null
  * list values are unique
  * number of items is less or equal than 100
- min\_values
- is int
- is greater or equal than `max_values`
- is greater or equal than numer of options
- max\_values
- is int
- is less or equal than `min_values`
- is greater or equal than numer of options

* `document` type

- max\_num\_of\_files
  * is required
  * is greater or equal than `1`
  * is less or equal than `100`

* `user` type

- options
  * is dict
  * is not empty
  * is not null
  * contains only `users` and `user_groups` keys
- min\_users\_values
- is int
- is greater or equal than `max_users_values`
- is greater or equal than numer of options
- max\_users\_values
- is int
- is less or equal than `min_users_values`
- is greater or equal than numer of options
- min\_groups\_values
- is int
- is greater or equal than `max_groups_values`
- is greater or equal than numer of options
- max\_groups\_values
- is int
- is less or equal than `min_groups_values`
- is greater or equal than numer of options
- allow\_sync
  * is bool
- allow\_members\_selection
  * is bool

### Response

* General keys

| Key            | Type  | Notes                       |
|----------------|-------|-----------------------------|
| id             | int   |                             |
| label          | str   |                             |
| type           | str   |                             |
| alias          | str   |                             |
| is\_unique      | bool  |                             |
| is\_identifier  | bool  |                             |
| is\_system      | bool  |                             |
| has\_duplicates | bool  |                             |
| extras         | array |                             |
| order          | int   |                             |
| \_meta          | array | only for `user` type fields |

### Response `_meta` array

| Key                         | Type    | Notes                                                                                  |
|-----------------------------|---------|----------------------------------------------------------------------------------------|
| is\_min\_users\_fulfilled      | bool    | Determine if the current User Type field configuration meets the minimum requirements  |
| users                       | array   | Users representation array                                                             |
| user\_groups                 | array   | User Groups representation array                                                       |

* Additional keys depends on field type and are described in `Validators` section

* Successful status `200 Ok`

* Response body:

```json
{
    "id": 1,
    "label": "field description",
    "alias": "some_field",
    "type": "int",
    "is_unique": false,
    "is_identifier": false,
    "is_system": false,
    "has_duplicates": false,
    "order": 3,
    "extras": {
        "default_value": null,
        "min_value": 4,
        "max_value": null
    },
    "default_value": null,
    "min_value": 4,
    "max_value": null
}
```

### Errors

| Cause                                                                                          | Response status code | Response message                                                                                                                                                            |
|------------------------------------------------------------------------------------------------|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| label missing                                                                                  | 400 Bad Request      | "label": \["This field is required."]                                                                                                                                      |
| label is empty                                                                                 | 400 Bad Request      | "label": \[ "This field may not be blank." ]                                                                                                                               |
| label is null                                                                                  | 400 Bad Request      | "label": \[ "This field may not be null." ]                                                                                                                                |
| label not unique                                                                               | 400 Bad Request      | "label": \["This field must be unique."]                                                                                                                                   |
| label too long                                                                                 | 400 Bad Request      | "label": \["Ensure this field has no more than 100 characters."]                                                                                                           |
| order invalid                                                                                  | 400 Bad Request      | "order": \["Ensure this value is greater than or equal to 0.'"]                                                                                                            |
| options is empty                                                                               | 400 Bad Request      | "options": \["This list may not be empty."]                                                                                                                                |
| options is null                                                                                | 400 Bad Request      | "options": \["This field may not be null."]                                                                                                                                |
| options is required                                                                            | 400 Bad Request      | "options": \["This field is required."]                                                                                                                                    |
| options is blank                                                                               | 400 Bad Request      | "options": \["This list may not be blank."]                                                                                                                                |
| option too long                                                                                | 400 Bad Request      | "options": \["Ensure this field has no more than 100 characters."]                                                                                                         |
| options not unique                                                                             | 400 Bad Request      | "options": \["Ensure options are unique."]                                                                                                                                 |
| options required for user                                                                      | 400 Bad Request      | "options": \["At least one users or user groups must be selected."]                                                                                                        |
| options required for user invalid type                                                         | 400 Bad Request      | "options": \["Expected a dictionary of items but got type "type"."]                                                                                                      |
| options for user null                                                                          | 400 Bad Request      | "options": \["This field may not be null."]                                                                                                                                |
| options for user required                                                                      | 400 Bad Request      | "options": \["This field is required."]                                                                                                                                    |
| users insufficient permissions                                                                 | 400 Bad Request      | "options": {"users": \["You do not have permission to select user "user\_id" as a user-type field option."]}                                                              |
| user\_groups insufficient permissions                                                           | 400 Bad Request      | "options": {"user\_groups": \["You do not have permission to select user group "group\_id" as a user-type field option."]}                                                 |
| user\_groups options for user greater than 10                                                   | 400 Bad Request      | "options": {"user\_groups": \["Ensure this list has at most 10 items."]}                                                                                                    |
| user\_groups options for user bool params required                                              | 400 Bad Request      | "options": \["At least one of allow\_sync or allow\_members\_selection must be set to true when group IDs are provided."]                                                     |
| user\_groups options for user bool params values                                                | 400 Bad Request      | "options": \["allow\_sync and allow\_members\_selection parameters can only be set to true when group IDs are provided."]                                                     |
| default\_value invalid                                                                          | 400 Bad Request      | "default\_value": \["The default value should be one of options."]                                                                                                          |
| max\_value invalid                                                                              | 400 Bad Request      | "max\_value": \["A valid integer is required."]                                                                                                                             |
| min\_value invalid                                                                              | 400 Bad Request      | "min\_value": \["A valid integer is required."]                                                                                                                             |
| max\_value < min\_value                                                                          | 400 Bad Request      | "detail": \["Max value cannot be smaller than min value."]                                                                                                                 |
| max\_users\_value invalid                                                                        | 400 Bad Request      | "max\_users\_value": \["A valid integer is required."]                                                                                                                       |
| min\_users\_value invalid                                                                        | 400 Bad Request      | "min\_users\_value": \["A valid integer is required."]                                                                                                                       |
| max\_users\_value < min\_users\_value                                                              | 400 Bad Request      | "detail": \["Users max value cannot be smaller than min value."]                                                                                                           |
| max\_users\_value and min\_users\_value with conditions                                            | 400 Bad Request      | "options": \["min\_users\_values and max\_users\_values can be specified only when user IDs are provided or group IDs are provided with allow\_members\_selection set to true."] |
| max\_groups\_value invalid                                                                       | 400 Bad Request      | "max\_groups\_value": \["A valid integer is required."]                                                                                                                      |
| min\_groups\_value invalid                                                                       | 400 Bad Request      | "min\_groups\_value": \["A valid integer is required."]                                                                                                                      |
| max\_groups\_value < min\_groups\_value                                                            | 400 Bad Request      | "detail": \["Groups max value cannot be smaller than min value."]                                                                                                          |
| max\_groups\_value and min\_groups\_value with allow\_sync                                          | 400 Bad Request      | "options": \["min\_groups\_values and max\_groups\_values can be passed only when allow\_sync is set to true."]                                                                 |
| default\_value < min\_value                                                                      | 400 Bad Request      | "detail": \["Default value cannot be smaller than min value."]                                                                                                             |
| default\_value > max\_value                                                                      | 400 Bad Request      | "detail": \["Default value cannot be bigger than max value."]                                                                                                              |
| required\_value invalid                                                                         | 400 Bad Request      | "required\_value": \["Only boolean or null values are allowed."]                                                                                                            |
| max\_num\_of\_files is required                                                                   | 400 Bad Request      | "max\_num\_of\_files": \["This field is required."]                                                                                                                           |
| max\_num\_of\_files is null                                                                       | 400 Bad Request      | "max\_num\_of\_files": \["This field may not be null."]                                                                                                                       |
| max\_num\_of\_files invalid type                                                                  | 400 Bad Request      | "max\_num\_of\_files": \["A valid integer is required."]                                                                                                                      |
| max\_num\_of\_files invalid valuer                                                                | 400 Bad Request      | "max\_num\_of\_files": \["Ensure this value is greater than or equal to 1."]                                                                                                  |
| max\_length is null                                                                             | 400 Bad Request      | "max\_length": \["This field may not be null."]                                                                                                                             |
| max\_length invalid                                                                             | 400 Bad Request      | "max\_length": \["A valid integer is required."]                                                                                                                            |
| is\_identifier forbidden type                                                                   | 400 Bad Request      | "is\_identifier": \["Object Field of type "type" cannot be set as identifier."]                                                                                           |
| allow\_sync is set to null                                                                      | 400 Bad Request      | "allow\_sync": \["This field may not be null."]                                                                                                                             |
| allow\_members\_selection is set to null                                                         | 400 Bad Request      | "allow\_members\_selection": \["This field may not be null."]                                                                                                                |
| modifiying is\_system flag  set to true                                                         | 400 Bad Request      | "is\_system": \["System object class field cannot be modified except for label, description or order."]                                                                             |
| modifiying fields differend than: name, description, ordering when is\_system flag  set to true | 400 Bad Request      | "is\_system": \["System object class field cannot be modified except for label, description or order."]                                                                               |
| Insufficient permissions                                                                       | 403 Forbidden        | "detail": "You do not have permission to perform this action."                                                                                                              |

## DELETE /api/object-classes/`object_class_id`/fields/`id or alias`/

Deletes single Object Field identified by either `id` or `alias`.

### Permissions

Requires `authentication` and `object_class.edit` permission.

### Request example

* Headers

```
Request Method: DELETE
Location: /api/object-classes/1/fields/1/
Authorization: JWT access_token
```

### Response example

* Status `204 No Content`
* Body

### Errors

| Error                               | Response code    | Message                                                        |
|-------------------------------------|------------------|----------------------------------------------------------------|
| Object Class Field in use           | 400 Forbidden    | "detail": "Object Class Field is in use by Sequences."         |
| Object Class Field is system field  | 400 Forbidden    | "detail": "System object class fields cannot be deleted."      |
| Insufficient permissions            | 403 Forbidden    | "detail": "You do not have permission to perform this action." |
| Object Class does not exist         | 404 Forbidden    | "detail": "Not found"                                          |
| Object Field does not exist         | 404 Forbidden    | "detail": "Not found"                                          |

## OPTIONS /api/object-classes/`id`/fields/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Request Method: OPTIONS
Content-Type: application/json
Location: /api/object-classes/1/fields/
Authorization: JWT access_token
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range",
                    "in"
                ],
                "sort_ok": true
            },
            {
                "alias": "label",
                "type": "string",
                "predicates": [
                    "icontains"
                ],
                "sort_ok": false,
                "search_key": "label__icontains"
            },
            {
                "alias": "type",
                "type": "enum",
                "predicates": [],
                "sort_ok": false,
                "values": [
                    {
                        "value": "int",
                        "text": "Integer"
                    },
                    {
                        "value": "float",
                        "text": "Decimal"
                    },
                    {
                        "value": "bool",
                        "text": "Checkbox"
                    },
                    {
                        "value": "string",
                        "text": "Text"
                    },
                    {
                        "value": "enum",
                        "text": "Single select"
                    },
                    {
                        "value": "set",
                        "text": "Multi select"
                    },
                    {
                        "value": "email",
                        "text": "Email"
                    },
                    {
                        "value": "phone",
                        "text": "Phone"
                    },
                    {
                        "value": "date",
                        "text": "Date"
                    },
                    {
                        "value": "time",
                        "text": "Time"
                    },
                    {
                        "value": "datetime",
                        "text": "Date/Time"
                    },
                    {
                        "value": "url",
                        "text": "URL"
                    },
                    {
                        "value": "json",
                        "text": "JSON"
                    },
                    {
                        "value": "document",
                        "text": "Document"
                    },
                    {
                        "value": "user",
                        "text": "User"
                    }
                ]
            },
            {
                "alias": "alias",
                "type": "string",
                "predicates": [
                    "in"
                ],
                "sort_ok": false
            },
            {
                "alias": "is_unique",
                "type": "bool",
                "predicates": [],
                "sort_ok": false
            }
        ]
    },
    "details": {
        "schema": [
            {
                "alias": "label",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "is_system",
                "type": "bool",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "alias",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "min_length",
                        "length": 1
                    },
                    {
                        "type": "max_length",
                        "length": 50
                    }
                ]
            },
            {
                "alias": "description",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 500
                    },
                ],
            },
            {
                "alias": "type",
                "type": "enum",
                "required": true,
                "values": [
                    {
                        "value": "string",
                        "text": "Text",
                        "is_unique": true,
                        "is_identifier": true,
                        "options": [
                            {
                                "name": "max_length",
                                "type": "int",
                                "required": false,
                                "validators": [
                                    {
                                        "type": "min_value",
                                        "length": 1
                                    },
                                    {
                                        "type": "max_value",
                                        "length": 5000
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "value": "int",
                        "text": "Integer",
                        "is_unique": true,
                        "is_identifier": true,
                        "options": [
                            {
                                "name": "min_value",
                                "type": "int",
                                "required": false,
                                "validators": []
                            },
                            {
                                "name": "max_value",
                                "type": "int",
                                "required": false,
                                "validators": []
                            },
                            {
                                "name": "default_value",
                                "type": "int",
                                "required": false,
                                "validators": []
                            }
                        ]
                    },
                    {
                        "value": "float",
                        "text": "Decimal",
                        "is_unique": true,
                        "is_identifier": false,
                        "options": [
                            {
                                "name": "min_value",
                                "type": "float",
                                "required": false,
                                "validators": []
                            },
                            {
                                "name": "max_value",
                                "type": "float",
                                "required": false,
                                "validators": []
                            },
                            {
                                "name": "default_value",
                                "type": "float",
                                "required": false,
                                "validators": []
                            }
                        ]
                    },
                    {
                        "value": "bool",
                        "text": "Checkbox",
                        "is_unique": false,
                        "is_identifier": false,
                        "options": [
                            {
                                "name": "default_value",
                                "type": "bool",
                                "required": false,
                                "validators": []
                            }
                        ]
                    },
                    {
                        "value": "email",
                        "text": "Email",
                        "is_unique": true,
                        "is_identifier": true,
                        "options": []
                    },
                    {
                        "value": "phone",
                        "text": "Phone",
                        "is_unique": true,
                        "is_identifier": true,
                        "options": [
                            {
                                "name": "max_length",
                                "type": "int",
                                "required": false,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 20
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "value": "date",
                        "text": "Date",
                        "is_unique": false,
                        "is_identifier": true,
                        "options": []
                    },
                    {
                        "value": "datetime",
                        "text": "Date/Time",
                        "is_unique": false,
                        "is_identifier": true,
                        "options": []
                    },
                    {
                        "value": "time",
                        "text": "Time",
                        "is_unique": false,
                        "is_identifier": false,
                        "options": []
                    },
                    {
                        "value": "url",
                        "text": "URL",
                        "is_unique": false,
                        "is_identifier": true,
                        "options": []
                    },
                    {
                        "value": "json",
                        "text": "JSON",
                        "is_unique": false,
                        "is_identifier": false,
                        "options": []
                    },
                    {
                        "value": "enum",
                        "text": "Single select",
                        "is_unique": false,
                        "is_identifier": false,
                        "options": [
                            {
                                "name": "default_value",
                                "type": "string",
                                "required": false,
                                "validators": []
                            },
                            {
                                "name": "options",
                                "type": "enum",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "min_option_length",
                                        "length": 1
                                    },
                                    {
                                        "type": "max_option_length",
                                        "length": 100
                                    },
                                    {
                                        "type": "max_options",
                                        "length": 200
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "value": "set",
                        "text": "Multi select",
                        "is_unique": false,
                        "is_identifier": false,
                        "options": [
                            {
                                "name": "options",
                                "type": "enum",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "min_option_length",
                                        "length": 1
                                    },
                                    {
                                        "type": "max_option_length",
                                        "length": 100
                                    },
                                    {
                                        "type": "max_options",
                                        "length": 100
                                    }
                                ]
                            },
                            {
                                "name": "min_values",
                                "type": "int",
                                "required": false,
                                "validators": []
                            },
                            {
                                "name": "max_values",
                                "type": "int",
                                "required": false,
                                "validators": []
                            }
                        ]
                    },
                    {
                        "value": "document",
                        "text": "Document",
                        "is_unique": false,
                        "is_identifier": false,
                        "options": [
                            {
                                "name": "max_num_of_files",
                                "type": "int",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "min_value",
                                        "length": 1
                                    },
                                    {
                                        "type": "max_value",
                                        "length": 100
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "value": "user",
                        "text": "User",
                        "is_unique": false,
                        "is_identifier": false,
                        "options": {
                            "users": [
                                {
                                    "name": "options",
                                    "type": "user",
                                    "required": false,
                                    "validators": [
                                        {
                                            "type": "min_options",
                                            "length": 1
                                        },
                                        {
                                            "type": "max_options",
                                            "length": 100
                                        }
                                    ]
                                },
                                {
                                    "name": "min_users_values",
                                    "type": "int",
                                    "required": false,
                                    "validators": []
                                },
                                {
                                    "name": "max_users_values",
                                    "type": "int",
                                    "required": false,
                                    "validators": []
                                }
                            ],
                            "user_groups": [
                                {
                                    "name": "options",
                                    "type": "user",
                                    "required": false,
                                    "validators": [
                                        {
                                            "type": "min_options",
                                            "length": 1
                                        },
                                        {
                                            "type": "max_options",
                                            "length": 10
                                        }
                                    ]
                                },
                                {
                                    "name": "min_groups_values",
                                    "type": "int",
                                    "required": false,
                                    "validators": []
                                },
                                {
                                    "name": "max_groups_values",
                                    "type": "int",
                                    "required": false,
                                    "validators": []
                                },
                                {
                                    "name": "allow_sync",
                                    "type": "bool",
                                    "required": false,
                                    "validators": []
                                },
                                {
                                    "name": "allow_members_selection",
                                    "type": "bool",
                                    "required": false,
                                    "validators": []
                                }
                            ]
                        }
                    }
                ]
            }
        ]
    },
    "restrictions": {
        "limit_items": 2000
    }
}
```

## GET /api/object-classes/`object_class_id`/fields/`id or alias`/

Returns single Object field identified by either `id` or `alias`.

### Permissions

Requires `authentication` and `object_classes.view` permission.

### URL parameters

| Key             | Type | Notes         |
|-----------------|------|---------------|
| object\_class\_id | id   |               |
| id              | id   |               |
| alias           | str  | Field's alias |

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Location: /api/object-classes/1/fields/1/
Authorization: JWT access_token
```

### Response

* General keys

| Key            | Type  | Notes |
|----------------|-------|-------|
| id             | int   |       |
| label          | str   |       |
| type           | str   |       |
| alias          | str   |       |
| is\_unique      | bool  |       |
| is\_identifier  | bool  |       |
| is\_system      | bool  |       |
| has\_duplicates | bool  |       |
| extras         | array |       |
| order          | int   |       |
| description    | str   |       |
| \_meta          | array |       |

* Additional keys depends on field type and are described in `Validators` section

* Successful status `200 OK`

* Response body:

* * Response body for `int` field type

```json
{
    "id": 18,
    "label": "field description",
    "alias": "some_field",
    "type": "int",
    "is_unique": false,
    "is_identifier": false,
    "is_system": false,
    "has_duplicates": false,
    "order": 3,
    "description": "int field description",
    "extras": {
        "default_value": null,
        "min_value": 4,
        "max_value": null
    },
    "default_value": null,
    "min_value": 4,
    "max_value": null
}
```

* * Response body for `user` field type

```json
{
  "_meta": {
    "is_min_users_fulfilled": true, 
    "user_groups": [
      {
        "id": 138,
        "name": "UsersGroup 0",
        "num_of_members": 1
      }
    ],
    "users": []
  },
  "alias": "slug_name_0",
  "allow_members_selection": true,
  "allow_sync": true,
  "extras": {
    "allow_members_selection": true,
    "allow_sync": true,
    "max_groups_values": 1,
    "max_users_values": 1,
    "min_groups_values": 1,
    "min_users_values": 1,
    "options": {
      "user_groups": [
        138
      ],
      "users": []
    }
  },
  "has_duplicates": false,
  "id": 8,
  "is_identifier": false,
  "is_unique": false,
  "label": "Name 0",
  "max_groups_values": 1,
  "max_users_values": 1,
  "min_groups_values": 1,
  "min_users_values": 1,
  "options": {
    "user_groups": [
      138
    ],
    "users": []
  },
  "order": 0,
  "description": "user field description",
  "type": "user"
}
```

### Errors

| Error                                 | Response code | Message                                                        |
|---------------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions              | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Object Field with "id" does not exist | 404 Not Found | "detail": "Not found."                                         |
| Object Class with "id" does not exist | 404 Not Found | "detail": "Not found."                                         |

## GET /api/object-classes/`object_class_id`/fields/

Endpoint retrieving the list of fields assigned to given Object Class.

### Permissions

Requires `authentication` and `object_class.view` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/object-classes/1/fields/
Authorization: JWT access_token
```

### Response

| Key           | Type   | Notes |
|---------------|--------|-------|
| id            | int    |       |
| label         | str    |       |
| type          | str    |       |
| alias         | str    |       |
| is\_unique     | bool   |       |
| is\_identifier | bool   |       |
| is\_system     | bool   |       |
| extras        | Object |       |
| order         | int    |       |
| sort\_ok       | bool   |       |

### Response `extras` array

Contains additional configuration options of a Field.

### Response example

* Status `200 OK`
* Body

```json
{ 
 "limit": 100, 
   "offset": 0, 
   "filtered_count": 2, 
   "total_count": 2, 
   "next": null, 
   "previous": null, 
   "results": [ 
  { 
           "id": 1,            
           "label": "First Name", 
           "type": "string", 
           "alias": "firstname", 
           "is_required": true, 
           "is_unique": false, 
           "is_identifier": false, 
           "is_system": false, 
           "extras": { 
             "max_length": null 
           }, 
           "order": 0,
           "sort_ok": true
       }, 
       { 
           "id": 2, 
           "label": "Has a dog", 
           "type": "bool", 
           "alias": "has_a_dog", 
           "is_required": false, 
           "is_unique": false, 
           "is_identifier": false, 
           "extras": { 
              "default_value": null 
            }, 
           "order": 1,
           "sort_ok": false
       }, 
   ] 
} 
```

### Sorting

| Parameter    | Example                                                                    | Notes          |
|--------------|----------------------------------------------------------------------------|----------------|
| id           | {build}/api/object-classes/`object_class_id`/fields/?ordering=id         | Ascending      |
| id           | {build}/api/object-classes/`object_class_id`/fields/?ordering=-id        | Descending (-) |

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter        | Type       | Example                                                                         |
|------------------|------------|---------------------------------------------------------------------------------|
| id               | int + enum | {build}/api/object-classes/`object_class_id`/fields/?id\_\_in=1,2                 |
| alias\_\_in        | enum       | {build}/api/object-classes/`object_class_id`/fields/?alias\_\_in=email,last\_name  |
| label\_\_icontains | string     | {build}/api/object-classes/`object_class_id`/fields/?label\_\_icontains=name      |

### Errors

| Error                        | Response code   | Message                                                            |
|------------------------------|-----------------|--------------------------------------------------------------------|
| `object_class_id` is invalid | 404 Bad Request | 'detail': "Not found."                                             |
| Unauthorized API call        | 403 Bad Request | 'detail': "You do not have permission to perform this action."     |

## GET /api/object-classes/{object\_class\_id}/fields/autocomplete/

Returns list of Object Classes Fields.

### Permissions

Requires `authentication` and `object_classes.view` permission.

Response contains only the fields for the associated object class.

### Request example

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key               | Type | Notes                                                                              |
|-------------------|------|------------------------------------------------------------------------------------|
| limit             | int  | 	                                                                                  |
| offset            | int  | 	                                                                                  |
| total\_count       | int  | Total number of results visible to the user (based on permissions).                |
| filtered\_count    | int  | Number of results visible to the user (based on permissions) with filters applied. |
| next              | url  | Next page URL (null if there is no next page)                                      |
| previous          | url  | Previous page URL (null if there is no previous page)                              |
| results           | Array    | List of results. Described in the next table.                                      |

#### Response `results` array

| Key        | Type  | Notes                                                                |
|------------|-------|----------------------------------------------------------------------|
| value      | str   | Field alias constructed from prefix and slug name`field_<slug_name>` |
| values     | Array | List of options to choice for choice type fields.                    |
| text       | str   | Field name.                                                          |
| predicates | Array | List of predicates for given field type.                             |

#### Response `results.values` array

| Key   | Type  | Notes                       |
|-------|-------|-----------------------------|
| value | str   | Option value.               |
| text  | str   | Option representation text. |

* Successful status `200 OK`
* Response body schema

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str>,
  "previous": <str>,
  "results": [
    {
      "id": <pk>,
      "value": <str>,
      "values": [
        {
          "value": <str>,
          "text": <str>
        },
      ],
      "text": <str>,
      "predicates": <Array>
    }
  ]
}
```

### Sorting

| Parameter     | Example                                                                    | Notes          |
|---------------|----------------------------------------------------------------------------|----------------|
| value         | /api/object-classes/{object\_class\_id}/fields/autocomplete/?ordering=value  | Ascending      |
| value         | /api/object-classes/{object\_class\_id}/fields/autocomplete/?ordering=-value | Descending (-) |
| text          | /api/object-classes/{object\_class\_id}/fields/autocomplete/?ordering=text   | Ascending      |
| text          | /api/object-classes/{object\_class\_id}/fields/autocomplete/?ordering=-text  | Descending (-) |

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter     | Type | Example                                                                        | Notes                                                                                                          |
|---------------|------|--------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------|
| text          | str  | /api/object-classes/{object\_class\_id}/fields/autocomplete/?text\_\_contains=text |                                                                                                                |
| for\_filtering | bool | /api/object-classes/{object\_class\_id}/fields/autocomplete/?for\_filtering=1     | Filter by types which supports filtering for given field type. Set `0` or skip parameter to disable filtering. |

### Field types with filtering support

```
text
integer
decimal
date
date/time
email
phone
set
enum
url
user
```

### Errors

| Error                                                                  | Response code    | Message                                                        |
|------------------------------------------------------------------------|------------------|----------------------------------------------------------------|
| Requesting user is not authenticated                                   | 401 Unauthorized | "detail": "Authentication credentials were not provided."      |
| Requesting user is authorized but without view perm for tasks resource | 403 Forbidden    | "detail": "You do not have permission to perform this action." |
| Object Class with "{id}" does not exist                                | 404 Not Found    | "detail": "Not found."                                         |

## POST /api/object-classes/`object_class_id`/fields/validate/

Validates object class fields.

### Permissions

Requires `authentication` and `object_classes.view` permission.

### URL parameters

| Key                | Notes             |
|--------------------|-------------------|
| object\_class\_id    | Object Class ID   |

### Request Schema

* Headers

```
Request Method: POST
Location: /api/object-classes/{object_class_id}/fields/validate/
Authorization: JWT access_token
```

* Body

```json
[<int>]
```

Request body must contain a list of Object Class Field ids.

```json
[<field_id1>, <field_id2>]
```

### Request example

```json
[2734, 7231]
```

### Validations

Validation logic for individual types.

* `user` type

| Field Configuration                                                          | Counting Logic                                                                                            | No `min_users_values`   | `min_users_values` defined                                                      |
|------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------|-------------------------|---------------------------------------------------------------------------------|
| Individual users                                                             | Individual users defined in the Class field                                                               | always fulfilled        | To be fulfilled must have at least the defined number of unique users available |
| Individual users and user groups with allow\_members\_selection                | Unique users from the ones defined in the Class field - including both individual users and group members | always fulfilled        | To be fulfilled must have at least the defined number of unique users available |
| Individual users and user groups with allow\_sync                             | Individual users defined in the Class field                                                               | always fulfilled        | To be fulfilled must have at least the defined number of unique users available |
| Individual users and user groups with allow\_sync and allow\_members\_selection | Unique users from the ones defined in the Class field - including both individual users and group members | always fulfilled        | To be fulfilled must have at least the defined number of unique users available |
| User groups with allow\_members\_selection                                     | Unique users from the group members list of the groups defined in the Class field                         | always fulfilled        | To be fulfilled must have at least the defined number of unique users available |
| User groups with allow\_members\_selection and allow\_sync                      | Unique users from the group members list of the groups defined in the Class field                         | always fulfilled        | To be fulfilled must have at least the defined number of unique users available |
| User groups with allow\_sync                                                  | n/a                                                                                                       | always fulfilled        | always fulfilled                                                                |

### Restrictions

* Up to 2000 Fields can be sent.

### Response

## Some Fields Invalid.

| Key   | Type   | Notes                          |
|-------|--------|--------------------------------|
| error | Object | field validation error message |

* Successful status `200 Ok`
* Response body:

```json
{
  "error": [ "The field "<field_name>" does not have enough valid options available." ]
}
```

## All Fields valid.

* Successful status `204 No Content`

### Errors

| Cause                        | Response status code | Response message                                               |
|------------------------------|----------------------|----------------------------------------------------------------|
| `object_class_id` is invalid | 404 Bad Request      | 'detail': "Not found."                                         |
| Insufficient permissions     | 403 Forbidden        | "detail": "You do not have permission to perform this action." |

## GET /api/object-classes/`object_class_id`/fields/`id or alias`/usage/

Returns usage data of an Object field identified by either `id` or `alias`.

### Permissions

Requires `authentication` and `object_class.view` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/object-classes/1/fields/2/usage/
Authorization: JWT access_token
```

### Response

| Key                                     | Type  | Notes                           |
|-----------------------------------------|-------|---------------------------------|
| num\_of\_message\_templates                | int   |                                 |
| message\_templates                       | array |                                 |
| num\_of\_message\_templates\_with\_field     | int   |                                 |
| num\_of\_records                          | int   |                                 |
| num\_of\_records\_with\_values              | int   |                                 |
| task\_template\_forms                     | array |                                 |
| num\_of\_task\_template\_forms              | int   |                                 |
| document\_templates                      | array |                                 |
| sequences                               | array |                                 |
| num\_of\_sequences                        | int   |                                 |
| num\_of\_upload\_components                | int   |                                 |

### Response `message_templates` array

| Key          | Type       | Notes                    |
|--------------|------------|--------------------------|
| id           | int        | Message template id      |
| name         | str        | Name of message template |

### Response `task_template_forms` array

| Key          | Type       | Notes                 |
|--------------|------------|-----------------------|
| id           | int        | Task Template id      |
| name         | str        | Name of Task Template |

### Response `document_templates` array

| Key               | Type | Notes                        |
|-------------------|------|------------------------------|
| id                | int  | Document Template id         |
| name              | str  | Name of Document Template    |
| object\_class\_id   | int  | ID of related Object Class   |
| object\_class\_name | str  | Name of related Object Class |

### Response `sequences` array

| Key          | Type       | Notes            |
|--------------|------------|------------------|
| id           | int        | Sequence id      |
| name         | str        | Name of Sequence |

### Response example

* Status `200 OK`
* Body

```json
{
    "num_of_message_templates": 55,
    "message_templates": [],
    "num_of_message_templates_with_field": 0,
    "num_of_records": 176,
    "num_of_records_with_values": 21,
    "task_template_forms": [
        {
            "id": 1,
            "name": "Template 1"
        }
    ],
    "num_of_task_template_forms": 1,
    "document_templates": [
        {
            "id": 1,
            "name": "Document Template 1",
            "object_class_id": 1,
            "object_class_name": "Object Class 1",
        }
    ],
    "sequences": [
        {
            "id": 1,
            "name": "Sequence 1"
        }
    ],
    "num_of_sequences": 1,
    "num_of_upload_components": 1,
}
```

### Errors

| Error                         | Response code   | Message                                                            |
|-------------------------------|-----------------|--------------------------------------------------------------------|
| `id` is invalid               | 404 Bad Request | 'detail': "Not found."                                             |
| Unauthorized API call         | 403 Bad Request | 'detail': "You do not have permission to perform this action."     |

---

---
url: /knowledgebase/system-configuration/object-classes.md
---
# Object Classes

Object Classes are one of the core building blocks of an Autologyx solution.

They define the structure of the Object Records your users will work with and provide the foundation for forms, permissions, tasks, workflows, document generation, and reporting. In practice, when you are designing a new application in Autologyx, Object Classes are usually one of the first things you need to think about.

This section is most relevant to **Config Admins**, analysts, and builders who are responsible for defining how data should be captured, presented, and governed within the platform.

## What you will find in this section

### **Understand Object Classes and create the class**

Start here if you want to understand what an Object Class is, why it matters, and how to create one.

* [What Are Object Classes?](/knowledgebase/system-configuration/object-classes/what-are-object-classes/)
* [How Do I Create An Object Class](/knowledgebase/system-configuration/object-classes/how-do-i-create-an-object-class/)
* [What Can I Edit In An Object Class](/knowledgebase/system-configuration/object-classes/what-can-i-edit-in-an-object-class/)

### **Define the class structure and fields**

These pages are about shaping the structure of the class itself, including the fields it contains and the types of data it can hold.

* [Object Class Field Types Uses And Attributes](/knowledgebase/system-configuration/object-classes/object-class-field-types-uses-and-attributes/)
* [Creating Object Class Fields](/knowledgebase/system-configuration/object-classes/creating-object-class-fields/)
* [Editing Object Class Fields](/knowledgebase/system-configuration/object-classes/editing-object-class-fields/)
* [Edit Object Class Remove Fields](/knowledgebase/system-configuration/object-classes/edit-object-class---remove-fields/)

### **Build the UI and forms**

Once the class structure is in place, these pages help you shape how users interact with it in the platform.

* [Edit Object Class Configure Displays](/knowledgebase/system-configuration/object-classes/edit-object-class---configure-displays/)
* [Create A Standalone Form](/knowledgebase/system-configuration/object-classes/create-a-standalone-form/)
* [Editing A Standalone Form](/knowledgebase/system-configuration/object-classes/editing-a-standalone-form/)

### **Configure access and permissions**

These pages explain how access works at both class and record level, and how to configure permissions and assignee behaviour.

* [Explanation Of Class Permissions](/knowledgebase/system-configuration/object-classes/explanation-of-class-permissions/)
* [Explanation Of Record Permissions](/knowledgebase/system-configuration/object-classes/explanation-of-record-permissions/)
* [Edit Object Class Creating Class Permissions And Addremove Assignees](/knowledgebase/system-configuration/object-classes/edit-object-class---creating-class-permissions-and-addremove-assignees/)
* [Edit Object Class Editing Permission Sets](/knowledgebase/system-configuration/object-classes/edit-object-class---editing-permission-sets/)

## Suggested build flow

A sensible order for working with Object Classes is:

1. **Understand** what the class needs to represent.
2. **Create** the Object Class.
3. **Add and refine** the fields.
4. **Configure** displays and forms.
5. **Define** class and record permissions.
6. **Review** what can be edited safely once the class is in use.

## Where to go next

Once your Object Class structure is in place, the next related areas are often:

* [Object class relationships](/knowledgebase/system-configuration/object-class-relationships/)
* [Relational Modeller](/knowledgebase/system-configuration/relational-modeller/)
* [Task Templates](/knowledgebase/system-configuration/task-templates/)
* [Sequences](/knowledgebase/system-configuration/sequences/)
* [Working with Document Templates](/knowledgebase/system-configuration/working-with-document-templates/)

## Notes

::: info
This section is focused on designing and maintaining the structure of an Object Class itself — its fields, forms, displays, and permissions.
:::

::: tip
If you are new to building in Autologyx, a good place to begin is **What Are Object Classes?**, then **How Do I Create An Object Class**, followed by **Creating Object Class Fields**.
:::

---

---
url: /api/catalyst/resources/object-classes/object-class-document-templates.md
---
# Object Classes Document Template

This technical design describes implementation and API for Object Classes Document Template.

## POST /api/object-classes/`object_class_id`/document-templates/

Creates document template.

### Permissions

Requires `authentication` and `object_classes.edit` permission.

### Request

* URL parameters

| Key             | Type    | Notes       |
|-----------------|---------|-------------|
| object\_class\_id | pk      |             |

* Body parameters

| Key                         | Type   | Notes      |
|-----------------------------|--------|------------|
| name                        | string |            |
| description                 | string |            |
| template\_file               | string | File token |
| allow\_on\_demand\_generation  | bool   |            |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/object-classes/1/document-templates/

{
    "name": "Test Document Template",
    "description": "",
    "template_file": "9d1b16dc-db37-4631-8469-804c7d4048b2",
    "allow_on_demand_generation": true
}
```

### Validations

* name
  * is string
  * is required
  * unique (case insensitive) for the given Object Class
  * max length is 100
  * must be trimmed of white spaces
* description
  * is string
  * is optional
  * max length is 500
* template\_file
  * is a file type (accepts uploaded file token, see doc)
  * is required
  * only " .docx " files allowed
  * only 1 file is allowed
  * validate Jinja template syntax
  * validate merge tags:
    * related classes
* allow\_on\_demand\_generation
  * is bool

### Restrictions

* Up to 1000 Document Templates per Object Class can be added, limit is configurable per build.

### Response

| Key                        | Type     | Notes                                                                                             |
|----------------------------|----------|---------------------------------------------------------------------------------------------------|
| id                         | pk       | Automatically generated by the backend.                                                           |
| name                       | string   | Name of the document template                                                                     |
| description                | string   | Description of the document template                                                              |
| template\_file              | integer  | Id of the template file                                                                           |
| allow\_on\_demand\_generation | bool     |                                                                                                   |
| created\_at                 | datetime |                                                                                                   |
| warning                    | string   |                                                                                                   |
| created\_by                 | user     |                                                                                                   |
| modified\_at                | datetime |                                                                                                   |
| modified\_by                | user     |                                                                                                   |
| \_meta.labels.files         | Object   | [Object containing template files details](/api/catalyst/resources/object-classes/object-classes#response-meta-labels-files-object) |

### Response `_meta.labels.files` object

| Key                | Type      | Notes                                                   |
|--------------------|-----------|---------------------------------------------------------|
| name               | string    | Template file name with extension                       |
| url                | string    | Template file download URL                              |
| size               | string    | Template file size in bytes                             |
| type               | string    | Template file extension                                 |

* Successful status `201 Created`
* Response body:

```json
{
    "id": 1,
    "name": "Test Document Template",
    "description": "",
    "template_file": 27,
    "allow_on_demand_generation" : true,
    "warning" : "",
    "created_at": "2022-10-13T10:22:33.344172+02:00",
    "created_by": {
        "id": 2,
        "first_name": "John",
        "last_name": "Kovalsky",
        "username": "john.kovalsky@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "full"
    },
    "modified_at": "2022-10-13T10:22:33.344193+02:00",
    "modified_by": {
        "id": 2,
        "first_name": "John",
        "last_name": "Kovalsky",
        "username": "john.kovalsky@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "full"
    },
    "_meta": {
        "labels": {
            "files": {
                "27": {
                    "name": "test.docx",
                    "url": "http://client.testserve/api/object-classes/1/document-templates/1/download/",
                    "size": "8085",
                    "type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
                }
            }
        }
    }
}
```

### Errors

| Cause                                    | Response status code | Response message                                                                                     |
|------------------------------------------|----------------------|------------------------------------------------------------------------------------------------------|
| Invalid object\_class\_id in URL           | 403 Forbidden        | "detail": "You do not have permission to perform this action."                                       |
| name missing                             | 400 Bad Request      | "name": \["This field is required."]                                                                  |
| name is empty                            | 400 Bad Request      | "name": \[ "This field may not be blank." ]                                                           |
| name is null                             | 400 Bad Request      | "name": \[ "This field may not be null." ]                                                            |
| name not unique                          | 400 Bad Request      | "name": \["This field must be unique."]                                                               |
| name too long                            | 400 Bad Request      | "name": \["Ensure this field has no more than 100 characters."]                                       |
| description too long                     | 400 Bad Request      | "description": \["Ensure this field has no more than 500 characters."]                                |
| template\_file missing                    | 400 Bad Request      | "template\_file": \["This field is required."]                                                         |
| template\_file is null                    | 400 Bad Request      | "template\_file": \[ "This field may not be null." ]                                                   |
| template\_file not docx                   | 400 Bad Request      | "template\_file": \["Invalid file type."]                                                              |
| allow\_on\_demand\_generation invalid value | 400 Bad Request      | "allow\_on\_demand\_generation": \["Must be a valid boolean."]                                           |
| Exceeded max number of templates         | 400 Bad Request      | "detail": "Limit of 1000 Document Templates has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED"  |
| Document can't be parsed                 | 400 Bad Request      | "error": \["Error while parsing document. Please check the syntax."]                                  |
| Class not related                        | 400 Bad Request      | "error": \["Merge field { name } refers to a Class ID={id} which is not related with Class ID={id}."] |
| Insufficient permissions                 | 403 Forbidden        | "detail": "You do not have permission to perform this action."                                       |

## GET /api/object-classes/`object_class_id`/document-templates/

Returns list of document templates.

### Permissions

Requires `authentication` and `object_classes.edit` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/object-classes/`object_class_id`/document-templates/
```

### Response

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

#### Response `results` array

| Key                        | Type     | Notes                                                                                             |
|----------------------------|----------|---------------------------------------------------------------------------------------------------|
| id                         | pk       | Automatically generated by the backend.                                                           |
| name                       | string   | Name of the document template                                                                     |
| description                | string   | Description of the document template                                                              |
| template\_file              | integer  | Id of the template file                                                                           |
| template\_file\_name         | string   | Name of the template file without extension                                                       |
| allow\_on\_demand\_generation | bool     |                                                                                                   |
| warning                    | string   |                                                                                                   |
| created\_at                 | datetime |                                                                                                   |
| created\_by                 | user     |                                                                                                   |
| modified\_at                | datetime |                                                                                                   |
| modified\_by                | user     |                                                                                                   |
| \_meta.labels.files         | Object   | [Object containing template files details](/api/catalyst/resources/object-classes/object-classes#response-meta-labels-files-object) |

* Successful status `200 OK`
* Response body schema

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 3,
      "name": "Document Templates Test",
      "description": "",
      "template_file": 29,
      "template_file_name": "test",
      "allow_on_demand_generation": true,
      "warning": "",
      "created_at": "2022-10-17T11:29:01.694549+02:00",
      "created_by": {
        "id": 2,
        "first_name": "John",
        "last_name": "Kovalsky",
        "username": "john.kovalsky@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "full"
      },
      "modified_at": "2022-10-17T11:29:01.694569+02:00",
      "modified_by": {
        "id": 2,
        "first_name": "John",
        "last_name": "Kovalsky",
        "username": "john.kovalsky@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "full"
      },
      "_meta": {
        "labels": {
          "files": {
            "29": {
              "name": "test.docx",
              "url": "/api/object-classes/1/document-templates/3/download/",
              "size": "152199",
              "type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
            }
          }
        }
      }
    }
  ]
}
```

### Sorting

| Parameter                   | Example                                                                                   | Notes          |
|-----------------------------|-------------------------------------------------------------------------------------------|----------------|
| id                          | {build}/api/object-classes/id/document-templates/?ordering=id                           | Ascending      |
| id                          | {build}/api/object-classes/id/document-templates/?ordering=-id                          | Descending (-) |
| name                        | {build}/api/object-classes/id/document-templates/?ordering=name                         | Ascending      |
| name                        | {build}/api/object-classes/id/document-templates/?ordering=-name                        | Descending (-) |
| allow\_on\_demand\_generation  | {build}/api/object-classes/id/document-templates/?ordering=allow\_on\_demand\_generation   | Ascending      |
| allow\_on\_demand\_generation  | {build}/api/object-classes/id/document-templates/?ordering=-allow\_on\_demand\_generation  | Descending (-) |
| created\_at                  | {build}/api/object-classes/id/document-templates/?ordering=created\_at                   | Ascending      |
| created\_at                  | {build}/api/object-classes/id/document-templates/?ordering=-created\_at                  | Descending (-) |
| modified\_at                 | {build}/api/object-classes/id/document-templates/?ordering=modified\_at                  | Ascending      |
| modified\_at                 | {build}/api/object-classes/id/document-templates/?ordering=-modified\_at                 | Descending (-) |

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter                  | Type     |
|----------------------------|----------|
| uuid                       | uuid     |
| name                       | string   |
| template\_file\_name         | string   |
| allow\_on\_demand\_generation | bool     |
| warning                    | string   |
| created\_at                 | datetime |
| created\_by                 | user     |
| modified\_at                | datetime |
| modified\_by                | user     |

### Errors

| Error                         | Response code   | Message                                                                             |
|-------------------------------|-----------------|-------------------------------------------------------------------------------------|
| Wrong ordering value          | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."] |

## GET /api/object-classes/`object_class_id`/document-templates/`document_template_id`/

### Permissions

Requires `authentication` and `document-templates.edit` permission.

### Request

* URL parameters

| Key                  | Type    | Notes       |
|----------------------|---------|-------------|
| object\_class\_id      | id      |             |
| document\_template\_id | id      |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/object-classes/`task_group_templates_id`/document-templates/`document_template_id`
```

### Response

| Key                        | Type     | Notes                                           |
|----------------------------|----------|-------------------------------------------------|
| id                         | pk       | Automatically generated by the backend.         |
| name                       | string   | Name of the document template                   |
| description                | string   | Description of the document template            |
| template\_file              | integer  | Id of the template file                         |
| allow\_on\_demand\_generation | bool     | Id of the template file                         |
| warning                    | string   | Id of the template file                         |
| created\_at                 | datetime |                                                 |
| created\_by                 | user     |                                                 |
| modified\_at                | datetime |                                                 |
| modified\_by                | user     |                                                 |
| \_meta.labels.files         | Object   | [Object containing template files details](/api/catalyst/resources/object-classes/object-classes#response-meta-labels-files-object) |

### Response example

* Status `200 OK`
* Body

```json
{
    "id": 1,
    "name": "Test Document Template",
    "description": "",
    "template_file": 1,
    "allow_on_demand_generation" : true,
    "warning" : "",
    "created_at": "2022-10-13T10:22:33.344172+02:00",
    "created_by": {
        "id": 2,
        "first_name": "John",
        "last_name": "Kovalsky",
        "username": "john.kovalsky@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "full"
    },
    "modified_at": "2022-10-13T10:22:33.344193+02:00",
    "modified_by": {
        "id": 2,
        "first_name": "John",
        "last_name": "Kovalsky",
        "username": "john.kovalsky@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "full"
    },
    "_meta": {
        "labels": {
            "files": {
                "27": {
                    "name": "test.docx",
                    "url": "http://client.testserve/api/object-classes/1/document-templates/1/download/",
                    "size": "8085",
                    "type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
                }
            }
        }
    }
}
```

### Sorting

Not supported

### Filtering

Not supported

### Errors

| Error                                           | Response code  | Message                                                        |
|-------------------------------------------------|----------------|----------------------------------------------------------------|
| A non-existent `document_template_id` was given | 404 Not Found  | "detail": "Not found."                                         |
| A non-existent `object_class_id` was given      | 404 Not Found  | "detail": "Not found."                                         |
| Insufficient permissions                        | 403 Forbidden  | "detail": "You do not have permission to perform this action." |

## PATCH /api/object-classes/`object_class_id`/document-templates/`document_template_id`/

Updates single document template.

### Permissions

Requires `authentication` and `object_classes.edit` permission.

### Request

* URL parameters

| Key                          | Type   | Notes |
|------------------------------|--------|-------|
| object\_class\_id              | pk     |       |
| document\_template\_id         | pk     |       |
| allow\_on\_demand\_generation   | bool   |       |

* Body parameters

| Key           | Type     | Notes       |
|---------------|----------|-------------|
| name          | string   |             |
| description   | string   |             |
| template\_file | string   | File token  |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
PATCH /api/object-classes/1/document-templates/1/

{
    "name": "Test Document Template",
    "description": "",
    "template_file": "9d1b16dc-db37-4631-8469-804c7d4048b2",
    "allow_on_demand_generation" : true
}
```

### Response

| Key                         | Type     | Notes                                                                                             |
|-----------------------------|----------|---------------------------------------------------------------------------------------------------|
| id                          | pk       | Automatically generated by the backend.                                                           |
| name                        | string   | Name of the document template                                                                     |
| description                 | string   | Description of the document template                                                              |
| template\_file               | integer  | Id of the template file                                                                           |
| allow\_on\_demand\_generation  | bool     |                                                                                                   |
| warning                     | string   |                                                                                                   |
| created\_at                  | datetime |                                                                                                   |
| created\_by                  | user     |                                                                                                   |
| modified\_at                 | datetime |                                                                                                   |
| modified\_by                 | user     |                                                                                                   |
| \_meta.labels.files          | Object   | [Object containing template files details](/api/catalyst/resources/object-classes/object-classes#response-meta-labels-files-object) |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": 1,
    "name": "Test Document Template",
    "description": "",
    "template_file": 27,
    "allow_on_demand_generation" : true,
    "warning" : "",
    "created_at": "2022-10-13T10:22:33.344172+02:00",
    "created_by": {
        "id": 2,
        "first_name": "John",
        "last_name": "Kovalsky",
        "username": "john.kovalsky@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "full"
    },
    "modified_at": "2022-10-13T10:22:33.344193+02:00",
    "modified_by": {
        "id": 2,
        "first_name": "John",
        "last_name": "Kovalsky",
        "username": "john.kovalsky@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "full"
    },
    "_meta": {
        "labels": {
            "files": {
                "27": {
                    "name": "test.docx",
                    "url": "http://client.testserve/api/object-classes/1/document-templates/1/download/",
                    "size": "8085",
                    "type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
                }
            }
        }
    }
}
```

### Errors

| Cause                                     | Response status code | Response message                                                                                     |
|-------------------------------------------|----------------------|------------------------------------------------------------------------------------------------------|
| Invalid object\_class\_id in URL            | 403 Forbidden        | "detail": "You do not have permission to perform this action."                                       |
| Invalid id in URL                         | 404 Not Found        | "detail": \["Not found."]                                                                             |
| name missing                              | 400 Bad Request      | "name": \["This field is required."]                                                                  |
| name is empty                             | 400 Bad Request      | "name": \[ "This field may not be blank." ]                                                           |
| name is null                              | 400 Bad Request      | "name": \[ "This field may not be null." ]                                                            |
| name not unique                           | 400 Bad Request      | "name": \["This field must be unique."]                                                               |
| name to long                              | 400 Bad Request      | "name": \["Ensure this field has no more than 100 characters."]                                       |
| description to long                       | 400 Bad Request      | "description": \["Ensure this field has no more than 500 characters."]                                |
| template\_file missing                     | 400 Bad Request      | "template\_file": \["This field is required."]                                                         |
| template\_file is null                     | 400 Bad Request      | "template\_file": \[ "This field may not be null." ]                                                   |
| template\_file not docx                    | 400 Bad Request      | "template\_file": \["Invalid file type."]                                                              |
| allow\_on\_demand\_generation invalid value  | 400 Bad Request      | "allow\_on\_demand\_generation": \["Must be a valid boolean."]                                           |
| Exceeded max number of templates          | 400 Bad Request      | "detail": "Limit of 1000 Document Templates has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED"  |
| Document can't be parsed                  | 400 Bad Request      | "error": \["Error while parsing document. Please check the syntax."]                                  |
| Class not related                         | 400 Bad Request      | "error": \["Merge field { name } refers to a Class ID={id} which is not related with Class ID={id}."] |
| Insufficient permissions                  | 403 Forbidden        | "detail": "You do not have permission to perform this action."                                       |

## DELETE /api/object-classes/`object_class_id`/document-templates/`document_template_id`/

Deletes single document template.

::: tip Important
During deletion, the use of Document Template in Sequences is checking.
:::

### Permissions

Requires `authentication` and `object_classes.edit` permission.

### Request

* URL parameters

| Key                  | Type    | Notes       |
|----------------------|---------|-------------|
| object\_class\_id      | pk      |             |
| document\_template\_id | pk      |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
DELETE /api/object-classes/1/document-templates/1/
```

### Response

* Successful status `204 No Content`

### Errors

| Error                             | Response code     | Message                                                        |
|-----------------------------------|-------------------|----------------------------------------------------------------|
| `object_class_id` is invalid      | 404 Bad Request   | "detail": "Not found."                                         |
| `document_template_id` is invalid | 404 Bad Request   | "detail": "Not found."                                         |
| Unauthorized API call	            | 403 Bad Request   | "detail": "You do not have permission to perform this action." |
| `Document Template` is in use     | 400 Bad Request   | "detail": "Document Template is in use by Sequences."          |

## GET /api/object-classes/`object_class_id`/document-templates/`document_template_id`/usage/

### Permissions

Requires `authentication` and `object_classes.view` permission.

### Request

* URL parameters

| Key                  | Type    | Notes       |
|----------------------|---------|-------------|
| object\_class\_id      | pk      |             |
| document\_template\_id | pk      |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| num\_of\_sequences  | int        |                                                                                  |
| sequences         | Array      |                                                                                  |

### Response `sequences` array

| Key          | Type       | Notes                                          |
|--------------|------------|------------------------------------------------|
| id           | int        | Sequence id                                    |
| name         | string     | Name of sequence                               |

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "num_of_sequences": 1, 
    "sequences": [
        {
            "id": 1,
            "name": "Sample sequence"
        }
    ]
}
```

### Errors

| Error                             | Response code   | Message                                                        |
|-----------------------------------|-----------------|----------------------------------------------------------------|
| `object_class_id` is invalid      | 404 Bad Request | 'detail': "Not found."                                         |
| `document_template_id` is invalid | 404 Bad Request | 'detail': "Not found."                                         |
| Unauthorized API call	            | 403 Bad Request | 'detail': "You do not have permission to perform this action." |

## OPTIONS /api/object-classes/`object_class_id`/document-templates/

### Permissions

Requires `authentication` and `object_classes.edit` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/object-classes/1/document-templates/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "name",
                "type": "string",
                "predicates": [
                    "exact",
                    "iexact",
                    "contains",
                    "icontains",
                    "startswith",
                    "istartswith",
                    "endswith",
                    "iendswith"
                ],
                "sort_ok": true
            },
            {
                "alias": "description",
                "type": "string",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "template_file_name",
                "type": "string",
                "predicates": [
                    "exact",
                    "iexact",
                    "contains",
                    "icontains",
                    "startswith",
                    "istartswith",
                    "endswith",
                    "iendswith"
                ],
                "sort_ok": false
            },
            {
                "alias": "allow_on_demand_generation",
                "type": "bool",
                "predicates": [
                    "exact"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "modified_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "modified_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            }
        ]
    },
    "details": {
        "schema": [
            {
                "alias": "name",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "min_length",
                        "length": 1
                    },
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "description",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 500
                    }
                ]
            },
            {
                "alias": "template_file",
                "type": "file",
                "required": true,
                "validators": [
                    {
                        "type": "allowed_extensions",
                        "extensions": [
                            "docx"
                        ]
                    },
                    {
                        "type": "max_size",
                        "size": 1
                    }
                ]
            }
        ]
    },
    "restrictions": {
        "limit_items_in_object_class": 1000
    }
}
```

## POST /api/object-classes/`object_class_id`/document-templates/verify/

Creates document template.

### Permissions

Requires `authentication` and `object_classes.edit` permission.

### Request

* URL parameters

| Key             | Type    | Notes       |
|-----------------|---------|-------------|
| object\_class\_id | pk      |             |

* Body parameters

| Key            | Type     | Notes                                                    |
|----------------|----------|----------------------------------------------------------|
| template\_file  | string   | Temporary File token or ID of Object Class Document File |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/object-classes/1/document-templates/verify/

{
    "template_file": "9d1b16dc-db37-4631-8469-804c7d4048b2"
}
```

### Validations

* template\_file
  * is required
  * is Temporary file token or Object Class Document File ID
  * validate Jinja template syntax
  * validate merge tags:
    * related classes
    * class fields

### Response

#### For valid template

* Successful status `204 No Content`

#### For invalid template

| Key   | Type            | Notes                 |
|-------|-----------------|-----------------------|
| error | Array\[string]   | List of found issues. |

#### For invalid class fields

| Key     | Type            | Notes                 |
|---------|-----------------|-----------------------|
| warning | Array\[string]   | List of found issues. |

### Responses

| Cause                    | Response status code | Response message                                                                                                               |
|--------------------------|----------------------|--------------------------------------------------------------------------------------------------------------------------------|
| Document can't be parsed | 200 OK               | "error": \["Error while parsing document. Please check the syntax."]                                                            |
| Class not related        | 200 OK               | "error": \["Merge field { name } refers to a Class ID={id} which is not related with Class ID={id}."]                           |
| Class field not valid    | 200 OK               | "warning": \["Merge field { record.field\_unknown } refers to a Field field\_unknown which is not available in Class ID={id}."]   |

* Successful status `200 OK`
* Response body:

```json
{
  "error": ["Merge field record refers to a Class ID=999 which is not related with Class ID=1."]
}
```

### Errors

| Cause                                                                                      | Response status code | Response message                                               |
|--------------------------------------------------------------------------------------------|----------------------|----------------------------------------------------------------|
| Invalid object\_class\_id in URL                                                             | 403 Forbidden        | "detail": "You do not have permission to perform this action." |
| Wrong file ID of object class document template or not related file to passed object class | 400 Bad Request      | "template\_file": \["Invalid file\_id {file\_id}."]                |
| Wrong file token                                                                           | 400 Bad Request      | "template\_file": \["Invalid token {token}."]                    |
| Insufficient permissions                                                                   | 403 Forbidden        | "detail": "You do not have permission to perform this action." |

## GET /api/object-classes/`object_class_id`/document-templates/`document_template_id`/download/

Download a given document template.

### Permissions

Requires `authentication` and `object_classes.view` permission for object class related to a given file.

### Request

* URL parameters

| Key                  | Type    | Notes       |
|----------------------|---------|-------------|
| object\_class\_id      | pk      |             |
| document\_template\_id | pk      |             |

* Headers

```
Content-Type: <MIME type>
Content-Disposition: <disposition>; filename="<filename>"
Content-Length: <file size in bytes>
Authorization: JWT access_token
```

### Response

* Successful status `200 OK`
* Response body:
*

The body will be the raw contents of the file.

### Errors

| Error                             | Response code   | Message                                                        |
|-----------------------------------|-----------------|----------------------------------------------------------------|
| `object_class_id` is invalid      | 404 Bad Request | 'detail': "Not found."                                         |
| `document_template_id` is invalid | 404 Bad Request | 'detail': "Not found."                                         |
| Unauthorized API call	            | 403 Bad Request | 'detail': "You do not have permission to perform this action." |

---

---
url: /api/catalyst/resources/object-classes/object-class-permission-sets.md
---
# Object Classes Permission Sets

This document describes API endpoints for managing Object Class Permission Sets. Theirs setup is configurable at Object Class level.

## Permissions

| Permission                 | Manageable via Roles | Manageable via other ways                                                                                               | Description        |
|----------------------------|----------------------|-------------------------------------------------------------------------------------------------------------------------|--------------------|
| object\_class.view          | true                 | Object Class owner`view` by Object Class permission sets | Allows access list |
| object\_class.edit\_perm\_set | false                | Object Class owner                                                                                             |                    |

Permissions for Object Class Permission Sets can be checked by:

| Context               | Endpoint                                     | Location              | Available perms         |
|-----------------------|----------------------------------------------|-----------------------|-------------------------|
| Specific Object Class | `GET /api/object-classes/{object_class_id}/` | `_meta.permissions`   | `view`, `edit_perm_set` |

## References

* [Object Class Permission Sets - Technical Design](https://autologyx.sharepoint.com/:w:/s/Dev/EZeCcNT-DdJBuWSJnaftkdkBWRCOeAuIEUZKKDAe9SJPOg?e=7IR3PC)

## GET /api/object-classes/`object_class_id`/permission-sets/

Returns list of Object Class Permission Sets for specific Object Class.

### Permissions

Requires `authentication` and `object_class.view` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/object-classes/`object_class_id`/permission-sets/
```

### Response

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

#### Response `results` array

| Key         | Type     | Notes                                                        |
|-------------|----------|--------------------------------------------------------------|
| id              | int      |                                                                                                                         |
| name            | string   |                                                                                                                         |
| permissions     | Object   | Complex object containing enabled permissions for resources.                                                            |
| mcp\_permissions | Array    | One entry per MCP Connector associated with the Object Class, describing that connector's granted permissions. See below. |
| created\_at      | datetime |                                                                                                                         |
| created\_by      | user     |                                                                                                                         |
| modified\_at     | datetime |                                                                                                                         |
| modified\_by     | user     |                                                                                                                         |
| \_meta           | Object   | Human-readable labels for referenced entities. See below. |

##### `mcp_permissions` array

`mcp_permissions` is a read-only field (not writable via `POST`/`PATCH`). It contains one entry per MCP Connector currently associated with the Object Class (association is managed separately, via [MCP Connector Object Classes](/api/catalyst/resources/mcp/mcp-connector-object-classes)). Each entry has the following shape:

| Key         | Type   | Notes                                                                                                     |
|-------------|--------|-----------------------------------------------------------------------------------------------------------|
| connector   | int    | MCP Connector id. Resolve the display name via `_meta.labels.connectors["<id>"]["name"]`.                 |
| permissions | Object | Granted permissions for this connector, using the same "resource → list of granted actions" shape as the top-level `permissions` field. |

Semantics:

* One entry per associated MCP Connector, ordered by connector `id`.
* `mcp_permissions[].connector` is always just the id (int); the connector name is provided separately in `_meta.labels.connectors`.
* If a connector is associated with the Object Class but has **no** saved permissions for this Permission Set, its entry is still returned, with empty lists for every resource (fail-closed). For example: `{ "connector": 7, "permissions": {"object_classes": [], "object_records": [], "tasks": []} }`.
* If no MCP Connectors are associated with the Object Class, `mcp_permissions` is an empty list (`[]`) and `_meta.labels.connectors` is an empty object (`{}`).

##### `_meta`

`_meta` is a read-only block following the existing `_meta.labels` convention. It maps each connector id referenced in `mcp_permissions` to its label:

```json
"_meta": {
  "labels": {
    "connectors": {
      "<id>": { "name": <str> }
    }
  }
}
```

* Successful status `200 OK`
* Response body schema

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str>,
  "previous": <str>,
  "results": [
    {
      "id": <int>,  
      "name": <str>, 
      "permissions": {
        "object_classes": [<str>],
        "object_records": [<str>],
        "tasks": [<str>]
      },
      "mcp_permissions": [
        {
          "connector": <int>,
          "permissions": {
            "object_classes": [<str>],
            "object_records": [<str>],
            "tasks": [<str>]
          }
        }
      ],
      "created_at": <datetime>,
      "created_by": <user>,
      "modified_at": <datetime>,
      "modified_by": <user>,
      "_meta": {
        "labels": {
          "connectors": {
            "<id>": {"name": <str>}
          }
        }
      }
    }
  ]  
}
```

* Response example

```json
{
  "limit": 50,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 12,
      "name": "Legal Reviewers",
      "permissions": {
        "object_classes": ["view"],
        "object_records": ["view", "edit"],
        "tasks": []
      },
      "mcp_permissions": [
        {
          "connector": 3,
          "permissions": {
            "object_classes": ["view"],
            "object_records": [],
            "tasks": ["edit"]
          }
        },
        {
          "connector": 7,
          "permissions": {"object_classes": [], "object_records": [], "tasks": []}
        }
      ],
      "created_at": "2026-08-03T10:00:00Z",
      "created_by": <user>,
      "modified_at": "2026-08-03T10:00:00Z",
      "modified_by": <user>,
      "_meta": {
        "labels": {
          "connectors": {
            "3": {"name": "Payroll connector"},
            "7": {"name": "Audit connector"}
          }
        }
      }
    }
  ]
}
```

### Sorting

Not available. Results are sorted by {id} ascending.

### Filtering

Not available.

### Errors

| Error                                         | Response code | Message                                                        |
|-----------------------------------------------|---------------|----------------------------------------------------------------|
| Object Class for {object\_class\_id} not found. | 404 Not found |                                                                |
| Insufficient permissions                      | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## POST /api/object-classes/`object_class_id`/permission-sets/

Creates single Object Class Permission Set.

### Permissions

Requires `authentication` and `object_class.edit_perm_set` permission.

### Request

* URL parameters

| Key             | Notes              |
|-----------------|--------------------|
| object\_class\_id | Object Class ID    |

* Body parameters

| Key           | Type   | Notes                                                                                       |
|---------------|--------|---------------------------------------------------------------------------------------------|
| name          | string | Unique (case insensitive) for the given Object Class.                                       |
| permissions   | Object | Optional. Complex object containing configuration for resources' permissions to be enabled. |

Available resources for `permissions`:

* `object_classes`
* `object_records`
* `tasks`

`object_classes`, `object_records`, `tasks` keys contain list of actions. By default, permissions are disabled if not given in request's body.

Valid actions for resources:

| object\_classes                                         | object\_records                             | tasks                                                                                     |
|--------------------------------------------------------|--------------------------------------------|-------------------------------------------------------------------------------------------|
| listeditviewdelete | editviewdelete  | createeditviewdeletecompleteassign  |

Sent permissions are converted with dependencies described in [technical doc](https://autologyx.sharepoint.com/:w:/s/Dev/EZeCcNT-DdJBuWSJnaftkdkBWRCOeAuIEUZKKDAe9SJPOg?e=7IR3PC).

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/object-classes/`object_class_id`/permission-sets/

{
  "name": <str>, 
  "permissions": {
    "object_classes": [<str>],
    "object_records": [<str>],
    "tasks": [<str>] 
  } 
}
```

* Request example

```json
{
  "name": "PermSet", 
  "permissions": {
    "object_classes": ["list", "view"],
    "object_records": ["edit"],
    "tasks": ["edit", "create"] 
  } 
} 
```

### Validations

* name
  * Max length: 100
  * Unique: for specific Object Class
* Maximum number of Object Class Permission Sets per specific Object Class: 10.

### Response

| Key         | Type     | Notes                                                     |
|-------------|----------|-----------------------------------------------------------|
| id          | int      | Automatically generated by the backend.                   |
| name        | string   |                                                           |
| permissions | Object   | Complex object contains saved permissions' configuration. |
| created\_at  | datetime |                                                           |
| created\_by  | user     |                                                           |
| modified\_at | datetime |                                                           |
| modified\_by | user     |                                                           |

* Successful status `201 Created`
* Response body schema

```json
{
  "id": <int>, 
  "name": <str>, 
  "permissions": {
    "object_classes": [<str>],
    "object_records": [<str>],
    "tasks":          [<str>] 
  }, 
  "created_at": <datetime>, 
  "created_by": <user>, 
  "modified_at": <datetime>, 
  "modified_by": <user> 
} 
```

### Errors

| Error                                              | Response code   | Message                                                                                                     |
|----------------------------------------------------|-----------------|-------------------------------------------------------------------------------------------------------------|
| "name" is missing                                  | 400 Bad Request | "name": \[ "This field is required." ]                                                                       |
| "name" is empty string                             | 400 Bad Request | "name": \[ "This field may not be blank." ]                                                                  |
| "name" is null                                     | 400 Bad Request | "name": \[ "This field may not be null." ]                                                                   |
| "name" has > 100 chars                             | 400 Bad Request | "name": \[ "Ensure this field has no more than 100 characters." ]                                            |
| "name" is not unique for specific Object Class     | 400 Bad Request | "name": \[ "This field must be unique." ]                                                                    |
| Given NULL for `permissions`                       | 400 Bad Request | "permissions": \["This field may not be null."]                                                              |
| Given wrong resource name for `permissions`        | 400 Bad Request | "permissions": \["Invalid resource \\"{given\_wrong\_resource\_name}\\"."]                                      |
| Given NULL for resource in `permissions`           | 400 Bad Request | "permissions": {"{resource\_name}": \["This field may not be null."] }                                        |
| Given wrong value for resource in `permissions`    | 400 Bad Request | "permissions": {"{resource\_name}": \["Invalid actions \\"{given\_wrong\_value}\\"."] }                         |
| Max 10 Permission Sets per class exceeded          | 400 Bad Request | "detail": "Limit of 10 Object Class Permission Sets has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED" |
| Object Class with {object\_class\_id} does not exist | 404 Not found   | 	                                                                                                           |
| Insufficient permissions                           | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                              |

## PATCH /api/object-classes/`object_class_id`/permission-sets/`id`/

Updates single Object Class Permission Set.

The endpoint also allows configuring permissions available through MCP Connectors associated with the Object Class.

### Permissions

Requires `authentication` and `object_class.edit_perm_set` permission.

### Request

* URL parameters

| Key             | Notes                          |
| --------------- | ------------------------------ |
| object\_class\_id | Object Class ID                |
| id              | Object Class Permission Set ID |

* Body parameters

| Key             | Type   | Notes                                                                                 |
| --------------- | ------ | ------------------------------------------------------------------------------------- |
| name            | string | Unique (case insensitive) for the given Object Class. Max length = 100 (configurable) |
| permissions     | Object | Complex object containing configuration for resources' permissions to be enabled.     |
| mcp\_permissions | Array  | Permissions granted to individual MCP Connectors associated with the Object Class.    |

Any parameters not listed above are silently ignored if passed.

#### `permissions`

Available resource keys for `permissions`:

* `object_classes`
* `object_records`
* `tasks`

`object_classes`, `object_records`, `tasks` keys contain lists of actions. All are optional. If a resource is omitted, permissions for it will not be modified.

Valid actions for resources:

| object\_classes           | object\_records     | tasks                                        |
| ------------------------ | ------------------ | -------------------------------------------- |
| list, edit, view, delete | edit, view, delete | create, edit, view, delete, complete, assign |

Sent permissions are converted with dependencies described in [technical doc](https://autologyx.sharepoint.com/:w:/s/Dev/EZeCcNT-DdJBuWSJnaftkdkBWRCOeAuIEUZKKDAe9SJPOg?e=7IR3PC).

> :warning: If fewer actions are sent than are already configured, actions not included in the request will be **removed** if they are not required by other enabled actions.
>
> For instance:
>
> Current actions: `["view", "edit"]`. Sent actions: `["view"]`. Result actions: `["view"]`.

#### `mcp_permissions`

`mcp_permissions` contains permissions granted to individual MCP Connectors.

Each item has the following structure:

| Key         | Type   | Notes                                                    |
| ----------- | ------ | -------------------------------------------------------- |
| connector   | int    | ID of an MCP Connector associated with the Object Class. |
| permissions | Object | Permissions available through this connector.            |

Available resources and actions in `mcp_permissions.permissions` are the same as for the main `permissions` field.

The same permission dependencies are applied to MCP permissions. For example, if an action requires another action, the required action is automatically enabled according to the standard permission dependency rules.

MCP permissions can never exceed permissions granted by the Permission Set itself. After resolving dependencies, every MCP permission must also be present in the corresponding main `permissions` resource.

For example, given:

```json
{
  "permissions": {
    "object_classes": ["view"]
  }
}
```

the following MCP configuration is valid:

```json
{
  "mcp_permissions": [
    {
      "connector": 10,
      "permissions": {
        "object_classes": ["view"]
      }
    }
  ]
}
```

but granting an additional action unavailable in the Permission Set is rejected:

```json
{
  "mcp_permissions": [
    {
      "connector": 10,
      "permissions": {
        "object_classes": ["edit"]
      }
    }
  ]
}
```

If `mcp_permissions` is omitted, MCP permissions are not directly modified.

If a connector is included in `mcp_permissions`, only permissions for that connector are modified. Permissions configured for other MCP Connectors remain unchanged.

Resources omitted from `mcp_permissions[].permissions` are not modified for that connector.

If main `permissions` are reduced, existing MCP permissions that would exceed the resulting Permission Set permissions are automatically removed. This applies to all MCP Connectors configured for the Permission Set, including connectors omitted from the request.

For example:

Current configuration:

```json
{
  "permissions": {
    "object_classes": ["view", "edit"]
  },
  "mcp_permissions": [
    {
      "connector": 10,
      "permissions": {
        "object_classes": ["view", "edit"]
      }
    }
  ]
}
```

Request:

```json
{
  "permissions": {
    "object_classes": ["view"]
  }
}
```

Result:

```json
{
  "permissions": {
    "object_classes": ["view"]
  },
  "mcp_permissions": [
    {
      "connector": 10,
      "permissions": {
        "object_classes": ["view"]
      }
    }
  ]
}
```

> :warning: `mcp_permissions` can only be modified using this `PATCH` endpoint.

* Headers

```text
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
PATCH /api/object-classes/`object_class_id`/permission-sets/`id`/

{
  "name": <str>,
  "permissions": {
    "object_classes": [<str>],
    "object_records": [<str>],
    "tasks": [<str>]
  },
  "mcp_permissions": [
    {
      "connector": <int>,
      "permissions": {
        "object_classes": [<str>],
        "object_records": [<str>],
        "tasks": [<str>]
      }
    }
  ]
}
```

All top-level fields are optional for PATCH.

Resource keys inside `permissions` and `mcp_permissions[].permissions` are also optional.

* Request example

```json
{
  "name": "PermSet",
  "permissions": {
    "object_classes": ["list", "view", "edit"],
    "object_records": ["view", "edit"],
    "tasks": ["view", "edit", "create"]
  },
  "mcp_permissions": [
    {
      "connector": 10,
      "permissions": {
        "object_classes": ["view", "edit"],
        "object_records": ["view"],
        "tasks": ["view"]
      }
    }
  ]
}
```

### Response

| Key             | Type     | Notes                                                                      |
| --------------- | -------- | -------------------------------------------------------------------------- |
| id              | int      |                                                                            |
| name            | string   |                                                                            |
| permissions     | Object   | Effective Permission Set permissions after resolving dependencies.         |
| mcp\_permissions | Array    | Effective permissions for MCP Connectors associated with the Object Class. |
| created\_at      | datetime |                                                                            |
| created\_by      | user     |                                                                            |
| modified\_at     | datetime |                                                                            |
| modified\_by     | user     |                                                                            |
| \_meta           | Object   | Additional labels for identifiers used in the response.                    |

* Successful status `200 OK`
* Response body schema:

```json
{
  "id": <int>,
  "name": <str>,
  "permissions": {
    "object_classes": [<str>, ...],
    "object_records": [<str>, ...],
    "tasks": [<str>, ...]
  },
  "mcp_permissions": [
    {
      "connector": <int>,
      "permissions": {
        "object_classes": [<str>, ...],
        "object_records": [<str>, ...],
        "tasks": [<str>, ...]
      }
    },
    ...
  ],
  "created_at": <datetime>,
  "created_by": <user>,
  "modified_at": <datetime>,
  "modified_by": <user>,
  "_meta": {
    "labels": {
      "connectors": {
        "<connector_id>": {
          "name": <str>
        }
      }
    }
  }
}
```

`mcp_permissions` contains one entry for each MCP Connector associated with the Object Class. If no permissions have been stored for a connector, its permission resources contain empty action lists.

Connector names are exposed separately in `_meta.labels.connectors`. The keys in `connectors` correspond to IDs referenced by `mcp_permissions[].connector`.

Example:

```json
{
  "mcp_permissions": [
    {
      "connector": 10,
      "permissions": {
        "object_classes": ["view"],
        "object_records": [],
        "tasks": []
      }
    }
  ],
  "_meta": {
    "labels": {
      "connectors": {
        "10": {
          "name": "Payroll connector"
        }
      }
    }
  }
}
```

### Errors

| Error                                                      | Response code   | Message                                                                                        |
| ---------------------------------------------------------- | --------------- | ---------------------------------------------------------------------------------------------- |
| `"name"` is empty string                                   | 400 Bad Request | `"name": ["This field may not be blank."]`                                                     |
| `"name"` is null                                           | 400 Bad Request | `"name": ["This field may not be null."]`                                                      |
| `"name"` has > 100 chars                                   | 400 Bad Request | `"name": ["Ensure this field has no more than 100 characters."]`                               |
| `"name"` is not unique for specific Object Class           | 400 Bad Request | `"name": ["This field must be unique."]`                                                       |
| Given NULL for `permissions`                               | 400 Bad Request | `"permissions": ["This field may not be null."]`                                               |
| Given wrong resource name for `permissions`                | 400 Bad Request | `"permissions": ["Invalid resource \"{given_wrong_resource_name}\"."]`                         |
| Given NULL for resource in `permissions`                   | 400 Bad Request | `"permissions": {"{resource_name}": ["This field may not be null."]}`                          |
| Given wrong action value for resource in `permissions`     | 400 Bad Request | `"permissions": {"{resource_name}": ["Invalid actions \"{given_wrong_value}\"."]}`             |
| Given NULL for `mcp_permissions`                           | 400 Bad Request | `"mcp_permissions": ["This field may not be null."]`                                           |
| Missing `connector` in an `mcp_permissions` item           | 400 Bad Request | `"mcp_permissions": [{"connector": ["This field is required."]}]`                              |
| Given NULL for `connector`                                 | 400 Bad Request | `"mcp_permissions": [{"connector": ["This field may not be null."]}]`                          |
| MCP Connector with given `connector` ID does not exist     | 404 Not Found   | Standard not-found response                                                                    |
| MCP Connector is not associated with the Object Class      | 400 Bad Request | `"detail": ["Invalid pk \"{id}\" - MCP connector is not associated with this Object Class."]`  |
| Given wrong resource name for MCP `permissions`            | 400 Bad Request | Invalid resource error for `mcp_permissions[].permissions`                                     |
| Given NULL for resource in MCP `permissions`               | 400 Bad Request | Null resource error for `mcp_permissions[].permissions`                                        |
| Given wrong action value for resource in MCP `permissions` | 400 Bad Request | Invalid action error for `mcp_permissions[].permissions`                                       |
| MCP permissions exceed main Permission Set permissions     | 400 Bad Request | `"Invalid actions \"{actions}\" for \"{resource}\" - exceeds the Permission Set's own grant."` |
| Object Class with `{object_class_id}` does not exist       | 404 Not Found   |                                                                                                |
| Object Class Permission Set with `{id}` does not exist     | 404 Not Found   |                                                                                                |
| Insufficient permissions                                   | 403 Forbidden   | `"detail": "You do not have permission to perform this action."`                               |

## DELETE /api/object-classes/`object_class_id`/permission-sets/`id`/

Deletes single Object Class Permission Set.

### Permissions

Requires `authentication` and `object_class.edit_perm_set` permission.

### Request

* URL parameters

| Key             | Notes                          |
|-----------------|--------------------------------|
| object\_class\_id | Object Class ID                |
| id              | Object Class Permission Set ID |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
DELETE /api/object-classes/`object_class_id`/permission-sets/`id`/
```

### Response

* Successful status `204 No Content`

### Errors

| Error                                                  | Response code | Message                                                        |
|--------------------------------------------------------|---------------|----------------------------------------------------------------|
| Object Class with "{object\_class\_id}" does not exist   | 404 Not found | 	                                                              |
| Object Class Permission Set with "{id}" does not exist | 404 Not Found | 	                                                              |
| Insufficient permissions                               | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## OPTIONS /api/object-classes/`object_class_id`/permission-sets/

### Permissions

Requires `authentication` only.

### Request

* URL parameters

| Key             | Notes              |
|-----------------|--------------------|
| object\_class\_id | Object Class ID    |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/object-classes/`object_class_id`/permission-sets/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
  "list": {
    "columns": [
      {
        "alias": "id",
        "type": "int",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "name",
        "type": "string",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "permissions",
        "type": "permissions",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "mcp_permissions",
        "type": "permissions",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_at",
        "type": "datetime",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_by",
        "type": "user",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "modified_at",
        "type": "datetime",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "modified_by",
        "type": "user",
        "predicates": [],
        "sort_ok": false
      }
    ]
  },
  "details": {
    "schema": [
      {
        "alias": "name",
        "type": "string",
        "required": true,
        "validators": [
          {
            "type": "min_length",
            "length": 1
          },
          {
            "type": "max_length",
            "length": 100
          }
        ]
      },
      {
        "alias": "permissions",
        "type": "permissions",
        "required": false,
        "schema": [
          {
            "resource": "object_classes",
            "actions": [
              "list",
              "view",
              "edit",
              "delete"
            ]
          },
          {
            "resource": "object_records",
            "actions": [
              "view",
              "edit",
              "delete",
              "create"
            ]
          },
          {
            "resource": "tasks",
            "actions": [
              "view",
              "edit",
              "delete",
              "create",
              "complete",
              "assign"
            ]
          }
        ]
      },
      {
        "alias": "mcp_permissions",
        "type": "permissions",
        "required": false,
        "schema": [
          {
            "resource": "object_classes",
            "actions": [
              "list",
              "view",
              "edit",
              "delete"
            ]
          },
          {
            "resource": "object_records",
            "actions": [
              "view",
              "edit",
              "delete",
              "create"
            ]
          },
          {
            "resource": "tasks",
            "actions": [
              "view",
              "create",
              "edit",
              "delete",
              "complete",
              "assign"
            ]
          }
        ]
      }
    ]
  },
  "restrictions": {
    "limit_items": 10
  }
} 
```

### Errors

| Error                                         | Response code    | Message |
|-----------------------------------------------|------------------|---------|
| Object Class for `object_class_id` not found. | 404 Not Found    |         |

## Not allowed endpoints

### GET /api/object-classes/`object_class_id`/permission-sets/`id`/

#### Response

* Status `405 Method Not Allowed`

---

---
url: /api/catalyst/resources/relational-model/object-models.md
---
# Object Models

This technical design describes implementation and API for Object Classes Relations.

# API

## POST /api/object-models/

::: danger

⚠️ NOTE: This endpoint has been marked for deprecattion from Catalyst **API 11.0.0**.
It's replacement is an improved endpoint that allows actions against full heirarchical structures, alleviating the need for multi-step transversal please visit: [Hierarchical records creation endpoints](/knowledgebase/release-notes/release-notes-1.11/hierarchical-records-creation-endpoints/) for more information!

:::

Creates Object Models.

### Permissions

Requires `authentication` and `SuperAdmin` permission.

### Request

* Headers

```
Request Method: POST
Authorization: JWT access_token
```

* Body

| Key            | Type   | Required | Notes                            |
|----------------|--------|----------|----------------------------------|
| name           | string | true     |                                  |
| description    | string | false    |                                  |
| object\_classes | Array  | true     | Relations between object classes |

#### Request `object_classes` array

| Key                     | Type    | Notes                                                                                                                                                                                                                                 |
|-------------------------|---------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| object\_class            | int     | Object Class id                                                                                                                                                                                                                       |
| multiplicity            | string  | Choices: (zero\_or\_more, zero\_or\_one)                                                                                                                                                                                                  |
| parent                  | int     | Object Class id                                                                                                                                                                                                                       |
| removable\_relation      | bool    | False if: Exists a relation between a record from the corresponding parent class and a record from the corresponding child class. Exists Sequence with Child added/removed event. Exists Relation Lookup with corresponding classes.  |
| modifiable\_multiplicity | bool    | False if there exist at least 2 relations between a single record from the corresponding parent class and several records from the corresponding child class and for all "root" classes.                                              |

#### Validations

* name
  * This field is required.
  * This field may not be blank.
  * This field may not be null.
  * Ensure this field has no more than 100 characters.
* description
  * This field may not be null.
  * Ensure this field has no more than 500 characters.
* object\_classes
  * This field is required.
  * This field may not be null.
  * non\_fields\_errors
    * Expected a list of items but got type \<type>.
    * Relation contains loop.
    * Limit of "limit" top parents exceeded.
  * object\_class
    * This field is required.
    * Invalid pk "value" - object does not exist.
    * This field may not be null.
    * The object class "value" might be given only once.
  * multiplicity
    * This field is required
    * This field may not be null.
    * "value" is not a valid choice.
  * parent
    * Invalid pk "value" - object does not exist.
    * Invalid pk "value" - Object Class not added to Object Model Definition.
    * Relation depth limit exceeded for Object Class ID \<value>.
    * Limit of "limit" children exceeded for Object Class ID \<value>.

### Sample request body

```json
POST /api/object-models/

{ 
  "name": "sample name",
  "description": "Sample description",
  "object_classes": [
    {
      "object_class": 6, 
      "multiplicity": "zero_or_one", 
      "parent": 7,
      "removable_relation": false,
      "modifiable_multiplicity": true
    },
     {
      "object_class": 7, 
      "multiplicity": "zero_or_one", 
      "parent": null,
      "removable_relation": true,
      "modifiable_multiplicity": false
    },
    {
      "object_class": 8, 
      "multiplicity": "zero_or_one", 
      "parent": 7,
      "removable_relation": true,
      "modifiable_multiplicity": false
    },
    {
      "object_class":9, 
      "multiplicity": "zero_or_one", 
      "parent": 8,
      "removable_relation": true,
      "modifiable_multiplicity": false
    },
    {
      "object_class":10, 
      "multiplicity": "zero_or_one", 
      "parent": 9,
      "removable_relation": true,
      "modifiable_multiplicity": false
    }
  ]
}

```

### Response

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| id                | int      | Automatically generated by the backend. |
| name              | string   |                                         |
| description       | string   |                                         |
| object\_classes    | Array    |                                         |
| created\_at        | datetime |                                         |
| created\_by        | user     |                                         |
| modified\_at       | datetime |                                         |
| modified\_by       | user     |                                         |
| \_meta.permissions | Object   | Dict describing permissions.            |

#### Response `object_classes` array

| Key          | Type    | Notes                                   |
|--------------|---------|-----------------------------------------|
| object\_class | int     | Object Class id                         |
| multiplicity | string  | Choices: (`zero_or_more`, `zero_or_one`)|
| parent       | int     | Object Class id                         |
| \_meta.labels | Object  | Object contains labels for Object Class |

* Successful status `201 Created`
* Response body schema

```json
{
    "id": 17,
    "name": "sample name",
    "description": "Sample description",
    "object_classes": [
        {
            "object_class": 7,
            "multiplicity": "zero_or_more",
            "parent": null,
            "_meta": {
                "labels": {
                    "object_class": "some n323ame22233"
                }
            }
        },
        {
            "object_class": 6,
            "multiplicity": "zero_or_one",
            "parent": 7,
            "_meta": {
                "labels": {
                    "object_class": "some name22233"
                }
            }
        },
        {
            "object_class": 8,
            "multiplicity": "zero_or_one",
            "parent": 7,
            "_meta": {
                "labels": {
                    "object_class": "some name22233"
                }
            }
        },
        {
            "object_class": 9,
            "multiplicity": "zero_or_one",
            "parent": 8,
            "_meta": {
                "labels": {
                    "object_class": "some name222336"
                }
            }
        },
        {
            "object_class": 10,
            "multiplicity": "zero_or_one",
            "parent": 9,
            "_meta": {
                "labels": {
                    "object_class": "some name2223334"
                }
            }
        }
    ],
    "created_at": "2022-11-17T14:40:54.687803+01:00",
    "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_at": "2022-11-17T14:40:54.687836+01:00",
    "modified_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "permissions": {
        "object_models": [
            "create",
            "edit",
            "view",
            "list"
        ]
    }
}
```

### Errors

| Cause                                           | Response code   | Message                                                                                                      |
|-------------------------------------------------|-----------------|--------------------------------------------------------------------------------------------------------------|
| name missing                                    | 400 Bad Request | "name": \["This field is required."]                                                                        |
| name is empty                                   | 400 Bad Request | "name": \[ "This field may not be blank."]                                                                  |
| name is null                                    | 400 Bad Request | "name": \[ "This field may not be null."]                                                                   |
| name to long                                    | 400 Bad Request | "name": \["Ensure this field has no more than 100 characters."]                                             |
| description to long                             | 400 Bad Request | "description": \["Ensure this field has no more than 500 characters."]                                      |
| description is null                             | 400 Bad Request | "description": \[ "This field may not be null."]                                                            |
| object\_classes missing                          | 400 Bad Request | "object\_classes": \["This field is required."]                                                              |
| object\_classes is null                          | 400 Bad Request | "object\_classes": \[ "This field may not be null." ]                                                        |
| object\_classes not a list                       | 400 Bad Request | "object\_classes": {"non\_field\_errors": \["Expected a list of items but got type "type"."]}                |
| object\_classes contains loop                    | 400 Bad Request | "object\_classes": {"non\_field\_errors": \["Relation contains loop."]}                                        |
| object\_classes to many parents                  | 400 Bad Request | "object\_classes": {"non\_field\_errors": \["Limit of "limit" top parents exceeded."]}                       |
| object\_class missing                            | 400 Bad Request | "object\_classes": {"object\_class": \["This field is required."]}                                            |
| object\_class invalid ID                         | 400 Bad Request | "object\_classes": {"object\_class": \["Invalid pk "value" - object does not exist."]}                      |
| object\_class is null                            | 400 Bad Request | "object\_classes": {"object\_class": \["This field may not be null."]}                                        |
| object\_class not unique                         | 400 Bad Request | "object\_classes": {"object\_class": \["The object class "value" might be given only once."]}               |
| multiplicity missing                            | 400 Bad Request | "object\_classes": {"multiplicity": \["This field is required."]}                                            |
| multiplicity is null                            | 400 Bad Request | "object\_classes": {"multiplicity": \[ "This field may not be null." ]}                                      |
| multiplicity invalid value                      | 400 Bad Request | "object\_classes": {"multiplicity": \[""value" is not a valid choice."]}                                   |
| parent invalid ID                               | 400 Bad Request | "object\_classes": {"parent": \["Invalid pk "value" - object does not exist."]}                            |
| parent ID not on the list                       | 400 Bad Request | "object\_classes": {"parent": \["Invalid pk "value" - Object Class not added to Object Model Definition."]}|
| relation depth exceeded                         | 400 Bad Request | "object\_classes": {"parent": \["Relation depth limit exceeded for Object Class ID "value"."]}             |
| To many children                                | 400 Bad Request | "object\_classes": {"parent": \["Limit of "limit" children exceeded for Object Class ID "value"."]}      |
| Exceeded max number of Object Model Definitions | 400 Bad Request | "detail": "Limit of 1 Object Model Definitions has been exceeded."                                           |
| Insufficient permissions                        | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                               |

## GET /api/object-models/

Returns list of object classes.

### Permissions

Requires `authentication` and `SuperAdmin` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/object-models/
```

### Response

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

#### Response `results` array

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| id                | int      | Automatically generated by the backend. |
| name              | string   |                                         |
| description       | string   |                                         |
| created\_at        | datetime |                                         |
| created\_by        | user     |                                         |
| modified\_at       | datetime |                                         |
| modified\_by       | user     |                                         |
| \_meta.permissions | Object   | Dict describing permissions.            |

* Successful status `200 OK`
* Response body schema

```json
GET /api/object-models/

{
    "limit": 100,
    "offset": 0,
    "filtered_count": 1,
    "total_count": 1,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": 17,
            "name": "simple name",
            "description": "Simple description",
            "created_at": "2022-11-17T14:40:54.687803+01:00",
            "created_by": {
                "id": 2,
                "first_name": "ALX",
                "last_name": "Developer",
                "username": "alx.dev@autologyx.com",
                "company_name": "",
                "is_deleted": false,
                "account_type": "super_admin"
            },
            "modified_at": "2022-11-17T14:40:54.687836+01:00",
            "modified_by": {
                "id": 2,
                "first_name": "ALX",
                "last_name": "Developer",
                "username": "alx.dev@autologyx.com",
                "company_name": "",
                "is_deleted": false,
                "account_type": "super_admin"
            },
            "permissions": {
                "object_models": [
                    "create",
                    "edit",
                    "view",
                    "list"
                ]
            }
        }
    ]
}
```

### Errors

| Error                             | Response code | Message                                                        |
|-----------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions          | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## GET /api/object-models/`id`

Returns single object model by `id`.

### Permissions

Requires `authentication` and `SuperAdmin` permission.

### Request

* URL parameters

| Key                      | Type     | Notes |
|--------------------------|----------|-------|
| id                       | id       |       |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| id                | int      | Automatically generated by the backend. |
| name              | string   |                                         |
| description       | string   |                                         |
| object\_classes    | Array    |                                         |
| created\_at        | datetime |                                         |
| created\_by        | user     |                                         |
| modified\_at       | datetime |                                         |
| modified\_by       | user     |                                         |
| \_meta.permissions | Object   | Dict describing permissions.            |

#### Response `object_classes` array

| Key                     | Type    | Notes                                                                                                                                                                                                                                |
|-------------------------|---------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| object\_class            | int     | Object Class id                                                                                                                                                                                                                      |
| multiplicity            | string  | Choices: (`zero_or_more`, `zero_or_one`)                                                                                                                                                                                             |
| parent                  | int     | Object Class id                                                                                                                                                                                                                      |
| removable\_relation      | bool    | False if: Exists a relation between a record from the corresponding parent class and a record from the corresponding child class. Exists Sequence with Child added/removed event. Exists Relation Lookup with corresponding classes. |
| modifiable\_multiplicity | bool    | False if there exist at least 2 relations between a single record from the corresponding parent class and several records from the corresponding child class and for all "root" classes.                                             |
| \_meta.labels            | Object  | Object contains labels for Object Class                                                                                                                                                                                              |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": 17,
    "name": "simple name",
    "description": "Simple description",
    "object_classes": [
        {
            "object_class": 7,
            "multiplicity": "zero_or_more",
            "parent": null,
            "removable_relation": false,
            "modifiable_multiplicity": true,
            "_meta": {
                "labels": {
                    "object_class": "some class name"
                }
            }
        },
        {
            "object_class": 6,
            "multiplicity": "zero_or_one",
            "parent": 7,
            "removable_relation": false,
            "modifiable_multiplicity": true,
            "_meta": {
                "labels": {
                    "object_class": "some class name 2"
                }
            }
        }
    ],
    "created_at": "2022-11-17T14:40:54.687803+01:00",
    "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_at": "2022-11-17T14:40:54.687836+01:00",
    "modified_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
     "permissions": {
        "object_models": [
            "create",
            "edit",
            "view",
            "list"
        ]
    }
}
```

### Errors

| Error                                 | Response code | Message                                                        |
|---------------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions              | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Object Model with "id" does not exist | 404 Not Found | "detail": "Not found."                                         |

## PATCH /api/object-models/`id`/

Updates single Object Model.

### Permissions

Requires `authentication` and `SuperAdmin` permission.

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| id             | int     |             |

* Headers

```
Request Method: PATCH
Authorization: JWT access_token
```

* Body

| Key            | Type   | Required | Notes                            |
|----------------|--------|----------|----------------------------------|
| name           | string | true     |                                  |
| description    | string | false    |                                  |
| object\_classes | Array  | true     | Relations between object classes |

#### Request `object_classes` array

| Key                     | Type     | Notes                                                                                                                                                                                                                                |
|-------------------------|----------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| object\_class            | int      | Object Class id                                                                                                                                                                                                                      |
| multiplicity            | string   | Choices: (zero\_or\_more, zero\_or\_one)                                                                                                                                                                                                 |
| parent                  | int      | Object Class id                                                                                                                                                                                                                      |
| removable\_relation      | bool     | False if: Exists a relation between a record from the corresponding parent class and a record from the corresponding child class. Exists Sequence with Child added/removed event. Exists Relation Lookup with corresponding classes. |
| modifiable\_multiplicity | bool     | False if there exist at least 2 relations between a single record from the corresponding parent class and several records from the corresponding child class and for all "root" classes.                                             |

* Sample request body

```json
PATCH /api/object-models/1/

{ 
  "name": "sample name",
  "description": "Sample description",
  "object_classes": [
    {
      "object_class": 6, 
      "multiplicity": "zero_or_one", 
      "parent": 7,
      "removable_relation": true,
      "modifiable_multiplicity": false
    },
     {
      "object_class": 7, 
      "multiplicity": "zero_or_one", 
      "parent": null,
      "removable_relation": true,
      "modifiable_multiplicity": false
    },
    {
      "object_class": 8, 
      "multiplicity": "zero_or_one", 
      "parent": 7,
      "removable_relation": true,
      "modifiable_multiplicity": false
    },
    {
      "object_class":9, 
      "multiplicity": "zero_or_one", 
      "parent": 8,
      "removable_relation": true,
      "modifiable_multiplicity": false
    },
    {
      "object_class":10, 
      "multiplicity": "zero_or_one", 
      "parent": 9,
      "removable_relation": true,
      "modifiable_multiplicity": false
    }
  ]
}
```

### Response

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| id                | int      | Automatically generated by the backend. |
| name              | string   |                                         |
| description       | string   |                                         |
| object\_classes    | Array    |                                         |
| created\_at        | datetime |                                         |
| created\_by        | user     |                                         |
| modified\_at       | datetime |                                         |
| modified\_by       | user     |                                         |
| \_meta.permissions | Object   | Dict describing permissions.            |

#### Response `object_classes` array

| Key          | Type    | Notes                                   |
|--------------|---------|-----------------------------------------|
| object\_class | int     | Object Class id                         |
| multiplicity | string  | Choices: (`zero_or_more`, `zero_or_one`)|
| parent       | int     | Object Class id                         |
| \_meta.labels | Object  | Object contains labels for Object Class |

* Successful status `200 OK`
* Response body schema

```json
{
    "id": 17,
    "name": "Sample name",
    "description": "Sample description",
    "object_classes": [
        {
            "object_class": 7,
            "multiplicity": "zero_or_more",
            "parent": null,
            "_meta": {
                "labels": {
                    "object_class": "some n323ame22233"
                }
            }
        },
        {
            "object_class": 6,
            "multiplicity": "zero_or_one",
            "parent": 7,
            "_meta": {
                "labels": {
                    "object_class": "some name22233"
                }
            }
        },
        {
            "object_class": 8,
            "multiplicity": "zero_or_one",
            "parent": 7,
            "_meta": {
                "labels": {
                    "object_class": "some name22233"
                }
            }
        },
        {
            "object_class": 9,
            "multiplicity": "zero_or_one",
            "parent": 8,
            "_meta": {
                "labels": {
                    "object_class": "some name222336"
                }
            }
        },
        {
            "object_class": 10,
            "multiplicity": "zero_or_one",
            "parent": 9,
            "_meta": {
                "labels": {
                    "object_class": "some name2223334"
                }
            }
        }
    ],
    "created_at": "2022-11-17T14:40:54.687803+01:00",
    "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_at": "2022-11-17T14:40:54.687836+01:00",
    "modified_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
     "permissions": {
        "object_models": [
            "create",
            "edit",
            "view",
            "list"
        ]
    }
}
```

### Errors

| Cause                                   | Response code   | Message                                                                                                                                                                                                                                                             |
|-----------------------------------------|-----------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| name missing                            | 400 Bad Request | "name": \["This field is required."]                                                                                                                                                                                                                               |
| name is empty                           | 400 Bad Request | "name": \[ "This field may not be blank."]                                                                                                                                                                                                                         |
| name is null                            | 400 Bad Request | "name": \[ "This field may not be null."]                                                                                                                                                                                                                          |
| name to long                            | 400 Bad Request | "name": \["Ensure this field has no more than 100 characters."]                                                                                                                                                                                                    |
| description to long                     | 400 Bad Request | "description": \["Ensure this field has no more than 500 characters."]                                                                                                                                                                                             |
| description is null                     | 400 Bad Request | "description": \[ "This field may not be null."]                                                                                                                                                                                                                   |
| object\_classes is null                  | 400 Bad Request | "object\_classes": \[ "This field may not be null." ]                                                                                                                                                                                                               |
| object\_classes not a list               | 400 Bad Request | "object\_classes": {"non\_field\_errors": \["Expected a list of items but got type "type"."]}                                                                                                                                                                       |
| object\_classes contains loop            | 400 Bad Request | "object\_classes": {"non\_field\_errors": \["Relation contains loop."]}                                                                                                                                                                                               |
| object\_classes to many parents          | 400 Bad Request | "object\_classes": {"non\_field\_errors": \["Limit of "limit" top parents exceeded."]}                                                                                                                                                                              |
| object\_class missing                    | 400 Bad Request | "object\_classes": {"object\_class": \["This field is required."]}                                                                                                                                                                                                   |
| object\_class invalid ID                 | 400 Bad Request | "object\_classes": {"object\_class": \["Invalid pk "value" - object does not exist."]}                                                                                                                                                                             |
| object\_class is null                    | 400 Bad Request | "object\_classes": {"object\_class": \["This field may not be null."]}                                                                                                                                                                                               |
| object\_class not unique                 | 400 Bad Request | "object\_classes": {"object\_class": \["The object class "value" might be given only once."]}                                                                                                                                                                      |
| object\_class existing record            | 400 Bad Request | "object\_classes": {"non\_field\_errors": \["Relation between "parent\_class\_name" and "child\_class\_name" can’t be removed because at least 1 relation between Records of these Classes exists."]}                                                                 |
| object\_class existing sequence          | 400 Bad Request | "object\_classes": {"non\_field\_errors": \["Relation between "parent\_class\_name" and "child\_class\_name" can’t be removed because at least 1 Sequence is referring to it. Sequence ids: \[sequence\_id1, sequence\_id2,..]." ]}                                    |
| object\_class existing document template | 400 Bad Request | "object\_classes": {"non\_field\_errors": \["Relation between "parent\_class\_name" and "child\_class\_name" can’t be removed because at least 1 Document template is referring to it. Document template ids: \[template\_id1, template\_id2,..]." ]}                  |
| multiplicity missing                    | 400 Bad Request | "object\_classes": {"multiplicity": \["This field is required."]}                                                                                                                                                                                                   |
| multiplicity is null                    | 400 Bad Request | "object\_classes": {"multiplicity": \[ "This field may not be null." ]}                                                                                                                                                                                             |
| multiplicity invalid value              | 400 Bad Request | "object\_classes": {"multiplicity": \[""value" is not a valid choice."]}                                                                                                                                                                                          |
| multiplicity existing record            | 400 Bad Request | "object\_classes": {"multiplicity": \["'Zero or one' value is invalid for relation between "parent\_class\_name" and "child\_class\_name" because at least 1 Record of Class "parent\_class\_name" has multiple children Records of Class "child\_class\_name"." ]} |
| parent invalid ID                       | 400 Bad Request | "object\_classes": {"parent": \["Invalid pk "value" - object does not exist."]}                                                                                                                                                                                   |
| parent ID not on the list               | 400 Bad Request | "object\_classes": {"parent": \["Invalid pk "value" - Object Class not added to Object Model Definition."]}                                                                                                                                                       |
| relation depth exceeded                 | 400 Bad Request | "object\_classes": {"parent": \["Relation depth limit exceeded for Object Class ID "value"."]}                                                                                                                                                                    |
| To many children                        | 400 Bad Request | "object\_classes": {"parent": \["Limit of "limit" children exceeded for Object Class ID "value"."]}                                                                                                                                                             |
| Insufficient permissions                | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                                                                                                                                                                                      |
| Invalid id in URL                       | 404 Not Found   | "detail": \["Not found."]                                                                                                                                                                                                                                          |

## OPTIONS /api/object-models/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/object-models/ 
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
  "list": {
    "columns": [
      {
        "alias": "id",
        "type": "int",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "name",
        "type": "string",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "description",
        "type": "string",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_at",
        "type": "datetime",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_by",
        "type": "user",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "modified_at",
        "type": "datetime",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "modified_by",
        "type": "user",
        "predicates": [],
        "sort_ok": false
      }
    ]
  },
  "details": {
    "schema": [
      {
        "alias": "name",
        "type": "string",
        "required": true,
        "validators": [
          {
            "type": "min_length",
            "length": 1
          },
          {
            "type": "max_length",
            "length": 100
          }
        ]
      },
      {
        "alias": "description",
        "type": "string",
        "required": false,
        "validators": [
          {
            "type": "max_length",
            "length": 500
          }
        ]
      },
      {
        "alias": "object_classes",
        "schema": [
          {
            "alias": "object_class",
            "type": "enum",
            "required": true,
            "autocomplete": "/api/object-classes/autocomplete/?text__icontains="
          },
          {
            "alias": "multiplicity",
            "type": "enum",
            "required": true,
            "values": [
              [
                "zero_or_one",
                "Zero or one"
              ],
              [
                "zero_or_more",
                "Zero or more"
              ]
            ]
          }
        ]
      }
    ]
  },
  "restrictions": {
    "limit_parents": 5,
    "limit_children": 5,
    "limit_depth": 5
  }
}
```

## GET /api/object-models/`id`/object-class/`class_id`/parents/

Returns parent for the specific Object Class in Object Model.

### Permissions

Requires `authentication` and `object_classes.view` permission for the specific Object Class.

### Request

* URL parameters

| Key                      | Type     | Notes |
|--------------------------|----------|-------|
| id                       | id       |       |
| class\_id                 | id       |       |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response array

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| id                | int      | Object Class id.                        |
| name              | string   |                                         |

* Successful status `200 OK`
* Response body schema:

::: tip Important
Parent class names are show only if the user has `view class` permission for the given parent class.
Otherwise `"name": NULL`.
:::

```json
[
  {
    "id": <int>,
    "name": <str>
  }
]
```

### Errors

| Error                                   | Response code | Message                                                        |
|-----------------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions                | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Object Model with "id" does not exist   | 404 Not Found | "detail": "Not found."                                         |
| Object Class with "id" does not exist   | 404 Not Found | "detail": "Not found."                                         |

## GET /api/object-models/`id`/object-class/`class_id`/children/

Returns children for the specific Object Class in Object Model.

### Permissions

Requires `authentication` and `object_classes.view` permission for the specific Object Class.

### Request

* URL parameters

| Key                      | Type     | Notes |
|--------------------------|----------|-------|
| id                       | id       |       |
| class\_id                 | id       |       |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response array

| Key               | Type   | Notes                              |
|-------------------|--------|------------------------------------|
| id                | int    | Object Class id.                   |
| name              | string |                                    |
| multiplicity      | enum   | Values: zero\_or\_one, zero\_or\_more. |
| \_meta.permissions | Object | Object describing permissions.     |

* Successful status `200 OK`
* Response body schema:

::: tip Important
Child class names are show only if the user has `view class` permission for the given child class.
Otherwise `"name": NULL`.
:::

```json
[
  {
    "id": <int>,
    "name": <str>,
    "multiplicity": <enum>,
    "_meta": {
        "labels": {
            "multiplicity": <str>
        },
        "permissions": {
            "list": <bool>,
            "view": <bool>,
            "object_records": {
                "create": <bool>,
                "list": <bool>
            }
        }
    }
  }
]
```

### Errors

| Error                                   | Response code | Message                                                        |
|-----------------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions                | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Object Model with "id" does not exist   | 404 Not Found | "detail": "Not found."                                         |
| Object Class with "id" does not exist   | 404 Not Found | "detail": "Not found."                                         |

## GET /api/object-models/`id`/object-records/

List Related Object Records based on query parameters and caller permissions.

::: tip Important
Access to endpoint require passing Result Class filter `/api/object-models/<model_id>/object-records/?result_class=<object_class_id>`
:::

### Permissions

Requires `authentication` and  `object_records.list` permission

### Request example

* Headers

```
Request Method: GET
Location: /api/object-models/<model_id>/object-records/
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        |                                                                                  |
| offset            | int        |                                                                                  |
| total\_count       | int        | Total number of items visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of items visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key           | Type     | Notes                                   |
|---------------|----------|-----------------------------------------|
| id            | id       |                                         |
| object\_name   | string   |                                         |
| object\_class  | int      |                                         |
| created\_at    | datetime |                                         |
| created\_by    | user     |                                         |
| modified\_at   | datetime |                                         |
| modified\_by   | user     |                                         |
| \_meta         | Object   | [\_meta](#response-meta-object) result   |

### Response `_meta` object

| Key             | Type          | Notes                                            |
|-----------------|---------------|--------------------------------------------------|
| permissions     | Object        |                                                  |
| labels          | Object        |                                                  |
| users           | Object        | Optional, added only if show\_fields is passed.   |
| user\_groups     | Object        |   Optional, added only if show\_fields is passed. |

### Response `_meta.users` object

| Key       | Type | Notes                                          |
|-----------|------|------------------------------------------------|
| \<user\_id> | user |                                                |

`_meta.users` contains max 50 user objects for first 50 unique items from user type fields.

### Response `_meta.user_groups` object

| Key              | Type   | Notes                                             |
|------------------|--------|---------------------------------------------------|
| \<users\_group\_id> | Object | Contains group `id`, `name` and `num_of_members`  |

`_meta.user_groups` contains max 50 user group objects for first 50 unique items from user type fields.

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 21,
  "total_count": 21,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 21,
      "object_name": "21",
      "object_class": 2,
      "status": "initiated",
      "created_at": "2022-08-18T12:23:25.927304+02:00",
      "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
      },
      "modified_at": "2022-08-18T12:23:25.927359+02:00",
      "modified_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
      },
      "field_usertype": {"users": [23]},
      "_meta": {
        "permissions": {
          "list": true,
          "view": true,
          "edit": true,
          "create": true,
          "delete": true,
          "edit_owners": true,
          "view_owners": true,
          "tasks": {
            "list": true,
            "view": true,
            "edit": true,
            "delete": true,
            "create": true,
            "complete": true,
            "assign": true
          }
        },
        "labels": {
          "object_class": "Some class name"
        },
        "users": {
            "23": {
                "id": 23,
                "first_name": "John",
                "last_name": "Smith",
                "username": "j.smith@autologyx.com",
                "company_name": "Autologyx",
                "is_deleted": false,
                "account_type": "super_admin"
            }
        },
        "allowed_status_transitions": [],
        "forbidden_actions": []
      }
    },
    {
      "id": 20,
      "object_name": "20",
      "object_class": 2,
      "status": "initiated",
      "created_at": "2022-08-18T12:21:35.921861+02:00",
      "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
      },
      "modified_at": "2022-08-18T13:43:42.874876+02:00",
      "modified_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
      },
      "_meta": {
        "permissions": {
          "list": true,
          "view": true,
          "edit": true,
          "create": true,
          "delete": true,
          "edit_owners": true,
          "view_owners": true,
          "tasks": {
            "list": true,
            "view": true,
            "edit": true,
            "delete": true,
            "create": true,
            "complete": true,
            "assign": true
          }
        },
        "labels": {
          "object_class": "Some class2"
        },
        "allowed_status_transitions": [],
        "forbidden_actions": []
      }
    },
  ]
}
```

### Sorting

| Parameter             | Example                                          | Notes           |
|-----------------------|--------------------------------------------------|-----------------|
| id                    | ..\&ordering=id                                   | Ascending       |
| id                    | ..\&ordering=-id                                  | Descending (-)  |
| created\_at            | ..\&ordering=created\_at                           | Ascending       |
| created\_at            | ..\&ordering=-created\_at                          | Descending (-)  |
| modified\_at           | ..\&ordering=modified\_at                          | Ascending       |
| modified\_at           | ..\&ordering=-modified\_at                         | Descending (-)  |
| object\_name           | ..\&ordering=object\_name                          | Ascending       |
| object\_name           | ..\&ordering=-object\_name                         | Descending (-)  |
| field\_\<field\_alias>   | ..\&show\_fields=field\_alias\&ordering=field\_alias  | Ascending       |
| field\_\<field\_alias>   | ..\&show\_fields=field\_alias\&ordering=-field\_alias | Descending (-)  |

#### Ordering by related Result Class Fields

Result Class Fields Query String parameters are included in [Object Classes - GET /api/object-classes/{object\_class\_id}/fields/autocomplete/](/api/catalyst/resources/object-classes/object-classes#get-api-object-classes-object-class-id-fields-autocomplete) endpoint.

The fields types / columns available for Ordering :

```
string
int
float
date
datetime
email
enum
```

The custom field from ordering should also be included in show\_fields parameter only then ordering by this field will be enabled.

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

#### Filtering by Object Record related fields

| Parameter                      | Type       | Example                                                                                                                         |
|--------------------------------|------------|---------------------------------------------------------------------------------------------------------------------------------|
| result\_class                   | =          | {build}/api/object-models/{model\_id}/object-records/?result\_class=1                                                             |
| result\_class\_created\_at        | datetime   | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_created\_at\_\_gte=2022-01-01                     |
| result\_class\_created\_by        | set        | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_created\_by\_\_in=123,234,345                     |
| result\_class\_modified\_at       | datetime   | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_modified\_at\_\_range=2022-01-01,2022-01-31       |
| result\_class\_modified\_by       | set        | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_modified\_by=123                                |
| result\_class\_object\_name       | string     | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_object\_name\_\_icontains=foobar                  |
| *show\_fields*                  | string     | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_object\_class=12\&show\_fields=field\_alias        |
| child\_class\_{cid}*id           | int + enum | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&child\_class*{cid}*id=3                                      |
| child\_class*{cid}*created\_at   | datetime   | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&child\_class*{cid}*created\_at\_\_gte=2022-01-01                |
| child\_class*{cid}*created\_by   | set        | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&child\_class*{cid}*created\_by\_\_in=123,234,345                |
| child\_class*{cid}*modified\_at  | datetime   | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&child\_class*{cid}*modified\_at\_\_range=2022-01-01,2022-01-31  |
| child\_class*{cid}*modified\_by  | set        | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&child\_class*{cid}*modified\_by=123                           |
| child\_class*{cid}*object\_name  | string     | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&child\_class*{cid}*object\_name\_\_icontains=foobar             |
| parent\_class*{pid}*id          | int + enum | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&parent\_class*{pid}*id=3                                     |
| parent\_class*{pid}*created\_at  | datetime   | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&parent\_class*{pid}*created\_at\_\_gte=2022-01-01               |
| parent\_class*{pid}*created\_by  | set        | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&parent\_class*{pid}*created\_by\_\_in=123,234,345               |
| parent\_class*{pid}*modified\_at | datetime   | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&parent\_class*{pid}*modified\_at\_\_range=2022-01-01,2022-01-31 |
| parent\_class*{pid}*modified\_by | set        | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&parent\_class*{pid}*modified\_by=123                          |
| parent\_class*{pid}*object\_name | string     | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&parent\_class*{pid}\_object\_name\_\_icontains=foobar            |

> `result_class` is required
>
> `show_fields` is required to attach fields with their value to the response each object record. It is possible to specify multiple fields by separating them with a comma. Max 10 fields.

#### Filtering by related Result Class Fields

Object Class Fields Query String parameters are included in [Object Classes - GET /api/object-classes/{object\_class\_id}/fields/autocomplete/](/api/catalyst/resources/object-classes/object-classes#get-api-object-classes-object-class-id-fields-autocomplete) endpoint.

This endpoint contains also predicates assigned for each type.

The fields types / columns available for filtering :

```
bool
string
int
float
date
datetime
email
phone
url
set
enum
user
document
```

At most, 10 total fields of any type from the object class are allowed for filtering.

For predicates `in`, `containssome`, `containsall` values must be separated by comma `,`. If single value contains comma inside, char must be escaped by `\,`.

> `?result_class_field_set__in=first\,text,second`

The User type field is unique because it stores both a list of users and groups.
Therefore, filtering by this field requires specifying which of these values will be filtered.

> `?result_class_field_user__users__containsall=1,2,3`
>
> `?result_class_field_user__user_groups__containssome=21,42,54`

The Document type field supports only `isempty` predicate. It checks whether the field contains any files or not.

> `?result_class_field_document__isempty=true`

| Parameter                   | Type     | Example                                                                                                                                                                                    |
|-----------------------------|----------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| field\_\<bool\_type\_alias>     | bool     | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_field\_bool\_alias=false\&child\_class\_{cid}*field\_bool\_alias=false                                           |
| field*\<text\_type\_alias>     | string   | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_field\_string\_alias\_\_contains=test\&child\_class\_{cid}*field\_string\_alias=aa                                 |
| field*\<integer\_type\_alias>  | int      | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_field\_integer\_\_gt=1\&child\_class\_{cid}*field\_integer\_\_lt=3                                                 |
| field*\<decimal\_type\_alias>  | int      | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_field\_decimal\_\_gt=1.5\&child\_class\_{cid}*field\_decimal=3.2\&parent\_class*{pid}*field\_decimal\_\_gt=2.9        |
| field*\<date\_type\_alias>     | date     | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_field\_date=2000-09-23\&child\_class\_{cid}*field\_date=2000-09-21                                             |
| field*\<datetime\_type\_alias> | datetime | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_field\_datetime=2000-09-23 10:00:00\&child\_class\_{cid}*field\_datetime\_\_gt=2000-09-23 11:00:00               |
| field*\<email\_type\_alias>    | string   | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_field\_email\_\_contains=test\&child\_class\_{cid}*field\_email\_\_contains=aa                                     |
| field*\<phone\_type\_alias>    | string   | {build}/api/object-models/{model\_id}/object-records/?result\_classd=1\&result\_class\_field\_phone\_\_contains=123\&child\_class\_{cid}*field\_phone=12345678                                         |
| field*\<url\_type\_alias>      | url      | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_field\_url\_\_iexact=http://website.sample\&child\_class\_{cid}*field\_url\_\_contains=test                        |
| field*\<set\_type\_alias>      | set      | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_field\_set\_\_containsall=abc,some,text,cde\&child\_class\_{cid}*field\_set\_\_containssome=aaa,bbb               |
| field*\<enum\_type\_alias>     | enum     | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_field\_enum\_\_in=abc,some,text,cde\&child\_class\_{cid}*field\_enum=ccc                                        |
| field*\<user\_type\_alias>     | user     | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_field\_user\_\_users\_\_containsall=1,2,3\&child\_class\_{cid}**field\_user\_\_users\_\_containsall=1,2                |
| field*\<user\_type\_alias>     | user     | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_field\_user\_\_user\_groups\_\_containssome=21,42,54\&child\_class*{cid}**field\_user\_\_user\_groups\_\_containsall=21 |
| field*\<document\_type\_alias> | document | {build}/api/object-models/{model\_id}/object-records/?result\_class=1\&result\_class\_field\_document\_\_isempty=false\&parent\_class*{pid}\_field\_document\_\_isempty=true                             |

### Errors

| Error                                                                 | Response code    | Message                                                                                                                                                 |
|-----------------------------------------------------------------------|------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|
| Filter created\_by with wrong user id                                  | 400 Bad Request  | "detail": {"created\_by":  \["Select a valid choice. That choice is not one of the available choices."]}                                                |
| Filter modified\_by with wrong user id                                 | 400 Bad Request  | "detail": {"modified\_by":  \['Select a valid choice. That choice is not one of the available choices."]}                                               |
| Missing object\_class parameter                                        | 400 Bad request  | "detail": { "object\_class": \["This field is required"] }                                                                                              |
| Invalid object\_class parameter                                        | 400 Bad request  | "detail": { "object\_class": \["Invalid pk "{object\_class}" - object does not exist."]  }                                                             |
| More that 10 combined filter params                                   | 400 Bad Request  | "detail": \["Too many filters. Max = {MAX}"]                                                                                                           |
| Invalid Child Class parameter                                         | 400 Bad Request  | "detail": \["Invalid parameter "child\_class\_field". Expected "child\_class\_{id}*{expression}"."]                                                    |
| Invalid Parent Class parameter                                        | 400 Bad Request  | "detail": \["Invalid parameter "parent\_class\_field". Expected "parent\_class*{id}*{expression}"."]                                                  |
| Invalid Child Class id                                                | 400 Bad Request  | "detail": \["Invalid pk "value" - object does not exist."]                                                                                           |
| Invalid Child Class type                                              | 400 Bad Request  | "detail": \["Invalid child class id. Must be an integer in "child\_class*{type}*id"."]                                                                |
| Invalid Parent Class type                                             | 400 Bad Request  | "detail": \["Invalid parent class id. Must be an integer in "parent\_class*{type}\_id"."]                                                              |
| Relation not exists.                                                  | 400 Bad Request  | "detail": \["Object Class ID "{child\_class.id}" is not related with parent Class ID "{result\_class.id}"."]                                         |
| Wrong class field type decimal value                                  | 400 Bad Request  | "detail": { "field\_decimal": \["A valid number is required."] }                                                                                        |
| Range filter for class field of int type must include exact 2 numbers | 400 Bad Request  | "detail": { "field\_integer": \["Range query expects two values."] }                                                                                    |
| Wrong class field type string value                                   | 400 Bad Request  | "detail": { "field\_text": \["Field "field\_text" expected a string but got ""number"" ] }                                                           |
| Wrong datetime format for datetime field type                         | 400 Bad Request  | "detail": { "field\_datetime": \["Datetime has wrong format. Use one of these formats instead: YYYY-MM-DDThh:mm\[:ss\[.uuuuuu]]\[+HH:MM-HH:MM Z]."]} |
| Wrong date format for date field type                                 | 400 Bad Request  | "detail": { "field\_date": \["Date has wrong format. Use one of these formats instead: YYYY-MM-DD."]}                                                   |
| Wrong value for choice/multichoice field type                         | 400 Bad Request  | "detail": { "field\_set": \[" "{value}" is not a valid choice."]}                                                                                     |
| Wrong value for user field type                                       | 400 Bad Request  | "detail": { "field\_user": \[" "{value}" is not a valid choice."]}                                                                                    |
| Wrong value type for user field type                                  | 400 Bad Request  | "detail": { "field\_user": \["The value must be an array of integers."]}                                                                                |
| Requesting user is not authenticated                                  | 401 Unauthorized | "detail": "Authentication credentials were not provided."                                                                                               |

## GET /api/object-models/`id`/object-classes/hierarchy/`class_id`/

Returning the Object Classes list with the support for relational hierarchy of Object Class in Object Model.

### Permissions

Requires `authentication` and `object_classes.view` permission for the specific Object Class.

### Request

* URL parameters

| Key      | Type | Notes        |
| -------- | ---- | ------------ |
| id       | id   | Object Model |
| class\_id | id   | Object Class |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response array

| Key            | Type       | Notes                           |
| -------------- | ---------- | ------------------------------- |
| id             | int        | Object Class id                 |
| name           | string     | Object Class name               |
| has\_children   | bool       | Object Class has children       |
| children\_count | int        | Object Class children count     |
| children       | list\[dict] | List of children Object Classes |

* Successful status `200 OK`
* Response body schema:

::: tip Important
Parent class names are show only if the user has `view class` permission for the given parent class.
Otherwise `"name": NULL`.
:::

```json
[
  {
    "id": <int>,
    "name": <str>,
    "has_children": <bool>,
    "children_count": <int>,
    "children": <list>
  }
]
```

### Errors

| Error                                 | Response code | Message                                                        |
| ------------------------------------- | ------------- | -------------------------------------------------------------- |
| Insufficient permissions              | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Object Model with "id" does not exist | 404 Not Found | "detail": "Not found."                                         |
| Object Class with "id" does not exist | 404 Not Found | "detail": "Not found.                                          |

## GET /api/object-models/`id`/object-classes/hierarchy/

Returning the Object Classes list with the support for relational hierarchy of Object Class in Object Model.

### Permissions

Requires `authentication` and `object_classes.view` permission for the specific Object Class.

### Request

* URL parameters

| Key | Type | Notes        |
| --- | ---- | ------------ |
| id  | id   | Object Model |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response array

| Key            | Type       | Notes                           |
| -------------- | ---------- | ------------------------------- |
| id             | int        | Object Class id                 |
| name           | string     | Object Class name               |
| has\_children   | bool       | Object Class has children       |
| children\_count | int        | Object Class children count     |
| children       | list\[dict] | List of children Object Classes |

* Successful status `200 OK`
* Response body schema:

::: tip Important
Parent class names are show only if the user has `view class` permission for the given parent class.
Otherwise `"name": NULL`.
:::

```json
[
  {
    "id": <int>,
    "name": <str>,
    "has_children": <bool>,
    "children_count": <int>,
    "children": <list>
  }
]
```

### Errors

| Error                                 | Response code | Message                                                        |
| ------------------------------------- | ------------- | -------------------------------------------------------------- |
| Insufficient permissions              | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Object Model with "id" does not exist | 404 Not Found | "detail": "Not found."                                         |
| Object Class with "id" does not exist | 404 Not Found | "detail": "Not found.

## POST /api/object-models/`id`/object-records/

Creates Object Record Relations.

### Permissions

Requires `authentication` and `object_records.view` permission for the given parent and child object record.

### Request

* Headers

```
Request Method: POST
Authorization: JWT access_token
```

* Body

| Key           | Type   | Notes                                |
|---------------|--------|--------------------------------------|
| object\_record | int    | Object Record id                     |
| parent        | int    | Object Record id                     |

#### Validations

* object\_record
  * This field is required.
  * This field may not be null.
  * Invalid pk "value" - object does not exist.
  * Invalid pk "value" - You do not have `object_records.view` permission for this Record.
  * Only one child Record of class "class\_name" is allowed.
  * Invalid pk "value" - Record of class "class\_name" can’t be added as a child.
* parent
  * This field is required.
  * This field may not be null.
  * Invalid pk "value" - object does not exist.
  * Invalid pk "value" - You do not have `object_records.view` permission for this Record.

### Sample request body

```json
POST /api/object-models/1/object-records/

{ 
  "object_record": 2,
  "parent": 3
}

```

### Response

| Key            | Type     | Notes                                   |
|----------------|----------|-----------------------------------------|
| object\_record  | int      |                                         |
| parent         | int      |                                         |
| created\_at     | datetime |                                         |
| created\_by     | user     |                                         |

* Successful status `201 Created`
* Response body schema

```json
{
    "object_record": 2,
    "parent": 3,
    "created_at": "2022-11-17T14:40:54.687803+01:00",
    "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "_meta": {
        "labels": {
            "object_record": "Some name2",
            "parent": "Some name3"
        }
    }
}
```

### Errors

| Cause                                  | Response code   | Message                                                                                                |
|----------------------------------------|-----------------|--------------------------------------------------------------------------------------------------------|
| object\_record missing                  | 400 Bad Request | "object\_record": \["This field is required."]                                                         |
| object\_record is null                  | 400 Bad Request | "object\_record": \[ "This field may not be null."]                                                    |
| object\_record insufficient permissions | 400 Bad Request | "object\_record": \["Invalid pk "value" - You do not have permission for this Record."]              |
| object\_record invalid ID               | 400 Bad Request | "object\_record": \["Invalid pk "value" - object does not exist."]                                   |
| object\_record to many children         | 400 Bad Request | "object\_record": \["Only one child Record of class "value" is allowed."]                            |
| object\_record invalid relation         | 400 Bad Request | "object\_record": \["Invalid pk "value" - Record of class "class\_name" can’t be added as a child."]|
| parent missing                         | 400 Bad Request | "parent": \["This field is required."]                                                                |
| parent is null                         | 400 Bad Request | "parent": \[ "This field may not be null."]                                                           |
| parent insufficient permissions        | 400 Bad Request | "parent": \["Invalid pk "value" - You do not have permission for this Record."]                     |
| parent invalid ID                      | 400 Bad Request | "parent": \["Invalid pk "value" - object does not exist."]                                          |
| parent object\_record not unique        | 400 Bad Request | "non\_field\_errors": \["The fields object\_record, parent must make a unique set."]                     |
| Invalid id in URL                      | 404 Not Found   | "detail": \["Not found."]                                                                             |
| Insufficient permissions               | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                         |

## POST /api/object-models/`id`/object-records/batch/

Creates Object Records Relations.

### Permissions

Requires `authentication` and `object_records.view` permission for the given parent and all children object records.

### Request

* Headers

```
Request Method: POST
Authorization: JWT access_token
```

* Body

| Key            | Type | Notes                   |
|----------------|------|-------------------------|
| object\_records | list | Object Records ids list |
| parent         | int  | Object Record id        |

#### Validations

* object\_records
  * This field is required.
  * This field may not be null.
  * Invalid pk "value" - object does not exist.
  * Up to 50 items allowed.
* parent
  * This field is required.
  * This field may not be null.
  * Invalid pk "value" - object does not exist.
  * Invalid pk "value" - You do not have permission for this Record.

### Sample request body

```json
POST /api/object-models/1/object-records/batch

{ 
  "object_records": [1,2],
  "parent": 3
}

```

### Response

| Key            | Type     | Notes                                     |
|----------------|----------|-------------------------------------------|
| object\_record  | list     |                                           |
| parent         | int      |                                           |
| \_meta.labels   | Object   | Object contains labels for Object Records |

* Successful status `201 Created`
* Response body schema

```json
{   
    "parent": 3,
    "object_record": [1,2],
    "_meta": {
        "labels": {
            "parent": "some name3"
            "object_class": ["some name1", "some name2"]
        }
    }
}
```

### Errors

| Cause                           | Response code   | Message                                                                           |
|---------------------------------|-----------------|-----------------------------------------------------------------------------------|
| object\_records missing          | 400 Bad Request | "object\_records": \["This field is required."]                                   |
| object\_records is null          | 400 Bad Request | "object\_records": \[ "This field may not be null."]                              |
| object\_records invalid ID       | 400 Bad Request | "object\_records": \["Invalid pk "value" - object does not exist."]             |
| object\_records limit exceed     | 400 Bad Request | "object\_records": \["Up to 50 items allowed."]                                   |
| parent missing                  | 400 Bad Request | "parent": \["This field is required."]                                           |
| parent is null                  | 400 Bad Request | "parent": \["This field may not be null."]                                       |
| parent insufficient permissions | 400 Bad Request | "parent": \["Invalid pk "value" - You do not have permission for this Record."]|
| parent invalid ID               | 400 Bad Request | "parent": \["Invalid pk "value" - object does not exist."]                     |
| Invalid id in URL               | 404 Not Found   | "detail": \["Not found."]                                                        |
| Insufficient permissions        | 403 Forbidden   | "detail": "You do not have permission to perform this action."                    |

## OPTIONS /api/object-models/`id`/object-records/batch/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/object-models/1/object-records/batch/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "batch": {
        "schema": [
            {
                "alias": "object_records",
                "type": "set",
                "required": true,
                "autocomplete": "/api/object-records/autocomplete/?object_class={object_class_id}&text__icontains="
            }
        ]
    },
    "restrictions": {
        "limit_items_in_batch": 50
    }
}
```

## GET /api/object-models/`id`/object-records/`parent_record_id`/children/

Retrieve children Object Records list.

### Permissions

Requires `authentication` and `object_records.view` permission for the given parent and children object record.

### Request

* URL parameters

| Key                         | Type    | Notes                                                        |
|-----------------------------|---------|--------------------------------------------------------------|
| id                          | pk      |                                                              |
| parent\_record\_id            | pk      |                                                              |

::: tip Important
To retrieve children Object Records list - param filter `object_record__object_class` is necessary.
The value is an `id` of the child Object Class.
More in [Filtering](#filtering) section.
:::

* Headers

```
GET /api/object-models/1/object-records/1/children/?object_record__object_class=1&show_fields=field_alias_1,field_alias_2

Request Method: GET
Authorization: JWT access_token
```

### Response

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

#### Response `results` array

| Key               | Type     | Notes                                                                                 |
|-------------------|----------|---------------------------------------------------------------------------------------|
| object\_record     | Object   | [Object Records](/api/catalyst/resources/object-records/object-records#get-api-object-records-record-id) |
| created\_at        | datetime |                                                                                       |
| created\_by        | user     |                                                                                       |
| \_meta.permissions | Object   |                                                                                       |

* Successful status `200 OK`
* Response body schema

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str | null>,
  "previous": <str | null>,
  "results": [
    {
      "object_record": { 
        "id": <object_record_id>, 
        "object_name": <str>, 
        "object_class": <object_class_id>, 
        "status": "initiated",
        "created_at": <datetime>, 
        "created_by": <user>, 
        "modified_at": <datetime>, 
        "modified_by": <user>, 
        "_meta": { 
          "labels": { 
            "object_class": <object_class_label>, 
          }, 
          "allowed_status_transitions": [ ],
          "forbidden_actions": [ ],
        },
        "field_alias_1" = <any>,
        "field_alias_2" = <any>
      },
      "created_at": <datetime>,
      "created_by": <user>,
      "_meta": { 
        "permissions": { 
          "list": true, 
          "view": true, 
          "create": true, 
          "edit": true, 
          "delete": true 
        } 
      } 
    }
  ]
}
```

### Sorting

| Parameter                  | Example                                                                                    | Notes          |
|----------------------------|--------------------------------------------------------------------------------------------|----------------|
| object\_record\_\_id          | ?ordering=object\_record\_\_id                                                                | Ascending      |
| object\_record\_\_id          | ?ordering=-object\_record\_\_id                                                               | Descending (-) |
| object\_record\_\_created\_at  | ?ordering=object\_record\_\_created\_at                                                        | Ascending      |
| object\_record\_\_created\_at  | ?ordering=-object\_record\_\_created\_at                                                       | Descending (-) |
| object\_record\_\_modified\_at | ?ordering=object\_record\_\_modified\_at                                                       | Ascending      |
| object\_record\_\_modified\_at | ?ordering=-object\_record\_\_modified\_at                                                      | Descending (-) |
| created\_at                 | ?ordering=created\_at                                                                       | Ascending      |
| created\_at                 | ?ordering=-created\_at                                                                      | Descending (-) |
| \<field\_alias>              | {build}/api/object-records/?object\_class=12\&show\_fields=field\_alias\&ordering=field\_alias   | Ascending      |
| \<field\_alias>              | {build}/api/object-records/?object\_class=12\&show\_fields=field\_alias\&ordering=-field\_alias  | Descending (-) |

Ordering by object record fields is possible only if the field is included in the `show_fields` parameter and works in the similar way as defined in the [Ordering by related Object Class Fields](/api/catalyst/resources/object-records/object-records#sorting) section.

### Filtering

| Parameter                   | Type        | Notes                                                                                                                          | Sample url param                               |
|-----------------------------|-------------|--------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------|
| object\_record\_\_object\_class | pk          | Filter is `required`. The value must be the ID of the "child class"                                                            | `&object_record__object_class=1`               |
| show\_fields                 | Array\[str]  | Filter is `optional`. Only the specified fields are returned in the response. Param should be given as list of `field_{alias}` | `&show_fields=field_{alias_1},field_{alias_2}` |

### Errors

| Cause                                 | Response code   | Message                                                                  |
|---------------------------------------|-----------------|--------------------------------------------------------------------------|
| `object_record__object_class` missing | 400 Bad Request | "object\_record\_\_object\_class": \["This field is required"]              |
| To many fields selected               | 400 Bad Request | "show\_fields": \["At most {limit} values are allowed."]                 |
| Insufficient permissions              | 403 Forbidden   | "detail": "You do not have permission to perform this action."           |
| Invalid `id` in URL                   | 404 Not Found   | "detail": \["Not found."]                                               |
| Invalid `parent_record_id` in URL     | 404 Not Found   | "detail": \["Not found."]                                               |

## GET /api/object-models/`id`/object-records/`child_record_id`/parents/

Retrieve a list of all parent records for a given child. The list will include only one level (one level up) of parent.

### Permissions

Requires `authentication` and `object_records.view` permission for the given child and parent object records.

### Request

* URL parameters

| Key              | Type    | Notes                                                        |
|------------------|---------|--------------------------------------------------------------|
| id               | pk      |                                                              |
| child\_record\_id  | pk      |                                                              |

* Headers

```
GET /api/object-models/1/object-records/1/parents/?show_fields=field_alias_1,field_alias_2

Request Method: GET
Authorization: JWT access_token
```

### Response

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

#### Response `results` array

| Key               | Type     | Notes                                                                                  |
|-------------------|----------|----------------------------------------------------------------------------------------|
| object\_record     | Object   | [Object Records](/api/catalyst/resources/object-records/object-records#get-api-object-records-record-id)  |
| created\_at        | datetime | The date and time when the relation between child and parent object record was created |
| created\_by        | user     | The user who create the relation between child and parent object record                |
| \_meta.permissions | Object   |                                                                                        |

* Successful status `200 OK`
* Response body schema

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str | null>,
  "previous": <str | null>,
  "results": [
    {
      "object_record": { 
        "id": <object_record_id>, 
        "object_name": <str>, 
        "object_class": <object_class_id>, 
        "status": "initiated",
        "created_at": <datetime>, 
        "created_by": <user>, 
        "modified_at": <datetime>, 
        "modified_by": <user>, 
        "_meta": { 
          "labels": { 
            "object_class": <object_class_label>, 
          }, 
          "allowed_status_transitions": [ ],
          "forbidden_actions": [ ],
        },
        "field_alias_1" = <any>,
        "field_alias_2" = <any>
      },
      "created_at": <datetime>,
      "created_by": <user>,
      "_meta": { 
        "permissions": { 
          "list": true, 
          "view": true, 
          "create": true, 
          "edit": true, 
          "delete": true 
        } 
      } 
    }
  ]
}
```

### Sorting

| Parameter                  | Example                                                                                    | Notes          |
|----------------------------|--------------------------------------------------------------------------------------------|----------------|
| object\_record\_\_id          | ?ordering=object\_record\_\_id                                                                | Ascending      |
| object\_record\_\_id          | ?ordering=-object\_record\_\_id                                                               | Descending (-) |
| object\_record\_\_created\_at  | ?ordering=object\_record\_\_created\_at                                                        | Ascending      |
| object\_record\_\_created\_at  | ?ordering=-object\_record\_\_created\_at                                                       | Descending (-) |
| object\_record\_\_modified\_at | ?ordering=object\_record\_\_modified\_at                                                       | Ascending      |
| object\_record\_\_modified\_at | ?ordering=-object\_record\_\_modified\_at                                                      | Descending (-) |
| created\_at                 | ?ordering=created\_at                                                                       | Ascending      |
| created\_at                 | ?ordering=-created\_at                                                                      | Descending (-) |
| \<field\_alias>              | {build}/api/object-records/?object\_class=12\&show\_fields=field\_alias\&ordering=field\_alias   | Ascending      |
| \<field\_alias>              | {build}/api/object-records/?object\_class=12\&show\_fields=field\_alias\&ordering=-field\_alias  | Descending (-) |

Ordering by object record fields is possible only if the field is included in the `show_fields` parameter and works in the similar way as defined in the [Ordering by related Object Class Fields](/api/catalyst/resources/object-records/object-records#sorting) section.

### Filtering

| Parameter                   | Type        | Notes                                                                                                                          | Sample url param                               |
|-----------------------------|-------------|--------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------|
| show\_fields                 | Array\[str]  | Filter is `optional`. Only the specified fields are returned in the response. Param should be given as list of `field_{alias}` | `&show_fields=field_{alias_1},field_{alias_2}` |

### Errors

| Cause                                             | Response code               | Message                                                        |
|---------------------------------------------------|-----------------------------|----------------------------------------------------------------|
| To many fields selected                           | 400 Bad Request             | "show\_fields": \["At most {limit} values are allowed."]       |
| Insufficient permissions                          | 403 Forbidden               | "detail": "You do not have permission to perform this action." |
| Invalid `id` in URL                               | 404 Not Found               | "detail": \["Not found."]                                     |
| `child_record_id` is a top parent object record   | 404 Not Found               | "detail": \["Not found."]                                     |
| Invalid `id` in URL                               | 404 Not Found               | "detail": \["Not found."]                                     |
| Invalid `child_record_id` in URL                  | 404 Not Found               | "detail": \["Not found."]                                     |
| Any other request method is used                  | 405 Method not allowed      |                                                                |

## DELETE /api/object-models/`id`/object-records/`parent_id`/children/`child_id`/

Deletes single object relation record.

### Permissions

Requires `authentication` and `object_records.view` permission for given parent and child.

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| id             | pk      |             |
| parent\_id      | pk      |             |
| child\_id       | pk      |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
DELETE /api/object-models/`id`/object-records/`parent_id`/children/`child_id`/
```

### Response

* Successful status `204 No Content`

### Errors

| Error                                      | Response code | Message                                                        |
|--------------------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions                   | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Invalid id in URL                          | 404 Not Found | "detail": "Not found."                                         |
| Invalid parent\_id in URL                   | 404 Not Found | "detail": "Not found."                                         |
| Invalid child\_id in URL                    | 404 Not Found | "detail": "Not found."                                         |

## OPTIONS /api/object-models/`id`/object-records/`parent_id`/children/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/object-models/`id`/object-records/`parent_id`/children/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
  "list": {
    "columns": [
      {
        "alias": "object_record",
        "schema": [
          {
            "alias": "id",
            "type": "int",
            "predicates": [],
            "sort_ok": true
          },
          {
            "alias": "object_name",
            "type": "string",
            "predicates": [],
            "sort_ok": false
          },
          {
            "alias": "object_class",
            "type": "int",
            "predicates": [
              "exact",
              "gt",
              "gte",
              "lt",
              "lte",
              "range"
            ],
            "sort_ok": false
          },
          {
            "alias": "created_at",
            "type": "datetime",
            "predicates": [],
            "sort_ok": true
          },
          {
            "alias": "created_by",
            "type": "user",
            "predicates": [],
            "sort_ok": false
          },
          {
            "alias": "modified_at",
            "type": "datetime",
            "predicates": [],
            "sort_ok": true
          },
          {
            "alias": "modified_by",
            "type": "user",
            "predicates": [],
            "sort_ok": false
          }
        ]
      },
      {
        "alias": "created_at",
        "type": "datetime",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_by",
        "type": "user",
        "predicates": [],
        "sort_ok": false
      }
    ]
  },
  "details": {
    "schema": [
      {
        "alias": "object_record",
        "type": "enum",
        "required": true,
        "autocomplete": "/api/object-records/autocomplete/?object_class={object_class_id}&text__icontains="
      }
    ]
  }
}
```

## GET /api/object-models/`id`/object-records/`parent_id`/children/autocomplete/

API for searching Object Records to be added as child in relation.

::: tip Important
Access to endpoint require passing Object Class filter `/api/object-models/<id>/object-records/<parent_id>/children/autocomplete/?object_class=object_class_id>`
:::

### Permissions

Requires `authentication` and `object_records.view` permission for the given parent.

### Request example

* Headers

```
Request Method: GET
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of items visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of items visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key       | Type     | Notes                                                          |
|-----------|----------|----------------------------------------------------------------|
| value     | id       |                                                                |
| text      | string   |                                                                |
| is\_child  | bool     | Records that are children of given parent are marked as `true` |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 2,
  "total_count": 2,
  "next": null,
  "previous": null,
  "results": [
    {
      "value": 21,
      "text": "21",
      "is_child": true,
      "status": "initiated",
      "_meta": {
        "allowed_status_transitions": [],
        "forbidden_actions": []
      }
    },
    {
      "value": 20,
      "text": "20",
      "is_child": false,
      "_meta": {
        "allowed_status_transitions": [],
        "forbidden_actions": []
      }
    }
  ]
}
```

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter        | Type     | Example                                                         |
|------------------|----------|-----------------------------------------------------------------|
| **object\_class** | enum     | autocomplete/?object\_class=12                                   |
| text             | string   | autocomplete/?object\_class=12\&text\_\_icontains=foobar            |

> `object_class` is required

| Error                                     | Response status code | Response message                                                                |
|-------------------------------------------|----------------------|---------------------------------------------------------------------------------|
| Invalid id in URL                         | 404 Not Found        | "detail": \["Not found."]                                                      |
| Invalid parent\_id in URL                  | 404 Not Found        | "detail": \["Not found."]                                                      |
| Missing object\_class parameter            | 400 Bad Request      | "detail": { "object\_class": \["This field is required.” ] }                    |
| Invalid object\_class parameter            | 400 Bad Request      | "detail": { "object\_class": \["This class is not related with given parent."]} |
| Insufficient permissions to parent record | 403 Forbidden        | "detail": "You do not have permission to perform this action."                  |

## POST /api/object-models/`model_id`/object-records/descendants/

Creates parent and child Object Records with relations simultaneously.

### Permissions

Requires `authentication`.

### Request

* Headers

```
Request Method: POST
Authorization: JWT access_token
```

* Body

| Key          | Type   | Required | Notes                                              |
|--------------|--------|----------|----------------------------------------------------|
| object\_class | string | true     |                                                    |
| children     | string | true     | Required only for root Object Class (first level). |

#### Validations

* object\_class
  * This field is required.
  * This field may not be null.
* children
  * This field is required (only for first level tree)
  * This field is list or null

### Sample request body

```json
POST /api/object-models/1/object-records/descendants/

{
  "object_class": <int>,
  "field_<field_alias>": <any_allowed>,
  ...
  "children": [
    {
      "object_class": <int>,
      "field_<field_alias>": <any_allowed>,
      "field_<field_alias>": <any_allowed>,
      ...
      "children": [
        {
          "object_class": <int>,
          "children": []
        }
      ]
    },
    {
      "object_class": <int>,
      "children": []
    }
  ]
}

```

### Response

| Key               | Type   | Notes |
|-------------------|--------|-------|
| id                | uuid   |       |
| status            | string |       |
| url               | string |       |

* Successful status `201 Created`
* Response body schema

```json
{
  "id": "7fa04f22-b30a-4e83-b2c0-5087d9d224e5",
  "status": "queued",
  "url": "https://test.com/api/object-models/1/object-records/transactions/7fa04f22-b30a-4e83-b2c0-5087d9d224e5/" 
}
```

### Errors

| Cause                                            | Response code      | Message                                                                                       |
|--------------------------------------------------|--------------------|-----------------------------------------------------------------------------------------------|
| Maximum of limit records passed in the request   | 400 Bad Request    | "detail": \["Limit of "limit" records that can be passed in one request has been exceeded."] |
| Invalid data structure                           | 400 Bad Request    | "detail": \["Incorrect data structure."]                                                       |
| Requesting user is not authenticated             | 401 Unauthorized   | "detail": "Authentication credentials were not provided."                                     |

## GET /api/object-models/1/object-records/descendants/

### Response example

* Status `405 Method Not Allowed`

## PATCH /api/object-models/1/object-records/descendants/

### Response example

* Status `405 Method Not Allowed`

## PUT /api/object-models/1/object-records/descendants/

### Response example

* Status `405 Method Not Allowed`

## DELETE /api/object-models/1/object-records/descendants/

### Response example

* Status `405 Method Not Allowed`

## OPTIONS /api/object-models/1/object-records/descendants/

### Response example

* Status `405 Method Not Allowed`

## GET /api/object-models/`id`/object-records/transactions/`transaction_id`/

Returns single object transaction by `id`.

::: tip Important
Processed transactions, whether successful or failed, are automatically deleted 7 days after the completion of processing.
:::

### Permissions

Requires `authentication`.

### Request

* URL parameters

| Key                      | Type | Notes |
|--------------------------|------|-------|
| id                       | uuid |       |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key              | Type   | Notes                                                                            |
|------------------|--------|----------------------------------------------------------------------------------|
| id               | uuid   | Automatically generated by the backend.                                          |
| status           | string |                                                                                  |
| error\_message    | string |                                                                                  |
| created\_records  | Array  | list of all records created in the transaction, grouped by their object class    |

#### Request `created_records` array

The created\_records list is returned only when the transaction has status `completed`.
For the other statuses, the `created_records` field is present but is always an empty list \[]

| Key                     | Type  | Notes                                                                  |
|-------------------------|-------|------------------------------------------------------------------------|
| object\_class            | int   | Object Class id                                                        |
| object\_records          | Array | Array of record IDs created in that class as part of this transaction. |

* Successful status `200 OK`
* Response body schema:

```json
{
  "id": <UUID>,
  "status": <enum>,
  "error_message" <object>
}
```

### "error\_message" details:

* Errors for Object Records creation.

| Error                                            | error\_message                                                                                               |
|--------------------------------------------------|-------------------------------------------------------------------------------------------------------------|
| Invalid class id                                 | {"object\_class": \["Invalid pk "class\_id" - object does not exist."]}                                      |
| Invalid class type                               | {"object\_class": \["Incorrect type. Expected pk value, received {type}."]}                                   |
| Insufficient permissions to create Object Record | {"object\_class": \["You do not have permission to create Object Record for Object Class ID "class\_id""]}   |
| Object Record limit exceed                       | {"detail" \["Limit of {limit} number of Object Records in Object Class ID "class\_id" has been exceeded."]} |

* Errors for creating a relationship between parents and child Object Records.

| Error                                        | error\_message                                                                                                |
|----------------------------------------------|--------------------------------------------------------------------------------------------------------------|
| Relationship between classes does not exist  | {"detail": \["Object Class ID "parent\_class\_id" is not related with parent Class ID "parent\_class\_id"."]} |
| Multiplicity exceed                          | {"detail": \["Only one child Record of Object Class ID "class\_id" is allowed."]}                            |

* Errors for each type of Object Record Field.

| Error                              | error\_message                                                                                                                                                                     |
|------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| All errors follow the same pattern | {"object\_class": {"id": {class\_id}, "errors": {"field\_slug1": \[[Object Record Field Errors](/api/catalyst/resources/object-records/object-records#field-type-errors) ...]}}} |

### Errors

| Error                                 | Response code     | Message                                                        |
|---------------------------------------|-------------------|----------------------------------------------------------------|
| Requesting user is not authenticated  | 401 Unauthorized  | "detail": "You do not have permission to perform this action." |
| Object Model with "id" does not exist | 404 Not Found     | "detail": "Not found."                                         |
| Transaction ID does not exist         | 404 Not Found     | "detail": "Not found."                                         |

## POST  /api/object-models/`id`/object-records/transactions/

### Response example

* Status `404 Not Found`

## POST  /api/object-models/`id`/object-records/transactions/`transaction_id`/

### Response example

* Status `405 Method Not Allowed`

## PATCH /api/object-models/`id`/object-records/transactions/`transaction_id`/

### Response example

* Status `405 Method Not Allowed`

## PUT /api/object-models/`id`/object-records/transactions/`transaction_id`/

### Response example

* Status `405 Method Not Allowed`

## DELETE /api/object-models/`id`/object-records/transactions/`transaction_id`/

### Response example

* Status `405 Method Not Allowed`

## OPTIONS /api/object-models/`id`/object-records/transactions/`transaction_id`/

### Response example

* Status `405 Method Not Allowed`

---

---
url: /api/catalyst/resources/object-records/object-record-documents.md
---
# Object Record Documents

Manually generating documents from document templates for a given Object Record.

# Object Record Documents API

## POST /api/object-records/documents/

Starting the document generation process.

### Permissions

Requires `authentication`

### Request example

* Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

### Body

| Key                 | Type | Required | Notes |
|---------------------|------|----------|-------|
| object\_record       | int  | True     |       |
| document\_template   | int  | True     |       |
| object\_record\_field | int  | False    |       |

### Validations

* object\_record\_id is an ID of Object Record
* object\_record\_field is slug name of Object Record field (ex. "field\_slug\_name")
* object\_record\_field is document type field
* object\_record\_field is defined in ObjectClass
* object\_record\_id and document\_template\_id have the same ObjectClass
* object\_records.view permission to individual object\_record
* object\_records.edit permission if object\_record\_field is not null
* If the generation process for a given pair (object\_record, document\_template) is running (status processing), the next generation attempt is skipped

### Sample request body

POST /api/object-records/documents/

```json

{
    "object_record": 1,
    "document_template": 2,
    "object_record_field": "field_abc"
}

```

### Response

| Key                 | Type   | Notes |
|---------------------|--------|-------|
| object\_record       | int    |       |
| document\_template   | int    |       |
| object\_record\_field | int    |       |
| \_meta.labels        | Object |       |

### Response `labels` object

| Key               | Type      | Notes                         |
|-------------------|-----------|-------------------------------|
| object\_record     | str       |                               |
| document\_template | str       |                               |

* Successful status 201 Created
* Response body schema

```json

{
    "object_record": 1,
    "document_template": 2,
    "object_record_field": "field_abc",
    "status": "processing",
    "_meta": {
        "labels": {
            "object_record": "Record repr value",
            "document_template": "Document Name"
           }
    }
}

```

### Errors

| Cause                                                             | Response code   | Message                                                                                       |
|-------------------------------------------------------------------|-----------------|-----------------------------------------------------------------------------------------------|
| object\_record is missing                                          | 400 Bad Request | "object\_record": \["This field is required."]                                                  |
| object\_record is null                                             | 400 Bad Request | "object\_record": \["This field may not be null."]                                              |
| object\_record insufficient permissions                            | 400 Bad Request | "object\_record": \["Invalid pk "value" - You do not have permission for this Record."]       |
| object\_record invalid ID                                          | 400 Bad Request | "object\_record": \["Invalid pk "value" - object does not exist."]                            |
| document\_template is missing                                      | 400 Bad Request | "document\_template": \["This field is required."]                                              |
| document\_template is null                                         | 400 Bad Request | "document\_template": \["This field may not be null."]                                          |
| document\_template insufficient permissions                        | 400 Bad Request | "document\_template": \["Invalid pk "value" - You do not have permission for this Document."] |
| document\_template invalid ID                                      | 400 Bad Request | "document\_template": \["Invalid pk "value" - object does not exist."]                        |
| document\_template, object\_record do not have the same ObjectClass | 400 Bad Request | "non\_field\_errors": \["Record pk "value" cannot be used with Document pk "value"."]        |
| object\_record\_field insufficient record.edit permissions          | 400 Bad Request | "object\_record\_field": \["Invalid pk "value" - You do not have permission for this Record."] |
| object\_record\_field invalid SLUG                                  | 400 Bad Request | "object\_record\_field": \["Invalid name "value" - field does not exist."]                     |
| object\_record\_field invalid type                                  | 400 Bad Request | "object\_record\_field": \["Invalid type - field "value" is not Document type."]               |
| Document for the given pair is already being processed            | 400 Bad Request | "detail": \["Your request is already processing."]                                             |
| insufficient permissions                                          | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                |

## GET /api/object-records/`id`/documents/

List Document Template based on query parameters and caller permissions.

The list is restricted only to those Document Templates for which the user has permission to view all classes
used in the relational MF in given document.
If the user does not have view permission for at least one Object Class used in the document,
they will not be able to see that document.

::: tip Important
Access to endpoint require passing Object Class filter `/api/object-records/<object_record_id>/documents/`
:::

### Permissions

Requires `authentication` and `object_records.list` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/object-records/1/documents/
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        |                                                                                  |
| offset            | int        |                                                                                  |
| total\_count       | int        | Total number of items visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of items visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key                         | Type   | Notes                                                 |
|-----------------------------|--------|-------------------------------------------------------|
| id                          | int    |                                                       |
| name                        | string |                                                       |
| allow\_on\_demand\_generation  | bool   |                                                       |
| generated\_document          | Array  |                                                       |

### Response `generated_document` array

| Key                   | Type     | Notes                                                                                 |
|-----------------------|----------|---------------------------------------------------------------------------------------|
| status                | enum     | `processing`, `canceled`, `completed`, `field_updated`, `field_not_updated`, `failed` |
| error\_message         | string   |                                                                                       |
| document              | int      |                                                                                       |
| generated\_at          | datetime |                                                                                       |
| generated\_by          | user     |                                                                                       |
| \_meta.labels.document | Array    |                                                                                       |

### Response `_meta.labels.document` array

| Key      | Type   | Notes                                                 |
|----------|--------|-------------------------------------------------------|
| name     | string |                                                       |
| url      | string |                                                       |
| size     | string |                                                       |
| type     | string |                                                       |

### Response example

* Status `200 OK`
* Body

```json
{
    "limit": 100,
    "offset": 0,
    "filtered_count": 2,
    "total_count": 2,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": 3,
            "name": "Test docx",
            "allow_on_demand_generation": true,
            "generated_document": {
                "id": 5,
                "status": "completed",
                "error_message": "",
                "document": 90,
                "generated_at": "2023-07-13T15:35:26.607101+02:00",
                "generated_by": {
                    "id": 240,
                    "first_name": "Ryan",
                    "last_name": "Sample",
                    "username": "ryan.sample@example.test",
                    "company_name": "",
                    "is_deleted": false,
                    "account_type": "super_admin"
                },
                "_meta": {
                    "labels": {
                        "document": {
                            "name": "Test docx.docx",
                            "url": "",
                            "size": "4258",
                            "type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
                        }
                    }
                }
            }
        },
        {
            "id": 4,
            "name": "Test",
            "generated_document": null
        }
    ]
}
```

### Sorting

| Parameter                      | Example                                                                      | Notes          |
|--------------------------------|------------------------------------------------------------------------------|----------------|
| id                             | {build}/api/object-records/1/documents/?ordering=id                          | Ascending      |
| id                             | {build}/api/object-records/1/documents/?ordering=-id                         | Descending (-) |
| name                           | {build}/api/object-records/1/documents/?ordering=name                        | Ascending      |
| name                           | {build}/api/object-records/1/documents/?ordering=-name                       | Descending (-) |
| allow\_on\_demand\_generation     | {build}/api/object-records/1/documents/?ordering=allow\_on\_demand\_generation  | Ascending      |
| allow\_on\_demand\_generation     | {build}/api/object-records/1/documents/?ordering=-allow\_on\_demand\_generation | Descending (-) |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter                  | Type   | Example                                                                 |
|----------------------------|--------|-------------------------------------------------------------------------|
| id                         | int    | {build}/api/object-records/1/documents/?id=1                            |
| id                         | int    | {build}/api/object-records/1/documents/?id\_\_in=1,2                      |
| name                       | string | {build}/api/object-records/1/documents/?name\_\_iexact=template name      |
| allow\_on\_demand\_generation | bool   | {build}/api/object-records/1/documents/?allow\_on\_demand\_generation=True |

| Error                                | Response code      | Message                                                        |
|--------------------------------------|--------------------|----------------------------------------------------------------|
| Invalid object\_record\_id in URL      | 404 Not Found      | "detail": \["Not found."]                                       |
| Insufficient permissions             | 403 Forbidden      | "detail": "You do not have permission to perform this action." |

## OPTIONS  /api/object-records/`object_record_id`/documents/

### Permissions

Requires `authentication` and `object_records.list` permission.

### Request example

* Headers

```
Request Method: OPTIONS
Location: /api/object-records/1/documents/
```

### Response example

* Status `200 OK`
* Body

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": true
            },
            {
                "alias": "name",
                "type": "string",
                "predicates": [],
                "sort_ok": true
            },
            {
                "alias": "allow_on_demand_generation",
                "type": "bool",
                "predicates": [
                    "exact"
                ],
                "sort_ok": true
            },
            {
                "alias": "generated_document",
                "type": "json",
                "predicates": [],
                "sort_ok": false
            }
        ]
    }
}
```

## GET /api/object-records/`object_record_id`/documents/`document_template_id`/

### Permissions

Requires `authentication` and Object Record view

### Request example

* Headers

```
Request Method: GET
Authorization: JWT access_token
```

### Response

| Key                          | Type    | Notes |
|------------------------------|---------|-------|
| id                           | int     |       |
| name                         | string  |       |
| allow\_on\_demand\_generation   | bool    |       |
| generated\_document           | Object  |       |

### Response `generated_document` object

| Key                   | Type     | Notes |
|-----------------------|----------|-------|
| status                | enum     |       |
| error\_message         | string   |       |
| document              | int      |       |
| generated\_at          | datetime |       |
| generated\_by          | user     |       |
| \_meta.labels.document | Object   |       |

### Response `_meta.labels.document` object

| Key  | Type   | Notes |
|------|--------|-------|
| name | string |       |
| url  | string |       |
| size | int    |       |
| type | string |       |

### Response example

* Status `200 OK`
* Body

```json
{
    "id": 2,
    "name": "Template name",
    "allow_on_demand_generation": true,
    "generated_document": {
        "status": "completed", 
        "error_message": "", 
        "document": 1,
        "generated_at": "2023-07-12T12:17:58.737002+02:00",
        "generated_by": {
                    "id": 240,
                    "first_name": "First Name",
                    "last_name": "Second",
                    "username": "mail@test.test",
                    "company_name": "",
                    "is_deleted": false,
                    "account_type": "super_admin"
                },
        "_meta": { 
            "labels": { 
                "document": {
                    "name": "TemplateName_2023-07-12.docx",
                    "url": "https://some.url",
                    "size": 4200,
                    "type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
                }
            } 
        } 
    }    
}  
```

### Errors

| Error                                           | Response code    | Message                                                        |
|-------------------------------------------------|------------------|----------------------------------------------------------------|
| A non-existent `record_id` was given            | 404 Not Found    | "detail": "Not found."                                         |
| A non-existent `document_template_id` was given | 404 Not Found    | "detail": "Not found."                                         |
| Insufficient permissions                        | 403 Forbidden    | "detail": "You do not have permission to perform this action." |
| Requesting user is not authenticated            | 401 Unauthorized | "detail": "Authentication credentials were not provided."      |

## POST /api/object-records/`object_record_id`/documents/`document_template_id`/cancel/

Canceling the document generation process.

### Permissions

Requires `authentication`, Object Record view and Object Class view to all Object Classes used in Template as merge fields.

### Request example

* Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

### Validations

* Document has already been processed

### Sample request body

POST /api/object-records/`object_record_id`/documents/`document_template_id`/cancel/

```json

{
}

```

### Response

| Key                 | Type   | Notes |
|---------------------|--------|-------|
| object\_record       | int    |       |
| document\_template   | int    |       |
| object\_record\_field | int    |       |
| \_meta.labels        | Object |       |

### Response `labels` object

| Key               | Type      | Notes                         |
|-------------------|-----------|-------------------------------|
| object\_record     | str       |                               |
| document\_template | str       |                               |

* Successful status 201 Created
* Response body schema

```json

{
    "object_record": 1,
    "document_template": 2,
    "object_record_field": "field_abc",
    "status": "cancelled",
    "_meta": {
        "labels": {
            "object_record": "Record repr value",
            "document_template": "Document Name"
           }
    }
}

```

### Errors

| Error                                           | Response code    | Message                                                        |
|-------------------------------------------------|------------------|----------------------------------------------------------------|
| A non-existent `record_id` was given            | 404 Not Found    | "detail": "Not found."                                         |
| A non-existent `document_template_id` was given | 404 Not Found    | "detail": "Not found."                                         |
| Cancelling for statuses other than "processing" | 400 Bad Request  | "detail": \["Document has already been processed."]             |
| Insufficient permissions                        | 403 Forbidden    | "detail": "You do not have permission to perform this action." |

## GET /api/object-records/`record_id`/documents/`template_id`/download/`uuid`/

Download generated document.

### Permissions

Requires `authentication`, Object Record view and Object Class view to all Object Classes used in Template as merge fields.

### Request

* Headers

```
Content-Type: application/force-download
```

* Schema

```json
GET /api/object-records/2/documents/12/download/4fef1510-7b0b-46fd-84d4-7b933d3b6f72/
```

## GET /api/object-records/`id`/document-fields/

Document fields list for given Object Record.

### Permissions

Requires `authentication` and `object_records.view` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/object-records/1/document-fields/
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        |                                                                                  |
| offset            | int        |                                                                                  |
| total\_count       | int        | Total number of items visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of items visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key              | Type   | Notes                                                 |
|------------------|--------|-------------------------------------------------------|
| alias            | string |                                                       |
| label            | string |                                                       |
| max\_num\_of\_files | int    |                                                       |
| is\_available     | bool   |                                                       |

### Response example

* Status `200 OK`
* Body

```json
{
    "limit": 50,
    "offset": 0,
    "filtered_count": 1,
    "total_count": 1,
    "next": null,
    "previous": null,
    "results": [
        {
            "alias": "field_document",
            "label": "Document",
            "max_num_of_files": 3,
            "is_available": true
        }
    ]
}
```

| Error                                | Response code      | Message                                                        |
|--------------------------------------|--------------------|----------------------------------------------------------------|
| Invalid object\_record\_id in URL      | 404 Not Found      | "detail": \["Not found."]                                       |
| Insufficient permissions             | 403 Forbidden      | "detail": "You do not have permission to perform this action." |

---

---
url: /api/websockets/resources/object-records.md
---
# Object Record Events

This page documents the WebSocket endpoint used to receive real-time Object Record change events in Catalyst.

The endpoint broadcasts Object Record-related events so that connected clients can reflect changes without polling or refreshing the page. It is intended for real-time UI updates and event-driven integrations that need to track record creation, value changes, ownership changes, assignment changes, document generation, and deletion.

::: warning
This section documents technical and service-level WebSocket APIs. It should be used as implementation reference material and not treated as end-user documentation.
:::

## Endpoint overview

This page covers the following endpoint:

* `GET /ws/events/object-records/`

## GET /ws/events/object-records/

Subscribes the client to a stream of Object Record change events.

The endpoint broadcasts updates for up to 1,000 Object Records every 5 seconds.

### Permissions

Requires `authentication`.

Authentication is based on the `uuid` query string parameter used when establishing the WebSocket connection.

### Request

#### Upgrade request example

```text
Request Method: GET
Connection: Upgrade
Upgrade: websocket
```

#### Query parameters

Optional filters can be passed in the WebSocket connection query string, alongside the `uuid` authentication parameter.

| Parameter | Type | Notes |
|---|---|---|
| object\_class\_ids | comma-separated int list | Optional. Limits delivered notifications to events where `object_class_id` matches one of the provided IDs. |
| field\_ids | comma-separated int list | Optional. Limits delivered `object_record_value_changed` notifications to events that include at least one matching Object Class Field ID. Other event types are not restricted by this parameter. |

Examples:

```text
GET /ws/events/object-records/?uuid=<uuid>&object_class_ids=1,2
GET /ws/events/object-records/?uuid=<uuid>&field_ids=10,11
GET /ws/events/object-records/?uuid=<uuid>&object_class_ids=1,2&field_ids=10,11
```

Empty parameters are treated as no filter. Invalid comma-separated values are silently ignored. A filter is active only when at least one valid integer value remains after parsing.

### Filtering behaviour

When `object_class_ids` is provided, the server delivers only notifications where `object_class_id` matches one of the provided values. Notifications for other Object Classes are dropped server-side.

When `field_ids` is provided, it applies only to `object_record_value_changed` notifications:

* a value-changed notification is delivered only when at least one changed field ID matches the provided `field_ids`
* the forwarded `field_ids` list contains only the matched subset
* other event types, such as `object_record_created` and `object_record_deleted`, are not restricted by this filter

When both `object_class_ids` and `field_ids` are provided, both filters apply. A notification must pass the Object Class filter and, for `object_record_value_changed` notifications, the field filter to be delivered.

Connections without `object_class_ids` or `field_ids` receive all events, preserving the previous behaviour.

### Response

After the connection is established, the server sends a list of Object Record change events.

Each list item contains the following fields:

| Key | Type | Notes |
|---|---|---|
| object\_record\_id | int | Object Record identifier |
| object\_class\_id | int | Related Object Class identifier |
| event | string | Object Record event type |
| field\_ids | array\[int] | Included on `object_record_value_changed` events. Contains the changed Object Class Field IDs. When `field_ids` filtering is active, contains only the matched subset. |
| timestamp | datetime | Time the event was created |

For `object_record_value_changed`, a single backend event with multiple changed fields produces one WebSocket message with a `field_ids` list. The message does not use a single `field_id` integer.

### Available events

The following event values are supported:

* `object_record_created`
* `object_record_value_changed`
* `object_record_owner_initialized`
* `object_record_owner_added`
* `object_record_owner_removed`
* `object_record_assignee_added`
* `object_record_assignee_removed`
* `object_record_deleted`
* `object_record_document_generated`

### Success

* WebSocket upgrade status: `101 Switching Protocols`

#### Example payload

```json
[
  {
    "object_record_id": 1,
    "object_class_id": 1,
    "event": "object_record_owner_initialized",
    "timestamp": "2025-01-16T11:07:57.954470+00:00"
  },
  {
    "object_record_id": 1,
    "object_class_id": 1,
    "event": "object_record_created",
    "timestamp": "2025-01-16T11:07:57.934931+00:00"
  },
  {
    "object_record_id": 1,
    "object_class_id": 1,
    "event": "object_record_value_changed",
    "field_ids": [10, 11],
    "timestamp": "2025-01-16T11:08:07.444085+00:00"
  }
]
```

## Ordering and delivery

Sorting cannot be controlled by the client.

By default, events are delivered in creation order. Where results are chunked, events are ordered in ascending order by event timestamp.

## Errors

| Error | Response code / close status | Message |
|---|---|---|
| Incorrect WebSocket URL path | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_INCORRECT_URL", "detail":"Incorrect WebSocket URL."` |
| Invalid UUID | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_INVALID_UUID", "detail":"A valid UUID is required."` |
| Sending messages to this WebSocket is not supported | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "RECEIVE_NOT_SUPPORTED", "detail": "This WebSocket connection does not support receiving messages."` |
| Rate limit exceeded | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_RATE_LIMIT_EXCEEDED", "detail":"The rate limit for requests has been exceeded. Please wait before trying again."` |
| Error during the handshake | `500 Internal Server Error` | |

## Notes

WebSocket standard close/error definitions are described in [RFC 6455](https://datatracker.ietf.org/doc/html/rfc6455#section-7.4.1).

---

---
url: /api/catalyst/resources/object-records/object-record-owners.md
---
# Object Record Owners

This technical design describes API for Object Record Owners.

Implementation details can be found in external document: [Event History - Object Records - Technical Design](https://autologyx.sharepoint.com/:w:/s/Dev/ESAwVIcuI3pNjXgZISWm7jYB_UvFyr8E1tz2tOvWf7sEHw?e=UGjRBX).

# Object Records Owners API

## POST /api/object-records/`record_id`/owners/

Creates Object Record Owner relations.

### Permissions

Requires `authentication` and any of

1. `object_records.edit` permission
2. Object Record Ownership

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| record\_id         | Object Record ID  |

### Request example

* Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

### Body

| Key | Type | Required | Notes          |
|-----|------|----------|----------------|
| -   | list | True     | owner ids list |

### Validations

* Maximum number of Owners per specific Object Record: 1.
* Maximum number of Owners in batch: 1.
* User is validated by account type, `one_time_completion` account cannot be owner.

### Sample request body

POST /api/object-records/1/owners/

```json

[
   2
]

```

### Response

| Key        | Type     | Notes                                     |
|------------|----------|-------------------------------------------|
| id         | int      | Automatically generated by the backend. 	 |
| name       | string   |                                           |
| owner\_id   | int      |                                           |
| type       | string   |                                           |
| created\_at | datetime |                                           |
| created\_by | user     |                                           |
| user       | Object   |                                           |

* Response `user` Object

| Key          | Type   | Notes                                     |
|--------------|--------|-------------------------------------------|
| id           | int    | Automatically generated by the backend. 	 |
| username     | string |                                           |
| first\_name   | string |                                           |
| last\_name    | string |                                           |
| account\_type | string |                                           |
| company\_name | string |                                           |
| is\_deleted   | bool   |                                           |

* Successful status 201 Created
* Response body schema

```json
{
   "id": 10,
   "owner_id": 41,
   "type": "user",
   "name": "sample name",
   "created_at": "2023-07-10T09:28:27.679165+02:00",
   "created_by": "some name (test.autologyx@autologyx.com)",
   "user": {
      "id":41,
      "first_name": "first name",
      "last_name": "last name",
      "username": "test.autologyx@autologyx.com",
      "company_name": "autologyx",
      "is_deleted": false,
      "account_type": "full"
   }
}

```

### Errors

| Cause                                                                                                     | Response code    | Message                                                                                                     |
|-----------------------------------------------------------------------------------------------------------|------------------|-------------------------------------------------------------------------------------------------------------|
| record\_id is invalid                                                                                      | 400 Bad Request  | "detail": "Invalid pk "99999" - object does not exist."                                                   |
| record\_id is not int                                                                                      | 400 Bad Request  | "detail": "Incorrect type. Expected pk value, received str."                                                |
| list in body is empty                                                                                     | 400 Bad Request  | "detail": "This list may not be empty."                                                                     |
| body has incorrect type                                                                                   | 400 Bad Request  | "detail": "Expected a list of items but got type "str"."                                                  |
| owner has wrong type                                                                                      | 400 Bad Request  | "detail": "1 Time Completion account cannot be owner."                                                      |
| batch size is above the limit                                                                             | 400 Bad Request  | "detail": "Up to 1 item allowed."                                                                           |
| object record owners is above the limit                                                                   | 400 Bad Request  | "detail": "Limit of 1 Object Record Owners has been exceeded."                                              |
| Request user does not have "users.list" permission for the user to be assigned as the Object Record owner | 400 Bad Request  | "detail": \["You do not have permission to make user "{user\_id}" the owner of Object Record "{record\_id}"."] |
| insufficient permissions	                                                                                 | 403 Forbidden    | "detail": "You do not have permission to perform this action."                                              |

## GET /api/object-records/`record_id`/owners/

Returns list of owners.

### Permissions

Requires `authentication` and any of

1. `object_records.view` permission
2. Object Record Ownership

### URL parameters

| Key               | Notes             |
|-------------------|-------------------|
| record\_id         | Object Record ID  |

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

### Response `results` array

| Key        | Type     | Notes                                     |
|------------|----------|-------------------------------------------|
| id         | int      | Automatically generated by the backend. 	 |
| name       | string   |                                           |
| owner\_id   | int      |                                           |
| type       | string   |                                           |
| created\_at | datetime |                                           |
| created\_by | user     |                                           |
| user       | Object   |                                           |

* Successful status `200 OK`
* Response body schema

```json
{
  "limit":50,
  "offset":0,
  "filtered_count":1,
  "total_count":1,
  "next":null,
  "previous":null,
  "results":[
    {
      "id":22,
      "owner_id":641,
      "type":"user",
      "name":"sample name",
      "created_at":"2023-07-10T09:28:27.679165+02:00",
      "created_by":"some name (test.autologyx@autologyx.com)",
      "user":
        {
          "id":641,
          "first_name":"sample first name",
          "last_name":"sample last name",
          "username":"test.autologyx@example.test",
          "company_name":"autologyx",
          "is_deleted":false,
          "account_type":"full"
        }
    }]}

```

### Sorting

| Parameter  | Example                                                             | Notes           |
|------------|---------------------------------------------------------------------|-----------------|
| id         | {build}/api/object-records/`record_id`/owners/?ordering=id          | Ascending       |
| id         | {build}/api/object-records/`record_id`/owners/?ordering=-id         | Descending (-)  |
| name       | {build}/api/object-records/`record_id`/owners/?ordering=name        | Ascending       |
| name       | {build}/api/object-records/`record_id`/owners/?ordering=-name       | Descending (-)  |
| created\_at | {build}/api/object-records/`record_id`/owners/?ordering=created\_at  | Ascending       |
| created\_at | {build}/api/object-records/`record_id`/owners/?ordering=-created\_at | Descending (-)  |

### Filtering

#### Filtering by Object Record related fields

| Parameter  | Type     | Example                                                                   |
|------------|----------|---------------------------------------------------------------------------|
| id         | int      | {build}/api/object-records/`record_id`/owners/?id=1                       |
| owner\_id   | datetime | {build}/api/object-records/`record_id`/owners/?owner\_id=2                 |
| name       | string   | {build}/api/object-records/`record_id`/owners/?name=John                  |
| created\_at | datetime | {build}/api/object-records/`record_id`/owners/?created\_at\_\_gte=2022-01-01 |
| created\_by | enum     | {build}/api/object-records/`record_id`/owners/?created\_by=321             |

### Errors

| Cause                     | Response code   | Message                                                          |
|---------------------------|-----------------|------------------------------------------------------------------|
| Insufficient permissions	 | 403 Forbidden   | "detail": "You do not have permission to perform this action."   |

## GET /api/object-records/`record_id`/owners/`owner_id`/

### Response example

* Status `405 Method Not Allowed`

## DELETE /api/object-records/`record_id`/owners/`object_record_owner_id`/

Delete single object relation record.

### Permissions

Requires `authentication` and any of

1. `object_records.edit` permission
2. Object Record Ownership

### URL parameters

| Key                    | Notes                   |
|------------------------|-------------------------|
| record\_id              | Object Record ID        |
| object\_record\_owner\_id | Object Record Owner ID  |

### Request example

* Headers

```
Request Method: DELETE
Content-Type: application/json
Authorization: JWT access_token
```

### Response

* Successful status `204 No Content`

### Errors

| Cause                     | Response code   | Message                                                          |
|---------------------------|-----------------|------------------------------------------------------------------|
| Insufficient permissions	 | 403 Forbidden   | "detail": "You do not have permission to perform this action."   |

## OPTIONS /api/object-records/`record_id`/owners/

### Permissions

Requires `authentication` only.

### Request example

* Headers

```
Request Method: DELETE
Content-Type: application/json
Authorization: JWT access_token
```

### Response example

* Status `200 OK`
* Body

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "owner_id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": false
            },
            {
                "alias": "name",
                "type": "string",
                "predicates": [
                    "exact",
                    "iexact",
                    "contains",
                    "icontains",
                    "startswith",
                    "istartswith",
                    "endswith",
                    "iendswith"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_by",
                "type": "enum",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            }
        ]
    },
    "batch": {
        "type": "set",
        "required": true,
        "autocomplete": "/api/users/autocomplete/?account_type!=one_time_completion&text__icontains="
    },
    "restrictions": {
        "limit_items": 1,
        "limit_items_in_batch": 1
    }
}
```

---

---
url: /api/catalyst/resources/object-records/object-record-uploads.md
---
# Object Record Uploads

This design describes API for Object Record Uploads.

# Object Records Uploads API

## POST /api/object-records/uploads/

Creates Object Record Upload instance.

### Permissions

Requires `authentication`

### Request example

* Headers

```
Request Method: POST
Content-Type: application/json
Authorization: JWT access_token
```

### Body

| Key                   | Notes                 |
|-----------------------|-----------------------|
| object\_class          | Object Class ID       |
| object\_class\_field    | Object Class Field ID |

### Validations

* object\_class
  * integer
  * required
  * must be a valid Class ID
  * user sending the request must have permission to object\_records.create for this Object Class
* object\_class\_field
  * integer
  * required
  * must be a valid field in the specified Object Class and of type "document"

### Sample request body

POST /api/object-records/uploads/

```json

{
    "object_class": <object_class_id>,
    "object_class_field": <object_class_field_id>
}

```

### Response

| Key       | Type | Notes                                     |
|-----------|------|-------------------------------------------|
| upload\_id | UUID | Automatically generated by the backend. 	 |

```json
{
   "upload_id": <UUID>
}

```

### Errors

| Cause                                               | Response code    | Message                                                                                            |
|-----------------------------------------------------|------------------|----------------------------------------------------------------------------------------------------|
| object\_class is invalid                             | 400 Bad Request  | "object\_class": \["Invalid pk "99999" - object does not exist."]                                  |
| object\_class is not int                             | 400 Bad Request  | "object\_class": \["Incorrect type. Expected pk value, received str."]                               |
| object\_class is required                            | 400 Bad Request  | "object\_class": \["This field is required."]                                                        |
| object\_class is empty                               | 400 Bad Request  | "object\_class": \["This field may not be null."]                                                    |
| insufficient permissions to object\_class            | 400 Bad Request  | "object\_class": \["You do not have permission to use this object class."]                           |
| object\_class\_field is invalid                       | 400 Bad Request  | "object\_class\_field": \["Invalid pk "99999" - object does not exist."]                            |
| object\_class\_field is not int                       | 400 Bad Request  | "object\_class\_field": \["Incorrect type. Expected pk value, received str."]                         |
| object\_class\_field is required                      | 400 Bad Request  | "object\_class\_field": \["This field is required."]                                                  |
| object\_class\_field is empty                         | 400 Bad Request  | "object\_class\_field": \["This field may not be null."]                                              |
| object\_class\_field is not document type             | 400 Bad Request  | "object\_class\_field": \["Invalid type - field "field name" is not Document type."]                |
| object\_class\_field does not belong to object\_class  | 400 Bad Request  | "details": \["Object Class Field ID "field\_id" does not belong to Object Class ID "class\_id"."] |

## GET /api/object-records/uploads/me/

Endpoint retrieving the list of upload sessions.

### Permissions

Requires `authentication` and `uploads.list` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/object-records/uploads/me/
Authorization: JWT access_token
```

### Response

| Key                 | Type     | Notes |
|---------------------|----------|-------|
| upload\_id           | UUID     |       |
| object\_class\_name   | str      |       |
| document\_field\_name | str      |       |
| zip\_filename        | str      |       |
| process\_initiated   | datetime |       |
| total\_files         | int      |       |
| status              | enum     |       |
| \_meta.permissions   | Object   |       |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 50,
  "offset": 0,
  "filtered_count": 2,
  "total_count": 2,
  "next": null,
  "previous": null,
  "results": [
    {
      "upload_id": "3c2b9b89-2f2a-497c-aa0a-1be5a8fd93c8",
      "object_class_name": "Invoices",
      "document_field_name": "Invoices ready",
      "zip_filename": "jan2025_invoices.zip",
      "process_initiated": "2025-06-20T14:32:10.341Z",
      "total_files": 20,
      "status": "complete with fails",
      "_meta": {
        "permissions": {
          "list": true,
          "view": true
        }
      }
    },
    {
      "upload_id": "23ae9b77-1f3e-4aa9-87a4-b9c3a7ef481c",
      "object_class_name": "Payments",
      "document_field_name": "Payments file",
      "zip_filename": "april_payments.zip",
      "process_initiated": "2025-04-11T11:02:00.134Z",
      "total_files": 12,
      "status": "complete",
      "_meta": {
        "permissions": {
          "list": true,
          "view": true
        }
       ]
      }
    }
  ]
}
```

### Sorting

Not available. Results are sorted by {process\_initiated} descending.

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter | Type   |
|-----------|--------|
| status    | enum   |

### Errors

| Error                | Response code      | Message                                                    |
|----------------------|--------------------|------------------------------------------------------------|
| Not authenticated    | 401 Unauthorized   | "detail": "Authentication credentials were not provided."  |

## GET /api/object-records/uploads/`upload_id`/summary/

Endpoint retrieving single upload summary.

### Permissions

Requires `authentication` and `uploads.view` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/object-records/uploads/`upload_id`/summary/
Authorization: JWT access_token
```

### Response

| Key                 | Type     | Notes |
|---------------------|----------|-------|
| upload\_id           | UUID     |       |
| object\_class\_name   | str      |       |
| document\_field\_name | str      |       |
| zip\_filename        | str      |       |
| process\_completed   | datetime |       |
| total\_files         | int      |       |
| successful\_count    | int      |       |
| successful\_percent  | int      |       |
| failed\_count        | int      |       |
| failed\_percent      | int      |       |
| \_meta.permissions   | Object   |       |

### Response example

* Status `200 OK`
* Body

```json
{
  "upload_id": "3c2b9b89-2f2a-497c-aa0a-1be5a8fd93c8",
  "object_class_name": "Invoice",
  "document_field_name": "field_invoice_document",
  "zip_filename": "jan2025_invoices.zip",
  "process_completed": "2025-06-20T14:32:10.341Z",
  "total_files": 20,
  "successful_count": 17,
  "successful_percent": 85,
  "failed_count": 3,
  "failed_percent": 15,
  "_meta": {
    "permissions": {
      "list": true,
      "view": true
    }
  }
}
```

### Errors

| Error                            | Response code    | Message                                                   |
|----------------------------------|------------------|-----------------------------------------------------------|
| Not authenticated                | 401 Unauthorized | "detail": "Authentication credentials were not provided." |
| Upload not found or invalid ID   | 404 Not Found    | "detail": "Not found."                                    |
| Upload is still being processed  | 404 Not Found    | "detail": "Not found."                                    |

## GET /api/object-records/uploads/`upload_id`/files/

Endpoint retrieving the list of completed upload files.

### Permissions

Requires `authentication` and `uploads.view` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/object-records/uploads/`upload_id`/files/
Authorization: JWT access_token
```

### Response

| Key           | Type     | Notes |
|---------------|----------|-------|
| file\_name     | str      |       |
| file\_size     | str      |       |
| status        | enum     |       |
| record\_id     | id       |       |
| created\_at    | datetime |       |
| error\_reason  | Object   |       |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 50,
  "offset": 0,
  "filtered_count": 3,
  "total_count": 3,
  "next": null,
  "previous": null,
  "results": [
    {
      "file_name": "invoice_002.pdf",
      "file_size": 58723,
      "status": "successful",
      "record_id": 7891,
      "created_at": "2025-06-20T14:36:45.410Z",
      "error_reason": null
    },
    {
      "file_name": "invoice_001.pdf",
      "file_size": 45678,
      "status": "successful",
      "record_id": 7842,
      "created_at": "2025-06-20T14:31:00.120Z",
      "error_reason": null
    },
    {
      "file_name": "broken_scan.tiff",
      "file_size": 38791,
      "status": "failed",
      "record_id": null,
      "created_at": null,
      "error_reason": "Unsupported file format: .tiff" 
    }
  ]
}
```

### Sorting

| Parameter  | Example                                                                    | Notes          |
|------------|----------------------------------------------------------------------------|----------------|
| created\_at | {build}/api/object-records/uploads/{upload\_id}/files/?ordering=created\_a   | Ascending      |
| created\_at | {build}/api/object-records/uploads/{upload\_id}/files/?ordering=-created\_a  | Descending (-) |
| file\_name  | {build}/api/object-records/uploads/{upload\_id}/files/?ordering=file\_name   | Ascending      |
| file\_name  | {build}/api/object-records/uploads/{upload\_id}/files/?ordering=-file\_name  | Descending (-) |

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter | Type   |
|-----------|--------|
| status    | enum   |

### Errors

| Error                           | Response code     | Message                                                                         |
|---------------------------------|-------------------|---------------------------------------------------------------------------------|
| Not authenticated               | 401 Unauthorized  | "detail": "Authentication credentials were not provided."                       |
| Upload not found or invalid ID  | 404 Not Found     | "detail": "Not found."                                                          |
| Upload is still being processed | 404 Not Found     | "detail": "Not found."                                                          |
| Invalid query parameter status  | 400 Bad Request   | "status": "Select a valid choice. {value} is not one of the available choices." |

## OPTIONS /api/object-records/uploads/`upload_id`/files/

### Permissions

Requires authentication only.

### Request example

* Headers

```
Request Method: OPTIONS
Location: /api/object-records/uploads/`upload_id`/files/
```

### Response example

* Status `200 OK`
* Body

```json
{
    "list": {
        "columns": [
            {
                "alias": "file_name",
                "type": "string",
                "predicates": [],
                "sort_ok": true
            },
            {
                "alias": "file_size",
                "type": "int",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "status",
                "type": "enum",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "values": [
                    {
                        "value": "completed",
                        "text": "Completed"
                    },
                    {
                        "value": "failed",
                        "text": "Failed"
                    }
                ]
            },
            {
                "alias": "record_id",
                "type": "int",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [],
                "sort_ok": true
            },
            {
                "alias": "error_reason",
                "type": "json",
                "predicates": [],
                "sort_ok": false
            }
        ]
    },
    "details": {
        "schema": []
    },
    "restrictions": {}
}
```

## OPTIONS /api/object-record/uploads/me/

### Permissions

Requires authentication only.

### Request example

* Headers

```
Request Method: OPTIONS
Location: /api/object-record/uploads/me/
```

### Response example

* Status `200 OK`
* Body

```json
{
    "list": {
        "columns": [
            {
                "alias": "upload_id",
                "type": "uuid",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "object_class_name",
                "type": "string",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "document_field_name",
                "type": "string",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "zip_filename",
                "type": "string",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "process_initiated",
                "type": "datetime",
                "predicates": [],
                "sort_ok": true
            },
            {
                "alias": "total_files",
                "type": "int",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "status",
                "type": "enum",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "values": [
                    {
                        "value": "pending",
                        "text": "Pending"
                    },
                    {
                        "value": "in_progress",
                        "text": "In Progress"
                    },
                    {
                        "value": "completed",
                        "text": "Completed"
                    },
                    {
                        "value": "failed",
                        "text": "Failed"
                    },
                    {
                        "value": "completed_with_fails",
                        "text": "Completed With Fails"
                    }
                ]
            }
        ]
    },
    "details": {
        "schema": []
    }
}
```

---

---
url: /api/catalyst/resources/object-records/object-records.md
---
# Object Records

This technical design describes implementation and API for Object Records.

# Object Records API

## POST /api/object-records/

Creates a new Object Record.

Creator (user) of Object Record becomes an owner.

### Permissions

Requires `authentication` and Object Class Ownership or has Object Record create permissions by any permission\_set.

### Request

* Headers

```
Request Method: POST
Authorization: JWT access_token
```

* Body

| Key                  | Type   | Required | Notes                                       |
|----------------------|--------|----------|---------------------------------------------|
| object\_name          | string | false    |                                             |
| object\_class         | pk     | true     | Relations between object classes            |
| field\_\<field\_alias>  | any    | false    | Fields based on Object Class configuration  |

#### Validations

* object\_name
  * Ensure this field has no more than 255 characters.

* object\_class
  * This field is required.
  * Invalid pk "value" - object does not exist.
  * This field may not be null.
  * The object class "value" might be given only once.

* field\_\<field\_alias>:
  * This field is required.
  * Check if field is valid
  * Depending on field type a various validation errors are raised for invalid value.
    * String:
      * Ensure this field has no more than {max} characters.
    * Integer:
      * A valid integer is required.
      * Ensure this value is greater than or equal to {min\_value}.
      * Ensure this value is less than or equal to {max\_value}.
    * Decimal:
      * A valid number is required.
      * Ensure this value is greater than or equal to {min\_value}.
      * Ensure this value is less than or equal to {max\_value}.
    * Bool:
      * Must be a valid boolean.
      * Field contains a value other than required.
    * Enum:
      * /value/ is not a valid choice.
    * Email:
      * Enter a valid email address.
      * Ensure this field has no more than /max/ characters.
    * Phone:
      * Ensure this field has no more than 100 characters.
    * Date:
      * Date has wrong format. Use one of these formats instead: YYYY-MM-DD.
    * Time:
      * Time has wrong format. Use one of these formats instead: hh:mm\[:ss\[.uuuuuu]].
    * Datetime:
      * Datetime has wrong format. Use one of these formats instead: YYYY-MM-DDThh:mm\[:ss\[.uuuuuu]]\[+HH:MM|-HH:MM|Z].
    * Enum
      * "{value}" is not a valid choice.
    * Url
      * Enter a valid URL.
      * Ensure this field has no more than {max} characters."
    * JSON
      * Value must be valid JSON.
      * Ensure this field has no more than {max} characters.
    * Set
      * Value must be valid Set.
      * The number of elements must be less than or equal to {max\_items}.
      * The number of elements must be greater than or equal to {min\_items}.
    * Document
      * Value must be valid tokens list.
      * The number of elements must be less than or equal to {max\_items}.
    * User
      * Value must be a valid object with key `users` or `user_groups`.
      * An `users` must be a valid set of users IDs.
      * An `user_groups` must be a valid set of groups IDs
      * User IDs must be an ID of existing not deleted users, limited to list defined in Object Class Field options.
      * Groups IDs ust be an ID of existing users group, limited to list defined in Object Class Field options.
      * The number of `users` elements must be less than or equal to {max\_users\_items}.
      * The number of `users` elements must be greater than or equal to {min\_users\_items}.
      * The number of `user_groups` elements must be less than or equal to {max\_groups\_items}.
      * The number of `user_groups` elements must be less than or equal to 10.
      * The number of `user_groups` elements must be greater than or equal to {min\_groups\_items}.

### Sample request body

```json
POST /api/object-records/

{
  "object_name": "Object Record",
  "object_class": 1,
  "field_first_name": "John",  
  "field_last_name": "Doe", 
  "field_email": "john-doe@nwc.xxx", 
  "field_age": 33, 
  "field_dob": "2022-11-17", 
  ... 
  "field_<field_alias>": <field_specific_type>
} 

```

### Sample users field body

```json
POST /api/object-records/

{
  ...
  "field_<field_alias>": {"users": [323, 4345], "user_groups": [2, 23]}
} 

```

### Response

| Key                   | Type     | Notes                                      |
|-----------------------|----------|--------------------------------------------|
| id                    | int      |                                            |
| object\_name           | string   |                                            |
| object\_class          | int      |                                            |
| status                | enum     | The only option is: "initiated"            |
| created\_at            | datetime |                                            |
| created\_by            | user     |                                            |
| modified\_at           | datetime |                                            |
| modified\_by           | user     |                                            |
| *meta                 | Object   | [\_meta](#response-meta-object) result      |
| field*\<field\_alias>   | any      | Fields based on Object Class configuration |

For fields with type:

* email
* phone
* url
* json

When user creates a record using  with request body shown below.

```json
{
    "field_<type>_field": "" 
}
```

The field value is set to null.

Expected response with this field is:

```json
{
    "field_<type>_field": null
}
```

### Response `_meta` object

| Key             | Type          | Notes |
|-----------------|---------------|-------|
| permissions     | Object        |       |
| labels          | Object        |       |
| users           | Object        |       |
| user\_groups     | Object        |       |

### Response `_meta.users` object

| Key       | Type | Notes                                          |
|-----------|------|------------------------------------------------|
| \<user\_id> | user |                                                |

`_meta.users` contains max 50 user objects for first 50 unique items from user type fields.

### Response `_meta.user_groups` object

| Key              | Type   | Notes                            |
|------------------|--------|----------------------------------|
| \<users\_group\_id> | Object | Contains group `id` and `name`   |

`_meta.user_groups` contains max 50 user group objects for first 50 unique items from user type fields.

* Successful status `201 Created`
* Response body schema

```json
{
  "id": 20,
  "object_name": "Object Record",
  "object_class": 1,
  "status": "initiated",
  "created_at": "2022-08-18T12:21:35.921861+02:00",
  "created_by": {
    "id": 2,
    "first_name": "ALX",
    "last_name": "Developer",
    "username": "alx.dev@autologyx.com",
    "company_name": "",
    "is_deleted": false,
    "account_type": "super_admin"
  },
  "modified_at": "2022-08-18T13:43:42.874876+02:00",
  "modified_by": {
    "id": 2,
    "first_name": "ALX",
    "last_name": "Developer",
    "username": "alx.dev@autologyx.com",
    "company_name": "",
    "is_deleted": false,
    "account_type": "super_admin"
  },
  "field_first_name": "John",
  "field_last_name": "Doe",
  "field_email": "john-doe@nwc.xxx",
  "field_age": 33,
  "field_dob": "2022-11-17", 
  "field_documents": null,
  "field_user": {"users": [23], "user_groups": [2]},
  "_meta": {
    "labels": {
      "object_class": "MareK Test #1",
      "files": null
    },
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "create": true,
      "delete": true,
      "edit_owners": true,
      "view_owners": true,
      "tasks": {
        "list": true,
        "view": true,
        "edit": true,
        "delete": true,
        "create": true,
        "complete": true,
        "assign": true
      }
    },
    "users": {
        "23": {
            "id": 23,
            "first_name": "John",
            "last_name": "Smith",
            "username": "j.smith@autologyx.com",
            "company_name": "Autologyx",
            "is_deleted": false,
            "account_type": "super_admin"
        }
    },
     "user_groups": {
        "2": {
            "id": 2,
            "name": "Group2"
        }
    },
    "allowed_status_transitions": [],
    "forbidden_actions": []
  }
}
```

### Restriction

* Max `500 000` Object Records in one Object Class

### Errors

| Cause                                        | Response code   | Message                                                                             |
|----------------------------------------------|-----------------|-------------------------------------------------------------------------------------|
| object\_class is required                     | 400 Bad Request | "object\_class": \[ "This field is required."]                                      |
| object\_class is empty                        | 400 Bad Request | "object\_class": \[ "This field may not be blank."]                                 |
| object\_class is null                         | 400 Bad Request | "object\_class": \[ "This field may not be null."]                                  |
| object\_class is invalid                      | 400 Bad Request | "object\_class": \[ "'Invalid pk "{object\_class\_id}" - object does not exist.'"]    |
| object\_name to long                          | 400 Bad Request | "object\_name": \["Ensure this field has no more than 255 characters."]             |
| Exceeded max number of Object Record fields  | 400 Bad Request | "detail": "Limit of 500 000 Object Records in this Object Class has been exceeded." |
| Insufficient permissions                     | 403 Forbidden   | "detail": "You do not have permission to perform this action."                      |

### Field type Errors

| Cause                                                                                      | Response code   | Message                                                                                                                  |
|--------------------------------------------------------------------------------------------|-----------------|--------------------------------------------------------------------------------------------------------------------------|
| string is too long                                                                         | 400 Bad Request | "field\_{string}": \["Ensure this field has no more than {max} characters."]                                               |
| string is required                                                                         | 400 Bad Request | "field\_{string}": \["This field is required."]                                                                            |
| string is not unique                                                                       | 400 Bad Request | "field\_{string}": \["This field must be unique."]                                                                         |
| integer value is invalid                                                                   | 400 Bad Request | "field\_{integer}": \["A valid integer is required."]                                                                      |
| integer is required                                                                        | 400 Bad Request | "field\_{integer}": \["This field is required."]                                                                           |
| integer value is below the limit                                                           | 400 Bad Request | "field\_{integer}": \["Ensure this value is greater than or equal to {min}."]                                              |
| integer value is above the limit                                                           | 400 Bad Request | "field\_{integer}": \["Ensure this value is less than or equal to {max}."]                                                 |
| integer is not unique                                                                      | 400 Bad Request | "field\_{integer}": \["This field must be unique."]                                                                        |
| float value is invalid                                                                     | 400 Bad Request | "field\_{float}": \["A valid number is required."]                                                                         |
| float is required                                                                          | 400 Bad Request | "field\_{float}": \["This field is required."]                                                                             |
| float value is below the limit                                                             | 400 Bad Request | "field\_{float}": \["Ensure this value is greater than or equal to {min}."]                                                |
| float value is above the limit                                                             | 400 Bad Request | "field\_{float}": \["Ensure this value is less than or equal to {max}."]                                                   |
| float is not unique                                                                        | 400 Bad Request | "field\_{float}": \["This field must be unique."]                                                                          |
| bool value is invalid                                                                      | 400 Bad Request | "field\_{bool}": \["Must be a valid boolean."]                                                                             |
| bool value different than required                                                         | 400 Bad Request | "field\_{bool}": \["Field contains a value other than required."]                                                          |
| email value is invalid                                                                     | 400 Bad Request | "field\_{email}": \["Enter a valid email address."]                                                                        |
| email is required                                                                          | 400 Bad Request | "field\_{email}": \["This field is required."]                                                                             |
| email value is above the limit                                                             | 400 Bad Request | "field\_{email}": \["Ensure this field has no more than {max} characters."]                                                |
| email is not unique                                                                        | 400 Bad Request | "field\_{email}": \["This field must be unique."]                                                                          |
| phone value is invalid                                                                     | 400 Bad Request | "field\_{phone}": \["Enter a valid email address."]                                                                        |
| phone is required                                                                          | 400 Bad Request | "field\_{phone}": \["This field is required."]                                                                             |
| phone value is above the limit                                                             | 400 Bad Request | "field\_{phone}": \["Ensure this field has no more than {max} characters."]                                                |
| phone is not unique                                                                        | 400 Bad Request | "field\_{phone}": \["This field must be unique."]                                                                          |
| date value is in wrong format                                                              | 400 Bad Request | "field\_{date}": \["Date has wrong format. Use one of these formats instead: YYYY-MM-DD."]                                 |
| date is required                                                                           | 400 Bad Request | "field\_{date}": \["This field is required."]                                                                              |
| date is not unique                                                                         | 400 Bad Request | "field\_{date}": \["This field must be unique."]                                                                           |
| time value is in wrong format                                                              | 400 Bad Request | "field\_{time}": \["Time has wrong format. Use one of these formats instead: hh:mm\[:ss\[.uuuuuu]]."]                        |
| time is required                                                                           | 400 Bad Request | "field\_{time}": \["This field is required."]                                                                              |
| time is not unique                                                                         | 400 Bad Request | "field\_{time}": \["This field must be unique."]                                                                           |
| datetime value is in wrong format                                                          | 400 Bad Request | "field\_{datetime}": \["Datetime has wrong format. Use one of these formats instead: YYYY-MM-DDThh:mm\[:ss\[.uuuuuu]]\[+HH:MM |-HH:MM|Z]."]          |
| datetime is required                                                                       | 400 Bad Request | "field\_{datetime}": \["This field is required."]                                                                          |
| datetime is not unique                                                                     | 400 Bad Request | "field\_{datetime}": \["This field must be unique."]                                                                       |
| enum value is invalid                                                                      | 400 Bad Request | "field\_{enum}": \["{value} is not a valid choice.]                                                                        |
| enum is required                                                                           | 400 Bad Request | "field\_{enum}": \["This field is required."]                                                                              |
| enum is not unique                                                                         | 400 Bad Request | "field\_{enum}": \["This field must be unique."]                                                                           |
| set value is invalid                                                                       | 400 Bad Request | "field\_{set}": \["Value must be valid Set."]                                                                              |
| set is not a list                                                                          | 400 Bad Request | "field\_{set}": \["Value must be valid Set."]                                                                              |
| set value is below the limit                                                               | 400 Bad Request | "field\_{set}": \["The number of elements must be greater than or equal to {min}."]                                        |
| set value is above the limit                                                               | 400 Bad Request | "field\_{set}": \["The number of elements must be less than or equal to {max}."]                                           |
| url value is invalid                                                                       | 400 Bad Request | "field\_{url}": \["Enter a valid URL."]                                                                                    |
| url is required                                                                            | 400 Bad Request | "field\_{url}": \["This field is required."]                                                                               |
| url value is above the limit                                                               | 400 Bad Request | "field\_{url}": \["Ensure this field has no more than {max} characters."]                                                  |
| url is not unique                                                                          | 400 Bad Request | "field\_{url}": \["This field must be unique."]                                                                            |
| json value is invalid                                                                      | 400 Bad Request | "field\_{json}": \["Value must be valid JSON."]                                                                            |
| json is required                                                                           | 400 Bad Request | "field\_{json}": \["This field is required."]                                                                              |
| json value is above the limit                                                              | 400 Bad Request | "field\_{json}": \["Ensure this field has no more than {max} characters."]                                                 |
| json is not unique                                                                         | 400 Bad Request | "field\_{json}": \["This field must be unique."]                                                                           |
| document value is invalid                                                                  | 400 Bad Request | "field\_{document}": \["Value must be valid list."]                                                                        |
| document token is invalid                                                                  | 400 Bad Request | "field\_{document}": \["Invalid token {token}."]                                                                           |
| document number files is above the limit                                                   | 400 Bad Request | "field\_{document}": \["The number of elements must be less than or equal to {max}."]                                      |
| user is not a object                                                                       | 400 Bad Request | "field\_{user}": \["Expected a dictionary of items but got type "{type}"."]                                              |
| user value  not in the class field definition or not existing user ID (users)              | 400 Bad Request | "field\_{user}": \[""{value}" is not a valid choice."]                                                                   |
| user value is below the limit (users)                                                      | 400 Bad Request | "field\_{user}": \["The number of users elements must be greater than or equal to {min}."]                                 |
| user value is above the limit (users)                                                      | 400 Bad Request | "field\_{user}": \["The number of users elements must be less than or equal to {max}."]                                    |
| user value is not an array of integers (users)                                             | 400 Bad Request | "field\_{user}": {"users": \["The value must be an array of integers."]}                                                   |
| user value  not in the class field definition or not existing users group ID (user\_groups) | 400 Bad Request | "field\_{user}": \[""{value}" is not a valid choice."]                                                                   |
| user value is below the limit (user\_groups)                                                | 400 Bad Request | "field\_{user}": \["The number of user\_groups elements must be greater than or equal to {min}."]                           |
| user value is above the limit (user\_groups)                                                | 400 Bad Request | "field\_{user}": \["The number of user\_groups elements must be less than or equal to {max}."]                              |
| user value is not an array of integers (user\_groups)                                       | 400 Bad Request | "field\_{user}": {"user\_groups": \["The value must be an array of integers."]}                                             |
| user field - attempted to pass values in the user\_groups field when it was not permitted   | 400 Bad Request | "field\_{user}":  \["user\_groups field is not allowed."]                                                                   |
| user field - attempted to pass values in the users field when it was not permitted         | 400 Bad Request | "field\_{user}": \["users field is not allowed."]                                                                          |

## PATCH /api/object-records/`record_id`/

Update Object Record.

> Default value is omitted for PATCH

### Permissions

Requires `authentication` and Object Class Ownership or Object Record Ownership or has Object Record edit permissions by any permission\_set.

### Request

* Headers

```
Request Method: POST
Authorization: JWT access_token
```

* Body

| Key                  | Type   | Required | Notes                                       |
|----------------------|--------|----------|---------------------------------------------|
| object\_name          | string | false    |                                             |
| object\_class         | pk     | true     | Relations between object classes            |
| field\_\<field\_alias>  | any    | false    | Fields based on Object Class configuration  |

#### Validations

* object\_name
  * Ensure this field has no more than 255 characters.

* object\_class
  * This field is required.
  * Invalid pk "value" - object does not exist.
  * This field may not be null.
  * The object class "value" might be given only once.

* field\_\<field\_alias>:
  * This field is required.
  * Check if field is valid
  * Depending on field type a various validation errors are raised for invalid value.
    * String:
      * Ensure this field has no more than {max} characters.
    * Integer:
      * A valid integer is required.
      * Ensure this value is greater than or equal to {min\_value}.
      * Ensure this value is less than or equal to {max\_value}.
    * Decimal:
      * A valid number is required.
      * Ensure this value is greater than or equal to {min\_value}.
      * Ensure this value is less than or equal to {max\_value}.
    * Bool:
      * Must be a valid boolean.
      * Field contains a value other than required.
    * Enum:
      * /value/ is not a valid choice.
    * Email:
      * Enter a valid email address.
      * Ensure this field has no more than /max/ characters.
    * Phone:
      * Ensure this field has no more than 100 characters.
    * Date:
      * Date has wrong format. Use one of these formats instead: YYYY-MM-DD.
    * Time:
      * Time has wrong format. Use one of these formats instead: hh:mm\[:ss\[.uuuuuu]].
    * Datetime:
      * Datetime has wrong format. Use one of these formats instead: YYYY-MM-DDThh:mm\[:ss\[.uuuuuu]]\[+HH:MM|-HH:MM|Z].
    * Enum
      * "{value}" is not a valid choice.
    * Url
      * Enter a valid URL.
      * Ensure this field has no more than {max} characters."
    * JSON
      * Value must be valid JSON.
      * Ensure this field has no more than {max} characters.
    * Set
      * Value must be valid Set.
      * The number of elements must be less than or equal to {max\_items}.
      * The number of elements must be greater than or equal to {min\_items}.
    * Document
      * Value must be valid tokens list.
      * The number of elements must be less than or equal to {max\_items}.
    * User
      * Value must be a valid object with key `users` or `user_groups`.
      * An `users` must be a valid set of users IDs.
      * An `user_groups` must be a valid set of groups IDs
      * User IDs must be an ID of existing not deleted users, limited to list defined in Object Class Field options.
      * Groups IDs ust be an ID of existing users group, limited to list defined in Object Class Field options.
      * The number of `users` elements must be less than or equal to {max\_users\_items}.
      * The number of `users` elements must be greater than or equal to {min\_users\_items}.
      * The number of `user_groups` elements must be less than or equal to {max\_groups\_items}.
      * The number of `user_groups` elements must be less than or equal to 10.
      * The number of `user_groups` elements must be greater than or equal to {min\_groups\_items}.

### Sample request body

```json
PATCH /api/object-records/1/

{
  "object_name": "Object Record",
  "object_class": 1,
  "field_first_name": "John",  
  "field_last_name": "Doe", 
  "field_email": "john-doe@nwc.xxx", 
  "field_age": 33, 
  "field_dob": "2022-11-17", 
  ... 
  "field_<field_alias>": <field_specific_type>, 
} 

```

### Response

| Key                   | Type     | Notes                                      |
|-----------------------|----------|--------------------------------------------|
| id                    | int      |                                            |
| object\_name           | string   |                                            |
| object\_class          | int      |                                            |
| status                | enum     | The only option is: "initiated"            |
| created\_at            | datetime |                                            |
| created\_by            | user     |                                            |
| modified\_at           | datetime |                                            |
| modified\_by           | user     |                                            |
| *meta                 | Object   | [\_meta](#response-meta-object) result      |
| field*\<field\_alias>   | any      | Fields based on Object Class configuration |

For fields with type:

* email
* phone
* url
* json

When user updates a record using  with request body shown below.

```json
{
    "field_<type>_field": "" 
}
```

And for fields type:

* user

When user updates a record using  with request body with empty dict or empty value for keys.

```json
{
    "field_<type>_field": {},
    "field_<type>_field": {"user":  []},
    "field_<type>_field": {"user":  [], "users_groups":  null}
}
```

The field value is set to null.

Expected response with this field is:

```json
{
    "field_<type>_field": null
}
```

### Response `_meta` object

| Key             | Type          | Notes |
|-----------------|---------------|-------|
| permissions     | Object        |       |
| labels          | Object        |       |
| users           | Object        |       |
| user\_groups     | Object        |       |

### Response `_meta.users` object

| Key       | Type | Notes                                          |
|-----------|------|------------------------------------------------|
| \<user\_id> | user |                                                |

`_meta.users` contains max 50 user objects for first 50 unique items from user type fields.

### Response `_meta.user_groups` object

| Key              | Type   | Notes                            |
|------------------|--------|----------------------------------|
| \<users\_group\_id> | Object | Contains group `id` and `name`   |

`_meta.user_groups` contains max 50 user group objects for first 50 unique items from user type fields.

* Successful status `200 Ok`
* Response body schema

```json
{
  "id": 20,
  "object_name": "Object Record",
  "object_class": 1,
  "status": "initiated",
  "created_at": "2022-08-18T12:21:35.921861+02:00",
  "created_by": {
    "id": 2,
    "first_name": "ALX",
    "last_name": "Developer",
    "username": "alx.dev@autologyx.com",
    "company_name": "",
    "is_deleted": false,
    "account_type": "super_admin"
  },
  "modified_at": "2022-08-18T13:43:42.874876+02:00",
  "modified_by": {
    "id": 2,
    "first_name": "ALX",
    "last_name": "Developer",
    "username": "alx.dev@autologyx.com",
    "company_name": "",
    "is_deleted": false,
    "account_type": "super_admin"
  },
  "field_first_name": "John",
  "field_last_name": "Doe",
  "field_email": "john-doe@nwc.xxx",
  "field_age": 33,
  "field_dob": "2022-11-17", 
  "field_documents": null,
  "field_user": {"users": [23], "user_groups": [2]},
  "_meta": {
    "labels": {
      "object_class": "MareK Test #1",
      "files": null
    },
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "create": true,
      "delete": true,
      "edit_owners": true,
      "view_owners": true,
      "tasks": {
        "list": true,
        "view": true,
        "edit": true,
        "delete": true,
        "create": true,
        "complete": true,
        "assign": true
      }
    },
    "users": {
        "23": {
            "id": 23,
            "first_name": "John",
            "last_name": "Smith",
            "username": "j.smith@autologyx.com",
            "company_name": "Autologyx",
            "is_deleted": false,
            "account_type": "super_admin"
        }
    },
     "user_groups": {
        "2": {
            "id": 2,
            "name": "Group2"
        }
    },
    "allowed_status_transitions": [],
    "forbidden_actions": []
  }
}
```

### Restriction

* Max `500 000` Object Records in one Object Class

### Errors

| Cause                                        | Response code   | Message                                                                             |
|----------------------------------------------|-----------------|-------------------------------------------------------------------------------------|
| object\_class is required                     | 400 Bad Request | "object\_class": \[ "This field is required."]                                      |
| object\_class is empty                        | 400 Bad Request | "object\_class": \[ "This field may not be blank."]                                 |
| object\_class is null                         | 400 Bad Request | "object\_class": \[ "This field may not be null."]                                  |
| object\_class is invalid                      | 400 Bad Request | "object\_class": \[ "'Invalid pk "{object\_class\_id}" - object does not exist.'"]    |
| object\_name to long                          | 400 Bad Request | "object\_name": \["Ensure this field has no more than 255 characters."]             |
| Exceeded max number of Object Record fields  | 400 Bad Request | "detail": "Limit of 500 000 Object Records in this Object Class has been exceeded." |
| Insufficient permissions                     | 403 Forbidden   | "detail": "You do not have permission to perform this action."                      |

### Field type Errors

| Cause                                                                                      | Response code   | Message                                                                                                                     |
|--------------------------------------------------------------------------------------------|-----------------|-----------------------------------------------------------------------------------------------------------------------------|
| string is too long                                                                         | 400 Bad Request | "field\_{string}": \[ "Ensure this field has no more than {max} characters."]                                               |
| string is required                                                                         | 400 Bad Request | "field\_{string}": \[ "This field is required."]                                                                            |
| string is not unique                                                                       | 400 Bad Request | "field\_{string}": \[ "This field must be unique."]                                                                         |
| integer value is invalid                                                                   | 400 Bad Request | "field\_{integer}": \[ "A valid integer is required."]                                                                      |
| integer is required                                                                        | 400 Bad Request | "field\_{integer}": \[ "This field is required."]                                                                           |
| integer value is below the limit                                                           | 400 Bad Request | "field\_{integer}": \[ "Ensure this value is greater than or equal to {min}."]                                              |
| integer value is above the limit                                                           | 400 Bad Request | "field\_{integer}": \[ "Ensure this value is less than or equal to {max}."]                                                 |
| integer is not unique                                                                      | 400 Bad Request | "field\_{integer}": \[ "This field must be unique."]                                                                        |
| float value is invalid                                                                     | 400 Bad Request | "field\_{float}": \[ "A valid number is required."]                                                                         |
| float is required                                                                          | 400 Bad Request | "field\_{float}": \[ "This field is required."]                                                                             |
| float value is below the limit                                                             | 400 Bad Request | "field\_{float}": \[ "Ensure this value is greater than or equal to {min}."]                                                |
| float value is above the limit                                                             | 400 Bad Request | "field\_{float}": \[ "Ensure this value is less than or equal to {max}."]                                                   |
| float is not unique                                                                        | 400 Bad Request | "field\_{float}": \[ "This field must be unique."]                                                                          |
| bool value is invalid                                                                      | 400 Bad Request | "field\_{bool}": \[ "Must be a valid boolean."]                                                                             |
| bool value different than required                                                         | 400 Bad Request | "field\_{bool}": \[ "Field contains a value other than required."]                                                          |
| email value is invalid                                                                     | 400 Bad Request | "field\_{email}": \[ "Enter a valid email address."]                                                                        |
| email is required                                                                          | 400 Bad Request | "field\_{email}": \[ "This field is required."]                                                                             |
| email value is above the limit                                                             | 400 Bad Request | "field\_{email}": \[ "Ensure this field has no more than {max} characters."]                                                |
| email is not unique                                                                        | 400 Bad Request | "field\_{email}": \[ "This field must be unique."]                                                                          |
| phone value is invalid                                                                     | 400 Bad Request | "field\_{phone}": \[ "Enter a valid email address."]                                                                        |
| phone is required                                                                          | 400 Bad Request | "field\_{phone}": \[ "This field is required."]                                                                             |
| phone value is above the limit                                                             | 400 Bad Request | "field\_{phone}": \[ "Ensure this field has no more than {max} characters."]                                                |
| phone is not unique                                                                        | 400 Bad Request | "field\_{phone}": \[ "This field must be unique."]                                                                          |
| date value is in wrong format                                                              | 400 Bad Request | "field\_{date}": \[ "Date has wrong format. Use one of these formats instead: YYYY-MM-DD."]                                 |
| date is required                                                                           | 400 Bad Request | "field\_{date}": \[ "This field is required."]                                                                              |
| date is not unique                                                                         | 400 Bad Request | "field\_{date}": \[ "This field must be unique."]                                                                           |
| time value is in wrong format                                                              | 400 Bad Request | "field\_{time}": \[ "Time has wrong format. Use one of these formats instead: hh:mm\[:ss\[.uuuuuu]]."]                    |
| time is required                                                                           | 400 Bad Request | "field\_{time}": \[ "This field is required."]                                                                              |
| time is not unique                                                                         | 400 Bad Request | "field\_{time}": \[ "This field must be unique."]                                                                           |
| datetime value is in wrong format                                                          | 400 Bad Request | "field\_{datetime}": \[ "Datetime has wrong format. Use one of these formats instead: YYYY-MM-DDThh:mm\[:ss\[.uuuuuu]]\[+HH:MM |-HH:MM|Z]."]          |
| datetime is required                                                                       | 400 Bad Request | "field\_{datetime}": \[ "This field is required."]                                                                          |
| datetime is not unique                                                                     | 400 Bad Request | "field\_{datetime}": \[ "This field must be unique."]                                                                       |
| enum value is invalid                                                                      | 400 Bad Request | "field\_{enum}": \[ "{value} is not a valid choice.]                                                                        |
| enum is required                                                                           | 400 Bad Request | "field\_{enum}": \[ "This field is required."]                                                                              |
| enum is not unique                                                                         | 400 Bad Request | "field\_{enum}": \[ "This field must be unique."]                                                                           |
| set value is invalid                                                                       | 400 Bad Request | "field\_{set}": \[ "Value must be valid Set."]                                                                              |
| set is not a list                                                                          | 400 Bad Request | "field\_{set}": \[ "Value must be valid Set."]                                                                              |
| set value is below the limit                                                               | 400 Bad Request | "field\_{set}": \[ "The number of elements must be greater than or equal to {min}."]                                        |
| set value is above the limit                                                               | 400 Bad Request | "field\_{set}": \[ "The number of elements must be less than or equal to {max}."]                                           |
| url value is invalid                                                                       | 400 Bad Request | "field\_{url}": \[ "Enter a valid URL."]                                                                                    |
| url is required                                                                            | 400 Bad Request | "field\_{url}": \[ "This field is required."]                                                                               |
| url value is above the limit                                                               | 400 Bad Request | "field\_{url}": \[ "Ensure this field has no more than {max} characters."]                                                  |
| url is not unique                                                                          | 400 Bad Request | "field\_{url}": \[ "This field must be unique."]                                                                            |
| json value is invalid                                                                      | 400 Bad Request | "field\_{json}": \[ "Value must be valid JSON."]                                                                            |
| json is required                                                                           | 400 Bad Request | "field\_{json}": \[ "This field is required."]                                                                              |
| json value is above the limit                                                              | 400 Bad Request | "field\_{json}": \[ "Ensure this field has no more than {max} characters."]                                                 |
| json is not unique                                                                         | 400 Bad Request | "field\_{json}": \[ "This field must be unique."]                                                                           |
| document value is invalid                                                                  | 400 Bad Request | "field\_{document}": \[ "Value must be valid list."]                                                                        |
| document token is invalid                                                                  | 400 Bad Request | "field\_{document}": \[ "Invalid token {token}."]                                                                           |
| document number files is above the limit                                                   | 400 Bad Request | "field\_{document}": \[ "The number of elements must be less than or equal to {max}."]                                      |
| user is not a object                                                                       | 400 Bad Request | "field\_{user}": \["Expected a dictionary of items but got type "{type}"."]                                               |
| user value  not in the class field definition or not existing user ID (users)              | 400 Bad Request | "field\_{user}": \[""{value}" is not a valid choice."]                                                                    |
| user value is below the limit (users)                                                      | 400 Bad Request | "field\_{user}": \["The number of users elements must be greater than or equal to {min}."]                                  |
| user value is above the limit (users)                                                      | 400 Bad Request | "field\_{user}": \["The number of users elements must be less than or equal to {max}."]                                     |
| user value is not an array of integers (users)                                             | 400 Bad Request | "field\_{user}": {"users": \["The value must be an array of integers."]}                                                    |
| user value  not in the class field definition or not existing users group ID (user\_groups) | 400 Bad Request | "field\_{user}": \[""{value}" is not a valid choice."]                                                                    |
| user value is below the limit (user\_groups)                                                | 400 Bad Request | "field\_{user}": \["The number of user\_groups elements must be greater than or equal to {min}."]                            |
| user value is above the limit (user\_groups)                                                | 400 Bad Request | "field\_{user}": \["The number of user\_groups elements must be less than or equal to {max}."]                               |
| user value is not an array of integers (user\_groups)                                       | 400 Bad Request | "field\_{user}": {"user\_groups": \["The value must be an array of integers."]}                                              |
| user field - attempted to pass values in the user\_groups field when it was not permitted   | 400 Bad Request | "field\_{user}": \["user\_groups field is not allowed."]                                                                     |
| user field - attempted to pass values in the users field when it was not permitted         | 400 Bad Request | "field\_{user}": \["users field is not allowed."]                                                                           |

## DELETE api/object-records/`id`/

Deletes single Object Record.

### Permissions

Requires `authentication` and Object Class Ownership or Object Record Ownership or has Object Record delete permissions by any permission\_set.

### Request example

* Headers

```
Request Method: DELETE
Location: /api/object-records/1/
Authorization: JWT access_token
```

### Response example

* Status `204 No Content`
* Body

### Errors

| Error                        | Response code | Message                                                        |
|------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions     | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Object Record does not exist | 404 Forbidden | "detail": "Not found"                                          |

## GET /api/object-records/

List Object Records based on query parameters and caller permissions.

::: tip Important
Access to endpoint require passing Object Class filter `/api/object-records/?object_class=<object_class_id>`
:::

### Permissions

Requires `authentication` and any of

1. `object_records.list` permission
2. Object Record Ownership
3. Object Class Ownership
4. Object Record Permission Set permission
5. Object Class Permission Set permission

### Request example

* Headers

```
Request Method: GET
Location: /api/object-records/
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of items visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of items visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key           | Type     | Notes                                                   |
|---------------|----------|---------------------------------------------------------|
| id            | id       | 	                                                       |
| object\_name   | string   | 	                                                       |
| object\_class  | int      | 	                                                       |
| created\_at    | datetime |                                                         |
| created\_by    | user     |                                                         |
| modified\_at   | datetime | 	                                                       |
| modified\_by   | user     | 	                                                       |
| \_meta         | Object   | [\_meta](#response-meta-object) result |

### Response `_meta` object

| Key             | Type          | Notes                                            |
|-----------------|---------------|--------------------------------------------------|
| permissions     | Object        |                                                  |
| labels          | Object        |                                                  |
| users           | Object        | Optional, added only if show\_fields is passed.   |
| user\_groups     | Object        |   Optional, added only if show\_fields is passed. |

### Response `_meta.users` object

| Key       | Type | Notes                                          |
|-----------|------|------------------------------------------------|
| \<user\_id> | user |                                                |

`_meta.users` contains max 50 user objects for first 50 unique items from user type fields.

### Response `_meta.user_groups` object

| Key              | Type   | Notes                                             |
|------------------|--------|---------------------------------------------------|
| \<users\_group\_id> | Object | Contains group `id`, `name` and `num_of_members`  |

`_meta.user_groups` contains max 50 user group objects for first 50 unique items from user type fields.

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 21,
  "total_count": 21,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 21,
      "object_name": "21",
      "object_class": 2,
      "status": "initiated",
      "created_at": "2022-08-18T12:23:25.927304+02:00",
      "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
      },
      "modified_at": "2022-08-18T12:23:25.927359+02:00",
      "modified_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
      },
      "field_usertype": {"users": [23]},
      "_meta": {
        "permissions": {
          "list": true,
          "view": true,
          "edit": true,
          "create": true,
          "delete": true,
          "edit_owners": true,
          "view_owners": true,
          "tasks": {
            "list": true,
            "view": true,
            "edit": true,
            "delete": true,
            "create": true,
            "complete": true,
            "assign": true
          }
        },
        "labels": {
          "object_class": "MareK Test #1"
        },
        "users": {
            "23": {
                "id": 23,
                "first_name": "John",
                "last_name": "Smith",
                "username": "j.smith@autologyx.com",
                "company_name": "Autologyx",
                "is_deleted": false,
                "account_type": "super_admin"
            }
        },
        "allowed_status_transitions": [],
        "forbidden_actions": []
      }
    },
    {
      "id": 20,
      "object_name": "20",
      "object_class": 2,
      "status": "initiated",
      "created_at": "2022-08-18T12:21:35.921861+02:00",
      "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
      },
      "modified_at": "2022-08-18T13:43:42.874876+02:00",
      "modified_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
      },
      "_meta": {
        "permissions": {
          "list": true,
          "view": true,
          "edit": true,
          "create": true,
          "delete": true,
          "edit_owners": true,
          "view_owners": true,
          "tasks": {
            "list": true,
            "view": true,
            "edit": true,
            "delete": true,
            "create": true,
            "complete": true,
            "assign": true
          }
        },
        "labels": {
          "object_class": "MareK Test #1"
        },
        "allowed_status_transitions": [],
        "forbidden_actions": []
      }
    },
  ]
}
```

### Sorting

| Parameter             | Example                                                                                   | Notes           |
|-----------------------|-------------------------------------------------------------------------------------------|-----------------|
| id                    | {build}/api/object-records/?ordering=id                                                   | Ascending       |
| id                    | {build}/api/object-records/?ordering=-id                                                  | Descending (-)  |
| created\_at            | {build}/api/object-records/?ordering=created\_at                                           | Ascending       |
| created\_at            | {build}/api/object-records/?ordering=-created\_at                                          | Descending (-)  |
| modified\_at           | {build}/api/object-records/?ordering=modified\_at                                          | Ascending       |
| modified\_at           | {build}/api/object-records/?ordering=-modified\_at                                         | Descending (-)  |
| object\_name           | {build}/api/object-records/?ordering=object\_name                                          | Ascending       |
| object\_name           | {build}/api/object-records/?ordering=-object\_name                                         | Descending (-)  |
| field\_\<field\_alias>   | {build}/api/object-records/?object\_class=12\&show\_fields=field\_alias\&ordering=field\_alias  | Ascending       |
| field\_\<field\_alias>   | {build}/api/object-records/?object\_class=12\&show\_fields=field\_alias\&ordering=-field\_alias | Descending (-)  |

#### Ordering by related Object Class Fields

Object Class Fields Query String parameters are included in [Object Classes - GET /api/object-classes/{object\_class\_id}/fields/autocomplete/](/api/catalyst/resources/object-classes/object-classes#get-api-object-classes-object-class-id-fields-autocomplete) endpoint.

The fields types / columns available for Ordering :

```
string
int
float
date
datetime
email
enum
```

At most, 10 total fields of any type from the object class are allowed for filtering.
For best performance, use the most selective fields first.
Recommended is ordering by only one field.
The custom field from ordering should also be included in show\_fields parameter only then ordering by this field will be enabled.

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

#### Filtering by Object Record related fields

| Parameter           | Type       | Example                                                                                                          |
|---------------------|------------|------------------------------------------------------------------------------------------------------------------|
| id                  | int + enum | {build}/api/object-records/?id=1                                                                                 |
| created\_at          | datetime   | {build}/api/object-records/?created\_at\_\_gte=2022-01-01                                                           |
| created\_by          | set        | {build}/api/object-records/?created\_by\_\_in=123,234,345                                                           |
| modified\_at         | datetime   | {build}/api/object-records/?modified\_at\_\_range=2022-01-01,2022-01-31                                             |
| modified\_by         | set        | {build}/api/object-records/?modified\_by=123                                                                      |
| object\_name         | string     | {build}/api/object-records/?object\_name\_\_icontains=foobar                                                        |
| *show\_fields*       | string     | {build}/api/object-records/?object\_class=12\&show\_fields=field\_alias                                              |
| **object\_class**    | enum       | {build}/api/object-records/?object\_class\_\_in=12,34                                                               |

> `object_class` is required
>
> `show_fields` is required to attach fields with their value to the response each object record. It is possible to specify multiple fields by separating them with a comma. Max 10 fields.

#### Filtering by related Object Class Fields

Object Class Fields Query String parameters are included in [Object Classes - GET /api/object-classes/{object\_class\_id}/fields/autocomplete/](/api/catalyst/resources/object-classes/object-classes#get-api-object-classes-object-class-id-fields-autocomplete) endpoint.

This endpoint contains also predicates assigned for each type.

The fields types / columns available for filtering :

```
bool
string
int
float
date
datetime
email
phone
url
set
enum
user
document
```

At most, 10 total fields of any type from the object class are allowed for filtering.

For predicates `in`, `containssome`, `containsall` values must be separated by comma `,`. If single value contains comma inside, char must be escaped by `\,`.

> `?field_set__in=first\,text,second`

The User type field is unique because it stores both a list of users and groups.
Therefore, filtering by this field requires specifying which of these values will be filtered.

> `?field_user__users__containsall=1,2,3`
>
> `?field_user__user_groups__containssome=21,42,54`

The Document type field supports only `isempty` predicate. It checks whether the field contains any files or not.

> `?field_document__isempty=true`

| Parameter                   | Type     | Example                                                                    |
|-----------------------------|----------|----------------------------------------------------------------------------|
| field\_\<bool\_type\_alias>     | bool     | {build}/api/object-records/?field\_bool\_alias=false                         |
| field\_\<text\_type\_alias>     | string   | {build}/api/object-records/?field\_string\_alias\_\_contains=test              |
| field\_\<integer\_type\_alias>  | int      | {build}/api/object-records/?field\_integer\_\_gt=1                            |
| field\_\<decimal\_type\_alias>  | int      | {build}/api/object-records/?field\_decimal\_\_gt=1.5                          |
| field\_\<date\_type\_alias>     | date     | {build}/api/object-records/?field\_date=2000-09-23                          |
| field\_\<datetime\_type\_alias> | datetime | {build}/api/object-records/?field\_datetime=2000-09-23 10:00:00             |
| field\_\<email\_type\_alias>    | string   | {build}/api/object-records/?field\_email\_\_contains=test                     |
| field\_\<phone\_type\_alias>    | string   | {build}/api/object-records/?field\_phone\_\_contains=123                      |
| field\_\<url\_type\_alias>      | url      | {build}/api/object-records/?field\_url\_\_iexact=http://website.sample        |
| field\_\<set\_type\_alias>      | set      | {build}/api/object-records/?field\_set\_\_containsall=abc,some,text,cde      |
| field\_\<enum\_type\_alias>     | enum     | {build}/api/object-records/?field\_enum\_\_in=abc,some,text,cde              |
| field\_\<user\_type\_alias>     | user     | {build}/api/object-records/?field\_user\_\_users\_\_containsall=1,2,3           |
| field\_\<user\_type\_alias>     | user     | {build}/api/object-records/?field\_user\_\_user\_groups\_\_containssome=21,42,54 |
| field\_\<document\_type\_alias> | document | {build}/api/object-records/?field\_document\_\_isempty=false                  |

### Errors

| Error                                                                 | Response code    | Message                                                                                                                                                |
|-----------------------------------------------------------------------|------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------|
| Filter created\_by with wrong user id                                  | 400 Bad Request  | "detail": {"created\_by":  \["Select a valid choice. That choice is not one of the available choices."]}                                               |
| Filter modified\_by with wrong user id                                 | 400 Bad Request  | "detail": {"modified\_by":  \['Select a valid choice. That choice is not one of the available choices."]}                                              |
| Missing object\_class parameter                                        | 400 Bad request  | "detail": { "object\_class": \["This field is required"] }                                                                                             |
| Invalid object\_class parameter                                        | 400 Bad request  | "detail": { "object\_class": \["Invalid pk "{object\_class}" - object does not exist."]  }                                                            |
| More that 10 fields in filtering                                      | 400 Bad Request  | "detail": "At most 10 fields from object class are allowed for filtering."                                                                             |
| Wrong class field type int value                                      | 400 Bad Request  | "detail": { "field\_integer": \["A valid integer is required."] }                                                                                      |
| Wrong class field type decimal value                                  | 400 Bad Request  | "detail": { "field\_decimal": \["A valid number is required."] }                                                                                       |
| Range filter for class field of int type must include exact 2 numbers | 400 Bad Request  | "detail": { "field\_integer": \["Range query expects two values."] }                                                                                   |
| Wrong class field type string value                                   | 400 Bad Request  | "detail": { "field\_text": \["Field "field\_text" expected a string but got ""number"" ] }                                                          |
| Wrong datetime format for datetime field type                         | 400 Bad Request  | "detail": { "field\_datetime": \["Datetime has wrong format. Use one of these formats instead: YYYY-MM-DDThh:mm\[:ss\[.uuuuuu]]\[+HH:MM-HH:MM Z]."]}|
| Wrong date format for date field type                                 | 400 Bad Request  | "detail": { "field\_date": \["Date has wrong format. Use one of these formats instead: YYYY-MM-DD."]}                                                  |
| Wrong value for choice/multichoice field type                         | 400 Bad Request  | "detail": { "field\_set": \[" "{value}" is not a valid choice."]}                                                                                    |
| Wrong value for user field type                                       | 400 Bad Request  | "detail": { "field\_user": \[" "{value}" is not a valid choice."]}                                                                                   |
| Wrong value type for user field type                                  | 400 Bad Request  | "detail": { "field\_user": \["The value must be an array of integers."]}                                                                               |
| Requesting user is not authenticated                                  | 401 Unauthorized | "detail": "Authentication credentials were not provided."                                                                                              |

Cannot encode None for key 'field\_country\_\_startswith' in a query string. Did you mean to pass an empty string or omit the value

## GET /api/object-records/`record_id`/

### Permissions

Requires `authentication` and any of

1. `object_records.view` permission
2. Object Record Ownership
3. Object Class Ownership
4. Object Record Permission Set permission
5. Object Class Permission Set permission

### Request example

* Headers

```
Request Method: GET
Location: /api/object-records/20/
Authorization: JWT access_token
```

### Response

| Key                 | Type        | Notes                                                   |
|---------------------|-------------|---------------------------------------------------------|
| id                  | int         |                                                         |
| object\_name         | string      | 	                                                       |
| object\_class        | int         | 	                                                       |
| created\_at          | datetime    |                                                         |
| created\_by          | user        |                                                         |
| modified\_at         | datetime    | 	                                                       |
| modified\_by         | user        | 	                                                       |
| *meta               | Object      | [\_meta](#response-meta-object) result |
| field*\<field\_alias> | any         | Fields based on Object Class configuration              |

### Response `_meta` object

| Key            | Type          | Notes                                                                              |
|----------------|---------------|----------------------------------------------------------------------------------- |
| permissions    | Object        |                                                                                    |
| labels         | Object        |                                                                                    |
| users          | Object        |                                                                                    |
| user\_groups    | Object        |                                                                                    |

### Response `_meta.users` object

| Key       | Type | Notes                                          |
|-----------|------|------------------------------------------------|
| \<user\_id> | user |                                                |

`_meta.users` contains max 50 user objects for first 50 unique items from user type fields.

### Response `_meta.user_groups` object

| Key              | Type   | Notes                                             |
|------------------|--------|---------------------------------------------------|
| \<users\_group\_id> | Object | Contains group `id`, `name` and `num_of_members`  |

`_meta.user_groups` contains max 50 user group objects for first 50 unique items from user type fields.

### Response example

* Status `200 OK`
* Body

```json
{
  "id": 20,
  "object_name": "20",
  "object_class": 2,
  "status": "initiated",
  "created_at": "2022-08-18T12:21:35.921861+02:00",
  "created_by": {
    "id": 2,
    "first_name": "ALX",
    "last_name": "Developer",
    "username": "alx.dev@autologyx.com",
    "company_name": "",
    "is_deleted": false,
    "account_type": "super_admin"
  },
  "modified_at": "2022-08-18T13:43:42.874876+02:00",
  "modified_by": {
    "id": 2,
    "first_name": "ALX",
    "last_name": "Developer",
    "username": "alx.dev@autologyx.com",
    "company_name": "",
    "is_deleted": false,
    "account_type": "super_admin"
  },
  "field_first_name": "John",
  "field_last_name": "Doe",
  "field_email": "john-doe@nwc.xxx",
  "field_documents": null,
  "field_usertype": {
    "users": [23],
    "user_groups": [2]
  }
  "_meta": {
    "labels": {
      "object_class": "MareK Test #1",
      "files": null
    },
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "create": true,
      "delete": true,
      "edit_owners": true,
      "view_owners": true,
      "tasks": {
        "list": true,
        "view": true,
        "edit": true,
        "delete": true,
        "create": true,
        "complete": true,
        "assign": true
      },
    },
     "users": {
        "23": {
            "id": 23,
            "first_name": "John",
            "last_name": "Smith",
            "username": "j.smith@autologyx.com",
            "company_name": "Autologyx",
            "is_deleted": false,
            "account_type": "super_admin"
        }
    },
     "user_groups": {
        "2": {
            "id": 2,
            "name": "Group2",
            "num_of_members": 3
        }
    },
    "allowed_status_transitions": [],
    "forbidden_actions": []
  }
}
```

### Errors

| Error                                                                  | Response code    | Message                                                        |
|------------------------------------------------------------------------|------------------|----------------------------------------------------------------|
| A non-existent `record_id` was given                                   | 404 Not Found    | "detail": "Not found."                                         |
| Requesting user is authorized but without view perm for tasks resource | 403 Forbidden    | "detail": "You do not have permission to perform this action." |
| Requesting user is not authenticated                                   | 401 Unauthorized | "detail": "Authentication credentials were not provided."      |

## OPTIONS  /api/object-records/

### Permissions

Requires authentication only.

### Request example

* Headers

```
Request Method: OPTIONS
Location: /api/object-records/
```

### Response example

* Status `200 OK`
* Body

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range",
                    "in"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "modified_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "modified_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            }
        ]
    },
    "details": {},
    "restrictions": {
        "limit_items_in_object_class": 500000
    }
}
```

## GET /api/object-records/autocomplete/

List Object Records based on query parameters and caller permissions.

::: tip Important
Access to endpoint require passing Object Class filter `/api/object-records/autocomplete/?object_class=<object_class_id>`
:::

### Permissions

Requires `authentication` and `object_records.list` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/object-records/autocomplete/
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of items visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of items visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key   | Type     | Notes                                                 |
|-------|----------|-------------------------------------------------------|
| value | id       |                                                       |
| text  | string   |                                                       |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 2,
  "total_count": 21,
  "next": null,
  "previous": null,
  "results": [
    {
      "value": 21,
      "text": "21",
      "status": "initiated",
      "_meta": {
        "allowed_status_transitions": [],
        "forbidden_actions": []
      }
    },
    {
      "value": 20,
      "text": "20",
      "status": "initiated",
      "_meta": {
        "allowed_status_transitions": [],
        "forbidden_actions": []
      }
    }
  ]
}
```

### Sorting

| Parameter   | Example                                                  | Notes          |
|-------------|----------------------------------------------------------|----------------|
| value       | {build}/api/object-records/autocomplete/?ordering=value  | Ascending      |
| value       | {build}/api/object-records/autocomplete/?ordering=-value | Descending (-) |
| text        | {build}/api/object-records/autocomplete//?ordering=text  | Ascending      |
| text        | {build}/api/object-records/autocomplete/?ordering=-text  | Descending (-) |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

#### Filtering by Object Record related fields

| Parameter        | Type     | Example                                                         |
|------------------|----------|-----------------------------------------------------------------|
| text             | string   | {build}/api/object-records/autocomplete/?text\_\_icontains=foobar |
| **object\_class** | enum     | {build}/api/object-records/?object\_class=12                     |

> `object_class` is required

| Error                                | Response code      | Message                                                                                     |
|--------------------------------------|--------------------|---------------------------------------------------------------------------------------------|
| Missing object\_class parameter       | 400 Bad request    | "object\_class": \["This field with predicate "exact" is required."]                        |
| Invalid object\_class parameter       | 400 Bad request    | "object\_class": \["Select a valid choice. That choice is not one of the available choices."] |
| Requesting user is not authenticated | 401 Unauthorized   | "detail": "Authentication credentials were not provided."                                   |
| Unauthorized API call                | 403 Forbidden      | "detail": "You do not have permission to perform this action."                              |

## POST /api/object-records/`id`/field-files/`alias`/

Uploads additional files to specific object record.

### Permissions

Requires `authentication` and Object Class Ownership or Object Record Ownership or has Object Record edit permissions by any permission\_set.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/object-records/1/field-files/field_alias/

["token_1", "token_2"]
```

### Validations

* data must be valid tokens list
* data must be not null

### Response |

* Successful status `201 Created`
* Response body is null

### Errors

| Cause                                                       | Response status code | Response message                                                                               |
|-------------------------------------------------------------|----------------------|------------------------------------------------------------------------------------------------|
| len(existing documents + newly uploaded) > max\_num\_of\_files | 400 Bad Request      | "field\_alias": \["The number of elements must be less than or equal to "max\_num\_of\_files"."]|
| not valid list                                              | 400 Bad Request      | "field\_alias": \["Value must be valid List."]                                                 |
| value is null                                               | 400 Bad Request      | "field\_alias": \["This field may not be null."]                                               |
| invalid value                                               | 400 Bad Request      | "field\_alias": \["Invalid token "token"."]                                                  |
| invalid alias in url                                        | 404 Not Found        |                                                                                                |
| alias in url is different type than document                | 404 Not Found        |                                                                                                |
| Insufficient permissions                                    | 403 Forbidden        | "detail": "You do not have permission to perform this action."                                 |

## DELETE /api/object-records/`id`/field-files/`alias`/

Removes files from existing Object Record’s field of document type.

### Permissions

Requires `authentication` and Object Class Ownership or Object Record Ownership or has Object Record edit permissions by any permission\_set.

### Request example

* Headers

```
Request Method: DELETE
Location: /api/object-records/1/field-files/field_alias/
Authorization: JWT access_token
```

* Schema

```json
POST /api/object-records/1/field-files/field_alias/

[1, 54]
```

### Response example

* Status `204 No Content`
* Body

### Errors

| Cause                                                      | Response status code | Response message                                                                          |
|------------------------------------------------------------|----------------------|-------------------------------------------------------------------------------------------|
| not valid list                                             | 400 Bad Request      | "detail": \["Expected a list of items but got type "{type}"."]                         |
| value is null                                              | 400 Bad Request      | "detail": \["This field may not be null."]                                               |
| invalid value                                              | 400 Bad Request      | "detail": \["A valid integer is required."]                                              |
| len(sent list) > max\_num\_of\_files                          | 400 Bad Request      | "detail": \["The number of elements must be less than or equal to "max\_num\_of\_files"."]|
| Required field will be NULL (all files could be deleted)   | 400 Bad Request      | "field\_alias": \["This field may not be null."]                                          |
| invalid alias in url                                       | 404 Not Found        |                                                                                           |
| alias in url is different type than document               | 404 Not Found        |                                                                                           |
| Insufficient permissions                                   | 403 Forbidden        | "detail": "You do not have permission to perform this action."                            |

## GET /api/object-records/`record_id`/fields/`field_alias`/

Field details based on query parameters and caller permissions.

### Permissions

Requires `authentication` and `view` for a specific object record.

### Request

* URL parameters

| Key         | Type  | Notes                                      |
|-------------|-------|--------------------------------------------|
| record\_id   | id    |                                            |
| field\_alias | any   | Fields based on Object Class configuration |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/object-records/1/fields/field_user
```

### Response

| Key                 | Type      | Notes                                                    |
|---------------------|-----------|----------------------------------------------------------|
| id                  | id        | id of an object record                                   |
| name                | string    | the object records name (ID or identifier)               |
| object\_class        | int       | the ID of an object class                                |
| *meta               | Object    | [\_meta](#response-meta-object) result |
| field*\<field\_alias> | any       | Fields based on Object Class configuration               |

### Response `_meta` object may contain various fields based on the field type.

| Key                     | Type   | Notes                                 |
|-------------------------|--------|---------------------------------------|
| files                   | Array  | Returned only for Document field type |
| users                   | Object | Returned only for User field type     |
| user\_groups             | Object | Returned only for User field type     |
| is\_min\_users\_fulfilled  | bool   | Returned only for User field type     |

### Response examples

* Status `200 OK`
* Body

```json
{
  "id": 1,
  "object_name": "Test",
  "object_class": 1,
  "field_user": {
    "users": [520, 642],
    "user_groups": [761]
  },
  "_meta": {
    "is_min_users_fulfilled": true,
    "users": {
      "520": {
        "id": 520,
        "first_name": "Kamille",
        "last_name": "Kohler",
        "username": "kamille.kohler11@example.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "full"
      },
      "642": {
        "id": 642,
        "first_name": "a",
        "last_name": "b",
        "username": "ab@example.test",
        "company_name": "",
        "is_deleted": false,
        "account_type": "full"
      }
    }
  },
  "user_groups": {
    "761": {
      "id": 761,
      "name": "54fd57",
      "num_of_members": 3
    }
  }
}

```

* Status `200 OK`
* Body

```json
{
  "id": 1,
  "object_name": "Test",
  "object_class": 1,
  "field_document":  [
       55513,
       55514,
       55515
     ]
   },
  "_meta": {
    "files": {
      "55513": {
        "name": "sample3.docx",
        "url": "https://file_url.autologyx.com",
        "size": "34375",
        "type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
      },
      "55514": {
        "name": "Invoice template.docx",
        "url": "https://file_url.autologyx.com",
        "size": "79533",
        "type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
      },
      "55515": {
        "name": "ABC_2024-06-13.docx",
        "url": "https://file_url.autologyx.com",
        "size": "14105376",
        "type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
      }
    }
  }
}
```

### Errors

| Error                                                          | Response code      | Message                                                        |
|----------------------------------------------------------------|--------------------|----------------------------------------------------------------|
| A non-existent record ID was given                             | 404 Not Found      |                                                                |
| Given {field\_alias} is not a class field                       | 404 Not Found      |                                                                |
| Given {field\_alias} is not used in object record configuration | 404 Not Found      |                                                                |
| Given {field\_alias} is not exists                              | 404 Not Found      |                                                                |
| No permission to view the record    	                          | 403 Forbidden      | "detail": "You do not have permission to perform this action." |
| Requesting user is not authenticated                           | 401 Unauthorized   |                                                                |

## GET /api/object-records/files/

Retrieve the details of selected documents by providing their file IDs.
The returned objects for each file match the existing Document-type field metadata returned in Record Details.

::: tip Important
Access to endpoint require passing Object Class filter `/api/object-records/files/?object_class=<object_class_id>`
:::

### Permissions

Requires `authentication` and `view` for a specific object record that contains the requested files.
Only files from records the user has permission to `view` are returned.

### Request

* URL parameters

| Key          | Type | Notes                         |
|--------------|------|-------------------------------|
| object\_class | id   |                               |
| id\_\_in       | id   | File id list, comma separated |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/object-records/files/?object_class=1&id__in=10,20,30
```

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter            | Type    |
|----------------------|---------|
| id\_\_in               | set     |
| object\_class         | enum    |

#### Validations

* id\_\_in
  * This field is required.
  * parameter can contain up to 50 file IDs.
* object\_class
  * This field is required.
  * Invalid pk "value" - object does not exist.

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of items visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of items visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key   | Type    | Notes                   |
|-------|---------|-------------------------|
| id    | id      | ID of an file object.   |
| name  | string  | File name.              |
| url   | url     | Link to file's content. |
| size  | string  | File size.              |
| type  | string  | File mime type.         |

### Response examples

* Status `200 OK`
* Body

```json
{
    "limit": 100,
    "offset": 0,
    "filtered_count": 3,
    "total_count": 3,
    "next": null,
    "previous": null,
    "results": [
        {
        "id": 10,
        "name": "sample3.docx",
        "url": "https://file_url.autologyx.com",
        "size": "34375",
        "type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
        },
        {
        "id": 20,
        "name": "Invoice template.docx",
        "url": "https://file_url.autologyx.com",
        "size": "79533",
        "type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
        },
        {
        "id": 30,
        "name": "ABC_2024-06-13.docx",
        "url": "https://file_url.autologyx.com",
        "size": "14105376",
        "type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
        }
    ]
}
```

* Status `200 OK`
* Body

### Errors

| Error                                                          | Response code    | Message                                                                        |
|----------------------------------------------------------------|------------------|--------------------------------------------------------------------------------|
| A non-existent record ID was given                             | 404 Not Found    |                                                                                |
| Missing object\_class parameter                                 | 400 Bad Request  | "detail": { "object\_class": \["This field is required."] }                    |
| Invalid object\_class parameter                                 | 400 Bad Request  | { "object\_class": \["Invalid pk "{object\_class}" - object does not exist."] } |
| Missing id\_\_in                                                 | 400 Bad Request  | "detail": { "id\_\_in": \["This field is required."] }                          |
| Invalid id\_\_in parameter                                       | 400 Bad Request  | "detail": { "id\_\_in": \["Invalid value. Must be valid file ids."] }           |
| Too many IDs (>50)                                             | 400 Bad Request  | {"detail": "At most 50 file IDs allowed for 'id\_\_in'."}                        |
| Requesting user is not authenticated                           | 401 Unauthorized |                                                                                |

## GET /api/object-records/transactions/`transaction_id`/

An authenticated user can retrieve the status of the record update transaction.

### Permissions

Requires `authentication` only.

### Request

* URL parameters

| Key    | Type | Notes                         |
|--------|------|-------------------------------|
| id     | uuid |                               |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/object-records/transactions/7fa04f22-xxxx-xxxx-xxxx-5087d9d224e5/
```

### Response

| Key              | Type   | Notes                                                                         |
|------------------|--------|-------------------------------------------------------------------------------|
| id               | uuid   | Automatically generated by the backend.                                       |
| status           | string |                                                                               |
| error\_message    | string |                                                                               |
| updated\_records  | Array  | list of all records updated in the transaction, grouped by their object class |

### Response examples

```json
{
  "id": 7fa04f22-xxxx-xxxx-xxxx-5087d9d224e5,
  "status": "processing",
  "error_message" "",
  "updated_records": [1, 2, 3, ...]
}
```

* Status `200 OK`
* Body

### "error\_message" details:

* Errors for Object Records.

| Error                              | error\_message                                                                                                                                                        |
|------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| All errors follow the same pattern | {"object\_class": {"id": {class\_id}, "errors": {"field\_slug1": \[[Object Record Errors](/api/catalyst/resources/object-records/object-records#errors-1) ...]}}}   |

* Errors for each type of Object Record Field.

| Error                              | error\_message                                                                                                                                                                     |
|------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| All errors follow the same pattern | {"object\_class": {"id": {class\_id}, "errors": {"field\_slug1": \[[Object Record Field Errors](/api/catalyst/resources/object-records/object-records#field-type-errors) ...]}}} |

### Errors

| Error                                 | Response code     | Message                                                        |
|---------------------------------------|-------------------|----------------------------------------------------------------|
| Requesting user is not authenticated  | 401 Unauthorized  | "detail": "You do not have permission to perform this action." |
| Transaction ID does not exist         | 404 Not Found     | "detail": "Not found."                                         |

## PATCH /api/object-records/update-by-filter/`object_class_id`/?{filter\_conditions}

Updating records based on filter conditions.

::: tip Important

1. The update transaction is created and can be retrieved using the [GET /api/object-records/transactions/`transaction_id`/](#get-apiobject-recordstransactiontransaction_id) endpoint.
2. The update transaction is created asynchronously and the response will be returned immediately.
3. The update transaction will be processed in the background.
4. The IDs of the records that will be updated are the records that match filtering results at the moment of the request.
5. Transaction details are retained for 7 days after processing is complete.
   :::

### Permissions

Requires `authentication`.

::: tip Important

1. Only the records that match the filter results and for which the user has the Object Record edit permission will be updated.
2. Records for which the user doesn't have permissions to edit are not updated.
   :::

### Request

* Headers

```
Request Method: PATCH
Authorization: JWT access_token
```

* Query parameters

| Key              | Type | Notes                                              |
|------------------|------|----------------------------------------------------|
| object\_class\_id  | int  |                                                    |

* Body

The `field_<field_alias>` (all allowed types of fields) can be included in the request body: the fields and values to be updated in the matching records.

::: tip Important
If the field passed in the request body does not exist, it's silently ignored.
:::

#### Validations

Fields validation works the same way as for the [Object Record Update API](/api/catalyst/resources/object-records/object-records#update-an-object-record).

### Sample request body

```json
PATCH /api/object-records/update-by-filter/12/?status__exact=initiated

{
  "field_<field_alias>": <any_allowed>,
  ...
  "field_<field_alias>": <any_allowed>,
}
```

Filtering works the same way as in [GET /api/object-records/](#filtering) endpoint.

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

#### Filtering by Object Record-related fields

| Parameter           | Type       | Example                                                                                                          |
|---------------------|------------|------------------------------------------------------------------------------------------------------------------|
| id                  | int + enum | {build}/api/object-models/1/object-records/descendants/?id=1                                                     |
| created\_at          | datetime   | {build}/api/object-models/1/object-records/descendants/?created\_at\_\_gte=2022-01-01                               |
| created\_by          | set        | {build}/api/object-models/1/object-records/descendants/?created\_by\_\_in=123,234,345                               |
| modified\_at         | datetime   | {build}/api/object-models/1/object-records/descendants/?modified\_at\_\_range=2022-01-01,2022-01-31                 |
| modified\_by         | set        | {build}/api/object-models/1/object-records/descendants/?modified\_by=123                                          |
| object\_name         | string     | {build}/api/object-models/1/object-records/descendants/?object\_name\_\_icontains=foobar                            |

#### Filtering by related Object Class Fields

1. At most, 10 total fields of any type from the object class are allowed for filtering.
2. Filter conditions must follow the standard Object records supported format and field filtering.
3. Filters can be combined, allowing multiple conditions to be applied simultaneously, as already implemented for the Records list.
4. Each filter can only be used once as already implemented for the Records list. (When duplicate fields are passed in the filter conditions, only the last one is applied).
5. The same field types and predicates are supported as in the [GET /api/object-records/](#filtering-by-related-object-class-fields) endpoint.

### Response

| Key               | Type   | Notes |
|-------------------|--------|-------|
| id                | uuid   |       |
| status            | string |       |
| url               | string |       |

* Successful status `200 Created`
* Response body schema

```json
{
  "id": "7fa04f22-xxxx-xxxx-xxxx-5087d9d224e5",
  "status": "queued",
  "url": "https://test.com/api/object-records/12/transactions/7fa04f22-xxxx-xxxx-xxxx-5087d9d224e5/" 
}
```

::: tip Important

1. The update transaction will be marked as "processing" until all records are updated.
2. The update transaction will be marked as "completed" once all records are processed successfully.
3. The update transaction will be marked as "failed" only if an error occurs during the enqueuing of the transaction.
4. If the error occurs during the processing of the transaction, for single records, it will be skipped and only logged in system logs.
   :::

### Errors

| Cause                                                                   | Response code    | Message                                                                                |
|-------------------------------------------------------------------------|------------------|----------------------------------------------------------------------------------------|
| Incorect object class                                                   | 404 Bad Request  | "detail": "Not found"                                                                  |
| Previous update transaction for this object\_class is still in progress  | 404 Bad Request  | "detail": \["Previous update transaction for this object\_class is still in progress."]  |
| Previous update transaction for this object\_class is still in progress  | 404 Bad Request  | "detail": \["Previous update transaction for this object\_class is still in progress."]  |
| Requesting user is not authenticated                                    | 401 Unauthorized | "detail": "Authentication credentials were not provided."                              |

---

---
url: /api/catalyst/resources/object-records/object-record-history-events.md
---
# Object Records History Events

This technical design describes API for access Object Record History Events.

Implementation details can be found in external document: [Event History - Object Records - Technical Design](https://autologyx.sharepoint.com/:w:/s/Dev/EYrssA8iATVNmkLQVSVLoKQBgh0rECFYgkd2Sp-agtYGJg).
History Events API Implementation details can be found: [Event History API - Microservice implementation](/api/event-history/resources/events#get-api-history-events).

# Object Records History Events API

## GET /api/object-records/`record_id`/history/

Endpoint to receive list of `Object Records History Events` stored in external application.

### Permissions

Perm to check: `object_class.view` (for individual Object Class). Permission can be checked, for example, by retrieving details of Object Classes (`GET /api/object-classes/{class_id}/`): `_meta.permissions`
Users of an external type are not allowed to access this endpoint.

### URL parameters

| Key      | Notes             |
|----------|-------------------|
| record\_id | Object Record ID  |

### Request schema

* Headers

```
Request Method: GET
Authorization: JWT access_token
```

### Response

| Key            | Type       | Notes                                                                            |
|----------------|------------|----------------------------------------------------------------------------------|
| limit          | int        |                                                                                  |
| offset         | int        | 	                                                                                |
| total\_count    | int        | Total number of permission sets for specific object class.                       |
| filtered\_count | int        | Number of permission sets for specific object class if some filters are applied. |
| next           | URL / null | Next page URL (null if there is no next page)                                    |
| previous       | URL / null | Previous page URL (null if there is no previous page)                            |
| results        | Array      | Described in the next table.                                                     |

### Response `results` array

| Key            | Type     | Notes                                                                                                                                                                                      |
|----------------|----------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| event\_id       | uuid     | 	                                                                                                                                                                                          |
| event\_datetime | datetime | 	                                                                                                                                                                                          |
| event\_type     | enum     | Values: record\_created, owner\_initialized, owners\_added, owners\_removed, assignees\_added, assignees\_removed, field\_values\_changed, record\_deleted, document\_generated, status\_initialized  |
| source\_type    | enum     | Values: user, sequence, system, mcp.                                                                                                                                                            |
| source\_name    | string   | 	                                                                                                                                                                                          |
| source\_id      | int      | 	                                                                                                                                                                                          |
| source\_info | string   | AI model identifier for `mcp` events (e.g. `"claude-code 2.1.158"`). Empty string `""` for all other source types. |
| event\_data     | json     | 	                                                                                                                                                                                          |

### Response `results.event_data` json

Depends on `event_type` returned `event_data` schema is different.

* Response `results.event_data` for `event_type` in `owner_initialized`, `owners_added`, `owners_removed` is an `Array` with `Object`.

| Key         | Type   | Notes        |
|-------------|--------|--------------|
| id          | int    | User id 	    |
| type        | enum   | Value 'user' |
| name        | string | User label	  |

```json
[
 {
  "id": 9768,
  "type": "user",
  "name": "John Smith"
 }
]

```

* Response `results.event_data` for `event_type` in `assignees_added`, `assignees_removed` is an `Object`.

| Key            | Type   | Notes                                   |
|----------------|--------|-----------------------------------------|
| assignees      | Array  | List with User or User Groups objects 	 |
| permission\_set | Object | Permission Set Object                   |

where `assignees` is

| Key            | Type   | Notes                                       |
|----------------|--------|---------------------------------------------|
| id             | int    | User or Users Group id                      |
| type           | enum   | Value 'user' or 'user\_group'                |
| name           | string | User First and Last name or User Group name |

and `permission_set` is

| Key       | Type   | Notes                |
|-----------|--------|----------------------|
| id        | int    | Permission Set id 	  |
| name      | string | Permission Set label |

```json
{ 
 "assignees":  [
   {
    "id": 9768,
    "type": "user",
    "name": "John Smith"
   },
   {
    "id": 3574,
    "type": "user",
    "name": null
   },
 ],
 "permission_set": {
    "id": 35,
    "name": "PermSet"  
  } 
}

```

or in case of User Group assignees

```json
{ 
 "assignees":  [
   {
    "id": 22,
    "type": "user_group",
    "name": "Acme group"
   }
 ],
 "permission_set": {
    "id": 3,
    "name": "PermSet"  
  } 
}

```

* Response `results.event_data` for `event_type` as `field_values_changed` is an `Array` with `Object`.

| Key   | Type   | Notes                           |
|-------|--------|---------------------------------|
| id    | int    | Field id 	                      |
| type  | enum   | Field type                      |
| value | Any    | Any JSON compatible field value |
| name  | string | Field label                     |

```json
[
 {
  "id": 9768,
  "type": "string",
  "value": "Ford",
  "name": "Car Name"
 }
]
```

Data for specific field types can include additional attributes.

1. Field's data of document type contains additional `value_labels` attribute - list of files' names in the same order as for `value` attribute.
   ```json
   {
     "id": 36,
     "type": "document",
     "name": "Passport",
     "value": [
       160
     ],
     "value_labels": [
       "passport_scan.pdf"
     ]
   }
   ```
2. Field's data of user type contains additional `value_labels`
   1. `value_labels.users` contains the list of user first and last names corresponding to the user ids in `value.users` in the same ordering
   2. `value_labels.user_groups` contains the list of group names corresponding to the user\_group ids in `value.user_groups` in the same ordering
   3. `value_labels` are sorted alphabetically by ascending.
   4. `value_labels` represent the values in the moment of event occurrence.
   5. Sample response:
      ```json
      {
        "id": 16,
        "type": "user",
        "name": "Reporters",
        "value": {
         "users": [
           1,
           20,
           100
         ],
         "user_groups": [
           1
         ]
        },
        "value_labels": {
         "users": [
           "Adam Lee",
           "Anthony Pawn",
           "Chuck Norris"
         ],
         "user_groups": [
           "Reporters"
         ]
        }
      }
      ```
   6. In case the empty list is saved in either `user` or `user_groups` the response format is:
      ```json
      {
        "id": 16,
        "type": "user",
        "name": "Reporters",
        "value": {"user_groups": [], "users": []},
        "value_labels": {"user_groups": [], "users": []}
      }
      ```

* Response `results.event_data` for `event_type` as `record_created` is an empty `Array`.

```json
[]
```

### Response schema

* Status `200 OK`
* Body:

```json
{
  "limit": <int>,  
  "offset": <int>,  
  "filtered_count": <int>,  
  "total_count": <int>,  
  "next": <str | null>,  
  "previous": <str | null>,  
  "results": [
    {
      "event_id": <uuid>,
      "event_datetime": <datetime>,
      "event_type": <str>,
      "source_type": <str>,
      "source_id": <int>,
      "source_name": <str | null>,
      "source_info": <str>,
      "record_id": <int>,
      "created_at": <datetime>,
      "event_data": <json> 
    }
  ]
}
```

* Response `results.event_data` for `event_type` as `document_generated` is an `Array` with `Object`.

| Key                  | Type   | Notes                                        |
|----------------------|--------|----------------------------------------------|
| document\_template\_id | int    | Document template id 	                       |
| file\_id              | uuid   | A unique file identifier in history database |
| file\_name            | string | A string name of the generated file          |

```json
[
   {
      "document_template_id": 565, 
      "file_id": "df00cf1b-8582-451d-a3b9-238ecfb07a8b", 
      "file_name": "test_2023-09-05.docx"
   }
]
```

* Response `results.event_data` for `event_type` as `status_initialized` is an `Array`.

```json
[{"status": "initiated"}]
```

### Response example

```json
{
  "limit": 10,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "event_id": "6e165f4b-8729-487c-93eb-7bf3445554e9",
      "event_datetime": "2021-10-27T12:27:43.462803+00:00",
      "event_type": "owner_initialized",
      "source_type": "user",
      "source_id": 1,
      "source_name": "John Smith",
      "source_info": "",
      "record_id": 56,
      "created_at": "2021-10-27T12:27:43.462803+00:00",
      "event_data": [
        {
          "id": 1,
          "type": "user",
          "name": "John Smith"
        }
      ]
    }
  ]
}
```

Example result object for an MCP event (`source_type: mcp`):

```json
{
  "event_datetime": "2024-04-20T09:15:00.462803+00:00",
  "event_type": "record_created",
  "source_type": "mcp",
  "source_id": 6,
  "source_name": null,
  "source_info": "claude-code 2.1.158",
  "event_data": []
}
```

### Sorting

Not available. The results are sorted ( descending ) by event\_datetime. No other sorting is supported.

1. record\_created is the first event (in chronological order), hence it is sorted at the end.
2. owner\_initialized immediately follows record\_created (in chronological order).

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

#### Filtering by History Event fields

| Parameter       | Type     | Example                                                                                          |
|-----------------|----------|--------------------------------------------------------------------------------------------------|
| event\_datetime  | datetime | {build}/api/object-classes/{record\_id}/history/?event\_datetime\_\_range=2022-01-01,2023-01-01      |
| source\_type     | enum     | {build}/api/object-classes/{record\_id}/history/?source\_type=user                                 |
| source\_type\_\_in | enum     | {build}/api/object-classes/{record\_id}/history/?source\_type\_\_in=user,sequence,system,mcp         |
| source\_id       | int      | {build}/api/object-classes/{record\_id}/history/?source\_id=0                                      |
| source\_id\_\_in   | int      | {build}/api/object-classes/{record\_id}/history/?source\_id\_\_in=0,1,2,3                            |
| field\_id        | int      | {build}/api/object-classes/{record\_id}/history/?field\_id=1                                       |
| field\_id\_\_in    | int      | {build}/api/object-records/{record\_id}/history/?field\_id\_\_in=121,122,150                         |
| field\_id\_\_in!   | int      | {build}/api/object-records/{record\_id}/history/?field\_id\_\_in!=121,122                            |
| event\_type          | enum     | {build}/api/object-classes/{record\_id}/history/?source\_type=record\_created                                    |
| event\_type\_\_in      | enum     | {build}/api/object-classes/{record\_id}/history/?source\_type\_\_in=record\_created,owner\_initialized              |
| source\_info     | string   | {build}/api/object-classes/{record\_id}/history/?source\_info=claude-code+2.1.158                           |
| source\_info\_\_in | string   | {build}/api/object-classes/{record\_id}/history/?source\_info\_\_in=claude-code+2.1.158,cursor+1.0.0          |

Both parameters also accept an exclusion variant via the `!` suffix: `source_info!`, `source_info__in!`.

`field_id__in` accepts a comma-separated list of Object Class field IDs. The maximum number of IDs per request is 50 (configurable per environment via `MAX_NUMBER_OF_FIELD_IDS_IN_RECORD_HISTORY_FILTER`). All IDs must belong to the Object Class of the record referenced by `{record_id}`. Only history events that carry a `field_id` (currently `field_values_changed`) are matched.

### Errors

| Error                                                | Response code   | Message                                                                                                   |
|------------------------------------------------------|-----------------|-----------------------------------------------------------------------------------------------------------|
| Invalid value used with event\_datetime.              | 400 Bad Request | "event\_datetime": \[ "Enter a valid date/time." ]   	                                                      |
| Invalid range filter value used with event\_datetime. | 400 Bad Request | "event\_datetime\_\_range": \[ "Range query expects two values." ]                                            |
| Invalid value used with source\_type.                 | 400 Bad Request | "source\_type": \[ "Select a valid choice. "\<source\_type>" is not one of the available choices." ] 	      |
| Invalid value used with source\_type!                 | 400 Bad Request | "source\_type!": \[ "Select a valid choice. "\<source\_type>" is not one of the available choices." ] 	     |
| Invalid value used with source\_type\_\_in.             | 400 Bad Request | "source\_type\_\_in": \[ "Select a valid choice. "\<source\_type>" is not one of the available choices." ] 	  |
| Invalid value used with source\_type\_\_in!.            | 400 Bad Request | "source\_type\_\_in!": \[ "Select a valid choice. "\<source\_type>" is not one of the available choices." ] 	 |
| Invalid value used with source\_id.                   | 400 Bad Request | "source\_id": \[ "Enter a number." ]  	                                                                     |
| Invalid value used with source\_id!                   | 400 Bad Request | "source\_id!": \[ "Enter a number." ]  	       	                                                            |
| Invalid value used with source\_id\_\_in.               | 400 Bad Request | "source\_id\_\_in": \[ "Enter a number." ]  	       	                                                         |
| Invalid value used with source\_id\_\_in!.              | 400 Bad Request | "source\_id\_\_in!": \[ "Enter a number." ]  	        	                                                       |
| Invalid value used with field\_id.                    | 400 Bad Request | "field\_id": \[ "Select a valid choice. That choice is not one of the available choices." ]   	             |
| Invalid ID used with field\_id\_\_in.                   | 400 Bad Request | "field\_id\_\_in": \[ "Select a valid choice. 999999 is not one of the available choices." ]                  |
| Non-integer value used with field\_id\_\_in.            | 400 Bad Request | "field\_id\_\_in": \[ "“abc” is not a valid value." ]                                                         |
| Too many IDs used with field\_id\_\_in.                 | 400 Bad Request | "field\_id\_\_in": \[ "At most 50 fields from object class are allowed for filtering." ]                      |
| Invalid value used with event\_type.                  | 400 Bad Request | "event\_type": \[ "Select a valid choice. "\<event\_type>" is not one of the available choices." ] 	        |
| Invalid value used with event\_type!                  | 400 Bad Request | "event\_type!": \[ "Select a valid choice. "\<event\_type>" is not one of the available choices." ] 	       |
| Invalid value used with event\_type\_\_in.              | 400 Bad Request | "event\_type\_\_in": \[ "Select a valid choice. "\<event\_type>" is not one of the available choices." ] 	    |
| Invalid value used with event\_type\_\_in!.             | 400 Bad Request | "event\_type\_\_in!": \[ "Select a valid choice. "\<event\_type>" is not one of the available choices." ] 	   |
| Invalid value used with source\_info.             | 400 Bad Request | "source\_info": \[ "Enter a valid value." ]                                                             |
| Invalid value used with source\_info!             | 400 Bad Request | "source\_info!": \[ "Enter a valid value." ]                                                            |
| Invalid value used with source\_info\_\_in.         | 400 Bad Request | "source\_info\_\_in": \[ "Enter a valid value." ]                                                         |
| Invalid value used with source\_info\_\_in!.        | 400 Bad Request | "source\_info\_\_in!": \[ "Enter a valid value." ]                                                        |
| Insufficient permissions                             | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                            |
| Object Record for `record_id` not found.             | 404 Not Found   | 	                                                                                                         |

## OPTIONS /api/object-records/`record_id`/history/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```
OPTIONS /api/object-records/`record_id`/history/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "list": {
        "columns": [
            {
                "alias": "event_id",
                "type": "uuid",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "event_datetime",
                "type": "datetime",
                "predicates": [
                  "exact",
                  "gt",
                  "gte",
                  "lt",
                  "lte",
                  "range"
                ],
                "sort_ok": false
            },
            {
                "alias": "event_type",
                "type": "enum",
                "predicates": [],
                "sort_ok": false,
                "values": [
                    {
                        "value": "record_created",
                        "text": "Record created"
                    },
                    {
                        "value": "field_values_changed",
                        "text": "Field values changed"
                    },
                    {
                        "value": "owner_initialized",
                        "text": "Owner initialized"
                    },
                    {
                        "value": "owners_added",
                        "text": "Owners added"
                    },
                    {
                        "value": "owners_removed",
                        "text": "Owners removed"
                    },
                    {
                        "value": "assignees_added",
                        "text": "Assignees added"
                    },
                    {
                        "value": "assignees_removed",
                        "text": "Assignees removed"
                    },
                    {
                        "value": "document_generated",
                        "text": "Document generated" 
                    },
                    {
                        "value": "status_initialized",
                        "text": "Status initialized" 
                    }
                ]
            },
            {
                "alias": "source_type",
                "type": "enum",
                "predicates": [],
                "sort_ok": false,
                "values": [
                    {
                        "value": "user",
                        "text": "User"
                    },
                    {
                        "value": "sequence",
                        "text": "Sequence"
                    },
                    {
                        "value": "system",
                        "text": "System"
                    },
                    {
                        "value": "mcp",
                        "text": "MCP"
                    }
                ]
            },
            {
                "alias": "source_name",
                "type": "string",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "source_id",
                "type": "int",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false
            },
            {
                "alias": "source_info",
                "type": "string",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false
            },
            {
                "alias": "record_id",
                "type": "int",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "event_data",
                "type": "json",
                "predicates": [],
                "sort_ok": false
            }
        ]
    }
}
```

---

---
url: /api/catalyst/resources/object-records/object-record-permission-sets.md
---
# Object Records Permission Sets

This document describes API endpoints for managing Object Record Permission Sets. Theirs setup is configurable at Object Class level.

Endpoints for assigning users for Object Record Permission Set of specific Object Record are described in separated [document](/api/catalyst/resources/object-records/object-record-permission-set-assignees).

## Permissions

| Permission                 | Manageable via Roles | Manageable via other ways                                                                                               | Description        |
|----------------------------|----------------------|-------------------------------------------------------------------------------------------------------------------------|--------------------|
| object\_class.view          | true                 | Object Class ownerObject Record owner`view` by Object Class or Object Record permission sets | Allows access list |
| object\_class.edit\_perm\_set | false                | Object Class owner                                                                                             |                    |

Permissions for Object Record Permission Sets can be checked by:

| Context               | Endpoint                                     | Location              | Available perms         |
|-----------------------|----------------------------------------------|-----------------------|-------------------------|
| Specific Object Class | `GET /api/object-classes/{object_class_id}/` | `_meta.permissions`   | `view`, `edit_perm_set` |

## References

* [Object Record Permission Sets - Technical Design](https://autologyx.sharepoint.com/:w:/s/Dev/EQ6UwfqnkKdOnyAW0bLBtBABuXBqI3fPHM5JMB38gDBD2A?e=9iOf9s)

## GET /api/object-classes/`object_class_id`/record-permission-sets/

Returns list of Object Record Permission Sets for specific Object Class.

### Permissions

Requires `authentication` and `object_class.view` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/object-classes/`object_class_id`/record-permission-sets/
```

### Response

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

#### Response `results` array

| Key         | Type     | Notes                                                        |
|-------------|----------|--------------------------------------------------------------|
| id              | int      |                                                                                                                         |
| name            | string   |                                                                                                                         |
| permissions     | Object   | Complex object containing enabled permissions for resources.                                                            |
| mcp\_permissions | Array    | One entry per MCP Connector associated with the Object Class, describing that connector's granted permissions. See below. |
| created\_at      | datetime |                                                                                                                         |
| created\_by      | user     |                                                                                                                         |
| modified\_at     | datetime |                                                                                                                         |
| modified\_by     | user     |                                                                                                                         |
| \_meta           | Object   | Human-readable labels for referenced entities. See below. |

##### `mcp_permissions` array

`mcp_permissions` is a read-only field (not writable via `POST`/`PATCH`). It contains one entry per MCP Connector currently associated with the Object Class (association is managed separately, via [MCP Connector Object Classes](/api/catalyst/resources/mcp/mcp-connector-object-classes)). Each entry has the following shape:

| Key         | Type   | Notes                                                                                                     |
|-------------|--------|-----------------------------------------------------------------------------------------------------------|
| connector   | int    | MCP Connector id. Resolve the display name via `_meta.labels.connectors["<id>"]["name"]`.                 |
| permissions | Object | Granted permissions for this connector, using the same "resource → list of granted actions" shape as the top-level `permissions` field (only `object_records` and `tasks`). |

Semantics:

* One entry per associated MCP Connector, ordered by connector `id`.
* `mcp_permissions[].connector` is always just the id (int); the connector name is provided separately in `_meta.labels.connectors`.
* If a connector is associated with the Object Class but has **no** saved permissions for this Permission Set, its entry is still returned, with empty lists for every resource (fail-closed). For example: `{ "connector": 7, "permissions": {"object_records": [], "tasks": []} }`.
* If no MCP Connectors are associated with the Object Class, `mcp_permissions` is an empty list (`[]`) and `_meta.labels.connectors` is an empty object (`{}`).

##### `_meta`

`_meta` is a read-only block following the existing `_meta.labels` convention. It maps each connector id referenced in `mcp_permissions` to its label:

```json
"_meta": {
  "labels": {
    "connectors": {
      "<id>": { "name": <str> }
    }
  }
}
```

* Successful status `200 OK`
* Response body schema

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str>,
  "previous": <str>,
  "results": [
    {
      "id": <int>,  
      "name": <str>, 
      "permissions": {
        "object_records": [<str>],
        "tasks": [<str>]
      },
      "mcp_permissions": [
        {
          "connector": <int>,
          "permissions": {
            "object_records": [<str>],
            "tasks": [<str>]
          }
        }
      ],
      "created_at": <datetime>,
      "created_by": <user>,
      "modified_at": <datetime>,
      "modified_by": <user>,
      "_meta": {
        "labels": {
          "connectors": {
            "<id>": {"name": <str>}
          }
        }
      }
    }
  ]  
}
```

* Response example

```json
{
  "limit": 50,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 12,
      "name": "Legal Reviewers",
      "permissions": {
        "object_records": ["view", "edit"],
        "tasks": []
      },
      "mcp_permissions": [
        {
          "connector": 3,
          "permissions": {
            "object_records": [],
            "tasks": ["edit"]
          }
        },
        {
          "connector": 7,
          "permissions": {"object_records": [], "tasks": []}
        }
      ],
      "created_at": "2026-08-03T10:00:00Z",
      "created_by": <user>,
      "modified_at": "2026-08-03T10:00:00Z",
      "modified_by": <user>,
      "_meta": {
        "labels": {
          "connectors": {
            "3": {"name": "Payroll connector"},
            "7": {"name": "Audit connector"}
          }
        }
      }
    }
  ]
}
```

### Sorting

Not available. Results are sorted by {id} ascending.

### Filtering

Not available.

### Errors

| Error                                         | Response code | Message                                                        |
|-----------------------------------------------|---------------|----------------------------------------------------------------|
| Object Class for {object\_class\_id} not found. | 404 Not found |                                                                |
| Insufficient permissions                      | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## POST /api/object-classes/`object_class_id`/record-permission-sets/

Creates single Object Record Permission Set.

### Permissions

Requires `authentication` and `object_class.edit_perm_set` permission.

### Request

* URL parameters

| Key             | Notes              |
|-----------------|--------------------|
| object\_class\_id | Object Class ID    |

* Body parameters

| Key           | Type   | Notes                                                                                       |
|---------------|--------|---------------------------------------------------------------------------------------------|
| name          | string | Unique (case insensitive) for the given Object Class.                                       |
| permissions   | Object | Optional. Complex object containing configuration for resources' permissions to be enabled. |

Available resources for `permissions`:

* `object_records`
* `tasks`

`object_records`, `tasks` keys contain list of actions. By default, permissions are disabled if not given in request's body.

Valid actions for resources:

| object\_records                             | tasks                                                                                     |
|--------------------------------------------|-------------------------------------------------------------------------------------------|
| editviewdelete  | createeditviewdeletecompleteassign  |

Sent permissions are converted with dependencies described in [technical doc](https://autologyx.sharepoint.com/:w:/s/Dev/EQ6UwfqnkKdOnyAW0bLBtBABuXBqI3fPHM5JMB38gDBD2A?e=oqskZk).

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/object-classes/`object_class_id`/record-permission-sets/

{
  "name": <str>, 
  "permissions": {
    "object_records": [<str>],
    "tasks": [<str>] 
  } 
}
```

* Request example

```json
{
  "name": "PermSet", 
  "permissions": {
    "object_records": ["edit"],
    "tasks": ["edit", "create"] 
  } 
} 
```

### Validations

* name
  * Max length: 100
  * Unique: for specific Object Class
* Maximum number of Object Record Permission Sets per specific Object Class: 10.

### Response

| Key         | Type     | Notes                                                     |
|-------------|----------|-----------------------------------------------------------|
| id          | int      | Automatically generated by the backend.                   |
| name        | string   |                                                           |
| permissions | Object   | Complex object contains saved permissions' configuration. |
| created\_at  | datetime |                                                           |
| created\_by  | user     |                                                           |
| modified\_at | datetime |                                                           |
| modified\_by | user     |                                                           |

* Successful status `201 Created`
* Response body schema

```json
{
  "id": <int>, 
  "name": <str>, 
  "permissions": {
    "object_records": [<str>],
    "tasks":          [<str>] 
  }, 
  "created_at": <datetime>, 
  "created_by": <user>, 
  "modified_at": <datetime>, 
  "modified_by": <user> 
} 
```

### Errors

| Error                                              | Response code   | Message                                                                                                     |
|----------------------------------------------------|-----------------|-------------------------------------------------------------------------------------------------------------|
| "name" is missing                                  | 400 Bad Request | "name": \[ "This field is required." ]                                                                       |
| "name" is empty string                             | 400 Bad Request | "name": \[ "This field may not be blank." ]                                                                  |
| "name" is null                                     | 400 Bad Request | "name": \[ "This field may not be null." ]                                                                   |
| "name" has > 100 chars                             | 400 Bad Request | "name": \[ "Ensure this field has no more than 100 characters." ]                                            |
| "name" is not unique for specific Object Class     | 400 Bad Request | "name": \[ "This field must be unique." ]                                                                    |
| Given NULL for `permissions`                       | 400 Bad Request | "permissions": \["This field may not be null."]                                                              |
| Given wrong resource name for `permissions`        | 400 Bad Request | "permissions": \["Invalid resource \\"{given\_wrong\_resource\_name}\\"."]                                      |
| Given NULL for resource in `permissions`           | 400 Bad Request | "permissions": {"{resource\_name}": \["This field may not be null."] }                                        |
| Given wrong value for resource in `permissions`    | 400 Bad Request | "permissions": {"{resource\_name}": \["Invalid actions \\"{given\_wrong\_value}\\"."] }                         |
| Max 10 Permission Sets per class exceeded          | 400 Bad Request | "detail": "Limit of 10 Object Class Permission Sets has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED" |
| Object Class with {object\_class\_id} does not exist | 404 Not found   | 	                                                                                                           |
| Insufficient permissions                           | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                              |

## PATCH /api/object-classes/`object_class_id`/record-permission-sets/`id`/

Updates single Object Record Permission Set.

### Permissions

Requires `authentication` and `object_class.edit_perm_set` permission.

The endpoint also allows configuring permissions available through MCP Connectors associated with the Object Class.

### Request

* URL parameters

| Key             | Notes                           |
|-----------------|---------------------------------|
| object\_class\_id | Object Class ID                 |
| id              | Object Record Permission Set ID |

* Body parameters

| Key               | Type   | Notes                                                                                   |
|-------------------|--------|-----------------------------------------------------------------------------------------|
| name              | string | Unique (case insensitive) for the given Object Class. Max length = 100 (configurable)   |
| permissions       | Object | Complex object containing configuration for resources' permissions to be enabled.       |
| mcp\_permissions   | Array  | Permissions granted to individual MCP Connectors associated with the Object Class.    |

Any parameter not listed above are silently ignored if passed.

Available resource keys for `permissions`:

* `object_records`
* `tasks`

`object_records`, `tasks` keys contain list of actions. All are optional. If some resource is omitted then permissions for it will not be modified.

Valid actions for resources:

| object\_records                             | tasks                                                                                     |
|--------------------------------------------|-------------------------------------------------------------------------------------------|
| editviewdelete  | createeditviewdeletecompleteassign  |

Sent permissions are converted with dependencies described in [technical doc](https://autologyx.sharepoint.com/:w:/s/Dev/EQ6UwfqnkKdOnyAW0bLBtBABuXBqI3fPHM5JMB38gDBD2A?e=9iOf9s).

> :warning: If less actions will be sent than are already in setup, not mentioned actions will be **removed** if they do not depend on other enabled actions.
>
> For instance:
>
> Current actions: `["view", "edit"]`. Sent actions: `["view"]`. Result actions: `["view"]`.

#### `mcp_permissions`

`mcp_permissions` contains permissions granted to individual MCP Connectors.

Each item has the following structure:

| Key         | Type   | Notes                                                    |
| ----------- | ------ | -------------------------------------------------------- |
| connector   | int    | ID of an MCP Connector associated with the Object Class. |
| permissions | Object | Permissions available through this connector.            |

Available resources and actions in `mcp_permissions.permissions` are the same as for the main `permissions` field.

The same permission dependencies are applied to MCP permissions. For example, if an action requires another action, the required action is automatically enabled according to the standard permission dependency rules.

MCP permissions can never exceed permissions granted by the Permission Set itself. After resolving dependencies, every MCP permission must also be present in the corresponding main `permissions` resource.

For example, given:

```json
{
  "permissions": {
    "object_records": ["view"]
  }
}
```

the following MCP configuration is valid:

```json
{
  "mcp_permissions": [
    {
      "connector": 10,
      "permissions": {
        "object_records": ["view"]
      }
    }
  ]
}
```

but granting an additional action unavailable in the Permission Set is rejected:

```json
{
  "mcp_permissions": [
    {
      "connector": 10,
      "permissions": {
        "object_records": ["edit"]
      }
    }
  ]
}
```

If `mcp_permissions` is omitted, MCP permissions are not directly modified.

If a connector is included in `mcp_permissions`, only permissions for that connector are modified. Permissions configured for other MCP Connectors remain unchanged.

Resources omitted from `mcp_permissions[].permissions` are not modified for that connector.

If main `permissions` are reduced, existing MCP permissions that would exceed the resulting Permission Set permissions are automatically removed. This applies to all MCP Connectors configured for the Permission Set, including connectors omitted from the request.

For example:

Current configuration:

```json
{
  "permissions": {
    "object_records": ["view", "edit"]
  },
  "mcp_permissions": [
    {
      "connector": 10,
      "permissions": {
        "object_records": ["view", "edit"]
      }
    }
  ]
}
```

Request:

```json
{
  "permissions": {
    "object_classes": ["view"]
  }
}
```

Result:

```json
{
  "permissions": {
    "object_records": ["view"]
  },
  "mcp_permissions": [
    {
      "connector": 10,
      "permissions": {
        "object_records": ["view"]
      }
    }
  ]
}
```

> :warning: `mcp_permissions` can only be modified using this `PATCH` endpoint.

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
PATCH /api/object-classes/`object_class_id`/record-permission-sets/`id`/

{
  "name": <str>,
  "permissions": {
    "object_records": [<str>],
    "tasks": [<str>]
  },
  "mcp_permissions": [
    {
      "connector": <int>,
      "permissions": {
        "object_records": [<str>],
        "tasks": [<str>]
      }
    }
  ]
}
```

* Request example

```json
{
  "name": "PermSet", 
  "permissions": {
    "object_records": ["edit"],
    "tasks": ["edit", "create"] 
  } 
} 
```

### Response

| Key             | Type     | Notes                                                                      |
|-----------------|----------|----------------------------------------------------------------------------|
| id              | int      |                                                                            |
| name            | string   |                                                                            |
| permissions     | Object   |                                                                            |
| mcp\_permissions | Object   | Effective permissions for MCP Connectors associated with the Object Class. |
| created\_at      | datetime |                                                                            |
| created\_by      | user     |                                                                            |
| modified\_at     | datetime |                                                                            |
| modified\_by     | user     |                                                                            |
| \_meta           | Object   | Additional labels for identifiers used in the response.                    |

* Successful status `200 OK`
* Response body schema:

```json
{
  "id": <int>,
  "name": <str>,
  "permissions": {
    "object_records": [<str>, ...],
    "tasks": [<str>, ...]
  },
  "mcp_permissions": [
    {
      "connector": <int>,
      "permissions": {
        "object_records": [<str>, ...],
        "tasks": [<str>, ...]
      }
    },
    ...
  ],
  "created_at": <datetime>,
  "created_by": <user>,
  "modified_at": <datetime>,
  "modified_by": <user>,
  "_meta": {
    "labels": {
      "connectors": {
        "<connector_id>": {
          "name": <str>
        }
      }
    }
  }
}
```

### Errors

| Error                                                  | Response code   | Message                                                                                        |
|--------------------------------------------------------|-----------------|------------------------------------------------------------------------------------------------|
| "name" is empty string                                 | 400 Bad Request | "name": \[ "This field may not be blank." ]                                                     |
| "name" is null                                         | 400 Bad Request | "name": \[ "This field may not be null." ]                                                      |
| "name" has > 100 chars                                 | 400 Bad Request | "name": \[ "Ensure this field has no more than 100 characters." ]                               |
| "name" is not unique for specific Object Class         | 400 Bad Request | "name": \[ "This field must be unique." ]                                                       |
| Given NULL for `permissions`                           | 400 Bad Request | "permissions": \["This field may not be null."]                                                 |
| Given wrong resource name for `permissions`            | 400 Bad Request | "permissions": \["Invalid resource \\"{given\_wrong\_resource\_name}\\"."]                         |
| Given NULL for resource in `permissions`               | 400 Bad Request | "permissions": {"{resource\_name}": \["This field may not be null."] }                           |
| Given wrong action value for resource in `permissions` | 400 Bad Request | "permissions": {"{resource\_name}": \["Invalid actions \\"{given\_wrong\_value}\\"."] }            |
| Given NULL for `mcp_permissions`                       | 400 Bad Request | `"mcp_permissions": ["This field may not be null."]`                                           |
| Missing `connector` in an `mcp_permissions` item       | 400 Bad Request | `"mcp_permissions": [{"connector": ["This field is required."]}]`                              |
| Given NULL for `connector`                             | 400 Bad Request | `"mcp_permissions": [{"connector": ["This field may not be null."]}]`                          |
| MCP Connector with given `connector` ID does not exist | 404 Not Found   | Standard not-found response                                                                    |
| MCP Connector is not associated with the Object Class  | 400 Bad Request | `"detail": ["Invalid pk \"{id}\" - MCP connector is not associated with this Object Class."]`  |
| MCP permissions exceed main Permission Set permissions | 400 Bad Request | `"Invalid actions \"{actions}\" for \"{resource}\" - exceeds the Permission Set's own grant."` |
| Object Class with {object\_class\_id} does not exist     | 404 Not Found   | 	                                                                                               |
| Object Record Permission Set with {id} does not exist  | 404 Not Found   | 	                                                                                               |
| Insufficient permissions                               | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                 |

## DELETE /api/object-classes/`object_class_id`/record-permission-sets/`id`/

Deletes single Object Record Permission Set.

### Permissions

Requires `authentication` and `object_class.edit_perm_set` permission.

### Request

* URL parameters

| Key             | Notes                           |
|-----------------|---------------------------------|
| object\_class\_id | Object Class ID                 |
| id              | Object Record Permission Set ID |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
DELETE /api/object-classes/`object_class_id`/record-permission-sets/`id`/
```

### Response

* Successful status `204 No Content`

### Errors

| Error                                                   | Response code | Message                                                        |
|---------------------------------------------------------|---------------|----------------------------------------------------------------|
| Object Class with "{object\_class\_id}" does not exist    | 404 Not found | 	                                                              |
| Object Record Permission Set with "{id}" does not exist | 404 Not Found | 	                                                              |
| Insufficient permissions                                | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## OPTIONS /api/object-classes/`object_class_id`/record-permission-sets/

### Permissions

Requires `authentication` only.

### Request

* URL parameters

| Key             | Notes              |
|-----------------|--------------------|
| object\_class\_id | Object Class ID    |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/object-classes/`object_class_id`/record-permission-sets/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
  "list": {
    "columns": [
      {
        "alias": "id",
        "type": "int",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "name",
        "type": "string",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "permissions",
        "type": "permissions",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "mcp_permissions",
        "type": "permissions",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_at",
        "type": "datetime",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_by",
        "type": "user",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "modified_at",
        "type": "datetime",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "modified_by",
        "type": "user",
        "predicates": [],
        "sort_ok": false
      }
    ]
  },
  "details": {
    "schema": [
      {
        "alias": "name",
        "type": "string",
        "required": true,
        "validators": [
          {
            "type": "min_length",
            "length": 1
          },
          {
            "type": "max_length",
            "length": 100
          }
        ]
      },
      {
        "alias": "permissions",
        "type": "permissions",
        "required": false,
        "schema": [
          {
            "resource": "object_records",
            "actions": [
              "view",
              "edit",
              "delete"
            ]
          },
          {
            "resource": "tasks",
            "actions": [
              "view",
              "edit",
              "delete",
              "create",
              "complete",
              "assign"
            ]
          }
        ]
      },
      {
        "alias": "mcp_permissions",
        "type": "permissions",
        "required": false,
        "schema": [
          {
            "resource": "object_records",
            "actions": [
              "view",
              "edit",
              "delete"
            ]
          },
          {
            "resource": "tasks",
            "actions": [
              "view",
              "create",
              "edit",
              "delete",
              "complete",
              "assign"
            ]
          }
        ]
      }
    ]
  },
  "restrictions": {
    "limit_items": 10
  }
} 
```

### Errors

| Error                                         | Response code    | Message |
|-----------------------------------------------|------------------|---------|
| Object Class for `object_class_id` not found. | 404 Not Found    |         |

## Not allowed endpoints

### GET /api/object-classes/`object_class_id`/record-permission-sets/`id`/

#### Response

* Status `405 Method Not Allowed`

---

---
url: /knowledgebase/administration/communication/okta-sso-in-catalyst.md
---

# Okta SSO in Catalyst

We are pleased to announce that login via **Okta Single Sign-On (SSO)** is now supported on the Catalyst platform.

This guide walks you through the full configuration process, from creating an application in Okta to enabling SSO within Catalyst, so that your users can log in securely using their existing Okta credentials.

This guide assumes you have administrator access to both your **Okta** account and your **Autologyx Catalyst** platform.

## Step 1: Create an Application in Okta

1. Sign in to your **Okta Admin Console**.
2. Go to the **Applications** section.
3. Click **Create App Integration**.
4. Select the **Sign-in method** as **OIDC – OpenID Connect**.
5. For **Application type**, choose **Web Application**.
6. Set an **App integration name** of your choice. This is just a label for your convenience.
7. Leave **Sign-in redirect URIs** and **Sign-out redirect URIs** empty for now. We’ll come back to these after setting up the SSO configuration in Autologyx.
8. In the **Assignments** section, select how the application should be made available:
   * You can assign it to all users in your organisation,
   * or to specific groups.
9. Click **Save** to create the application.

![New Okta APP.gif](../../../images2/zendesk_4833512082719_001_81407d322066.gif)

## Step 2: Retrieve Credentials from Okta

Now that your application is set up, locate and securely store the following:

* **Client ID** – a unique public identifier for your application. Catalyst uses it to recognise your app during the login flow.
* **Client Secret** – a confidential key used to authenticate your application with Okta. Treat this as a password - do not share it or store it insecurely.
* **Okta Domain** – this is your organisation’s Okta tenant domain. You can find it in the browser’s address bar or under your email address in the top right of the Okta dashboard. It typically looks like:\
  `yourcompany.okta.com` or `trial-1234567.okta.com`

You will use all three of these values when configuring SSO in Catalyst.

![Picture1.png](../../../images2/zendesk_4833512082719_002_f8560de7d5af.png)

## Step 3: Set Up SSO Configuration in Catalyst

1. Log in to the Catalyst platform with a user who has permissions to create SSO.
2. Go to **Administration > Single Sign-On Settings**.
3. Click **Create** to begin configuring a new SSO provider.
4. For **Single Sign-On Provider**, select **Okta OpenID Connect (OIDC)**.
5. Fill in the following fields:
   * **Client ID** – the identifier from your Okta application, as described in Step 2.
   * **Client Secret** – the confidential key associated with your Client ID.
   * **Okta Domain** – your organisation’s unique Okta URL. This will be used to route authentication requests.
6. Optionally, you may enable:
   * **Catalyst login support** – enable this if you want users to log into Catalyst using SSO.
   * **Automatically create user** – when enabled, any valid Okta user who logs in for the first time will automatically have a Catalyst account created for them as an Internal User with active status.
7. Click **Save** to complete the SSO configuration.

![Oktainalx.gif](../../../images2/zendesk_4833512082719_003_1211c630000d.gif)

After saving, go back to the Okta SSO edit page, where you will find **two important URLs**:

* **Redirect / Callback URI** – the URI where Okta will send users after a successful login.
* **Logout URL** – the URI Okta will call after a user signs out.

You will now need to return to Okta to input these values.

## Step 4: Update the Okta Application with Catalyst URIs

1. Go back to the **Applications** section in your Okta Admin Console and open the application you created earlier.
2. Click **Edit** in the **General Settings** or **Login** section.
3. Fill in the following:
   * **Sign-in redirect URIs** – paste the **Redirect / Callback URI** provided by Catalyst.
   * **Sign-out redirect URIs** – paste the **Logout URL** from Catalyst.
4. Click **Save**.

This ensures Okta can communicate correctly with Catalyst during login and logout flows.

![Okta edit.gif](../../../images2/zendesk_4833512082719_004_39c74ee55b0e.gif)

## Step 5: Configure Access Policy and Rules in Okta

To complete the setup, ensure that your Okta **Authorization Server** allows access from the application.

1. Go to **Security > API** in your Okta Admin Console.
2. Click on the **default** Authorization Server.
3. Go to the **Access Policies** tab.
4. Click **Add Policy**.
5. Fill in the form as follows:
   * **Name** – a descriptive name such as **Catalyst SSO Policy**.
   * **Description** – an optional field to document the policy’s purpose.
   * **Assign to** – choose whether this policy should apply to all clients or only specific applications. You should decide this based on your organisation’s internal security policy.
6. Click **Create Policy**.
7. In the newly created policy, click **Add Rule** and configure it with:
   * **Rule Name**: provide a clear name, e.g. `Auth Code Grant Rule`.
   * Under **IF Grant type is**, check **Authorization Code**.
   * Configure any other options, such as users, scopes, and token lifetime, according to your organisation's security policies.
8. Click **Create Rule**.

![Okta policy.gif](../../../images2/zendesk_4833512082719_005_36a35eabe476.gif)

## Step 6: Enable SSO

Once your SSO configuration is saved and enabled in Catalyst, users will see the **Okta login option** on the Catalyst sign-in screen.

Any user with an active Okta account who also meets your organisation’s policy rules will be able to authenticate and access Catalyst through Okta.

If you selected the **Automatically create user** option, first-time Okta users will have Catalyst accounts created automatically upon login.

---

---
url: >-
  /knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai.md
---

# OpenAI

OpenAI services can be used in Autologyx workflows where a Sequence needs to send text, record data, document content, or structured prompts to an AI model and use the response later in the workflow.

OpenAI can be used through dedicated Autologyx actors for common OpenAI use cases, including ChatGPT-style prompts and embeddings. For more advanced use cases, OpenAI endpoints can also be called directly by using generic API actors.

This article explains the main OpenAI options available for AI and the Sequencer.

## When to use OpenAI

Use OpenAI in a Sequence when you want to:

* summarise text, documents, emails, or records,
* classify inbound work,
* extract structured information from unstructured content,
* generate draft content for review,
* prepare data for downstream workflow routing,
* create embeddings for search, comparison, matching, or retrieval,
* call an OpenAI endpoint directly for an advanced or custom integration pattern.

The right approach depends on what the workflow needs to do and how much control you need over the OpenAI request.

## Before you start

Before configuring OpenAI actors or API calls, check that:

1. your Autologyx environment has the relevant OpenAI integration enabled,
2. you have an OpenAI platform account where required,
3. you can create and manage OpenAI API keys,
4. you have an Authentication Object configured for the OpenAI API key,
5. you have permission to edit the relevant Sequence.

OpenAI availability, models, and settings may vary by customer environment, subscription, enabled integrations, and tenant configuration.

## OpenAI options in Autologyx

There are three main ways to use OpenAI with the Sequencer.

## The ChatGPT Actor

The **OpenAI: GPT** or **ChatGPT** actor is used where a workflow needs to send a prompt to a chat model and use the model response inside the Sequence.

Typical uses include:

* summarising an email, document, or record,
* classifying work into a known category,
* extracting key information from text,
* drafting a response for human review,
* producing a JSON response that can be used by later Sequence steps.

The ChatGPT Actor is usually the best starting point where you want to use OpenAI for language understanding, drafting, classification, or summarisation inside a controlled workflow.

## Configure the ChatGPT Actor

Add the actor to a Sequence in the same way as other Sequence actors.

1. Go to **System Configuration** > **Sequences**.
2. Open the Sequence you want to update.
3. Find the OpenAI or ChatGPT actor in the relevant actor category.
4. Drag the actor onto the Sequence canvas.
5. Connect it to the appropriate trigger or workflow step.
6. Open the actor configuration.

The exact labels available in your environment may depend on the integration version and enabled actors.

## ChatGPT Actor settings

The ChatGPT Actor configuration modal allows you to define the model, authentication, prompt, context, temperature, and test record.

![OpenAI GPT configuration modal showing model, authentication object, prompt, context, temperature, record ID, test integration, and save settings](/knowledgebase/images/openai-gpt-configuration-modal.png)

### Model

Select the OpenAI chat model that the actor should use.

Where available, the modal may show a short description of the selected model to help explain what that model is commonly suited for. Use this as guidance, but choose the model based on the workflow goal, expected input size, response type, cost profile, and customer AI policy.

The available model list depends on the models enabled for your environment and OpenAI account.

### Auth Object

Select the Authentication Object that contains the OpenAI API key.

This allows the Sequence to make the request without exposing the API key inside the actor configuration.

### Prompt

The prompt is the main instruction that will be sent to the model.

A prompt can contain static text and Merge fields from the record being processed. This allows each request to be tailored to the specific Object Record in the workflow.

For example, a prompt could include the body of an inbound email, such as {{ record.field\_email\_body }}, so that the model can summarise or classify the content in the context of the current record.

### Context

Context can be used to give the model additional guidance about how to respond.

Context is optional. Use it where the model needs additional instructions that should sit alongside the prompt. If the workflow does not need separate context, remove it and keep the prompt focused.

For example, the context might explain:

* the role the model should perform,
* the type of work being processed,
* the categories the model can choose from,
* the expected output format,
* when the model should flag something for human review.

For workflow use cases, context is often where you define guardrails for the response.

### Temperature

Temperature controls how varied or creative the model response can be.

Lower values are usually better for workflow automation because they make the output more focused and consistent. Higher values may be useful for more creative drafting tasks, but they are usually less suitable where the response needs to be parsed or used by later deterministic workflow logic.

The modal guidance explains that lower values, such as `0.2`, make responses more focused and more consistent, while higher values, such as `0.8`, make responses more creative and varied.

### Record ID and Test Integration

Where the prompt or context includes merge fields, enter a **Record ID** before testing. This allows the actor to resolve record-specific values during the test.

Use **Test Integration** to test the request before saving. This helps you check the request and response using real record data before relying on the actor in a live workflow.

Click **Save** to save the actor configuration. Remember to save the Sequence itself after updating the actor.

## Use ChatGPT responses in the Sequence

The ChatGPT Actor response is most useful when it is stored or transformed into data that later Sequence steps can use.

**Common patterns include:**

* storing the response in a variable,
* extracting part of a JSON response,
* updating fields on the source record,
* creating a task for human review,
* sending the result into a document or message,
* using the response to decide the next workflow route.

For JSON responses, a Local Variable actor can be used to store or extract the content returned by the OpenAI actor.

For example, if the OpenAI response is returned in a chat-completion style structure, the message content may be accessed using a merge-field expression such as:

```jinja
{{ output.choices.0.message.content }}
```

The exact response path depends on the actor, endpoint, and response structure being used.

## OpenAI Embedding Actors

OpenAI Embedding Actors are used to convert text into embeddings.

An embedding is a numerical representation of text. Embeddings can help workflows support search, similarity comparison, matching, retrieval, clustering, and other AI-assisted patterns where the system needs to compare the meaning of text rather than match exact words.

Use embedding actors where the workflow needs to:

* create a searchable representation of record text,
* compare one piece of text with another,
* support semantic search,
* prepare content for retrieval-augmented workflows,
* identify similar records, clauses, requests, or documents,
* store vector-ready output for downstream processing.

Embedding actors are different from ChatGPT-style actors. They do not generate a narrative answer. Their role is to create embeddings that another process can store, compare, or use later.

## Configure an OpenAI Embedding Actor

The OpenAI embeddings configuration modal allows you to define the model, authentication, input text, output format, dimensions, and test record.

![OpenAI embeddings configuration modal showing model, authentication object, input text, encoding format, dimensions, user, record ID, and test embeddings settings](/knowledgebase/images/openai-embeddings-configuration-modal.png)

**The available settings include:**

### Model

Select the embedding model to use.

The available model options depend on the OpenAI integration and tenant configuration. Confirm the exact model list in the target environment before publishing this page. Current OpenAI embedding configurations may include options such as:

* `text-embedding-3-small`,
* `text-embedding-3-large`,
* `text-embedding-ada-002`, where legacy support is enabled.

### Auth Object

Select the Authentication Object used to authenticate with OpenAI.

This should normally be the same OpenAI Authentication Object pattern used by other OpenAI actors.

### Input

Enter the text that should be embedded.

This can be static text, record data, extracted document text, or a combination of text and merge fields.

For example, an embedding input might combine a matter description, request summary, document extract, or email body so that the resulting embedding represents the content that matters for search or comparison.

### Encoding format

Choose the format used to return the embedding.

The modal supports:

* **float**,
* **base64**.

The correct choice depends on the downstream system or actor that will consume the embedding.

### Dimensions

Use **Dimensions** where the selected model supports configurable embedding dimensions and the workflow requires a specific output size.

Leave this blank unless the downstream storage, comparison, or retrieval process requires a particular dimensionality.

### User

The **User** field can be used to pass a unique identifier representing the end user.

This can help OpenAI monitor and detect abuse. Use this field only where it is appropriate for the customer’s governance and configuration approach.

### Record ID

Use **Record ID** to test the embedding configuration where the input includes merge fields.

This lets you check that the actor can resolve the merge fields and generate an embedding for a real record before the Sequence is used in production.

### Test embeddings

Use **Test embeddings** to test the configuration before saving.

Testing is especially important where the input uses merge fields, extracted text, or record-specific values.

## Choosing between ChatGPT and embeddings

Use the ChatGPT Actor where you need the model to produce language or structured text output.

Use an Embedding Actor where you need a vector representation of text for later retrieval, search, comparison, or matching.

**In simple terms:**

* ChatGPT actors answer, summarise, classify, extract, or draft.
* Embedding actors represent text so it can be searched, compared, or retrieved by meaning.

A workflow can use both. For example, a Sequence might create embeddings for a document so that similar content can be found, then use a ChatGPT Actor to summarise the most relevant text for a user review step.

## Making direct API calls to OpenAI

For more advanced OpenAI use cases, you can call OpenAI endpoints directly by using generic API actors.

This can be useful where:

* a native actor does not expose the OpenAI endpoint or option you need,
* you need a newer OpenAI API capability before a dedicated actor exists,
* you need precise control over request headers, body, or response handling,
* you want to use structured JSON outputs,
* you want to use tool-calling style patterns,
* you need to call a customer-controlled gateway in front of OpenAI,
* you want one Sequence pattern to support several AI providers or endpoints.

Generic API calls are more flexible, but they require more careful configuration. You need to define the endpoint, authentication, request body, content type, and response handling yourself.

For more information, see [Making API calls to OpenAI](/knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai/).

## JSON outputs and deterministic processing

OpenAI calls are often most useful in Autologyx when the response can be turned into structured data.

For example, a model might be asked to return JSON with fields such as:

```json
{
  "classification": "human_review",
  "summary": "The email appears to request review of a supplier contract.",
  "recommended_next_step": "Create a legal review task",
  "confidence": "medium"
}
```

This can make it easier for the Sequence to apply deterministic checks after the model has responded.

For example, the Sequence can check whether `classification` is one of a known set of values before deciding what happens next. It can also send uncertain, incomplete, or unexpected responses to a human review task.

**This approach is especially powerful when combined with:**

* clear prompt instructions,
* constrained output schemas,
* validation logic,
* known allowed values,
* Local Variable actors,
* API response parsing,
* human review gates.

## Important reminder about model outputs

::: warning Important reminder
OpenAI model responses are not deterministic in the same way as conventional workflow logic.

Prompt design, structured JSON, low temperature settings, validation rules, and deterministic Sequence logic can reduce risk, but they cannot absolutely guarantee that a model will always return a perfect, complete, or accurate response.

Where the model returns a specific structured value, the Sequencer can often apply deterministic checks to decide whether the value is acceptable. Where the model produces semantic output, such as a narrative summary, interpretation, or recommendation, customers should strongly consider human review before the output is used for important decisions, external communications, or final record updates.
:::

## Things to remember

1. Use the ChatGPT Actor for summarisation, classification, extraction, drafting, and structured language outputs.
2. Use OpenAI Embedding Actors where you need semantic search, comparison, matching, retrieval, or vector-based processing.
3. Use generic API actors where you need direct access to OpenAI endpoints or more control than a native actor provides.
4. Store or transform AI responses into structured values before using them in later workflow logic.
5. Use deterministic validation where the response must match known options or schema requirements.
6. Use human review where outputs are semantic, high impact, externally visible, or difficult to validate automatically.
7. Confirm model availability, authentication, and integration settings in the customer environment before publishing or deploying the workflow.

---

---
url: >-
  /knowledgebase/system-configuration/integrations/openai-embeddings-integration.md
---

# OpenAI Embeddings integration

The OpenAI Embeddings integration adds semantic search and semantic analysis capabilities to Catalyst workflows.

Embeddings convert text into numerical vector representations, allowing systems to analyse meaning and contextual similarity rather than relying only on keywords.

## Typical use cases

OpenAI Embeddings can be used for:

* semantic document search
* similarity matching
* intelligent document retrieval
* data classification
* clustering and grouping
* AI-enhanced analysis

## Example business scenarios

Examples include:

* semantic clause searching in iManage
* identifying risky contract language
* fraud investigation support
* AI-assisted document review
* financial report analysis
* contextual knowledge retrieval

## Configurable settings

The Embeddings integration supports configuration of:

* models
* input formats
* encoding methods
* vector dimensions

## Integration with workflows

Embeddings can be combined with:

* iManage
* Salesforce
* Microsoft Graph
* DocuSign
* workflow automation
* Sequencer tasks and records

## Things to remember

* Embeddings analyse meaning and similarity rather than generating conversational text.
* Search quality depends on the quality and consistency of the source content.
* Some use cases may require integration with external document systems.

---

---
url: /knowledgebase/system-configuration/integrations/openai-gpt-integration.md
---

# OpenAI GPT integration

The OpenAI GPT integration allows Catalyst workflows to use ChatGPT capabilities directly inside Sequencer.

The OpenAI GPT actor can be used to:

* summarise content
* generate text
* analyse information
* classify records
* draft communications
* enrich workflows with AI-generated responses

## Dynamic prompts using merge fields

Prompts can use merge fields to dynamically insert record data into AI requests.

This allows prompts to adapt automatically based on:

* record information
* workflow state
* task data
* external system content

## Using AI-generated responses

Outputs generated by the OpenAI GPT actor can be:

* written back into records
* inserted into tasks
* used in workflow decisions
* added to reports or summaries
* passed into later workflow steps

## Configurable AI behaviour

The actor supports configurable parameters including:

* prompts
* context
* temperature
* model selection
* authentication configuration

This allows organisations to tailor AI behaviour to their business requirements.

## Typical use cases

Examples include:

* legal document summarisation
* contract review assistance
* policy explanation
* regulatory analysis
* fraud investigation support
* financial reporting summaries
* recruitment and HR analysis
* customer communication drafting

## Things to remember

* The OpenAI integration must be enabled.
* AI outputs should be reviewed before being relied upon operationally.
* Prompt quality directly affects AI response quality.
* Authentication Objects may be required depending on deployment configuration.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.10/openai-embeddings-integration.md
---

# OpenAI: Embeddings integration

The integration of **OpenAI: Embeddings** into our platform marks a transformative step forward in how businesses handle unstructured data.

With this functionality, companies can embed semantic intelligence into their workflows, enabling unprecedented insights and automation. Configurable in our **Sequencer**, Embeddings allow users to define every parameter - selecting models, input formats, encoding methods, and dimensions—while seamlessly integrating with existing records, tasks, and templates.

![Embeddings 1.gif](/knowledgebase/images/img_4635701895583_1776895629.png)

When paired with our platform’s capabilities and integrations, OpenAI Embeddings has the potential to optimise workflows, reduce manual effort, and unlock insights across industries.

## Legal use cases

**Semantic search and review**

Instead of manually sifting through documents to find the most relevant information, lawyers can now perform advanced searches that analyse the meaning behind their queries. This is made possible by integrating **OpenAI Embeddings** with tools like **iManage**, which enables semantic search across document repositories.

Lawyers can retrieve clauses, precedents, or key sections in seconds, saving hours of manual effort. Beyond search capabilities, **Embeddings** streamline contract review processes by identifying risky clauses, inconsistencies, or missing information. Using our platform’s automation features, these insights can be injected directly into tasks for legal teams, ensuring no critical detail is overlooked.

## Risk and financial analysis use cases

**Faster analysis and response**

OpenAI Embeddings transform the way data is analysed and interpreted, bringing clarity to complex datasets. For instance, fraud detection becomes significantly faster when embeddings analyse suspicious transactions flagged in integrated **Salesforce**. By understanding the contextual relationships between transactions, Embeddings generates concise risk insights for compliance officers. This allows them to respond to potential threats with confidence and agility.

Analysts can feed financial reports into workflows enhanced by Embeddings, comparing performance across assets and identifying areas of concern. Automated alerts and tasks can then be triggered for portfolio managers, reducing manual workload while ensuring proactive decision-making.

## Platform integrations

**The real value** lies in how OpenAI Embeddings seamlessly integrates with our automation platform and its built-in tools. By combining Embeddings with integrations like DocuSign for digital signatures, Salesforce for customer data management, and Microsoft Graph for organisational insights, businesses can create tailored solutions that streamline processes. This reduces manual work, accelerates decision-making, and provides a decisive competitive advantage in today’s data-driven landscape.

---

---
url: >-
  /knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/chatgpt-actor.md
---

# OpenAI: GPT Actor

![OpenAI-GPT-Autologyx.png](/knowledgebase/images2/zendesk_4764076721567_001_a7c6a7682002.png)

### Introduction

With the **OpenAI: GPT** actor, you can bring the power of ChatGPT into your workflows:

* **Dynamic Prompt Customisation**: Prompts can be configured using merge fields to pull data directly from records, ensuring that every input is tailored to a specific context. This means you can design workflows where prompts adapt dynamically to the needs of the task or the data within a record.
* **Versatile Responses**: The output generated by ChatGPT can be seamlessly injected back into the system. Whether it’s adding insights to a record, generating summaries, or creating custom reports, the integration enables you to operationalise AI responses across your business processes.
* **Full API Configuration in Sequencer**: The actor allows complete customisation, mirroring API functionality. You can set parameters such as context, temperature, authentication objects, and even the model version to ensure your workflows leverage AI in the way that best suits your needs.

### How to get the OpenAI: GPT actor

Our **OpenAI: GPT integration** is a premium service that is enabled by contacting your client manager who will ensure it is switched on based on your subscription to the service.

### Configuring the OpenAI: GPT actor

The **OpenAI: GPT** integration into Autologyx Catalyst relies on a couple of dependancies:

1. That you have an OpenAI platform account
2. That you are able to create and manage OpenAI API Keys

All being well with those, to get started with OpenAI: GPT in Autologyx, you must first set up an [Authentication Object](/knowledgebase/administration/authentication-objects/what-is-an-authentication-object-and-how-do-i-configure-it/) using the API method.

1. Head to the **Administration** section of your Autologyx Catalyst instance
2. Click **Authentication Objects**
3. Click **Create**

   ![Screenshot 2025-04-22 at 16.43.59.png](/knowledgebase/images2/zendesk_4764076721567_002_b78a0e58092c.png)
4. Fill out the fields below, choosing **API Key** from the drop down and ensuring you use your **API Key** from your OpenAI Platform account

   ![Screenshot 2025-04-22 at 16.42.29.png](/knowledgebase/images2/zendesk_4764076721567_003_0e612de90c8b.png)
5. Complete by clicking **Save**.

### Adding the OpenAI: GPT actor to a Sequence

As with all actors in the [Autologyx Catalyst Sequence](/knowledgebase/system-configuration/sequences/what-is-the-sequencer/) builder, the OpenAI: GPT actor can be dragged onto your Sequence canvas to perform a function based on your triggers.

1. Go to **System Configuration** > **Sequences** > Open your Sequence
2. You'll find the **OpenAI: GPT** actor under the **ML and AI** tab
3. In **Edit** mode, drag it onto your Sequence canvas at the relevant point of your workflow
4. In the example below, the OpenAI: GPT actor is linked by a simple trigger from the Email Intake [Object Class](/knowledgebase/system-configuration/object-classes/what-are-object-classes/)

![Screenshot 2025-04-23 at 13.04.59.png](/knowledgebase/images2/zendesk_4764076721567_004_4d29a533d8ae.png)

### Using the OpenAI: GPT actor in a Sequence

Where your **OpenAI: GPT** actor is placed in your workflow will depend on precisely what it is required to do, at what point in your workflow, and how it is progressing your automation.

Right click on the actor and you will see two options:

1. **Properties**: where you can name your actor and give it a brief description
2. **Configure**: this will open a modal window (below) where you will select your model, authentication method, choose your data points to send to the LLM, and add your prompts.

![Screenshot 2025-04-24 at 15.39.04.png](/knowledgebase/images2/zendesk_4764076721567_005_e79823c86975.png)

**Configuration breakdown**

Here's a breakdown based on a very simple legal intake and triaging use case:

1. **Model:** Choose from the three models:
   * GPT 3.5
   * GPT 4.0
   * GPT 4
2. **Auth Object:** Select the authentication object that you created earlier using your API key.
3. **Prompt:** This is where you will most likely use a combination of static prompt text and data points (merge fields) from the Object Class that you are referencing in your Sequence. In this example, we have an Object Class that stores email data, and our prompt is asking for a review of the email subject and body content, and to summarise the email together with any actions that are required.

   **Record Fields** (for example, {{record.field\_email\_from}}) or **Record Properties** can be inserted by right clicking on the Prompt box and choosing the fields you need, e.g.

   ![Screenshot 2025-04-24 at 15.56.17.png](/knowledgebase/images2/zendesk_4764076721567_006_19ce2f092c28.png)

   This data will then be parsed into the prompt and sent to the model as part of the query.
4. **Context:** In addition, you can also set additional context to aid the model with its response. In the example below, we're setting some additional parameters in which the response should be framed, e.g to look at the email with a view to deciding what actions need to be taken, to classify the email as in need of 'human review' if anything is unclear, and to return a response in JSON format with predesignated keys, e.g. 'classification' and 'summary'.

   ![Screenshot 2025-04-24 at 16.54.05.png](/knowledgebase/images2/zendesk_4764076721567_007_a00c2c9d1b15.png)
5. **Temperature:** You can adjust the creativity level of GPT's responses by using the slider. Lower values (e.g., 0.2) make the output more focused and deterministic, while higher values (e.g., 0.8) make it more creative and varied.

   ![Screenshot 2025-04-24 at 16.59.46.png](/knowledgebase/images2/zendesk_4764076721567_008_22f85300a872.png)
6. **Testing the OpenAI: GPT actor responses:** If the prompt or context includes merge fields then you can test your OpenAI: GPT actor responses by providing a record ID to test the integration. Insert a record ID into the **Record ID** box and click the **Test Integration** button.

   ![Screenshot 2025-04-25 at 10.04.26.png](/knowledgebase/images2/zendesk_4764076721567_009_4d0a5ac0ad5e.png)

   An additional modal window will open with the query you've sent to OpenAI and the model's response, e.g.

   ![Screenshot 2025-04-25 at 10.07.09.png](/knowledgebase/images2/zendesk_4764076721567_010_e224ddb217d0.png)
7. **Save** both your actor configuration and Sequence.

### Using the OpenAI response in a Sequence

1. Typically, you'll need to create a variable to store the OpenAI:GPT actor's response to enable you to use the data within your sequence. For this, we use the Local Variable actor.

   ![VARIABLE-Autologyx.png](/knowledgebase/images2/zendesk_4764076721567_011_4801bdf561ad.png)
2. Drag the Local Variable actor onto your Sequence canvas, connected by a trigger to the OpenAI:GPT actor that you've just configured.
3. In the example below, the Local Variable actor is then configured to return the output of the OpenAI:GPT actor. You will need to define:
   * **Variable**: add a variable name to the Variable field
   * **Type**: select what type of variable it is, in this case JSON (remember that's what we asked GPT to output as)
   * **Source**: this will be the OpenAI:GPT response
   * **Value**: this is where you define the fields in the JSON response that you want included in the variable, e
     * The required format for a **JSON** variable is valid JSON, for example: {"key": "value"}.
     * ChatGPT Integration actor returns a complete JSON structure as documented [here](https://platform.openai.com/docs/api-reference/chat/object).
       You can access individual attributes using the merge fields syntax in the **Value** input.
       For example, to extract the message content, use:

```jinja
{{ output.choices.0.message.content }}
```

* **Save**

  ![Screenshot 2025-06-13 at 14.25.09.png](/knowledgebase/images2/zendesk_4764076721567_012_932d3ff32629.png)
* Your variable is now ready to use through the Sequencer, e.g. updating the initial record with the LLM response, sending an email that includes the response etc

### For more information

[OpenAI: GPT integration](/knowledgebase/release-notes/release-notes-1.10/openai-gpt-integration/)

[Azure OpenAI integration](/knowledgebase/release-notes/release-notes-1.11/azure-openai-integration/)

[OpenAI: Embeddings integration](/knowledgebase/release-notes/release-notes-1.10/openai-embeddings-integration/)

---

---
url: /knowledgebase/release-notes/release-notes-1.10/openai-gpt-integration.md
---

# OpenAI: GPT integration

The future of workflow automation has arrived with our **OpenAI GPT** integration in Sequencer. This new actor, available to clients with OpenAI integration enabled, empowers you to seamlessly integrate ChatGPT's capabilities into your processes.

Whether it's generating tailored insights, summarising complex data, or even creating dynamic content, the possibilities are endless.

## What makes this integration unique

With the **OpenAI: GPT actor**, you can bring the power of ChatGPT into your workflows. Here’s what makes this integration unique:

* **Dynamic prompt customisation**: Prompts can be configured using merge fields to pull data directly from records, ensuring that every input is tailored to a specific context. This means you can design workflows where prompts adapt dynamically to the needs of the task or the data within a record.
* **Versatile responses**: The output generated by ChatGPT can be seamlessly injected back into the system. Whether it’s adding insights to a record, generating summaries, or creating custom reports, the integration enables you to operationalise AI responses across your business processes.
* **Full API configuration in Sequencer**: The actor allows complete customisation, mirroring API functionality. You can set parameters such as context, temperature, authentication objects, and even the model version to ensure your workflows leverage AI in the way that best suits your needs.

![GPT 1.gif](../../../images2/zendesk_4635689679519_001_1d1e7d3b705b.gif)

With our latest integration, companies can now deploy ChatGPT in their processes, taking advantage of automation and context-aware AI capabilities to address real-world challenges.

## Example use cases by sector

### Legal

Law firms often face the daunting task of summarising extensive case files or contracts. With ChatGPT, this process becomes effortless.

By dynamically pulling key data from records, ChatGPT can generate concise, accurate summaries, freeing legal professionals to focus on strategy rather than administration. Similarly, contract reviews are expedited as ChatGPT identifies clauses, flags risks, and highlights inconsistencies, ensuring compliance and reducing manual errors. Tailored communications - such as case updates or client queries - can also be automated, improving response times and client satisfaction.

![GPT 2.gif](../../../images2/zendesk_4635689679519_002_0226bd701f9c.gif)

### Financial services

In **financial services**, where the stakes are high and data volumes immense, ChatGPT drives operational efficiency. Portfolio managers, for instance, can generate personalised investment summaries by merging key performance metrics and risk assessments directly from records, delivering tailored insights to clients faster than ever. Fraud detection workflows are enhanced as ChatGPT analyes flagged transactions, providing clear, actionable explanations for compliance officers. Meanwhile, regulatory updates - an ever-present challenge - can be distilled into concise internal summaries, ensuring teams stay compliant without poring over lengthy legal texts.

### Accounting

The **accounting sector** also benefits immensely from ChatGPT’s integration. Tasks like tax preparation, often labor-intensive, are simplified as the AI analyses financial records to identify deductions and create tailored tax summaries or checklists. During audits, ChatGPT pinpoints areas of concern, providing accountants with clear insights into potential risks while ensuring accuracy. Automated invoice summaries and follow-up reminders streamline workflows, allowing teams to prioritise strategic decision-making over repetitive tasks.

![GPT 3.gif](../../../images2/zendesk_4635689679519_003_53da5ccd4667.gif)

### Human resources

For **human resources**, ChatGPT redefines hiring and employee management. During recruitment, ChatGPT can analyse candidate profiles and generate summaries, helping hiring managers quickly identify top talent. This means less time spent reviewing resumes and more time selecting the right candidates. Additionally, ChatGPT transforms employee feedback into actionable insights, allowing HR teams to address workplace concerns effectively. Policy updates, training materials, or even internal announcements can be drafted quickly and consistently, ensuring clear communication across organisations.

## Benefits

By integrating ChatGPT into workflows, businesses across all these sectors gain measurable benefits: **reduced manual effort, improved accuracy, faster decision-making, and enhanced customer or client satisfaction**.

The flexibility of ChatGPT allows you to tailor its capabilities to your unique needs, ensuring it becomes a key driver of innovation and efficiency.

---

---
url: /knowledgebase/administration/communication/outbound-mail-setup.md
---

# Outbound mail setup

This is one of the most important system settings, as here you will define and configure which mail service is used for all outgoing email notifications.

## Access

The Outbound mail setup page is found under Administration in the left hand menu. Only users with a Super admin account type will have access to view and edit these details.

## Mail service options

There are three options under **What kind of mail service are you using?**

**Recommended option:** Microsoft Office 365 Exchange (Graph) with oAuth 2.0.\
This is because Microsoft support for Basic Authentication (the traditional username and password method) for third-party apps and services that use SMTP to send email, is being removed from September 2025. After this time, oAuth must be used.

[Read more about this change.](https://techcommunity.microsoft.com/blog/exchange/exchange-online-to-retire-basic-auth-for-client-submission-smtp-auth/4114750)

![](../../../images2/zendesk_4402900566033_001_fafdb4815bc6.png)

When you choose this option, we have included a link to a help article which will take you through the steps required to set this up. That article can also be accessed here: [Configuring Outbound mail setup with Microsoft client credentials.](../configuring-outbound-mail-setup-with-microsoft-client-credentials/index.md)

## Requirements

You will need access to your Azure Active Directory in order to register and configure an Application. If this is not your area of expertise, you will need assistance from your IT department.

You will also need to create an Authentication Object which will securely hold all the details required for the Catalyst system to authenticate itself.

You will find further information here: [Creating an Authentication Object.](/knowledgebase/administration/authentication-objects/what-is-an-authentication-object-and-how-do-i-configure-it/)

## Microsoft Client Credentials settings

After selecting the authentication object, enter the **Microsoft Client Credentials settings**:

* **Host**
* **Port**
* **Username**

You'll notice that the **TLS** field is defaulted to **ON**.

## Testing mail settings

The **Test mail settings** button allows you to check the credentials entered. The test result will appear alongside the button, as below:

![mceclip2.png](../../../images2/zendesk_4402900566033_002_1c660eaed664.png)

![mceclip1.png](../../../images2/zendesk_4402900566033_003_83c27e9672d8.png)

If the test result returned is not "Authentication success!" you will still be able to save the page, but until the setup is successfully validated, mail will not be sent from the system.

**Common errors** are as above:

* **Authentication Error**: where incorrect details have been entered in the authentication object
* **Connection error**: where the host, port or TLS settings are incorrect

## Email fields

The two final email fields are mandatory and are used for the following:

* **From email address**: this is the email address for the mailbox account and will be shown on all outgoing messages as the From address.
* **Backend failure alerts email address**: this field will allow you to enter up to 10 email addresses (these can be comma or semi-colon separated) of individuals who will be notified in the event that emails cannot be sent from the system because, for instance, the account settings have been changed and need to be updated here. The email addresses entered here do not have to belong to users of the system.

### Validation errors

If you enter more than 10 email addresses, the following error is shown:

![mceclip4.png](../../../images2/zendesk_4402900566033_004_10ed38db424c.png)

If you enter an email address in an unrecognised format, or do not separate the email addresses, the following error is shown:

![mceclip3.png](../../../images2/zendesk_4402900566033_005_832ae2ff8786.png)

## Editing existing settings

If you are editing the page settings, you'll notice that the password is concealed with asterisks when basic auth is being used. As another security measure, we have ensured that the password cannot be copied from this field.

---

---
url: >-
  /knowledgebase/record-and-task-forms/formbuilder-components/overview-of-formbuilder.md
---

# Overview of formbuilder

The articles in this section of the knowledgebase are designed to give a quick overview of the components found in the Catalyst formbuilder.

## What the formbuilder is used for

The formbuilder is used to create the three record displays, standalone forms (for creation of records), and Task templates.

## Formbuilder layout

The formbuilder is made up of a **main section** (or canvas) and a **side panel**.

**Depending on the system area being configured,** the side panel will contain the following sections:

|  |  |  |  |  |  |  |
| --- | --- | --- | --- | --- | --- | --- |
|  | Layout | Fields | Object Class Fields | Properties | Child Object Classes | Elements |
| Object class - Card view | N | N | Y | Y | N | N |
| Object class - Create and edit view | Y | N | Y | Y | Y if object class is a parent | Y |
| Object class - Summary view | Y | N | Y | Y | N | Y |
| Standalone Forms | Y | N | Y | N | N | Y |
| Task template - self contained form | Y | Y | N | N | N | N |
| Task template - update object record | Y | Y | Y | N | N | N |

Components can be dragged and dropped from the side panel into sections on the canvas.

Once the component is in place, click on it to open the **properties** or **options** panel, where you can configure it as required.

---

---
url: >-
  /knowledgebase/administration/roles-and-permissions/overview-of-user-permissions.md
---

# Overview of User Permissions

A user's permissions determine what they can see and do in Catalyst.

Permissions are controlled by several different settings, including account type, Roles, Object Class permissions, Record permissions, and User Group permissions.

This article gives you an overview of how these permission layers work together and where to configure them.

## 1. Account type

Every user must have an account type.

Account type is the first level of access control and determines the broad type of access the user can have.

![User account type options on the user account form](../../../images2/zendesk_17355158328349_001_ecebc30eeb55.png)

Catalyst includes the following user account types.

### Super Admin

Use this account type carefully and sparingly.

A user with a Super Admin account type has full access across the platform, including delete permissions.

Only Super Admin users can access the following areas:

* **Administration** > **Users**
* **Administration** > **Roles**
* **Administration** > **Elements**
* **Administration** > **Outbound mail setup**
* **System configuration** > **Landing page**
* **System configuration** > **Theme**

### Config Admin

Config Admin users usually configure the system rather than complete day-to-day work.

They can be given one or more Roles, allowing them to create or edit areas such as:

* Task Templates
* Sequences
* Object Classes
* Single Sign-on settings
* Authentication configuration

### 1-time completion

1-time completion users do not log in to Catalyst.

They complete Tasks from secure links in email notifications. This account type is useful for people who only need to complete occasional tasks and do not need access to records.

### Internal

Internal users are usually employees of your organisation.

They are typically responsible for processing records, completing tasks, and working inside the Workspace. Their access is usually controlled through Object Class permissions, Record permissions, and User Groups.

### External

External users are usually people outside your organisation, such as clients, suppliers, or other third parties.

They may have limited access to assigned Tasks or specific records, depending on how permissions have been configured.

## 2. Roles

Roles are used for users with the Config Admin account type.

A Role controls which Administration and System configuration areas a Config Admin user can access.

The example below shows a Role that allows a Config Admin user to create and edit Sequences, Task Templates, Object Classes, and the relational model.

This Role does not allow the user to configure Administration areas or delete configuration.

![Role permissions showing Sequencer access](../../../images2/zendesk_17355158328349_002_14185371efa6.png)

![Role permissions showing Task configuration access](../../../images2/zendesk_17355158328349_003_4dd6ba96ebc6.png)

![Role permissions showing Data model access](../../../images2/zendesk_17355158328349_004_63063c262a1e.png)

![Role permissions showing Administration access](../../../images2/zendesk_17355158328349_005_86333340ab92.png)

Roles are high-level system administration permissions. They do not control access to individual Object records.

## 3. Object Class permissions

Object Class permissions control access to Object Classes, records, and tasks.

They are split into:

* Class permissions
* Record permissions

### Class permissions

Class permissions apply across the Object Class.

When an Object Class is created, the creator is added to the default Owner permission set.

This Owner permission set has all permissions enabled and cannot be changed.

Additional Owners can be added by the Object Class Owner or by a Super Admin user.

![Class permissions showing the default Owner permission set](../../../images2/zendesk_17355158328349_006_580d6dc221df.png)

Additional permission sets can be created to allow users or User Groups to work with:

* the Object Class itself
* Object records in that class
* Tasks available for that class

These permissions apply across all records and tasks in the Object Class.

### Record permissions

Record permissions control access to individual Object records.

Each record has a default Owner permission set with all permissions enabled for the record Owner.

Additional Record Permission Sets can be created by Object Class Owners.

These permission sets can then be assigned to users from the Record access tab in the side panel of an individual record.

![Record permissions showing the default Owner permission set](../../../images2/zendesk_17355158328349_007_bce2861d87eb.png)

![Record access tab showing Record Permission Sets](../../../images2/zendesk_17355158328349_008_8156e91f59b6.png)

Record Permission Sets can also be assigned to individual users or User Groups using the Record Access actor in the Sequencer.

![Record Access actor assigning Record Permission Sets in a Sequence](../../../images2/zendesk_17355158328349_009_7df9805f003e.png)

When **Configure record permission set assignment** is selected, you can choose:

1. the required Record Permission Set
2. whether to append assignees, override assignees, or remove assignees
3. whether to grant access to individual users, User Groups, or users from a user field
4. the users or User Groups that should receive the permission

## 4. User Group permissions

User Groups are used to manage teams or subsets of users.

They make it easier to reference multiple users in permissions, task assignment, and workflow configuration.

Each User Group has two main configuration areas:

* **Membership** - used to manage members and Owners
* **Permissions** - used to control who can view, edit, or delete the User Group

For more information, see [Why do I need User Groups?](/knowledgebase/administration/user-groups/why-do-i-need-user-groups/).

## How the permission layers work together

A user's final access is usually the result of several permission layers working together.

For example:

* Account type determines the user's broad access model.
* Roles determine which Administration or System configuration areas a Config Admin user can access.
* Object Class permissions determine what the user can do across an Object Class.
* Record permissions determine what the user can do on specific records.
* User Group permissions determine visibility and access to User Groups and their members.

## Things to remember

1. Account type is the first level of user access.
2. Roles apply only to Config Admin users.
3. Super Admin users have full access and do not need Roles.
4. Object Class permissions apply across a whole Object Class.
5. Record permissions apply to individual Object records.
6. User Groups make it easier to manage permissions for teams.
7. A user's effective permissions may come from more than one place.

---

---
url: /knowledgebase/getting-started/platform-admin-administrators.md
---

# Platform administrators

As someone responsible for administering Catalyst, you will typically have a Super admin account type. Your responsibilities may include managing users, roles, permissions, authentication settings, and outbound communications.

In practice, your interaction with Catalyst will focus on ensuring the platform is configured correctly and maintained as company policies, integrations, and user access requirements evolve.

## Quick checklist of global settings

You will find the following under Administration:

* [**Users, Roles and User groups**](/knowledgebase/administration/users-roles-and-user-groups/) - this section of the Knowledgebase will help you to create and manage your users. Most of your users will only interact with records and tasks in their Workspace; they probably won't need a Role but are likely to be in one or more User groups.

* \[**Company details**] - details entered here are available as merge fields and will be used in message templates.

* [**Standard authentication**](/knowledgebase/administration/communication/how-do-i-configure-user-activation-rules/) - this area allows you to set the user login password rules for the system. This article will show you what the user sees when they activate their account, and how you set the password rules.

* [**Single sign-on**](/knowledgebase/administration/communication/how-do-i-configure-single-sign-on-for-users/) - if you use this feature it will allow you to configure a single sign on provider such as Microsoft or Google. Users can select this method of authentication on the login page instead of entering their email address and password.

* \[**Authentication Objects**] - these are used to hold sensitive login details which are required to connect to third party systems via API calls.

* [**Outbound mail setup**](/knowledgebase/administration/communication/outbound-mail-setup/) - this is where you will define and configure the mail service used for all outgoing notifications. See outbound mail setup.

---

---
url: /knowledgebase/release-notes/release-notes-1.2/present-child-records.md
---

# Present child records

Get ready to experience Autologyx like never before! Our latest update introduces a powerful new feature that allows you to seamlessly integrate child records into your workflows. With the ability to set up relations between object classes in our Relational modeller, adding child object classes to records is now possible.

![Adding\_children\_to\_canvas\_article.gif](../../../images2/zendesk_10871222034973_001_dc1bc73dfd87.gif)

## Configuration and display

**The child record component is fully customizable**, allowing one to adjust the width of list headers and select the content within the list itself.

While using the Form builder, Record properties and Class fields can be added to the list to ensure that end-users see only the information they need when on the Create and edit view display of a record.

Once the child object classes component is configured, it will be visible to end-users on the record's page, where they can easily view a list of related records with selected information.

**Navigating through multiple related records is easier** with the help of pagination and the results count, enabling end users to access the information they need without hassle.

## Permissions and access

With the appropriate permissions, the end user can add new records from related object classes using the intuitive search engine. The user simply needs to search for the record and click to add it to the list.

Plus, the Child Record Summary side tab panel gives quick and easy access to important information about selected child records.

**It's important to note** that viewing the record's details depends on end-users permissions. The record's data is protected and will enforce restrictions based on granted permissions and the relations created in the relational modeller.

![Adding\_children\_to\_records\_article.gif](../../../images2/zendesk_10871222034973_002_5245ed7d07c1.gif)

With child records, you can now easily link relevant information together in a way that makes sense for your business. Say goodbye to data silos and hello to a more efficient workflow!

---

---
url: /knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai.md
---

# Private Cloud Ai

**Status:** This page is being prepared.

---

---
url: >-
  /knowledgebase/applied-ai/applied-ai-and-the-sequencer/private-cloud-ai/connecting-to-other-private-models.md
---

# Privately hosted models

Privately hosted models can be used with Autologyx where a Sequence needs to call an AI or machine learning service that is hosted, managed, or controlled outside the standard OpenAI, Azure OpenAI, or AWS Bedrock actors.

This is a flexible pattern. Instead of using a dedicated AI actor, the Sequence uses the generic API integration capability in Autologyx to send structured requests to a model endpoint and use the response later in the workflow.

Privately hosted models can include large language models, smaller specialist models, conventional machine learning models, image or audio models, redaction services, named entity recognition services, or customer-specific AI gateways.

## When to use privately hosted models

Use privately hosted models where the customer needs more control over the model, hosting environment, data handling, or inference behaviour than a standard public model integration provides.

This can be useful where:

* the model performs a specialist task that is not well served by a general-purpose LLM
* the customer wants stronger control over data location, data retention, logging, or access
* the customer has fine-tuned or otherwise adapted a model for a specific domain
* the model needs to process images, voice, video, documents, or other non-text inputs
* the customer already has a model-serving platform or AI gateway
* the workflow needs to call a conventional machine learning model, not an LLM
* the organisation wants to run AI workloads inside a private cloud, private network, or customer-controlled environment
* the workflow needs to combine structured Autologyx data with specialist model inference

This approach can be powerful because Autologyx is very good at managing structured records, workflow state, user tasks, permissions, documents, and integrations. A privately hosted model can add specialist prediction or analysis capabilities while the Sequencer continues to control the business process.

## How privately hosted model integration works

A privately hosted model normally exposes an API endpoint.

The Sequence can use an API Call actor or another generic API integration pattern to:

1. collect data from an Object Record,
2. prepare a request body,
3. authenticate to the private endpoint,
4. send text, structured data, files, references, or metadata to the model service,
5. receive a response,
6. parse or store the result,
7. update the record, create a task, generate a document, or route the workflow.

**Important:** Autologyx does not need to understand every detail of the model internally. The model endpoint needs to expose a reliable API contract, and the Sequence needs to know what to send and how to interpret the response.

## Why customers choose private hosting

Privately hosted models are sometimes chosen for reasons that are technical, commercial, operational, or governance-related.

Common reasons include:

### Specialist capability

Some models are designed for a specific type of processing.

For example, a customer may have a high-performance model for:

* PII detection and redaction
* named entity recognition
* legal clause detection
* document layout understanding
* image classification
* voice transcription or speaker analysis
* video frame analysis
* fraud detection
* risk scoring
* outcome prediction
* anomaly detection

These models may be smaller, faster, cheaper, or more accurate for a specific task than a general-purpose LLM.

### Conventional machine learning

Not every AI use case requires a large language model.

Some workflow decisions are better supported by conventional machine learning, such as regression, classification, clustering, ranking, or scoring models. These models can be particularly useful when paired with Autologyx because Autologyx can supply structured data from records, tasks, forms, documents, and process history.

For example, a privately hosted model might return:

```json
{
  "risk_score": 0.82,
  "predicted_category": "supplier_contract",
  "requires_review": true,
  "reason_code": "high_value_and_non_standard_terms"
}
```

The Sequence can then apply deterministic logic to the returned values. For example, it can create a human review task where `requires_review` is `true`, or route the record differently where the risk score exceeds a configured threshold.

### Fine-tuning and post-training optimisation

Some applications benefit from fine-tuning, retrieval tuning, adapter-based approaches, reinforcement learning from human feedback, domain-specific evaluation, or other post-training techniques.

Private hosting may be useful where a customer has a model that has been adapted for:

* their document types
* their terminology
* their risk taxonomy
* their clause library
* their intake categories
* their matter types
* their internal playbooks
* their historic decision data

This can help the model behave in a way that is more closely aligned to the customer’s domain and workflow than a general-purpose public model.

### Privacy and control

Private hosting can provide the highest degree of control over where the model runs, who can access it, how data is logged, and how traffic is routed.

This may matter where:

* sensitive documents are being processed
* the customer has strict data residency requirements
* model inputs and outputs must remain inside a private network
* security teams require direct control over infrastructure
* the customer wants to apply their own monitoring, logging, encryption, retention, or access controls
* the organisation has an approved private AI gateway

Private hosting does not remove the need for careful AI governance, but it can give the customer more control over the infrastructure and data path.

## Examples of privately hosted model use cases

Privately hosted models can support many different workflow patterns.

Examples include:

### PII detection and redaction

A Sequence sends document text to a private named entity recognition or redaction model.

The model returns structured entities such as names, addresses, dates of birth, passport numbers, national identifiers, email addresses, or account numbers. The Sequence can then store the results, create a review task, or pass the output to a downstream redaction service.

This can be useful where the customer needs high-performance PII processing at scale and wants to keep the model and data inside a controlled environment.

### Risk scoring

A Sequence sends structured matter, contract, or request data to a private scoring model.

The model returns a risk score, confidence value, and reason codes. The Sequence can then route the record to a low-risk path, create a review task, or escalate it for specialist handling.

This pattern is often more deterministic than asking an LLM to make a broad judgement because the model is designed to return defined numeric or categorical outputs.

### Specialist document classification

A private model classifies documents using a customer-specific taxonomy.

The Sequence can use the returned category to select a workflow route, assign a task, apply a document template, or trigger a review process.

### Image, audio, or video processing

A private model processes non-text content.

For example, a workflow might send an image for classification, audio for transcription, or video metadata for analysis. The returned structured result can then be stored on the record and used by later workflow steps.

### Customer AI gateway

Some customers expose a single approved AI gateway rather than allowing different workflows to call different model providers directly.

The gateway may route requests to different models, enforce data policies, log usage, apply redaction, or standardise responses. Autologyx can call that gateway through a generic API actor, while the customer’s AI platform team manages the model selection and hosting behind it.

## Cloud infrastructure and GPUs

Private hosting does not necessarily mean running models on physical hardware owned by the customer.

Many organisations use cloud providers to run private or controlled AI workloads. Cloud platforms can provide GPU-backed virtual machines, managed Kubernetes, container services, networking, identity controls, monitoring, and storage.

This can give customers flexibility. They can run a private endpoint using cloud infrastructure while still controlling the deployment, model weights, network route, security policy, and data handling approach.

Customers should work with their cloud, data science, and security teams to choose the right hosting pattern. Model size, throughput, latency, memory, GPU requirements, cost, security, and operational support all matter.

## Model-serving platforms and tooling

Privately hosted model endpoints may be built using a range of platforms and tools.

Examples include:

* Hugging Face Inference Endpoints
* Hugging Face Text Generation Inference
* Hugging Face Text Embeddings Inference
* vLLM
* Ray Serve
* custom FastAPI, Flask, or containerised services
* Kubernetes-based model-serving platforms
* customer AI gateways
* cloud-native model-serving services

Autologyx does not require a specific model-serving platform. The key requirement is that the service exposes an API that the Sequencer can call and that the response can be handled predictably.

## API design considerations

A privately hosted model endpoint should have a clear API contract.

Before connecting it to Autologyx, agree:

* the endpoint URL
* the authentication method
* the request method
* the request headers
* the expected request body
* whether files, text, JSON, or references are being sent
* the expected response format
* how errors are returned
* how timeouts and retries should be handled
* whether responses are synchronous or asynchronous
* how model versioning is controlled
* how requests and responses are logged
* who owns monitoring and support

**The clearer the API contract, the easier it is to configure the Sequencer and make the workflow reliable.**

## Structured responses and deterministic processing

Private model responses are most useful when they are returned as structured data.

For example:

```json
{
  "document_type": "contract",
  "pii_detected": true,
  "entities": [
    {
      "type": "person_name",
      "value": "Example Name",
      "confidence": 0.94
    }
  ],
  "recommended_action": "human_review"
}
```

A structured response lets the Sequence apply deterministic logic after the model has responded.

For example, the Sequence can check whether `pii_detected` is `true`, whether `confidence` is above a threshold, or whether `recommended_action` matches an allowed value.

This is usually safer and easier to maintain than relying only on free text output.

## Human review and governance

Privately hosted models still need governance.

Even when the model is hosted in a customer-controlled environment, the output may still be uncertain, incomplete, or unsuitable for fully automated use. This is especially true where the model produces semantic output, narrative analysis, predictions, or recommendations.

Use human review where the output affects important decisions, external communications, sensitive data, record updates, or regulated processes.

Governance should also cover:

* what data may be sent to the model
* who can configure or call the endpoint
* how outputs are logged
* how model performance is monitored
* how model versions are changed
* how errors are handled
* when a workflow must stop and ask for review

## Preparing a private model for Autologyx

In principle, the customer or implementation team should:

1. choose the model or model-serving platform,
2. decide where the model will be hosted,
3. define the endpoint and API contract,
4. configure authentication and network access,
5. agree what data Autologyx will send,
6. agree what structured response the model will return,
7. configure the Authentication Object in Autologyx,
8. configure the API Call actor in the Sequence,
9. test using representative records,
10. add validation and human review gates where needed,
11. monitor model behaviour after release.

The best private model integrations are designed jointly by the Autologyx configuration team, the customer’s AI or data science team, and the customer’s security or cloud platform team.

## Where to find more information

The following resources may be useful when planning privately hosted model patterns.

**Cloud GPU and infrastructure options:**

* [AWS Deep Learning AMI GPU instance guidance](https://docs.aws.amazon.com/dlami/latest/devguide/gpu.html)
* [Google Cloud GPUs](https://cloud.google.com/gpu)
* [Azure GPU-accelerated virtual machine sizes](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/gpu-accelerated)

**Model and inference platforms:**

* [Hugging Face Inference Endpoints](https://huggingface.co/docs/inference-endpoints/index)
* [Hugging Face Text Generation Inference](https://huggingface.co/docs/text-generation-inference/index)
* [Hugging Face Text Embeddings Inference](https://huggingface.co/docs/text-embeddings-inference/index)
* [vLLM OpenAI-compatible server](https://docs.vllm.ai/en/latest/serving/openai_compatible_server/)
* [Ray Serve](https://docs.ray.io/en/latest/serve/index.html)

These links are starting points only. Customers should use the current documentation for their chosen platform, hosting provider, model, and security architecture.

## Important reminder about model outputs

::: warning Important reminder
Privately hosted models are not automatically deterministic or risk-free.

Some private models may return highly structured and predictable outputs. Others, especially LLMs and generative models, may produce inconsistent, incomplete, or inaccurate responses.

Prompt design, model choice, fine-tuning, structured JSON, validation rules, confidence thresholds, and deterministic Sequence logic can reduce risk, but they cannot absolutely guarantee that a model will always return a perfect, complete, or accurate response.

Where the model returns specific structured values, the Sequencer can often apply deterministic checks to decide what should happen next. Where the model produces semantic output, such as a narrative summary, interpretation, prediction, or recommendation, customers should strongly consider human review before the output is used for important decisions, external communications, or final record updates.
:::

## Things to remember

1. Privately hosted models are integrated through generic API patterns rather than a single dedicated provider actor.
2. Private hosting can support LLMs, specialist models, conventional machine learning, redaction, entity extraction, image processing, audio processing, video processing, and customer AI gateways.
3. Private models are useful where the customer needs specialist capability, fine-tuning, post-training optimisation, or stronger control over data and infrastructure.
4. The model endpoint should expose a clear API contract.
5. Structured responses are easier for the Sequencer to validate and process deterministically.
6. The customer’s AI, cloud, security, and Autologyx configuration teams should agree the data flow before production use.
7. Use human review where outputs are semantic, high impact, externally visible, or difficult to validate automatically.

---

---
url: /knowledgebase/record-and-task-forms/formbuilder-components/properties.md
---

# Properties

Properties are found in the side panel of the following forms.

## Forms

* **Card view**
* **Create and edit view**
* **Summary view**

## Available properties

The available properties are:

* **ALX ID** - the record ID which is applied on creation and which will be used as the Identifier if no other field has been chosen as such for the Object class.
* **Created date/time** - displays the date/time the record was created.
* **Updated date/time** - displays the date/time the record was last updated. This value will be the same as Created date/time on creation of the record, but will change as soon as one of the fields in the record is amended.
* **Owners** (not **Card view**) - displays the avatar of the owner of the record.

## Using properties on a form

The Properties components can be dragged and dropped onto the form in the same way as other components.

Once added to the form canvas, they become greyed out on the side panel.

**Example:** The below shows the Properties being used on a Create and edit view.

![1406a.png](../../../images2/zendesk_19546002716189_001_4187a275c696.png)

When using this form to create a record:

* **ALX ID**, **Created date/time** and **Updated date/time** will display "(visible only when editing)".
* The **Owners** field cannot be populated.
* Placeholder avatars are shown instead.

These properties will be automatically set on creation of the record.

![1406b.png](../../../images2/zendesk_19546002716189_002_8ab145b02d69.png)

Once the record has been created, the properties are populated, as shown below.

![1406c.png](../../../images2/zendesk_19546002716189_003_f8ea490d9ea3.png)

## Useful info

1. A record can have only one Owner.
2. The User who manually creates a record will automatically become the Owner.

---

---
url: /knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers.md
---

# Public Ai Providers

This page on Public Ai Providers is being prepared.

---

---
url: /knowledgebase/release-notes/release-notes-1.6/read-only-fields.md
---

# Read-only fields

Read-only fields put your data in the spotlight, offering a visual experience while preserving its integrity.

This new feature is a useful addition to our platform, designed to empower display form designers by enabling customization of field accessibility. When configured, these fields become read-only for end-users, preventing manual modifications.

**Configuration**

Configuring Read-only fields is a seamless process. During field setup in your chosen display form, simply enable the **Read-only** option.

Once activated, the field becomes impervious to manual changes, safeguarding your data against unintended modifications. The Sequencer can then automatically update the field based on specified conditions, ensuring a controlled and predictable workflow.

![Readonly1article.gif](../../../images2/zendesk_14581471748381_001_6802040f15d5.gif)

**How to make the most of Read-only fields**

Consider a situation where you want to preserve a **Status** field, keeping it unchangeable upon record creation. With Read-only fields, you can preset this status, allowing it to change automatically only after specific conditions, defined in Sequencer, are met.

![Readonly2article.gif](../../../images2/zendesk_14581471748381_002_63a14057bf44.gif)

**At a glance**

Unmodifiable yet clearly visible, this feature adds a new chapter to your workflow's story. By allowing visibility without direct modification, Read-only fields ensure that critical information remains accurate, providing a robust mechanism to control data modifications.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.14/real-time-workflow-improvements.md
---

# Real-Time & Workflow Improvements

## New context menu items in Sequencer

We’ve introduced new context menu options in Sequencer to make working with commonly used merge fields faster and more intuitive.

You can now easily insert the following merge fields directly into sequence objects such as Send Message actors, API calls, and Variables:

* **Client:** name and URL
* **Date/Time:** current date and current date/time

**At runtime,** each merge field is automatically replaced with its corresponding value:

* {{client.name}} — the client’s name, as defined at system inception
* {{client.url}} — the client’s Catalyst system URL
* {{current\_date}} — the current system date at the moment the sequence actor executes
* {{current\_datetime}} — the current system date and time at the moment the sequence actor executes

|  |  |
| --- | --- |
| clipboard-202509261403-sn8eo.png | clipboard-202509261403-olypo.png |

## Introduced new merge fields

We’ve expanded merge field capabilities to support more dynamic, loop-driven workflows.

### {{ loop\_item }} support in Local Variables

You can now use the {{ loop\_item }} merge field within Local Variables when using a Static value with a Document Type source. This allows you to reference and reuse document values dynamically within your workflows.

**How this works:**

* When a Local Variable uses a Static value containing {{ loop\_item }}, the system resolves it at runtime using the document from the current loop iteration
* The resolved value represents the Document object and can be used in subsequent actors
* When multiple Loop actors are chained, {{ loop\_item }} resolves to the closest upstream loop context available at runtime
* If used outside of a Loop actor, the value resolves to an empty string
* When testing via the Test Variable functionality, {{ loop\_item }} resolves using the document assigned to the current loop iteration

![clipboard-202510101130-hrf5b.png](/knowledgebase/images/img_5585565776671_1776895580.png)

### {{ loop\_counter }} for loop-driven execution

We’ve also introduced the {{ loop\_counter }} merge field to support loop-based sequencing.

**This field:**

* Represents the current iteration index (starting from 1)
* Available to all supported actors downstream of a Loop actor

**This enables you to:**

* Dynamically generate incremental values
* Append counters to filenames
* Create sequential identifiers
* Support ordering logic within loop-based automation

{{ loop\_counter }} works alongside {{ loop\_item }} and follows the same availability, resolution, and actor support rules.

## Extended user-type merge fields to return User Group Members

We’ve enhanced merge field resolution for User-type Object Class fields, making it easier to work with User Groups in your automation.

Previously, the merge field

```jinja
{{ record.field_user.meta.user_groups }}
```

returned only metadata about groups (IDs, names, and member counts).

With this update, you can now access the full list of users within each group using:

```jinja
{{ record.field_user.meta.user_groups[&lt;index&gt;].members }}
```

**Example response structure:**

```json
[
{
"id": 12,
"first_name": "Bridget",
"last_name": "Marquardt",
"username": "bridget.marquardt826@example.com
",
"company_name": "",
"phone": "16253372",
"mobile": "27363737"
},
{
"id": 591,
"first_name": "Abelardo",
"last_name": "Gutkowski",
"username": "abelardo.gutkowski752@example.com
",
"company_name": "",
"phone": "76235342",
"mobile": "93833722"
}
]
```

The merge field can be used where standard record-based merge fields are supported, eg Send Message actor, document templates, Local Variable, API Call, etc.

This enhancement allows you to dynamically reference users within selected groups, enabling more powerful and flexible automation, messaging, and document generation.

## Real-time updates for Task Lists using WebSockets

We’re laying the groundwork for a more responsive, real-time experience across the platform.

As part of this, we’ve introduced a new back-end API powered by WebSockets, enabling task state changes to be reflected **instantly** — without the need for a page refresh.

This enhancement paves the way for real-time updates across the Landing Page, Task List, and Task Panel, helping users stay up to date with the latest activity as it happens.

**Watch this space — there’s more to come.**

---

---
url: >-
  /knowledgebase/workspace/records/record-access---adding-and-removing-assignees.md
---

# Record access - adding and removing Assignees

You will have access to the Record access tab if you are one of the following:

* **Owner** of the Object class to which the record belongs
* **Owner** of the record
* A user with a Super admin account type

For more information, see [Record access tab](/knowledgebase/workspace/records/record-access-tab/).

## Adding Assignees using Record Permission Sets

A user with access to the Record Access tab can grant access to other users.

### Add users to a Record Permission Set

1. Click the **Give access** button.

   The tab display changes and the **Add people** panel is shown.

![Record Access tab showing the Give access button](/knowledgebase/images/workspace/record-access-assignees-1.png)

![Add people panel displayed after clicking Give access](/knowledgebase/images/workspace/record-access-assignees-2.png)

2. Select the required Permission Set from the dropdown list.

   **Note:** The **All** option is not available.

3. Search for and select the required user by clicking their tile.

   The user is marked as **Already selected** and becomes greyed out. You can add multiple users in this way.

   Users who have already been assigned to the selected Permission Set are also greyed out.

4. If you select a user in error, click the **X** on the right-hand side of their tile to remove them from the selection.

![Permission Set dropdown list](/knowledgebase/images/workspace/record-access-assignees-3.png)

![User selected for assignment to a Permission Set](/knowledgebase/images/workspace/record-access-assignees-4.png)

![Multiple users selected for assignment to a Permission Set](/knowledgebase/images/workspace/record-access-assignees-10.png)

![Removing a selected user before access is granted](/knowledgebase/images/workspace/record-access-assignees-5.png)

5. Click **Add**.

   A green success notification is displayed. The tab returns to its normal view and the Owner/Assignees counter increases according to the number of users added.

6. The new Assignees are granted access to the record immediately.

## Checking access

The record Owner is clearly identified in the list.

Other users are displayed with the number of Permission Sets to which they belong.

To see which Permission Sets have been assigned to a user, click the **Permission Sets** link below their name.

![Owner and Assignees list showing assigned users](/knowledgebase/images/workspace/record-access-assignees-6.png)

![Permission Sets displayed for a selected user](/knowledgebase/images/workspace/record-access-assignees-7.png)

The Permission Sets assigned to the user are displayed.

## Removing a user from a Record Permission Set

1. Click the **Permission Sets** link beneath the user's name.

2. Click the **X** next to the Permission Set you want to remove.

3. A confirmation dialog is displayed.

   * Click **Cancel** to keep the Permission Set assigned.
   * Click **Yes, remove** to remove the Permission Set.

   A green success notification is displayed and the user immediately loses the associated access.

![Confirmation dialog for removing a Permission Set](/knowledgebase/images/workspace/record-access-assignees-8.png)

4. If the user belonged to only one Permission Set, they are removed from the Owner/Assignees list.

   If they belong to multiple Permission Sets, they remain in the list with their remaining assignments.

![User removed from a Permission Set](/knowledgebase/images/workspace/record-access-assignees-9.png)

5. The user immediately loses any permissions associated with the removed Permission Set.

## Things to remember

1. A record can have only one Owner but can have multiple Assignees through one or more Record Permission Sets.

2. A Record Permission Set can contain up to 100 Assignees.

3. The Record Access tab displays warnings when the number of Assignees approaches the maximum limit.

4. Changes to Record Permission Set assignments take effect immediately.

5. Removing a user's final Permission Set removes their access to the record.

---

---
url: /knowledgebase/workspace/records/record-access---owners.md
---

# Record access - Owners

Each Object record has a Record access tab in the side panel.

This tab can be enabled from the **View** menu in the top-right corner of the page.

You can access this tab if you are one of the following:

* Owner of the Object class to which the record belongs
* Owner of the record
* A user with a Super admin account type

For more information, see [Record access tab](/knowledgebase/workspace/records/record-access-tab/).

## Assigning an Owner

If a record does not currently have an Owner, you can assign one using the Record Access tab.

1. Click the **Give access** button.

2. In the **Add as** dropdown list, select **Owner**.

3. Search for the required user or scroll through the list and click their tile to select them.

| Click **Give access** | Select **Owner** from the **Add as** list |
| --- | --- |
| ![Record Access tab showing the Give access button](/knowledgebase/images/workspace/record-access-owners-1.png) | ![Add people panel with Owner selected in the Add as dropdown](/knowledgebase/images/workspace/record-access-owners-2.png) |

4. A warning message is displayed indicating that only one Owner can be assigned.

   Click **+ Add** to continue.

![Warning message showing that only one Owner can be assigned](/knowledgebase/images/workspace/record-access-owners-3.png)

5. A green success notification is displayed.

   The selected user is shown as the Owner in the Owner/Assignees list and the Owner/Assignees counter is updated.

![Owner successfully assigned to the record](/knowledgebase/images/workspace/record-access-owners-4.png)

## Things to remember

1. A record can have only one Owner.
2. Only authorised users can assign or change the Owner of a record.
3. Changes to record ownership take effect immediately.

---

---
url: /knowledgebase/release-notes/release-notes-1.10/record-access-actor.md
---

# Record Access actor

Managing access to records securely and efficiently is essential for businesses of all sizes. That’s why we’re excited to introduce the **Record Access actor**, a new tool in the Sequencer that gives you **complete control over record access and ownership**. Whether you need to configure record ownership, set up record permissions assignments, or dynamically manage access based on field values, this actor offers a centralised and highly flexible solution.

At its core, the **Record Access actor** handles two critical aspects of data management:

* **Record ownership**
* **permission sets**

## Record ownership configuration

**Record ownership configuration** offers flexibility through four distinct approaches. You can:

* remove all current owners
* set ownership only for records that don't have owners assigned
* completely override existing ownership with new assignments
* append additional owners while maintaining current ones

**Ownership can be assigned in the following ways:**

* **By User:** selecting specific users directly from the list
* **By Field:** dynamically pulling users from a designated field in the record

![Record access 1.gif](../../../images2/zendesk_4640685748639_001_5ac13e006a60.gif)

**Important:** Ownership assignments are subject to database limits. By default, only one owner can be assigned to a record. If the field selected for ownership contains more users than the allowed limit, the actor will complete execution but will not update the ownership. This ensures your Sequencer flow continues smoothly while respecting system constraints.

## Permission set configuration

**Permission set configuration** elevates access control to a new level of precision. The actor gives you **three approaches** to managing permissions:

1. **Remove access** — clear all assignees at once, target specific users or groups for removal, or base your removals on field values.
2. **Append** — add new users, groups, or field-based assignments while preserving existing assignees.
3. **Override** — completely replace current assignees with your new configuration, whether that's specific users, user groups, or dynamic field-based assignments.

**How these approaches work:** These three approaches work seamlessly together, giving you control over who has access to your records at any time.

![Record access 3.gif](../../../images2/zendesk_4640685748639_002_aa912d2a2ad0.gif)

**Limits and processing behaviour:** Each permission set can accommodate up to 100 users and 10 user groups, providing ample room for complex organisational structures. While you can configure multiple setups for the same permission set, each configuration must stick to a single action type - for instance, you can't simultaneously append and override assignees for the same permission set. The actor processes these configurations sequentially from top to bottom, ensuring predictable and consistent results.

Any part of the configuration that cannot be executed (e.g., exceeding limits) will be completed but will not update the record or permission set. This ensures your Sequencer continues to function without interruptions, even if certain constraints aren’t met. Built-in safeguards prevent the assignment of 1TC users to permission sets, adding an extra layer of security to your access management.

![Record access 34.gif](../../../images2/zendesk_4640685748639_003_9b99bb676735.gif)

**Dynamic assignment:** The ability to assign users or groups dynamically, based on field values, makes the actor highly adaptable to your unique business workflows. This thoughtful approach to access management means you can maintain robust security controls while ensuring your teams have exactly the access they need to operate efficiently. The Record Access Actor transforms complex permission management into a streamlined, reliable process that grows with your organisation.

---

---
url: /knowledgebase/system-configuration/sequence-actors/record-access-actor.md
---

# Record Access Actor

## What does the Record Access actor do?

The Record Access actor manages control of record access and ownership. It handles two critical aspects of record data management: **record ownership** and **record access via permission sets**.

It is worth noting at this point that a user who manually creates a record will become the record owner by default. The record owner has full permissions for that record, including the ability to delete it. Therefore, a common use of the Record Access actor is to remove or override ownership immediately after record creation.

![Screenshot 2026-04-16 at 12.58.01.png](../../../images2/zendesk_5645923976351_001_565f23329b4b.png)

## How do I use the Record Access actor?

Click, drag and drop the Record Access actor onto your sequence workspace.

Right click on it and select Configure. The Record access configuration modal will open.

The modal gives you two options:

* **Configure record ownership**
* **Configure record permission set assignment**

You can use the same actor to configure both types of access or deal with only one, as required.

![Screenshot 2026-04-16 at 12.59.17.png](../../../images2/zendesk_5645923976351_002_753c0e04c4d2.png)

## Configure record ownership

Check the box to configure record ownership. A single-select field will offer you 3 options:

![Screenshot 2026-04-16 at 13.02.37.png](../../../images2/zendesk_5645923976351_003_404f92984cef.png)

### Remove owners

This will do exactly as it says and remove the record owner, resulting in this user losing record ownership permissions. They will then need class permissions or a record permission set to be able to access the record, unless they have a Super Admin account type.

No further configuration is required for this option.

### Override owners

This option will remove the existing owner and allow a replacement owner to be set.

### Set owners

This option will allow an owner to be set where the record does not already have an owner.

### Override owners and Set owners

Having selected **Override owners** or **Set owners**, the display will allow you to choose to do this **By user** or **By field**.

### By user

Tick the box and start typing the name of the required user. The user list will filter accordingly.

![Screenshot 2026-04-16 at 14.48.25.png](../../../images2/zendesk_5645923976351_004_47e686fc606a.png)

Click on the required user to select them. You can, of course, scroll through the list if you prefer. You will only be able to select one user.

### By field

Tick the box and click into the **Search for field** drop-down.

All user type fields associated with the sequence's object class will be shown.

![Screenshot 2026-04-16 at 15.01.58.png](../../../images2/zendesk_5645923976351_005_6ca96092cfe6.png)

This is a single selection; only one field can be chosen. Click on it and save the configuration.

By default, only one owner can be assigned to a record. If the field selected for ownership contains more than one user for a record, the actor will complete execution but **not** update the ownership. This ensures that the sequencer flow continues while respecting system constraints.

## Configure record permission set assignment

Before you can configure record permission set assignment, the sequence's object class must have at least one [**record permission set**](/knowledgebase/system-configuration/object-classes/explanation-of-record-permissions/) configured.

The screenshot below shows that two record permission sets have been configured - Mortgage Reviewer and Team Lead.

The Record Access actor can now be used to control assignment and removal of these permission sets for any records which trigger the actor, for single or multiple users.

![Screenshot 2026-04-16 at 15.26.07.png](../../../images2/zendesk_5645923976351_006_26cee3b73d3a.png)

Click into the drop-down and the available permission sets will be displayed.

![Screenshot 2026-04-16 at 15.24.29.png](../../../images2/zendesk_5645923976351_007_57b2e2de0999.png)

Select one permission set and a further drop-down will provide 3 single-select options:

![Screenshot 2026-04-16 at 15.33.49.png](../../../images2/zendesk_5645923976351_008_2e4faea3f613.png)

### Append assignees

This option will add the selected users to the chosen record permission set. Existing assignees are preserved.

### Override assignees

This option will remove existing assignees from the record permission set and replace them with the users selected here.

### Remove assignees

This option will remove existing assignees from the record permission set.

**Append assignees** and **Override assignees** have the same configuration single-select options: **Users**, **User groups** and **Field**.

![Screenshot 2026-04-16 at 16.22.39.png](../../../images2/zendesk_5645923976351_009_02d6eb65af2f.png)

### Users

Having selected **Users**, click into the **Search for users** field and start typing the name of the required user. The user list will filter accordingly.

![Screenshot 2026-04-16 at 16.26.19.png](../../../images2/zendesk_5645923976351_010_69991c1f752e.png)

Click on the required user and either save the configuration or, if more than one assignee is appropriate, start typing again. You can, of course, scroll through the list if you prefer.

Continue selecting users and save the configuration.

### User groups

Click into the **Search for user groups** field. All system User groups will be available for selection.

![Screenshot 2026-04-16 at 16.29.28.png](../../../images2/zendesk_5645923976351_011_7358fa8d64c4.png)

Click on each required User group to select it and save the configuration.

### Field

Click into the **Search for field** drop-down.

All user type fields associated with the sequence's object class will be shown.

![Screenshot 2026-04-16 at 16.34.00.png](../../../images2/zendesk_5645923976351_012_9aefdc5c8b97.png)

Unlike the other two options, this is a single-select field. Click on the required field name to select it and save.

**Remove assignees** has all of the above configuration options plus **Remove all**.

### Remove all

**Remove all** will remove record access from all users other than the owner, if one is set.

![Screenshot 2026-04-16 at 16.37.03.png](../../../images2/zendesk_5645923976351_013_6a60c2806240.png)

**Remember:** save your configuration and label the actor with something meaningful.

|  |  |
| --- | --- |
| Right click on the actor and select Properties.  Enter the new label in the Name field and save. | Screenshot 2026-04-16 at 17.21.03.png |
| The new label will appear under the Record Access actor.  If the label is too long it will be truncated but can be viewed by hovering over the name. | Screenshot 2026-04-16 at ![17.21.22.png](../../../images2/zendesk_5645923976351_015_8282df02fa40.png) |

While you can configure multiple setups for the same permission set, each configuration must stick to a single action. For instance, you cannot simultaneously append and override assignees for the same permission set.

The Record Access actor processes these configurations sequentially from top to bottom, so the configuration shown in the screenshot below is logical and acceptable:

![Screenshot 2026-04-16 at 17.55.59.png](../../../images2/zendesk_5645923976351_016_30ee5fe6cc70.png)

Any part of the configuration which cannot be executed, eg exceeding limits, will be completed but will not update the record or permission set.

If your sequence's object class is in a relationship with other object classes and you want to ensure that ownership and/or record assignees are the same for parent, child, grandchild, etc, you will need to do this via cascading sequences using Relation Lookup and [**Sequence Runner**](/knowledgebase/system-configuration/sequence-actors/sequence-runner-actor/) actors. In addition, you will need to configure matching record permission sets on all related object classes.

## Useful info

1. A record can have only one owner.
2. Each record permission set can accommodate up to 100 users and 10 user groups.
3. Each User group can have up to 1,000,000 users.
4. One-time completion users cannot be assigned to a permission set.

---

---
url: /knowledgebase/workspace/records/record-access-tab.md
---

# Record access tab

Each Object record includes a Record Access tab in the side panel.

This tab can be enabled from the **View** menu in the top-right corner of the page.

You can access this tab if you are one of the following:

* Owner of the Object class to which the record belongs
* Owner of the record
* A user with a Super admin account type

The **Record Access tab** shows which user is the Owner of the record and which users have access through a Record Permission Set.

![Record Access tab showing the Owner and Assignees list](/knowledgebase/images/workspace/record-access-tab-1.png)

The user who manually creates a record automatically becomes the Owner. However, the Owner can be changed using an API Call in a sequence.

## Components

The **Record Access tab** contains the following components:

1. The record Identifier
2. **Owner/Assignees counter** - changes when the dropdown menu is used to filter users
3. **Give access** button
4. **Users search field** - users with a 1 time completion account type are not available
5. **Dropdown menu** with options:
   * **All** - shows the Owner and Assignees from all Permission Sets for the record
   * **Owner** - shows the record Owner
   * names of all available Record Permission Sets created on the Object class, shown in alphabetical order
6. **Owner/Assignees list**

![Record Access tab showing the available controls and filters](/knowledgebase/images/workspace/record-access-tab-2.png)

If a record has no Owner or Assignees, the tab displays the message:

> No results\
> No one has been given access

![Record Access tab showing a record with no Owner or Assignees](/knowledgebase/images/workspace/record-access-tab-3.png)

## What you can do from this tab

From this tab, you can:

* assign, change, or remove the Owner
* grant access to users through Record Permission Sets
* remove user access from Record Permission Sets

## Things to remember

1. A record can have only one Owner but multiple Assignees through one or more Record Permission Sets.
2. Record Permission Sets are created on the Object class.
3. A Record Permission Set can have up to 100 Assignees.

---

---
url: /knowledgebase/record-and-task-forms.md
---
# Record and Task Forms

This section explains how forms are designed and configured in Autologyx, and how they support both Object Records and Tasks.

Forms are an important part of the user experience in Catalyst. They control how information is presented, captured, validated, and updated, whether a user is creating a new record, editing an existing one, or completing a task as part of a wider workflow.

This section is most relevant to Config Admins, analysts, and builders who need to design clear, usable forms that work well for end users and support the wider process and data model.

## What you will find in this section

### Formbuilder Components

**Purpose:** This area explains the building blocks available in the Catalyst formbuilder.

It includes guidance on the main parts of the formbuilder and the different configuration panels used to shape a form, such as layout, properties, Elements, child Object Classes, and task form fields.

* [Formbuilder Components](/knowledgebase/record-and-task-forms/formbuilder-components/)

### The Form Builder

**Purpose:** This area focuses on designing effective forms, especially where users need to create new records or enter information in a structured way.

It is particularly useful when working with the Create and edit view, standalone forms, and other form experiences that need to be clear, practical, and easy for users to complete.

* [The Form builder](/knowledgebase/record-and-task-forms/the-form-builder/)

### Using Conditional Logic in Forms

**Purpose:** This area explains how to make forms more dynamic by changing what the user sees or can do based on values entered elsewhere in the form.

It also covers the impact of changing or removing fields, columns, and sections that are already being used in conditional logic, which is important when maintaining forms over time.

* [Using Conditional Logic in Forms](/knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/)

## How this section fits into the wider platform

**Record and task forms** sit between the platform's underlying configuration and the day-to-day user experience.

They are closely related to:

* Object Classes, which define the structure of the data being captured
* Task Templates, which define how users are asked to complete work
* Standalone Forms, which allow records to be created outside the main logged-in workspace experience
* Create and edit view, which controls how users create and edit records inside the platform

A well-designed form does more than collect information. It helps users understand what is needed, reduces mistakes, and makes the wider process easier to complete.

## Suggested path

If you are new to this area, a sensible order is:

1. start with **Formbuilder Components** to understand the building blocks available
2. review **The Form Builder** to understand how form design works in practice
3. use **Using Conditional Logic in Forms** when you need more dynamic behaviour or are maintaining existing form logic

## Notes

::: info
This section is about how forms are built and behave in Autologyx, rather than the wider workflow or data model that sits behind them.
:::

::: tip
If you are designing a form for end users, think not only about what data is required, but also about clarity, layout, effort to complete, and how the form fits into the wider process.
:::

---

---
url: /knowledgebase/system-configuration/merge-fields/record-properties.md
---

# Record properties

The following Object records properties can be accessed using merge fields in templates:

| Property | Merge Field Syntax | Type |
| --- | --- | --- |
| ID | {{ record.id }} | Integer |
| Created | {{ record.created\_at }} | Date/time |
| Modified | {{ record.modified\_at }} | Date/time |

**Useful info**

1. The shorthand {{ record }} will be automatically substituted with the `record.id` property.
2. Jinja merge fields **do not** support referencing the record identifier field using the syntax `<<record.identifier>>`.

---

---
url: /knowledgebase/workspace/records.md
---

# Records

Records are used throughout Catalyst to store and manage information relating to a business process, case, matter, customer, application, or any other type of work item.

Depending on your permissions, you may be able to create records, update information, manage access, complete tasks, and view activity associated with a record.

The following articles explain the most common record-related actions and features.

## Working with records

### Creating and editing records

* [Manual creation of Object records](/knowledgebase/workspace/records/manual-creation-of-object-records/)
* [Editing Object records](/knowledgebase/workspace/records/editing-object-records/)

These articles explain how records are created and how information can be updated after a record has been created.

### Record access and permissions

* [Record access tab](/knowledgebase/workspace/records/record-access-tab/)
* [Record access - owners](/knowledgebase/workspace/records/record-access---owners/)
* [Record access - adding and removing Assignees](/knowledgebase/workspace/records/record-access---adding-and-removing-assignees/)

These articles explain how access to a record is controlled and how users can be granted or removed from a record.

### Finding and managing records

* [Records list](/knowledgebase/workspace/records/records-list/)

This article explains how to use the Records list page, including navigation, searching, filtering, and other common actions.

## Things to remember

* Access to records depends on your permissions and role.
* Some records may be automatically created by workflows and integrations.
* Record visibility can be controlled using Owners, Assignees, and other access settings.
* The Records list provides tools for finding, filtering, and managing records.

---

---
url: /knowledgebase/workspace/records/records-list.md
---

# Records list

From the Workspace, users can access lists of Object records that their permissions allow them to interact with.

Object records are grouped by Object class. Only one Object class can be selected at a time.

The Records list has the same common features as other list pages in Catalyst.

Find out more about [List pages](/knowledgebase/finding-your-way-around/ui-and-navigation/list-pages/).

The default Records list is shown below.

![Default Records list showing Object records for the selected Object class](/knowledgebase/images/workspace/records-list-1.png)

## Column headings

The default Records list includes the following columns:

* **ALX ID** - a unique number given to the Object record when it is created.
* **Created** - the date and time the Object record was created.
* **Actions** - contains available actions for the Object record:
  * **Open** - opens the Object record. Depending on your permissions, you may be able to view or edit the record.
  * **Delete** - shown only if you have permission to delete the Object record.

The default view also includes the field selected as the Identifier in the Object class Fields tab.

In the example below, the Identifier is **Mortgage Application Number**.

![Records list showing the Identifier column](/knowledgebase/images/workspace/records-list-2.png)

If the Identifier field is blank for any Object record, the ALX ID is shown instead.

## Useful features

The Records list includes features that help you find, view, and manage Object records.

### Select an Object class

Use the Object class selector to filter the Records list to records from a specific Object class.

![Object class selector on the Records list](/knowledgebase/images/workspace/records-list-3.png)

### Switch between List View and Card View

Use the view switch icon to move between traditional List View and Card View.

Record views are configured on the Object class.

Find out more about [editing Object class display configuration](/knowledgebase/system-configuration/object-classes/edit-object-class---configure-displays/).

![View switch icon on the Records list](/knowledgebase/images/workspace/records-list-4.png)

![Records displayed in Card View](/knowledgebase/images/workspace/records-list-5.png)

In Card View, each Object record has an **Open** icon in the top-left corner.

Clicking this icon opens the Object record in Edit View with the side panel open, showing available tabs such as Summary, Tasks, and Record access.

![Open icon shown on an Object record card](/knowledgebase/images/workspace/records-list-6.png)

### Use the side panel

In List View, the side panel opens when an Object record is selected, provided one or more items are selected in the **View** menu.

![View menu showing available side panel options](/knowledgebase/images/workspace/records-list-7.png)

![Records list with the side panel open](/knowledgebase/images/workspace/records-list-8.png)

The side panel can include up to four tabs relating to the selected Object record.

### Summary tab

The **Summary** tab shows the Summary View configured on the Object class.

It is for information only and cannot be edited.

![Summary tab showing configured Object record information](/knowledgebase/images/workspace/records-list-9.png)

### Tasks tab

The **Tasks** tab shows all Tasks associated with the Object record, regardless of how they were created.

Completed tasks show a **View** button, the completion date, and the avatar of the user who completed the task.

Outstanding or overdue Tasks show a **Complete** button. If a due date was set in the Task template, it is also displayed.

![Tasks tab showing completed and outstanding Tasks for an Object record](/knowledgebase/images/workspace/records-list-10.png)

### Activity log tab

The **Activity log** tab shows history events directly related to the Object record, such as Owner changes and field value updates.

A user can access the Activity log only if they have **View record** permission for the selected record.

This tab is hidden from users with an External account type.

![Activity log tab showing Object record history events](/knowledgebase/images/workspace/records-list-11.png)

### Record access tab

The **Record access** tab shows Object record Owners and Assignees.

When an Object record is created manually, the user creating it automatically becomes the record Owner.

Users with a Super Admin account type and Object class Owners can access this tab. Other users will not see it.

![Record access tab showing Object record Owners and Assignees](/knowledgebase/images/workspace/records-list-12.png)

### Configure columns

You can select Object class fields in column configuration.

If the selected columns exceed the available main content area, a horizontal scrollbar appears at the bottom of the table.

Long field names or values are truncated.

![Column configuration showing Object class fields](/knowledgebase/images/workspace/records-list-13.png)

![Records list showing additional configured columns and horizontal scrolling](/knowledgebase/images/workspace/records-list-14.png)

### Filter records

The filter editor allows you to filter records by record properties and Object class fields.

![Records list filter editor showing record properties and Object class fields](/knowledgebase/images/workspace/records-list-15.png)

Filtered results are displayed under the list page name as the number of matching results out of the total number of records.

The page navigation also shows the **Filtered results** control.

![Filtered Records list showing matching results](/knowledgebase/images/workspace/records-list-16.png)

![Records list page navigation showing the Filtered results control](/knowledgebase/images/workspace/records-list-17.png)

Find out more about the [list page filter editor](/knowledgebase/finding-your-way-around/ui-and-navigation/list-page-filter-editor/).

Find out more about [Editing Object records](/knowledgebase/workspace/records/editing-object-records/).

## Things to remember

1. The maximum number of Object records any Object class in your system can have is 500,000.
2. The **+ Create record** button opens the Create and Edit View configured on the Object class.
3. Only one Object class can be selected in the Records list at a time.
4. The side panel tabs available depend on the Object class configuration and your permissions.
5. The Records list supports filtering, column configuration, List View, and Card View.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.6/redirect-url-on-standalone-forms.md
---

# Redirect URL on Standalone forms

Navigating the world of user interaction has just become smoother with our latest enhancement: **Redirect URL on Standalone Forms**. Seamlessly guiding users to their desired destinations has never been easier, helping to ensure a tailored experience from start to finish.

**Setup is straightforward.** Within the standalone form settings, enable the feature and specify the destination URL to integrate this tool into your existing workflows.

![Redirect1\_article.gif](../../../images2/zendesk_14581442395933_001_2f67114fc9e8.gif)

**After submission,** users can transition to specific websites or other standalone forms after completing their form submissions. Say goodbye to generic thank-you pages and hello to personalized redirection tailored to individual user needs and interests.

![Redirect2\_article.gif](../../../images2/zendesk_14581442395933_002_62d3ca6617f3.gif)

**Experience the difference** with Redirect URL on Standalone Forms. Standalone forms are no longer just data collection tools - they are the starting point of personalized and meaningful user experiences.

---

---
url: /knowledgebase/release-notes/release-notes-1.2/relation-lookup.md
---

# Relation Lookup

Meet our latest addition to the Sequence designer: Relation Lookup actor. Designed to work seamlessly with the Sequence Runner, this powerful tool simplifies your workflow by effortlessly locating children or parent records of the object class.

When you attach a Sequence Runner to the Relation Lookup, an extraordinary synergy emerges. This dynamic duo allows the sequencer to check through associated parent or child records, identifying those that match the given conditions configured within it. You'll have the ability to run a sequence specifically for the records identified in the chosen parent or child object class.

![Relational\_lookup\_article.gif](/knowledgebase/images/img_11180912083101_1776895698.png)

## Before you dive in

Before you dive into the world of **Relation Lookup**, make sure you have your relational model defined — it's essential to unlock the full potential of this feature.

## Benefits

With the **Relation Lookup actor** at your disposal, the possibilities are endless. Customise triggers, configure the relation lookup in countless ways, and leverage this actor multiple times when designing your sequence.

**Discover the ease** of managing complex workflows, optimising sequence efficiency, and enjoying a smoother automation experience. Get started today and witness the power of Autologyx Catalyst's latest features!

---

---
url: /knowledgebase/system-configuration/sequence-actors/relation-lookup-actor.md
---

# Relation Lookup Actor

## What does the Relation Lookup actor do?

The **Relation Lookup actor** allows the sequencer to check through the associated parent or child records and identify those which match the given conditions configured within it.

When it has run, a list of parent or child records matching the Relation Lookup conditions is stored in the backend for further processing.

The Relation Lookup actor is quite often used with the [**Sequence Runner actor**](/knowledgebase/system-configuration/sequence-actors/sequence-runner-actor/).

Having identified related parent or child records with the Relation Lookup actor, you can attach a Sequence Runner actor to run a sequence specifically for those records identified in the chosen parent or child object class.

## How do I use the Relation Lookup actor?

Before you can use the Relation Lookup actor, your Catalyst system must have a relational model defined.

Find out more about the [**relational modeller and how to create one**](/knowledgebase/system-configuration/relational-modeller/what-is-the-relational-modeller/).

The relational model used for the purposes of this article is shown below.

![Screenshot 2026-04-20 at 15.02.32.png](/knowledgebase/images/img_5658634260895_1776895838.png)

Click, drag and drop the Relation Lookup actor onto your sequence workspace at the point where it is appropriate to check related records.

Right click on the actor and select Configure. The Relation lookup configuration window will open.

**Lookup options**

The Lookup field has two options: **Children** and **Parents**.

![Screenshot 2026-04-20 at 14.57.37.png](/knowledgebase/images/img_5658634260895_1776895839.png)

Make your lookup selection, but remember that you can only look up a parent object class if the sequencer's object class is a child, and you can only look up a child object class if the sequencer's object class is a parent.

|  |  |
| --- | --- |
| The sequence object class is "Mortgage Application".  You will note that this object class is a parent but not a child in the relational model.  Therefore, the Relation Lookup actor has a blank class field when Lookup Parents is selected. | Screenshot 2026-04-20 at 15.35.47.png |

**Add conditions**

Next, add any conditions about the records you want to reach.

|  |  |
| --- | --- |
| These can be about the Record | Screenshot 2026-04-20 at 15.09.49.png |
| And, or relating to field data | Screenshot 2026-04-20 at 15.10.38.png |

Complete the configuration and save.

![Screenshot 2026-04-20 at 13.00.01.png](/knowledgebase/images/img_5658634260895_1776895840.png)

**Configure the trigger**

Take a trigger from the Relation Lookup actor and connect it to the next sequence object; this can be any other sequence object but is often a Sequence Runner actor or even another Relation Lookup actor.

Right click on the trigger and select Trigger so that the Trigger configuration opens. You will note that the first field options includes **"Matched Records"**.

The **Relation Lookup actor** does not automatically stop downstream workflow from processing just because the search returns 0 records. By using the **Matched Records** condition, you are able to ensure that pieces of workflow only progress when the correct number of records is matched. For example, if a Relation Lookup returned 0 children, but the trigger only referenced "When Actor Completed", a Sequence Runner actor following it would unnecessarily trigger and attempt to run against **all records in the empty list**.

![Screenshot 2026-04-20 at 18.07.49.png](/knowledgebase/images/img_5658634260895_1776895840.png)![Screenshot 2026-04-20 at 18.32.42.png](/knowledgebase/images/img_5658634260895_1776895840.png)

However, if the subsequent actor is not a Sequence Runner (as with the example shown above), the impact is not solely one redundant actor activation. The Relation Lookup in this example successfully finds 0 records, but without **Matched Records > 0** as a Trigger Condition, the DocAuto Actor will trigger regardless, leading to unintended document creation (or other further workflow).

|  |  |
| --- | --- |
| In this use case cascading Relation Lookup actors are being used to check the DocuSign Recipient's signing status.  The Recipient (Seller) is a party in a Deal transaction. There are multiple Sellers who must sign the agreement.  The overall Deal status is being set based on the value of all Sellers eg the status will only become "Completed" when every child record Seller has signed.  We are using a combination of Matched Records > 0 and Matched Records = 0 to rule out each earlier status before confirming that everyone has signed.  Dependent on the status, different onward processing is achieved with API calls. | image (3).pngimage (4).png |
| Here the first Relation Lookup actor is being used to determine whether the Deal relationship contains one or more Buyers.  If one Buyer is present, the sequence will take the left hand route. The second Relation Lookup actor is checking the Seller records against which another sequence will be run.  If more than one Buyer is present, the sequence will take the right hand route. | image (2).png |

**Naming**

As with all sequence actors, it is good practice to replace the default actor name with a label which is more meaningful and describes its purpose.

|  |  |
| --- | --- |
| Right click on the actor and select Properties.  Enter the new label in the Name field and save. | Screenshot 2026-04-20 at 18.37.10.png |
| The new label will appear under the Relation Lookup actor.  If the label is too long it will be truncated but can be viewed by hovering over the name. | Screenshot 2026-04-20 at 18.44.02.png |

Click for more information on [**using the Relation Lookup and Sequence Runner actors together**](/knowledgebase/system-configuration/sequences-for-relational-records/a-guide-to-using-the-relation-lookup-and-sequence-runner-actors-together/).

## Useful info

1. The Relation Lookup actor configuration is limited to 3 conditions which cannot be nested. Therefore, this limits you to 3 x All or 3 x Any conditions. If a user needs to do more complex logic than the 3 allowed they would need to use a Local Variable and potentially an API Call to trigger children in very specific cases OR rather trigger all children and add the nesting logic into the "When Sequence Activated" trigger.
2. An Autologyx Catalyst instance can have up to 1,000 sequences but there is no limit to the number of Relation Lookup actors you can use.

---

---
url: /knowledgebase/release-notes/release-notes-1.2/relational-modeller.md
---

# Relational modeller

We're excited to announce the latest addition to the Autologyx platform: Relational modeller! This feature helps you organize your data and identify relationships between key data points, streamlining your workflow and improving data organization.

With **Relational modeller**, establishing relationships between object classes is a breeze. It's an easy drag-and-drop tool that lets you define the parent class and add multiple children to it.

![Relational\_article.gif](/knowledgebase/images/img_10871122566941_1776895706.png)

## How it works

**Relational modeller** not only provides a visual display of these relationships, but is also the mechanism by which child object classes are made available to the parent object class.

This design pattern can represent either a **one-to-one** or **one-to-many** relationship.

When a relationship has been configured and saved in the relational modeller, child object classes can be added to the Create and edit view of the parent object class, giving the parent record access to the data held in related child records.

## Limits

With **Relational modeller**, you can create up to **5** root parent object classes, and each object class can have up to **5** child object classes.

The maximum number of parent/child levels for any relationship is also **5**, starting from the root parent (or top object class) down to the deepest descendent.

Take advantage of our newest feature today and enjoy a more efficient and organized platform. Don't wait: start using **Relational modeller** now!

---

---
url: /knowledgebase/system-configuration/relational-modeller.md
---
# Relational Modeller

**Browse the sections below:**

* [Creating The Relational Model](/knowledgebase/system-configuration/relational-modeller/creating-the-relational-model/)
* [Editing The Relational Model](/knowledgebase/system-configuration/relational-modeller/editing-the-relational-model/)
* [What Is The Relational Modeller](/knowledgebase/system-configuration/relational-modeller/what-is-the-relational-modeller/)
* [Who Can Create A Relational Model](/knowledgebase/system-configuration/relational-modeller/who-can-create-a-relational-model/)

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.5/relational-support-in-word-add-in.md
---

# Relational support in Word Add-in

We know you love creating document templates with our Catalyst Word Add-in, but sometimes you need more than just one object class to fill in the blanks. With the introduction of relational support in our Catalyst Word Add-in, we're bringing a new dimension to document generation.

**Why this matters**

We've made managing relational classes an absolute breeze, ensuring effortless connections and streamlined access to related data. Say goodbye to the limitations of working with data from a single object class. Relational support empowers you to incorporate data from related object classes, providing a comprehensive view of your business processes.

![Relational1\_article.gif](/knowledgebase/images/img_12574121422237_1776895682.png)

**How it helps**

By leveraging the power of the relational tree in the Word Add-in, you can optimize your document creation process. No more jumping between different templates or manually merging data from various sources.

With relational support, you can ensure that your documents are always up-to-date and accurate. By pulling data from related object classes, you eliminate the risk of using outdated or inconsistent information.

![Relational2\_article.gif](/knowledgebase/images/img_12574121422237_1776895683.png)

**What this enables**

Relational support opens up a world of creativity and customization. From complex legal agreements to comprehensive client reports, you can now create templates that capture the full breadth of your business relationships.

So, whether you're a law firm looking to streamline your contract creation process or a business aiming to enhance your document workflows, the relational support in Catalyst Word Add-in is your secret weapon.

Are you ready to rewrite the story of your document management? Don't miss out on the benefits of relational support in Word Add-in, transforming how you work with related classes!

---

---
url: /knowledgebase/release-notes/release-notes-1.10.md
---
# Release Notes 1.10

**Browse the sections below:**

* [Analytics Database](/knowledgebase/release-notes/release-notes-1.10/analytics-database/)
* [Api For Groups In Record Permission Sets](/knowledgebase/release-notes/release-notes-1.10/api-for-groups-in-record-permission-sets/)
* [Bug Fixes And Improvements](/knowledgebase/release-notes/release-notes-1.10/bug-fixes-and-improvements/)
* [Groups As Task Assignees](/knowledgebase/release-notes/release-notes-1.10/groups-as-task-assignees/)
* [Groups In Class Permission Sets](/knowledgebase/release-notes/release-notes-1.10/groups-in-class-permission-sets/)
* [Groups In User Type Class Fields](/knowledgebase/release-notes/release-notes-1.10/groups-in-user-type-class-fields/)
* [Groups In User Type Fields](/knowledgebase/release-notes/release-notes-1.10/groups-in-user-type-fields/)
* [New Autologyx Catalyst 1.10 Release Notes](/knowledgebase/release-notes/release-notes-1.10/new-autologyx-catalyst-1.10-release-notes/)
* [Openai Embeddings Integration](/knowledgebase/release-notes/release-notes-1.10/openai-embeddings-integration/)
* [Openai Gpt Integration](/knowledgebase/release-notes/release-notes-1.10/openai-gpt-integration/)
* [Record Access Actor](/knowledgebase/release-notes/release-notes-1.10/record-access-actor/)
* [Users And Groups Visibility Control](/knowledgebase/release-notes/release-notes-1.10/users-and-groups-visibility-control/)

---

---
url: /knowledgebase/release-notes/release-notes-1.11.md
---
# Release Notes 1.11

**Browse the sections below:**

* [Aws Bedrock Integration](/knowledgebase/release-notes/release-notes-1.11/aws-bedrock-integration/)
* [Azure Openai Integration](/knowledgebase/release-notes/release-notes-1.11/azure-openai-integration/)
* [Bug Fixes And Improvements](/knowledgebase/release-notes/release-notes-1.11/bug-fixes-and-improvements/)
* [Delayed Account Activation](/knowledgebase/release-notes/release-notes-1.11/delayed-account-activation/)
* [Hierarchical Records Creation Endpoints](/knowledgebase/release-notes/release-notes-1.11/hierarchical-records-creation-endpoints/)
* [Microsoft Oauth In Outbound Mail Setup](/knowledgebase/release-notes/release-notes-1.11/microsoft-oauth-in-outbound-mail-setup/)
* [Multipart Data Support In Api Call Actor](/knowledgebase/release-notes/release-notes-1.11/multipart-data-support-in-api-call-actor/)
* [New Autologyx Catalyst 1.11 Release Notes](/knowledgebase/release-notes/release-notes-1.11/new-autologyx-catalyst-1.11-release-notes/)
* [Ropc Flow Authentication Objects](/knowledgebase/release-notes/release-notes-1.11/ropc-flow-authentication-objects/)
* [Websockets](/knowledgebase/release-notes/release-notes-1.11/websockets/)

---

---
url: /knowledgebase/release-notes/release-notes-1.12.md
---
# Release Notes 1.12

**Browse the sections below:**

* [New Autologyx Catalyst 1.12 Release Notes](/knowledgebase/release-notes/release-notes-1.12/new-autologyx-catalyst-1.12-release-notes/)

---

---
url: /knowledgebase/release-notes/release-notes-1.13.md
---
# Release Notes 1.13

**Browse the sections below:**

* [Authentication Object Changes](/knowledgebase/release-notes/release-notes-1.13/authentication-object-changes/)
* [Bug Fixes And Improvements](/knowledgebase/release-notes/release-notes-1.13/bug-fixes-and-improvements/)
* [Delete Option In Set Task Actor](/knowledgebase/release-notes/release-notes-1.13/delete-option-in-set-task-actor/)
* [Dynamic Document Assembly With .Docx Merge Fields](/knowledgebase/release-notes/release-notes-1.13/dynamic-document-assembly-with-.docx-merge-fields/)
* [File Upload Component](/knowledgebase/release-notes/release-notes-1.13/file-upload-component/)
* [How Do I Create A Test User Account](/knowledgebase/release-notes/release-notes-1.13/how-do-i-create-a-test-user-account/)
* [Imanage Integration](/knowledgebase/release-notes/release-notes-1.13/imanage-integration/)
* [Integrations](/knowledgebase/release-notes/release-notes-1.13/integrations/)
* [New Ai Models In Sequencer](/knowledgebase/release-notes/release-notes-1.13/new-ai-models-in-sequencer/)
* [New Autologyx Catalyst 1.13 Release Notes](/knowledgebase/release-notes/release-notes-1.13/new-autologyx-catalyst-1.13-release-notes/)
* [The Loop Actor](/knowledgebase/release-notes/release-notes-1.13/the-loop-actor/)

---

---
url: /knowledgebase/release-notes/release-notes-1.14.md
---
# Release Notes 1.14

**Browse the sections below:**

* [Authentication Security](/knowledgebase/release-notes/release-notes-1.14/authentication-security/)
* [Document Records Enhancements](/knowledgebase/release-notes/release-notes-1.14/document-records-enhancements/)
* [Error Handling Reliability](/knowledgebase/release-notes/release-notes-1.14/error-handling-reliability/)
* [New Autologyx Catalyst 1.14 Release Notes](/knowledgebase/release-notes/release-notes-1.14/new-autologyx-catalyst-1.14-release-notes/)
* [Real Time Workflow Improvements](/knowledgebase/release-notes/release-notes-1.14/real-time-workflow-improvements/)
* [User Experience Interface Improvements](/knowledgebase/release-notes/release-notes-1.14/user-experience-interface-improvements/)

---

---
url: /knowledgebase/release-notes/release-notes-1.15.md
---
# Release Notes 1.15 \[DRAFT]

**Browse the sections below:**

---

---
url: /knowledgebase/release-notes/release-notes-1.2.md
---
# Release Notes 1.2

**Browse the sections below:**

* [Bug Fixes And Improvements](/knowledgebase/release-notes/release-notes-1.2/bug-fixes-and-improvements/)
* [Click To Call On Autologyx](/knowledgebase/release-notes/release-notes-1.2/click-to-call-on-autologyx/)
* [Improved Breadcrumbs](/knowledgebase/release-notes/release-notes-1.2/improved-breadcrumbs/)
* [Improved Instructions Editor](/knowledgebase/release-notes/release-notes-1.2/improved-instructions-editor/)
* [Json Type Field](/knowledgebase/release-notes/release-notes-1.2/json-type-field/)
* [New Autologyx Catalyst 1.2 Release Notes](/knowledgebase/release-notes/release-notes-1.2/new-autologyx-catalyst-1.2-release-notes/)
* [Present Child Records](/knowledgebase/release-notes/release-notes-1.2/present-child-records/)
* [Relation Lookup](/knowledgebase/release-notes/release-notes-1.2/relation-lookup/)
* [Relational Modeller](/knowledgebase/release-notes/release-notes-1.2/relational-modeller/)
* [Sequence Runner](/knowledgebase/release-notes/release-notes-1.2/sequence-runner/)
* [Tasks For One   Time Completion Users](/knowledgebase/release-notes/release-notes-1.2/tasks-for-one---time-completion-users/)

---

---
url: /knowledgebase/release-notes/release-notes-1.3.md
---
# Release Notes 1.3

**Browse the sections below:**

* [Bug Fixes And Improvements](/knowledgebase/release-notes/release-notes-1.3/bug-fixes-and-improvements/)
* [Catalyst Word Add In](/knowledgebase/release-notes/release-notes-1.3/catalyst-word-add-in/)
* [New Autologyx Catalyst 1.3 Release Notes](/knowledgebase/release-notes/release-notes-1.3/new-autologyx-catalyst-1.3-release-notes/)
* [New Template Merge Fields](/knowledgebase/release-notes/release-notes-1.3/new-template-merge-fields/)
* [Sorting Records](/knowledgebase/release-notes/release-notes-1.3/sorting-records/)
* [User Type Field](/knowledgebase/release-notes/release-notes-1.3/user-type-field/)

---

---
url: /knowledgebase/release-notes/release-notes-1.5.md
---
# Release Notes 1.5

**Browse the sections below:**

* [Authentication Objects   Api Keys](/knowledgebase/release-notes/release-notes-1.5/authentication-objects---api-keys/)
* [Create Task Actor](/knowledgebase/release-notes/release-notes-1.5/create-task-actor/)
* [Documents In Sequencer](/knowledgebase/release-notes/release-notes-1.5/documents-in-sequencer/)
* [Elements](/knowledgebase/release-notes/release-notes-1.5/elements/)
* [New Autologyx Catalyst 1.5 Release Notes](/knowledgebase/release-notes/release-notes-1.5/new-autologyx-catalyst-1.5-release-notes/)
* [Relational Support In Word Add In](/knowledgebase/release-notes/release-notes-1.5/relational-support-in-word-add-in/)
* [Task Assignment Actor](/knowledgebase/release-notes/release-notes-1.5/task-assignment-actor/)
* [Templates Panel](/knowledgebase/release-notes/release-notes-1.5/templates-panel/)

---

---
url: /knowledgebase/release-notes/release-notes-1.6.md
---
# Release Notes 1.6

**Browse the sections below:**

* [Imanage Authentication Objects](/knowledgebase/release-notes/release-notes-1.6/imanage-authentication-objects/)
* [New Autologyx Catalyst 1.6 Release Notes](/knowledgebase/release-notes/release-notes-1.6/new-autologyx-catalyst-1.6-release-notes/)
* [Read Only Fields](/knowledgebase/release-notes/release-notes-1.6/read-only-fields/)
* [Redirect Url On Standalone Forms](/knowledgebase/release-notes/release-notes-1.6/redirect-url-on-standalone-forms/)
* [Sequencer File Download](/knowledgebase/release-notes/release-notes-1.6/sequencer-file-download/)
* [The New Type Of Variable – Json Type](/knowledgebase/release-notes/release-notes-1.6/the-new-type-of-variable-–-json-type/)
* [“Relationship Created” Trigger In Sequencer](/knowledgebase/release-notes/release-notes-1.6/“relationship-created”-trigger-in-sequencer/)

---

---
url: /knowledgebase/release-notes/release-notes-1.8.md
---
# Release Notes 1.8

**Browse the sections below:**

* [Bug Fixes And Improvements](/knowledgebase/release-notes/release-notes-1.8/bug-fixes-and-improvements/)
* [Database Views](/knowledgebase/release-notes/release-notes-1.8/database-views/)
* [Image Merge Fields](/knowledgebase/release-notes/release-notes-1.8/image-merge-fields/)
* [Imanage In Api Call Actor](/knowledgebase/release-notes/release-notes-1.8/imanage-in-api-call-actor/)
* [Microsoft Authentication Object](/knowledgebase/release-notes/release-notes-1.8/microsoft-authentication-object/)
* [New Autologyx Catalyst 1.8 Release Notes](/knowledgebase/release-notes/release-notes-1.8/new-autologyx-catalyst-1.8-release-notes/)
* [New User Account Types](/knowledgebase/release-notes/release-notes-1.8/new-user-account-types/)
* [User Group Permissions](/knowledgebase/release-notes/release-notes-1.8/user-group-permissions/)

---

---
url: /knowledgebase/release-notes/release-notes-1.9.md
---
# Release Notes 1.9

**Browse the sections below:**

* [Api For Delaying User Account Activation](/knowledgebase/release-notes/release-notes-1.9/api-for-delaying-user-account-activation/)
* [Authentication Objects](/knowledgebase/release-notes/release-notes-1.9/authentication-objects/)
* [Bug Fixes And Improvements](/knowledgebase/release-notes/release-notes-1.9/bug-fixes-and-improvements/)
* [New Autologyx Catalyst 1.9 Release Notes](/knowledgebase/release-notes/release-notes-1.9/new-autologyx-catalyst-1.9-release-notes/)
* [New Jinja Filters For Date And Time Manipulations](/knowledgebase/release-notes/release-notes-1.9/new-jinja-filters-for-date-and-time-manipulations/)
* [Viewer Panel](/knowledgebase/release-notes/release-notes-1.9/viewer-panel/)

---

---
url: >-
  /knowledgebase/system-configuration/task-templates/response-configuration---task-type---complete-self-contained-form.md
---

# Response Configuration - Task type - Complete self-contained form

The **Response configuration** tab provides the area in which the task is defined, eg what it consists of, how it will be presented to the User completing it, and how it will be created - the **Task creation mechanism**.

There are two Task types. The first, **Complete self contained form**, is highly versatile in that it lets you build a task which might consist of only one field, multiple fields or a very comprehensive form. If created using generic language, you will be able to use if to create Tasks for Records in more than one Object class.

This article takes you through the steps to create a simple claim form.

## Create a response form

On the **Response configuration** tab, you will see a section called **Response Form**. Here, click onto the **+ Create response form** button which will take you into the Form builder.

![mceclip0.png](/knowledgebase/images/img_4402900794897_1776895918.png)

![mceclip1.png](/knowledgebase/images/img_4402900794897_1776895918.png)

The Form builder is displayed with a section header. All other form components are in the layout panel on the right hand side.

Click on the section header. The right hand panel will now display the section properties.

**You can:**

* Give the section the correct name by amending the Label
* Choose whether to show the section header on the form. It's useful to be able to section parts of forms but not necessarily have a distinct division between the sections - in this case turn off the selector to **Show this section header**
* Select how many columns you require for this section
* Adjust the column ratios; the options will change dependent on the number of columns selected
* If appropriate, use the **Conditional Visibility** feature to control the display of sections. [**CLICK HERE**](/knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/using-conditional-logic-in-a-form/) for more information

![mceclip2.png](/knowledgebase/images/img_4402900794897_1776895919.png)

The example shown has **2 columns** at a ratio of **50:50**.

Click into the canvas below to start populating your columns.

Each component can be dragged and dropped into position. Clicking on each component will allow you to label it and define its properties.

### Field types and properties

**Single Select**

When using a **Single Select** field type you are able to have the options displayed as radio buttons or as a drop down list.

![mceclip3.png](/knowledgebase/images/img_4402900794897_1776895919.png)

Next, list the options as shown and select a default value if appropriate.

![mceclip4.png](/knowledgebase/images/img_4402900794897_1776895919.png)

**Date/Time Picker**

The **Date/Time Picker** field type allows you to choose an input of the date, time or date and time. You can also specify that the date must be in the future.

![mceclip5.png](/knowledgebase/images/img_4402900794897_1776895919.png)

**Textbox**

The **Textbox** field type allows you to select a single or multi line input.

![mceclip6.png](/knowledgebase/images/img_4402900794897_1776895920.png)

### Alias and labels

Irrespective of the field type being used, the alias will auto-populate from the label; this can of course be overriden if preferred. It is worth noting that the alias must be unique while the same label can be given to many fields.

[**CLICK HERE**](/knowledgebase/record-and-task-forms/formbuilder-components/task-form-fields-and-how-to-configure-them/) for more information on configuration of field types.

### Instruction component

The **Instruction** component can be dragged anywhere onto your form in order to provide advisory text for the User who is completing the form. You can use up to 5000 characters as shown.

![mceclip7.png](/knowledgebase/images/img_4402900794897_1776895920.png)

## Preview and save

The Form builder has a **Preview** so that you can check at any stage how your form will look when displayed to the User responsible for completing the task.

![mceclip9.png](/knowledgebase/images/img_4402900794897_1776895920.png)

![mceclip8.png](/knowledgebase/images/img_4402900794897_1776895920.png)

Use the **Exit preview** button to return to the Form builder.

|  |  |
| --- | --- |
| The **Cancel** button can be used to abort the creation of the form. If you have unsaved changes, the **Unsaved changes will be lost** warning will be displayed.  If you confirm **Yes**, you will be taken back to the **Response configuration**tab on the **Create task template** page.  If you select **x No, go back** the **Form builder** will remain open so that you can continue. | mceclip0.png  You will also see this warning if you navigate away from the page. |

The **Save** button is only enabled when you have unsaved changes. Ensure that you **Save** the form when you are happy with it. This will take you back to the **Response configuration** tab on the **Create task template** page. Here you can complete the configuration of the Task and Save it.

## Example uses

This task type can also be used to provide a statement to a User or to get them to sign a declaration. The example shown below (in Preview mode) is a statement about how data will be used.

The form has been constructed with two sections. In the first an **Instruction** component has been used to provide the statement. In the second the User is presented with a **Textbox** in which to "sign" their name and a **Date/Time Picker** so that they can select today's date when giving their consent.

![mceclip10.png](/knowledgebase/images/img_4402900794897_1776895921.png)

Your task may be much simpler. For example, the requirement may be for the person completing it to provide a document.

This can be done very simply with the use of a **File upload** field.

The example shown also includes a **Date/Time picker** with input type "Date (only)" so that the document expiry date can be given at the same time.

|  |  |
| --- | --- |
| mceclip11.png | mceclip12.png |

![mceclip13.png](/knowledgebase/images/img_4402900794897_1776895922.png)

## Availability in the Sequence designer

All Tasks of the type **Complete self-contained form** which have the **Task creation mechanism, Automatic** will be available in the Task Templates menu in the Sequence designer - for ALL Object classes.

These can be dragged and dropped onto the **Workflow** section as required.

|  |  |
| --- | --- |
| seq\_task\_3.jpg | seq\_task\_2.jpg |

|  |  |
| --- | --- |
| Tasks of this type which have the **Task creation mechanism, Manual** will be available for creation against any Record in any Object class from the Tasks tab in the side panel. | mceclip15.png |

---

---
url: >-
  /knowledgebase/system-configuration/task-templates/response-configuration---task-type---update-object-record.md
---

# Response configuration - Task type - Update object record

The **Response configuration** tab provides the area in which the task is defined, for example what it consists of, how it will be presented to the User completing it, and how it will be created - the **Task creation mechanism**.

In addition, for the **Task type, Update object record**, it is here that you must select the **Object class** for which you wish to use the Task template to create Tasks.

## Select the Object class

The **Object class** field is a single-select which will filter as you type into it.

![mceclip0.png](/knowledgebase/images/img_6408807349917_1776895923.png)

Having selected the required Object class, click the **+ Create response form** button which will take you into the Form builder.

![mceclip1.png](/knowledgebase/images/img_6408807349917_1776895924.png)

![mceclip2.png](/knowledgebase/images/img_6408807349917_1776895924.png)

## Build the response form

The Form builder is displayed with a section header. All other form components are in the layout panel on the right hand side.

Like the Task type, **Complete self-contained** form, the panel contains a section called **Fields**. These components can be used to create fields on the response form which have no relation to the Object class and its Records.

Most importantly, the panel contains a section called **Object Class Fields** under which you will have a ready-made component for each field that the chosen Object class contains.

To start building the form, click on the section header. The right hand panel will now display the section properties.

**You can:**

* Give the section the correct name by amending the Label
* Choose whether to show the section header on the form. It is useful to be able to section parts of forms but not necessarily have a distinct division between the sections - in this case turn off the selector to **Show this section header**
* Select how many columns you require for this section
* Adjust the column ratios; the options will change dependent on the number of columns selected
* If appropriate, use the **Conditional Visibility** feature to control the display of sections. [**CLICK HERE**](/knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/using-conditional-logic-in-a-form/) for more information

![mceclip3.png](/knowledgebase/images/img_6408807349917_1776895924.png)

The example shown has **3 columns** at a ratio of **33:33:33**.

Click into the canvas below to start populating your columns.

Each component can be dragged and dropped into position. Clicking on each component from the **Fields** section will allow you to label it and define its properties.

However, this Task type is primarily designed to allow a User to enter data which will be used to populate or amend the fields for that Record.

### Using Object class fields

When you drag and drop any of the Object class fields onto the canvas you will note:

* You cannot amend the **Field label, Alias, Type of field, Default value** if one has been defined, **Selection options** for Single and Multi select field types. These values appear in the **Field Summary** which is non-editable
* You can amend the **Input type** for Single and Multi select and Text field types
* You can make the field mandatory in the context of completing the form/task by enabling the **Required** selector

![mceclip4.png](/knowledgebase/images/img_6408807349917_1776895925.png)

### Instruction component

The **Instruction** component can be dragged anywhere onto your form in order to provide advisory text for the User who is completing the form. You can use up to **5000 characters** as shown.

|  |  |
| --- | --- |
| mceclip5.png | mceclip6.png |

### Preview and save

The Form builder has a **Preview** so that you can check at any stage how your form will look when displayed to the User responsible for completing the task.

![mceclip9.png](/knowledgebase/images/img_6408807349917_1776895925.png)

![mceclip7.png](/knowledgebase/images/img_6408807349917_1776895925.png)

Use the **Exit preview** button to return to the Formbuilder.

|  |  |
| --- | --- |
| The **Cancel** button can be used to abort the creation of the form. If you have unsaved changes, the **Unsaved changes will be lost** warning will be displayed.  If you confirm **Yes**, you will be taken back to the **Response configuration**tab on the **Create task template** page.  If you select **x No, go back** the **Form builder** will remain open so that you can continue. | mceclip0.png  You will also see this warning if you navigate away from the page. |

The **Save** button is only enabled when you have unsaved changes. Ensure that you **Save** the form when you are happy with it. This will take you back to the **Response configuration** tab on the **Create task template** page. Here you can complete the configuration of the Task and Save it.

## Availability in the Sequence designer

Task templates of the type **Update object record**, which have the **Task creation mechanism, Automatic** will be available in the Task Templates menu in the Sequence designer - ONLY for the Object class specified in the **Response configuration** tab of the Task template.

These can be dragged and dropped onto the **Workflow** section as required.

![seq\_task.jpg](/knowledgebase/images/img_6408807349917_1776895926.jpg)

|  |  |
| --- | --- |
| Tasks of this type which have the **Task creation mechanism, Manual** will be available for creation against any Record in the specified Object class from the Tasks tab in the side panel. | |
| mceclip9.png | mceclip8.png |

## What happens when the task is completed

When a User completes a Task of the Update object record type, the Record for which the task was created will immediately be updated in line with the User's response data.

## Useful info

1. If a Single or Multi select field has been defined in the Object class with numerous options, it is advisable to display this as a dropdown list rather than radio buttons otherwise the task page is unnecessarily elongated.

---

---
url: /api/catalyst/resources/roles.md
---
# Roles

ALX also supports commonly used roles system. Roles are simply groups (or sets) of permissions. Rather than assigning
each user a permission (access) for each endpoint, he is assigned to a role. It is common that a single user is assigned
to several roles. When the system needs to determine whether the given user has access to a specific endpoint, it simply
loops through the user’s roles. It suffices that one role grants the user access to the given endpoint.

Hence, system administrators first define system roles and then assign these roles to individual users. This document
explains technical details how this is implemented as well as the API for managing permissions.

### References

* [Task templates](/api/catalyst/resources/tasks/task-templates)

# Roles API

## GET /api/roles/

Retrieves the roles list.

### Permissions

Requires `authentication` and `roles.list` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/roles/
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key               | Type     | Notes                                         |
|-------------------|----------|-----------------------------------------------|
| id                | uuid     | 	                                             |
| name              | string   | 	                                             |
| description       | int      | 	                                             |
| created\_at        | datetime | 	                                             |
| created\_by        | user     | 	                                             |
| modified\_at       | datetime | 	                                             |
| modified\_by       | user     | 	                                             |
| \_meta.permissions | Object   | Dict describing permissions.                  |

### Response example

* Status `200 OK`
* Body

```json
{
    "limit": 100,
    "offset": 0,
    "filtered_count": 1,
    "total_count": 1,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": 15,
            "name": "Role 1",
            "description": "",
            "created_at": "2022-08-22T09:30:04.640178+02:00",
            "created_by": {
                "id": 2,
                "first_name": "John",
                "last_name": "Smith",
                "username": "j.smith@autologyx.com",
                "company_name": "Autologyx",
                "is_deleted": false,
                "account_type": "full"
            },
            "modified_at": "2022-08-22T09:45:49.582526+02:00",
            "modified_by": {
                "id": 2,
                "first_name": "John",
                "last_name": "Smith",
                "username": "j.smith@autologyx.com",
                "company_name": "Autologyx",
                "is_deleted": false,
                "account_type": "full"
            },
            "_meta": {
                "permissions": {
                    "list": true,
                    "view": true,
                    "create": true,
                    "edit": true,
                    "delete": true
                }
            }
        }
    ]
}
```

### Sorting

| Parameter       | Example                                               | Notes           |
|-----------------|-------------------------------------------------------|-----------------|
| id              | {build}/api/roles/?ordering=id                        | Ascending       |
| id              | {build}/api/roles/?ordering=-id                       | Descending (-)  |
| name            | {build}/api/roles/?ordering=-name                     | Ascending (-)   |
| name            | {build}/api/roles/?ordering=-name                     | Descending (-)  |
| created\_at      | {build}/api/roles/?ordering=created\_at                | Ascending       |
| created\_at      | {build}/api/roles/?ordering=-created\_at               | Descending (-)  |
| modified\_at     | {build}/api/roles/?ordering=modified\_at               | Ascending       |
| modified\_at     | {build}/api/roles/?ordering=-modified\_at              | Descending (-)  |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter    | Predicates        | Example                                                               |
|--------------|-------------------|-----------------------------------------------------------------------|
| id           | standard pk       | {build}/api/object-records/?id=1                                      |
| name         | standard string   | {build}/api/object-records/?name=Sample                               |
| created\_at   | standard datetime | {build}/api/object-records/?created\_at\_\_gte=2022-01-01                |
| created\_by   | standard set      | {build}/api/object-records/?created\_by\_\_in=123,234,345                |
| modified\_at  | standard datetime | {build}/api/object-records/?modified\_at\_\_range=2022-01-01,2022-01-31  |
| modified\_by  | standard set      | {build}/api/object-records/?modified\_by=123                           |

### Errors

| Error                                 | Response code    | Message                                                   |
|---------------------------------------|------------------|-----------------------------------------------------------|
| Requesting user is not authenticated  | 401 Unauthorized | "detail": "Authentication credentials were not provided." |

## POST /api/roles/

Create new role.

### Permissions

Requires `authentication` and `superadmin` permission.

### URL parameters

| Key                      | Type     | Notes                                                          |
|--------------------------|----------|----------------------------------------------------------------|
| name                     | string   | Max length 80                                                  |
| description              | string   | Max length 500                                                 |
| permissions              | Object   | [Available permissions](#available-permissions)      |

### Available permissions

| Resource                | `list` | `view` | `create` | `edit` | `delete` | `complete` |
|-------------------------|--------|--------|----------|--------|----------|------------|
| task\_templates          | +      | +      | +        | +      | +        |            |
| tasks                   | +      | +      |          | +      | +        | +          |
| users                   | +      | +      |          |        |          |            |
| standard\_authentication |        | +      |          | +      |          |            |
| object\_classes          | +      | +      | +        | +      | +        |            |
| authentication\_objects  | +      | +      | +        | +      | +        |            |
| company\_details         |        | +      |          |        |          |            |
| task\_group\_templates    | +      | +      | +        | +      | +        |            |
| roles                   | +      | +      |          |        |          |            |
| sequences               | +      | +      | +        | +      | +        |            |
| single\_sign\_on          | +      | +      | +        | +      | +        |            |
| user\_groups             |        |        | +        |        |          |            |
| message\_templates       | +      |        |          |        |          |            |
| object\_models           | +      | +      | +        | +      |          |            |

### Request example

* Headers

```
Request Method: POST
Location: /api/roles/
Authorization: JWT access_token
```

* Body

```json
{
  "name": "Sample Role",
  "description": "Sample description",
  "permissions": {
    "task_template": [
      "list",
      "create",
      "view",
      "edit",
      "delete"
    ]
  }
}
```

### Response

| Key                      | Type     | Notes                          |
|--------------------------|----------|--------------------------------|
| id                       | int      | 	                              |
| name                     | string   | 	                              |
| description              | int      | 	                              |
| num\_of\_users             | enum     | 	                              |
| permissions              | bool     | 	                              |
| created\_at               | datetime | 	                              |
| created\_by               | user     | 	                              |
| modified\_at              | datetime | 	                              |
| modified\_by              | user     | 	                              |
| \_meta.permissions        | Object   | Object describing permissions  |

### Response example

* Status `201 CREATED`
* Body

```json
{
  "id": 10,
  "name": "Sample Role",
  "description": "Sample description",
  "num_of_users": 0,
  "permissions": {
    "task_group": [
      "list",
      "create",
      "view",
      "edit",
      "delete"
    ]
  },
  "created_by": {
    "id": 1,
    "first_name": "John",
    "last_name": "Smith",
    "username": "j.smith@autologyx.com",
    "company_name": "Autologyx",
    "is_deleted": false
  },
  "modified_by": {
    "id": 1,
    "first_name": "John",
    "last_name": "Smith",
    "username": "j.smith@autologyx.com",
    "company_name": "Autologyx",
    "is_deleted": false
  },
  "created_at": "2020-05-06T10:21:30.751914Z",
  "modified_at": "2020-05-06T10:21:30.751914Z",
  "_meta": {
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "create": true,
      "delete": true
    }
  }
}
```

### Errors

| Error                                 | Response code    | Message                                                   |
|---------------------------------------|------------------|-----------------------------------------------------------|
| Requesting user is not authenticated  | 401 Unauthorized | "detail": "Authentication credentials were not provided." |

## GET /api/roles/`id`/

Retrieve the role.

### Permissions

Requires `authentication` and `roles.view` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/roles/1/
Authorization: JWT access_token
```

### Response

| Key                      | Type     | Notes                           |
|--------------------------|----------|---------------------------------|
| id                       | int      | 	                            |
| name                     | string   | 	                            |
| description              | int      | 	                            |
| num\_of\_users             | enum     | 	                            |
| permissions              | bool     | 	                            |
| created\_at               | datetime | 	                            |
| created\_by               | user     | 	                            |
| modified\_at              | datetime | 	                            |
| modified\_by              | user     | 	                            |
| \_meta.permissions        | Object   | Object describing permissions   |

### Response example

* Status `200 OK`
* Body

```json
{
  "id": 10,
  "name": "Sample Role",
  "description": "Sample description",
  "num_of_users": 0,
  "permissions": {
    "task_group": [
      "list",
      "create",
      "view",
      "edit",
      "delete"
    ]
  },
  "created_by": {
    "id": 1,
    "first_name": "John",
    "last_name": "Smith",
    "username": "j.smith@autologyx.com",
    "company_name": "Autologyx",
    "is_deleted": false
  },
  "modified_by": {
    "id": 1,
    "first_name": "John",
    "last_name": "Smith",
    "username": "j.smith@autologyx.com",
    "company_name": "Autologyx",
    "is_deleted": false
  },
  "created_at": "2020-05-06T10:21:30.751914Z",
  "modified_at": "2020-05-06T10:21:30.751914Z",
  "_meta": {
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "create": true,
      "delete": true
    }
  }
}
```

## PATCH /api/roles/`id`/

Update the role.

### Permissions

Requires `authentication` and `superadmin` permission.

### Allowed parameters

| Key                      | Type     | Notes                                                          |
|--------------------------|----------|----------------------------------------------------------------|
| name                     | string   | Max length 80                                                  |
| description              | string   | Max length 500                                                 |
| permissions              | Object   | [Available permissions](#available-permissions)      |

Any parameter not listed above are silently ignored if passed.

### Request example

* Headers

```
Request Method: PATCH
Location: /api/roles/1/
Authorization: JWT access_token
```

* Body

```json
{
  "name": "Sample Role",
  "description": "Sample description",
  "permissions": {
    "task_template": [
      "list",
      "create",
      "view",
      "edit",
      "delete"
    ]
  }
}
```

### Response

| Key                      | Type     | Notes                           |
|--------------------------|----------|---------------------------------|
| id                       | int      | 	                            |
| name                     | string   | 	                            |
| description              | int      | 	                            |
| num\_of\_users             | enum     | 	                            |
| permissions              | bool     | 	                            |
| created\_at               | datetime | 	                            |
| created\_by               | user     | 	                            |
| modified\_at              | datetime | 	                            |
| modified\_by              | user     | 	                            |
| \_meta.permissions        | Object   | Object describing permissions   |

### Response example

* Status `200 OK`
* Body

```json
{
  "id": 10,
  "name": "Sample Role",
  "description": "Sample description",
  "num_of_users": 0,
  "permissions": {
    "task_group": [
      "list",
      "create",
      "view",
      "edit",
      "delete"
    ]
  },
  "created_by": {
    "id": 1,
    "first_name": "John",
    "last_name": "Smith",
    "username": "j.smith@autologyx.com",
    "company_name": "Autologyx",
    "is_deleted": false
  },
  "modified_by": {
    "id": 1,
    "first_name": "John",
    "last_name": "Smith",
    "username": "j.smith@autologyx.com",
    "company_name": "Autologyx",
    "is_deleted": false
  },
  "created_at": "2020-05-06T10:21:30.751914Z",
  "modified_at": "2020-05-06T10:21:30.751914Z",
  "_meta": {
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "create": true,
      "delete": true
    }
  }
}
```

### Errors

| Error                                 | Response code    | Message                                                   |
|---------------------------------------|------------------|-----------------------------------------------------------|
| Requesting user is not authenticated  | 401 Unauthorized | "detail": "Authentication credentials were not provided." |

## OPTIONS /api/roles/

### Permissions

Requires authentication only.

### Request example

* Headers

```
Request Method: OPTIONS
Location: /api/roles/
```

### Response example

* Status `200 OK`
* Body

```json
{
  "list": {
    "columns": [
      {
        "alias": "id",
        "type": "int",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range"
        ],
        "sort_ok": true
      },
      {
        "alias": "name",
        "type": "string",
        "predicates": [
          "exact",
          "iexact",
          "contains",
          "icontains",
          "startswith",
          "istartswith",
          "endswith",
          "iendswith"
        ],
        "sort_ok": true
      },
      {
        "alias": "description",
        "type": "string",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "created_at",
        "type": "datetime",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range"
        ],
        "sort_ok": true
      },
      {
        "alias": "created_by",
        "type": "user",
        "predicates": [
          "exact",
          "in"
        ],
        "sort_ok": false,
        "autocomplete": "/api/users/autocomplete/?text__icontains="
      },
      {
        "alias": "modified_at",
        "type": "datetime",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range"
        ],
        "sort_ok": true
      },
      {
        "alias": "modified_by",
        "type": "user",
        "predicates": [
          "exact",
          "in"
        ],
        "sort_ok": false,
        "autocomplete": "/api/users/autocomplete/?text__icontains="
      }
    ]
  },
  "details": {
    "schema": [
      {
        "alias": "name",
        "type": "string",
        "required": true,
        "validators": [
          {
            "type": "max_length",
            "length": 80
          }
        ]
      },
      {
        "alias": "description",
        "type": "string",
        "required": false,
        "validators": [
          {
            "type": "max_length",
            "length": 500
          }
        ]
      },
      {
        "alias": "permissions",
        "type": "permissions",
        "required": false,
        "schema": [
          {
            "resource": "task_templates",
            "actions": [
              "list",
              "view",
              "create",
              "edit",
              "delete"
            ]
          },
          {
            "resource": "tasks",
            "actions": [
              "list",
              "view",
              "edit",
              "complete"
            ]
          },
          {
            "resource": "users",
            "actions": [
              "list",
              "view"
            ]
          },
          {
            "resource": "standard_authentication",
            "actions": [
              "view",
              "edit"
            ]
          },
          {
            "resource": "object_classes",
            "actions": [
              "list",
              "view",
              "create",
              "edit",
              "delete"
            ]
          },
          {
            "resource": "authentication_objects",
            "actions": [
              "list",
              "view",
              "create",
              "edit",
              "delete"
            ]
          },
          {
            "resource": "company_details",
            "actions": [
              "edit",
              "view"
            ]
          },
          {
            "resource": "task_group_templates",
            "actions": [
              "list",
              "view",
              "create",
              "edit"
            ]
          },
          {
            "resource": "roles",
            "actions": [
              "list",
              "view"
            ]
          },
          {
            "resource": "sequences",
            "actions": [
              "list",
              "view",
              "create",
              "edit",
              "delete"
            ]
          },
          {
            "resource": "single_sign_on",
            "actions": [
              "list",
              "view",
              "create",
              "edit",
              "delete"
            ]
          },
          {
            "resource": "user_groups",
            "actions": [
              "create"
            ]
          },
          {
            "resource": "message_templates",
            "actions": [
              "list"
            ]
          },
          {
            "resource": "object_models",
            "actions": [
              "list",
              "view",
              "create",
              "edit"
            ]
          }
        ]
      }
    ]
  },
  "restrictions": {
    "limit_items": 5000
  }
} 
```

---

---
url: /knowledgebase/administration/roles-and-permissions.md
---

# Roles and Permissions

Roles determine what Config Admin users can configure within Autologyx, while Permission Sets determine which records, tasks and other resources users can access.

This section explains how to create and manage Roles, how different permission models work together, and how changes to Roles affect users across the platform.

## Create and manage Roles

### Create a Role

Learn how to create a new Role and configure permissions for System Configuration and Administration.

* [How do I create a Role?](/knowledgebase/administration/roles-and-permissions/how-do-i-create-a-role/)

### Edit a Role

Understand what happens when Role permissions are changed and how those changes affect users immediately.

* [What happens if I edit a Role?](/knowledgebase/administration/roles-and-permissions/what-happens-if-i-edit-a-role/)

## Understanding permissions

### Overview of user permissions

See how Account Types, Roles, Object Class Permission Sets, Record Permission Sets and User Group Permission Sets work together to control access throughout the platform.

* [Overview of User Permissions](/knowledgebase/administration/roles-and-permissions/overview-of-user-permissions/)

### Why users need Roles

Learn when Roles should be used, what they control, and how they differ from Permission Sets.

* [Why do Users need Roles?](/knowledgebase/administration/roles-and-permissions/why-do-users-need-roles/)

## Things to remember

1. Roles are assigned only to Config Admin users.
2. Roles control access to Administration and System Configuration—they do not grant access to business records.
3. Access to records, tasks and Object Classes is managed separately using Permission Sets.
4. Users can have multiple Roles. Where permissions overlap, the most permissive permissions are applied.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.11/ropc-flow-authentication-objects.md
---

# ROPC flow Authentication Objects

In our ongoing efforts to expand integration capabilities, we are introducing a new **Generic ROPC (Resource Owner Password Credentials) flow** in Authentication Objects. This enhancement allows integration with any provider that supports ROPC, giving users greater flexibility in connecting their authentication processes with external systems.

## Generic ROPC flow

**ROPC flow** is a simple authentication method where users provide their credentials (username and password) directly to obtain an access token. This flow is particularly useful in scenarios where interactive login is not possible, such as system-to-system authentication or secure backend service connections.

With our new **Generic ROPC Authentication Object**, users can now configure authentication by providing only the essential parameters:

* **Token URL** – the endpoint where authentication requests are sent
* **Username** and **Password** – credentials for authentication

**Optional fields** allow for greater control and flexibility:

* **Refresh Token URL** – if the provider supports refresh tokens, this can be specified to maintain access without repeated logins
* **Client ID** and **Client Secret** – required by some providers for additional security
* **Scope** – defines the level of access granted by the token

![ROPC1\_article.gif](/knowledgebase/images/img_4703011774495_1776895612.png)

## Expiry Date feature

Beyond introducing ROPC, we are also enhancing all Authentication Objects with an **Expiry Date** feature. This ensures that secrets with expiration policies are managed proactively, preventing unexpected authentication failures.

Now, when setting up an Authentication Object, users can **set an expiry date** for credentials and specify which parameters it applies to (for example, client secrets). This feature allows for better oversight by enabling users to filter Authentication Objects by the expiry date, making it easier to track and renew credentials before they lapse.

Additionally, automated notifications can be configured via the Sequencer to send email reminders when expiration is approaching, ensuring uninterrupted access.

![ROPC2\_article.gif](/knowledgebase/images/img_4703011774495_1776895613.png)

## Summary

These updates streamline authentication configuration, making it easier to integrate with external providers while also improving security and credential management.

The new **Generic ROPC Authentication Object**, paired with our **Expiry Date** feature, gives you control over your authentication processes. You can now properly configure, monitor, and maintain your credentials with clear visibility into expiration timelines. Set up your automated notifications, stay ahead of credential renewals, and ensure your integrations remain secure and fully operational at all times.

---

---
url: /api/catalyst/resources/security-rules.md
---
# Security Rules

> Autologyx allows clients to configure security rules:
>
> * Password Complexity
> * Prevent password re-use
> * Password rotation interval
> * Activation link valid period

> **Password Complexity**
>
> Autologyx allows clients to configure their own password complexity rules. They do it by turning on/off rules supported by the system. The rules are used globally across the system:
>
> * Account activation.
> * Password reset.
> * Editing users.
>
> The rules must be enforced both in the backend (API endpoints) and in the frontend (GUI). This enforcement must be consistent.
> This document covers technical requirements and implementation details that ensure this consistency.

> **Prevent password re-use**
>
> It takes two states: True/False (on/off). When switched on then user cannot use password used by him before.

> **Password rotation interval**
>
> Specifies time period in days to force password change.

> **Activation link valid period**
>
> Specifies time period in days to expiry activation link (activation token).

## References

* [Security Rules Technical Dock](https://autologyx.sharepoint.com/:w:/s/Dev/EUnFd_2VL8ZOvHKVzOQZ5BcBIhhWCPDinZFtPjIhilmGyA?e=ChwfaC)

## GET /api/security/

Returns security rules.

### Permissions

Requires `authentication` and `standard_authentication.list` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> GET /api/security/

```json
```

### Response

| Key                   | Type   | Notes        |
|-----------------------|--------|--------------|
| password\_complexity   | Object |              |
| systemconf            | Object |              |
| authentication\_method | Object |              |
| \_meta                 | Object |              |

#### Response `password_complexity` object

| Key                 | Type     | Notes      |
|---------------------|----------|------------|
| max\_repeating\_chars | int      |            |
| min\_letters         | int      |            |
| min\_numbers         | int      |            |
| min\_symbols         | int      |            |
| min\_lower\_case      | int      |            |
| min\_upper\_case      | int      |            |
| min\_length          | int      |            |

#### Response `systemconf` object

| Key                          | Type | Notes |
|------------------------------|------|-------|
| password\_prevent\_reuse       | bool |       |
| password\_rotation\_interval   | int  |       |
| activation\_link\_valid\_period | int  |       |

#### Response `authentication_method` object

| Key          | Type  | Notes |
|--------------|-------|-------|
| internal     | enum  | available values: any, password, sso |
| external     | enum  |       |
| full         | enum  |       |
| super\_admin  | enum  |       |

* Successful status `200 OK`
* Response body schema

```json
{
  "password_complexity": {
    "max_repeating_chars": 0,
    "min_letters": 2,
    "min_numbers": 1,
    "min_symbols": 0,
    "min_lower_case": 1,
    "min_upper_case": 1,
    "min_length": 8
  },
  "systemconf": {
    "password_prevent_reuse": true,
    "password_rotation_interval": 90,
    "activation_link_valid_period": 7
  },
  "authentication_method": {
    "internal": "any",
    "external": "sso",
    "full": "password",
    "super_admin": "password"
  },
  "_meta": {
    "permissions": {
      "view": true,
      "edit": true
    }
  }
}
```

## PATCH /api/security/

Updates security rules.

### Permissions

Requires `authentication` and `standard_authentication.edit` permission.

### Request

* Body parameters

| Key                   | Type   | Notes        |
|-----------------------|--------|--------------|
| password\_complexity   | Object |              |
| systemconf            | Object |              |
| authentication\_method | Object |              |

#### Request `password_complexity` object

| Key                 | Type     | Notes      |
|---------------------|----------|------------|
| max\_repeating\_chars | int      |            |
| min\_letters         | int      |            |
| min\_numbers         | int      |            |
| min\_symbols         | int      |            |
| min\_lower\_case      | int      |            |
| min\_upper\_case      | int      |            |
| min\_length          | int      |            |

#### Request `systemconf` object

| Key                          | Type | Notes |
|------------------------------|------|-------|
| password\_prevent\_reuse       | bool |       |
| password\_rotation\_interval   | int  |       |
| activation\_link\_valid\_period | int  |       |

#### Request `authentication_method` object

| Key               | Type  | Notes                                |
|-------------------|-------|--------------------------------------|
| internal          | enum  | available values: any, password, sso |
| external          | enum  |                                      |
| service\_internal  | enum  |                                      |
| service\_external  | enum  |                                      |
| full              | enum  |                                      |
| super\_admin       | enum  |                                      |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> PATCH /api/security/

```json
{ 
    "password_complexity": { 
       "max_repeating_chars": 0, 
       "min_letters": 2, 
       "min_numbers": 1, 
       "min_symbols": 0, 
       "min_lower_case": 1, 
       "min_upper_case": 1, 
       "min_length": 8 
    }, 
    "systemconf": { 
       "password_prevent_reuse": true, 
       "password_rotation_interval": 90, 
       "activation_link_valid_period": 7
    },
    "authentication_method": { 
        "internal": "any", 
        "external": "sso", 
        "full": "password", 
        "super_admin": "password" 
    }
} 
```

### Validations

* password\_complexity
  * max\_repeating\_chars
    * min 0, max 128
  * min\_letters
    * min 0, max 128
  * min\_numbers
    * min 0, max 128
  * min\_symbols
    * min 0, max 128
  * min\_lower\_case
    * min 0, max 128
  * min\_upper\_case
    * min 0, max 128
  * min\_length
    * min 0, max 128
* systemconf
  * password\_rotation\_interval
    * min 0, max 32767
  * activation\_link\_valid\_period
    * min 0, max 32767
* authentication\_method
  * Valid enum value for method: any, password, sso
  * Null value is not allowed
  * Proper dictionary structure is required
  * Authentication\_method for `service_external` and `service_internal` account type cannot be modified

### Response

| Key                   | Type   | Notes        |
|-----------------------|--------|--------------|
| password\_complexity   | Object |              |
| systemconf            | Object |              |
| authentication\_method | Object |              |

#### Response `password_complexity` object

| Key                 | Type     | Notes      |
|---------------------|----------|------------|
| max\_repeating\_chars | int      |            |
| min\_letters         | int      |            |
| min\_numbers         | int      |            |
| min\_symbols         | int      |            |
| min\_lower\_case      | int      |            |
| min\_upper\_case      | int      |            |
| min\_length          | int      |            |

#### Response `systemconf` object

| Key                          | Type | Notes |
|------------------------------|------|-------|
| password\_prevent\_reuse       | bool |       |
| password\_rotation\_interval   | int  |       |
| activation\_link\_valid\_period | int  |       |

#### Response `authentication_method` object

| Key                | Type  | Notes |
|--------------------|-------|-------|
| internal           | enum  |       |
| external           | enum  |       |
| service\_internal   | enum  |       |
| service\_external   | enum  |       |
| full               | enum  |       |
| super\_admin        | enum  |       |

* Successful status `200 OK`
* Response body schema:

```json
{ 
    "password_complexity": { 
       "max_repeating_chars": 0, 
       "min_letters": 2, 
       "min_numbers": 1, 
       "min_symbols": 0, 
       "min_lower_case": 1, 
       "min_upper_case": 1, 
       "min_length": 8 
    }, 
    "systemconf": { 
       "password_prevent_reuse": true, 
       "password_rotation_interval": 90, 
       "activation_link_valid_period": 7
    },
    "authentication_method": { 
        "internal": "any", 
        "external": "sso", 
        "service_internal": "any", 
        "service_external": "any", 
        "full": "password", 
        "super_admin": "password" 
    },
    "_meta": {
        "permissions": {
            "view": true,
            "edit": true
        }
    }
}
```

### Errors

Please check for [Standard Errors](/api/standards/#patch-standards).

## OPTIONS /api/security/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> OPTIONS /api/security/

```json
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "details": {
        "schema": [
            {
                "alias": "password_complexity",
                "schema": [
                    {
                        "alias": "max_repeating_chars",
                        "type": "int",
                        "required": false,
                        "validators": [
                            {
                                "type": "min_value",
                                "value": 0
                            }
                        ]
                    },
                    {
                        "alias": "min_letters",
                        "type": "int",
                        "required": false,
                        "validators": [
                            {
                                "type": "min_value",
                                "value": 0
                            }
                        ]
                    },
                    {
                        "alias": "min_numbers",
                        "type": "int",
                        "required": false,
                        "validators": [
                            {
                                "type": "min_value",
                                "value": 0
                            }
                        ]
                    },
                    {
                        "alias": "min_symbols",
                        "type": "int",
                        "required": false,
                        "validators": [
                            {
                                "type": "min_value",
                                "value": 0
                            }
                        ]
                    },
                    {
                        "alias": "min_lower_case",
                        "type": "int",
                        "required": false,
                        "validators": [
                            {
                                "type": "min_value",
                                "value": 0
                            }
                        ]
                    },
                    {
                        "alias": "min_upper_case",
                        "type": "int",
                        "required": false,
                        "validators": [
                            {
                                "type": "min_value",
                                "value": 0
                            }
                        ]
                    },
                    {
                        "alias": "min_length",
                        "type": "int",
                        "required": false,
                        "validators": [
                            {
                                "type": "min_value",
                                "value": 0
                            }
                        ]
                    }
                ]
            },
            {
                "alias": "systemconf",
                "schema": [
                    {
                        "alias": "password_prevent_reuse",
                        "type": "bool",
                        "required": false
                    },
                    {
                        "alias": "password_rotation_interval",
                        "type": "int",
                        "required": false,
                        "validators": [
                            {
                                "type": "min_value",
                                "value": 0
                            },
                            {
                                "type": "max_value",
                                "value": 32767
                            }
                        ]
                    },
                    {
                        "alias": "activation_link_valid_period",
                        "type": "int",
                        "required": false,
                        "validators": [
                            {
                                "type": "min_value",
                                "value": 0
                            }
                        ]
                    }
                ]
            },
            {
                "alias": "authentication_method",
                "schema": [
                    {
                        "alias": "internal",
                        "type": "enum",
                        "required": false,
                        "values": [
                            {
                                "value": "any",
                                "text": "Any"
                            },
                            {
                                "value": "password",
                                "text": "Password"
                            },
                            {
                                "value": "sso",
                                "text": "Single Sign-On"
                            }
                        ]
                    },
                    {
                        "alias": "external",
                        "type": "enum",
                        "required": false,
                        "values": [
                            {
                                "value": "any",
                                "text": "Any"
                            },
                            {
                                "value": "password",
                                "text": "Password"
                            },
                            {
                                "value": "sso",
                                "text": "Single Sign-On"
                            }
                        ]
                    },
                    {
                        "alias": "full",
                        "type": "enum",
                        "required": false,
                        "values": [
                            {
                                "value": "any",
                                "text": "Any"
                            },
                            {
                                "value": "password",
                                "text": "Password"
                            },
                            {
                                "value": "sso",
                                "text": "Single Sign-On"
                            }
                        ]
                    },
                    {
                        "alias": "super_admin",
                        "type": "enum",
                        "required": false,
                        "values": [
                            {
                                "value": "any",
                                "text": "Any"
                            },
                            {
                                "value": "password",
                                "text": "Password"
                            },
                            {
                                "value": "sso",
                                "text": "Single Sign-On"
                            }
                        ]
                    }
                ]
            }
        ]
    }
}
```

## GET /api/security/

Returns security rules for password complexity.

### Permissions

Allowed for any one - public access.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> GET /api/security/

```json
```

#### Response

| Key                 | Type     | Notes      |
|---------------------|----------|------------|
| max\_repeating\_chars | int      |            |
| min\_letters         | int      |            |
| min\_numbers         | int      |            |
| min\_symbols         | int      |            |
| min\_lower\_case      | int      |            |
| min\_upper\_case      | int      |            |
| min\_length          | int      |            |

* Successful status `200 OK`
* Response body schema

```json
{
     "max_repeating_chars": 0, 
     "min_letters": 2, 
     "min_numbers": 1, 
     "min_symbols": 0, 
     "min_lower_case": 1, 
     "min_upper_case": 1, 
     "min_length": 8
}
```

---

---
url: /knowledgebase/system-configuration/sequence-actors/send-message-actor.md
---

# Send Message Actor

## What does the Send Message actor do?

The Send Message actor can be used in a sequence to automatically send emails.

Messaging is an important part of any process to ensure that those involved are kept up to date, told when things need to be done, and are provided with relevant information when appropriate.

The Send Message actor can be configured to send bespoke emails at any point during the workflow.

**The resulting email can be sent to one or a combination of the following:**

* the record creator
* the record owner
* individual users
* user groups containing one or more users
* specified email addresses of people who do not have to be system users
* email addresses stored in fields on records

## How do I use the Send Message actor?

**Add the actor to your sequence**

Drag and drop the Send Message actor onto your sequence.

Right click on the actor and select **Configure**.

**Configure recipients and message content**

Add the required recipients.

Note that you can add CC and BCC recipients if required.

Add your subject heading and text to the Message area.

Right click in the Subject and/or Message area to insert merged information from record fields, Constants and Variables.

![](../../../images2/zendesk_5277186456351_001_492ffa792c6a.png)

The editor will allow you to use formatting such as indenting, bold and bullets. Links can be added, images can be uploaded, and tables included in the Message body.

If the Send Message actor follows a document picker, you have the option to include the document as an attachment in the email.

![](../../../images2/zendesk_5277186456351_002_03421583f002.png)

**Test the actor**

To test the actor, find a record ID in the object class for which the sequence is being created; enter the record ID under the Message area.

![](../../../images2/zendesk_5277186456351_003_18f6c6eedd2d.png)

Click **Test Email**.

You will see a confirmation that the test message has been sent to your inbox. However, please be aware that the test message will not arrive in your inbox if either there is a syntax error or merge field error in the configuration eg missing curly brackets, missing endifs, etc OR your Outbound mail setup is not correctly configured.

![](../../../images2/zendesk_5277186456351_004_e295a42e8047.png)

The test email will allow you to check that merge fields and any links you have included are working correctly.

![](../../../images2/zendesk_5277186456351_005_8b307957c316.png)

**Save your changes**

Remember to save the email actor configuration and also save your sequence.

---

---
url: /knowledgebase/system-configuration/sequence-actors.md
---
# Sequence Actors

**Browse the sections below:**

* [Create Task Actor](/knowledgebase/system-configuration/sequence-actors/create-task-actor/)
* [Docauto Actor](/knowledgebase/system-configuration/sequence-actors/docauto-actor/)
* [Document Picker Actor](/knowledgebase/system-configuration/sequence-actors/document-picker-actor/)
* [Invalid Actors And Best Practice](/knowledgebase/system-configuration/sequence-actors/invalid-actors-and-best-practice/)
* [Record Access Actor](/knowledgebase/system-configuration/sequence-actors/record-access-actor/)
* [Relation Lookup Actor](/knowledgebase/system-configuration/sequence-actors/relation-lookup-actor/)
* [Send Message Actor](/knowledgebase/system-configuration/sequence-actors/send-message-actor/)
* [Sequence Runner Actor](/knowledgebase/system-configuration/sequence-actors/sequence-runner-actor/)
* [Set Task Actor](/knowledgebase/system-configuration/sequence-actors/set-task-actor/)
* [Task Assignment Actor](/knowledgebase/system-configuration/sequence-actors/task-assignment-actor/)
* [Update Record Actor](/knowledgebase/system-configuration/sequence-actors/update-record-actor/)

---

---
url: /knowledgebase/release-notes/release-notes-1.2/sequence-runner.md
---

# Sequence Runner

At Autologyx, we're constantly pushing the boundaries of automation, and this time we are introducing our latest addition - the Sequence Runner. Prepare to take control of your automation workflows like never before as we empower you with expanded configuration options.

## Capabilities

**Flexible configuration**

But that's just the beginning of what the Sequence Runner can do. With its remarkable versatility, you can configure this actor not only for the current record but also for records obtained through the Relation Lookup. When combined with the Relation Lookup actor, you can run a sequence in the selected parent or child object class, unlocking a whole new level of automation potential.

Furthermore, the Sequence Runner can also function independently, effortlessly running sequences against the same object class.

![Sequence\_runner\_article.gif](/knowledgebase/images/img_11182132487581_1776895697.png)

## Trigger configuration

**Custom trigger options**

The Sequence Runner opens up a world of possibilities, allowing you to seamlessly trigger sequences based on specific conditions. Whether it's upon completion of a connected actor or at a designated milestone, you now have the ability to fine-tune your automation to match your unique requirements.

**Available trigger parameters** include records, fields, tasks, task groups, and variables. With granular control at your fingertips, you can orchestrate complex automation flows with ease.

Embrace the power of customised triggers, unveiling limitless possibilities in workflow optimisation and experiencing the effortless flow of sequences as you take control of your automation processes.

---

---
url: /knowledgebase/system-configuration/sequence-actors/sequence-runner-actor.md
---

# Sequence runner actor

**What does the Sequence Runner actor do?**

The Sequence Runner actor allows one sequence to be started from another one.

Although the **Sequence Runner** actor will quite often be used together with the Relation Lookup actor so that an action such as assigning a task or updating a field may be carried out against the parent or child records which the Relation Lookup has identified, ([view the guide](/knowledgebase/system-configuration/sequences-for-relational-records/a-guide-to-using-the-relation-lookup-and-sequence-runner-actors-together/)), there are many occasions when it will be used alone.

The Sequence Runner can be used at any point in a sequence to run another sequence for a sub-process against the same object class. This allows you to keep sequences from getting overly large and therefore difficult to maintain.

**How do I use the Sequence Runner actor?**

Click, drag and drop the Sequence Runner actor onto your sequence workspace at the point where it is appropriate to start another workflow or sub-process.

Right click on the Sequence Runner actor and select Configure. The Sequence Runner Configuration window will open.

![Screenshot 2026-04-15 at 12.19.12.png](../../../images2/zendesk_16724910937245_001_8d21bc701f1d.png)

## Without a Relation Lookup actor

When used **without a Relation Lookup actor**, the Record field will contain only one option ie **Self**.

This means that only sequences for the same object class will be shown in the Sequence selection field AND you will only see sequences which have a starting trigger of "When sequence activated".

Select the required sequence and save the config.

![Screenshot 2026-04-15 at 12.24.59.png](../../../images2/zendesk_16724910937245_002_434531853345.png)

**Important:** remember to label the starting trigger of the sequence being activated to state which sequence is starting it.

## With a Relation Lookup actor

When used **with a Relation Lookup actor**, the Record field will contain another option, **From Relation lookup**.

![Screenshot 2026-04-15 at 16.30.26.png](../../../images2/zendesk_16724910937245_003_dcf14a1ecf8c.png)

In this case, the Relation Lookup is looking for children of the sequence object class in an object class called "Lender". The Sequence Runner actor will display any sequences for that child object class which can be activated ie they contain a starting trigger of "When sequence activated".

This Sequence Runner will trigger the sequence for all the children that match the relation lookup conditions.

## Naming and description

As with all sequence actors, it is best practice to label Sequence Runner actors with meaningful names that reflect their purpose. Particularly with Sequence Runners, it is a good idea to indicate the ID and Name of the sequence they are starting.

Right click on the Sequence Runner actor and select Properties.

Enter in the Name field the ID and Name of the sequence which will be run.

The Description field provides more space where additional information can be stored if needed.

![Screenshot 2026-04-15 at 10.44.13.png](../../../images2/zendesk_16724910937245_004_09ae085cf455.png)

|  |  |
| --- | --- |
| Save the Properties so that they replace the default actor name and clearly indicate what the sequence Runner is doing. | Screenshot 2026-04-15 at 10.45.49.png |

## Example use cases

There are two Sequence Runners in the below screenshot - see the pink actors.

![Screenshot\_2023-05-31\_at\_19.36.02.png](../../../images2/zendesk_16724910937245_006_b15239475d2a.png)

The preceding Trigger will determine whether a Sequence Runner is triggered for any particular record in this execution of the Sequence. By adding Trigger Conditions, you can determine whether this Sequence Runner should apply to all records that reach this point in the Sequence, or to a subset.

A Sequence Runner could be used to activate sequences by subject matter. For example, you could have a starting sequence for intake of a number of different types of matters or claims in which would be included your KYC tasks. You could then use the Sequence Runner to commence different processes for Real Estate, Commercial, Employment and other types of case.

Alternatively, your use case may be to do with the additional legal compliance required when operating in different countries, or screening compliance for working in different sectors - this type of sub-process could be triggered from your main sequence once the common core checks have been completed.

The following example shows how you might use one sequence for all escalation tasks relating to Mortgage Applications. If these tasks are all escalated to one user or a group of users, you can make them the default task assignee(s) when creating the sequence to be activated from the main one.

The above screenshot shows the first few steps of the main sequence. You can see that once data consent has been given in the "GDPR Agreement" task, there are two further tasks:

* Review application - intake
* Check affordability

Both of these tasks require the task owner to make a decision as to whether this part of the mortgage application can be approved, or if it should be rejected or escalated.

The task template for the Affordability Check is shown below.

![Screenshot\_2023-05-31\_at\_16.06.46.png](../../../images2/zendesk_16724910937245_007_abd436590647.png)

Each of the 3 outcomes has a very distinct route in the process:

|  |  |
| --- | --- |
| **The applicant meets the affordability criteria** - the Application Status is updated to "Affordability passed" and the next task called "Primary terms" is created for the record. | ![Screenshot\_2023-05-31\_at\_16.41.21.png](../../../images2/zendesk_16724910937245_008_44e8ce2e30c7.png) |
| **The applicant DOES NOT meet the affordability criteria** - when this option is chosen in the task form a new field is presented where the user can enter the reason for this decision.  This input is merged into an email to the applicant(s) informing them of their failure to meet the criteria.  The application status is updated to "Application rejected".  The process would stop at this point. | ![Screenshot\_2023-05-31\_at\_16.43.16.png](../../../images2/zendesk_16724910937245_009_69bba39ca0fe.png)  ![Screenshot\_2023-05-31\_at\_16.49.39.png](../../../images2/zendesk_16724910937245_010_1f8feba93476.png) |

**Escalate** - this is where the Sequence Runner is used.

The first screenshot shows that the application status is updated to "Escalate affordability".

![Screenshot\_2023-05-31\_at\_16.52.49.png](../../../images2/zendesk_16724910937245_011_76aeeeab28f4.png)

Following this, the Sequence Runner has been configured so that it is looking at "Self" records which means records in the same object class as the current sequence is running against, in this case, Mortgage Applications.

![Screenshot\_2023-05-31\_at\_17.01.22.png](../../../images2/zendesk_16724910937245_012_e850849f6018.png)

The sequence which the actor will run is one called "Escalations".

The below screenshot shows the part of this sequence which relates to the escalation at the affordability check in the starting sequence.

The trigger configuration is set to "When Sequence Activated". However, because this sequence is activated for more than one type of escalation, there is a supplementary condition which is looking for records where the field "Affordability check outcome" is equal to Escalate.

![Screenshot\_2023-05-31\_at\_19.15.53.png](../../../images2/zendesk_16724910937245_013_d74f35fa36a2.png)

If a record matches this condition, a task called "Affordability Check - escalation" will be assigned. This check has two possible outcomes:

**Affordability failed** - the application status is updated to "Application rejected"; an email is sent to the applicant(s) to let them know of their failure to meet the criteria. The process would stop at this point.

**Affordability approved** - the application status is updated to "Affordability passed". An email is sent to all record owners to advise them of this outcome.

Going back to the starting sequence, because the task "Affordability Check - escalation" was of the "Update object record" type, the field where the outcome was recorded can be used to rejoin the main process at the appropriate next stage.

The sequence trigger is "When Record Updated" with a supplementary condition using the field which was updated in the escalation task. Following this update, the "Primary terms" task is created for the record.

![Screenshot\_2023-05-31\_at\_19.40.13.png](../../../images2/zendesk_16724910937245_014_d9ab2e9db037.png)

The process will continue through the main sequence workflow.

## Useful info

1. There is no limit to the number of sequence runners you can use in any one sequence or any one instance of Catalyst.
2. A Sequence Runner is a terminal actor (it cannot be used to trigger any later actor).
3. Only a single actor can trigger a single Sequence Runner. If you have two branches in the sequence that could trigger the same sequence and have no shared final actor in those branches, you will need to duplicate the Sequence Runner actor once for each actor that could trigger it.

---

---
url: /knowledgebase/release-notes/release-notes-1.6/sequencer-file-download.md
---

# Sequencer file download

Navigating the ever-evolving landscape of workflow automation demands seamless integration of documents from a multitude of sources. To meet this challenge, our enhanced API Call actor steps forward, equipped with a new feature. This upgrade empowers you to effortlessly integrate documents from different origins directly into your workflows, ensuring a smooth flow of information and boosting productivity.

## **Configuration**

When configuring our API Call actor, specify the source from which you wish to retrieve files, choose your preferred authentication method, and leave the rest to us. The selected document will be securely stored and ready for further use in Sequencer.

![Filedownload1\_article.gif](../../../images2/zendesk_14581377365021_001_391443084bea.gif)

## **Using the saved document**

Once your document is securely saved, the Document Picker actor comes into play, acting as your versatile bridge to other actors.

Pair it with the Update Record actor to store the document in a specific field, collaborate on it by sending it through the Send Message Actors, or pass it along using another API Call actor.

![Filedownload2\_article.gif](../../../images2/zendesk_14581377365021_002_440f73d1bfe2.gif)

## **Why this matters**

In a world where data flow defines efficiency, our enhanced API Call actor ensures your workflow remains uninterrupted. Whether you're collaborating on crucial legal documents, managing intricate project files, or sharing vital information across teams, this feature simplifies the process, allowing you to focus on what truly matters: your work.

Retrieving client documents, modifying contracts, or initiating approval workflows are all seamlessly integrated into your thoughtfully designed sequences. The synergy between actors opens doors to outstanding automation, transforming your tasks from arduous to effortless.

It's not just automation; it's a transformation in how you approach document integration within your workflows.

---

---
url: /api/monitoring-and-infrastructure/catalyst/sequences.md
---
# Sequences

This technical design describes implementation and API for Sequences.

# API

::: danger Important
For security reasons, we should ensure that not supported generic endpoints cannot be accessed – they are not working.
:::

## POST /api/sequences/

Creates sequence.

### Permissions

Requires `authentication` and `sequence.create` permission.

### Request

* Headers

```
Request Method: POST
Content-Type: application/json
Location: /api/sequences/
Authorization: JWT access_token
```

* Body

| Key           | Type     | Required | Notes           |
|---------------|----------|----------|-----------------|
| name          | string   | true     |                 |
| description   | string   | false    |                 |
| object\_class  | int      | true     |                 |

#### Validations

* name
  * This field is required.
  * This field must be unique.
  * Ensure this field has no more than 100 characters.
* description
  * Ensure this field has no more than 500 characters.
* object\_class
  * This field is required.
  * Invalid pk "99900" - object does not exist.
  * Not owned by user.

### Sample request body

```json
{
    "name": "SEQ 1,
    "description": "Sample description",
    "object_class": 1
}
```

### Response

| Key               | Type     | Notes                                    |
|-------------------|----------|------------------------------------------|
| id                | int      | Automatically generated by the backend.  |
| name              | string   |                                          |
| description       | string   |                                          |
| object\_class      | int      |                                          |
| state             | string   |                                          |
| is\_debug\_enabled  | boolean  |                                          |
| created\_at        | datetime |                                          |
| created\_by        | user     |                                          |
| modified\_at       | datetime |                                          |
| modified\_by       | user     |                                          |
| \_meta.labels      | Object   | Object containing labels for attributes. |
| \_meta.permissions | Object   | Object describing permissions.           |

* Successful status `201 Created`
* Response body schema

```json
{
    "id": <int>,
    "name": <string>,
    "description": <string>,
    "object_class": <int>,
    "state": <string>,
    "is_debug_enabled": <bool>,
    "created_at": <datetime>,
    "created_by": <user,
    "modified_at": <datetime>,
    "modified_by": <user>,
    "_meta": {
        "labels": {
            "object_class": <string>,
            "state": <string>
        },
        "permissions": {
            "list": <bool>,
            "view": <bool>,
            "create": <bool>,
            "edit": <bool>,
            "delete": <bool>,
            "run": <bool>,
            "design": <bool>
        }
    }
}
```

### Errors

| Cause                                            | Response code    | Message                                                               |
|--------------------------------------------------|------------------|-----------------------------------------------------------------------|
| "name" is missing                                | 400 Bad Request  | "name": \["This field is required."]                                   |
| "name" is not unique                             | 400 Bad Request  | "name": \["This field must be unique."]                                |
| "description" is too long                        | 400 Bad Request  | "description": \["Ensure this field has no more than 500 characters."] |
| "object\_class" is required                       | 400 Bad Request  | "object\_class": \["This field is required."]                           |
| "object\_class" doesn't exists                    | 400 Bad Request  | "object\_class": \["Invalid pk "99900" - object does not exist."]     |
| Insufficient permissions                         | 403 Forbidden    | "detail": "You do not have permission to perform this action."        |

## GET /api/sequences/

Returns list of sequences.

### Permissions

Requires `authentication` and `sequence.list` permission.

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Location: /api/sequences/
Authorization: JWT access_token
```

### Response

| Key               | Type   | Notes                                                                              |
|-------------------|--------|------------------------------------------------------------------------------------|
| limit             | int    |                                                                                    |
| offset            | int    |                                                                                    |
| total\_count       | int    | Total number of results visible to the user (based on permissions).                |
| filtered\_count    | int    | Number of results visible to the user (based on permissions) with filters applied. |
| next              | url    | Next page URL (null if there is no next page)                                      |
| previous          | url    | Previous page URL (null if there is no previous page)                              |
| results           | Array  | List of results. Described in the next table.                                      |

### Response `results` array

| Key                  | Type     | Notes                                    |
|----------------------|----------|------------------------------------------|
| id                   | int      | Automatically generated by the backend.  |
| name                 | string   |                                          |
| description          | string   |                                          |
| object\_class         | int      |                                          |
| task\_group\_templates | int      |                                          |
| state                | string   |                                          |
| created\_at           | datetime |                                          |
| created\_by           | user     |                                          |
| modified\_at          | datetime |                                          |
| modified\_by          | user     |                                          |
| \_meta.labels         | Object   | Object containing labels for attributes. |
| \_meta.permissions    | Object   | Object describing permissions.           |

* Successful status `200 OK`
* Response body schema

```json
{
    "limit": <int>,
    "offset": <int>,
    "filtered_count": <int>,
    "total_count": <int>,
    "next": <str>,
    "previous": <str>,
    "results": [
        {
            "id": <int>,
            "name": <string>,
            "description": <string>,
            "object_class": <int>,
            "task_group_templates": <list>,
            "state": <string>,
            "created_at": <datetime>,
            "created_by": <user>,
            "modified_at": <datetime>,
            "modified_by": <user>,
            "_meta": {
                "labels": {
                    "object_class": <string>
                },
                "permissions": {
                    "list": <bool>,
                    "view": <bool>,
                    "create": <bool>,
                    "edit": <bool>,
                    "delete": <bool>,
                    "run": <bool>,
                    "design": <bool>
                }
            }
        }
}
```

### Sorting

| Parameter     | Example                                | Notes          |
|---------------|----------------------------------------|----------------|
| id            | /api/sequences/?ordering=id            | Ascending      |
| id            | /api/sequences/?ordering=-id           | Descending (-) |
| name          | /api/sequences/?ordering=name          | Ascending      |
| name          | /api/sequences/?ordering=-name         | Descending (-) |
| object\_class  | /api/sequences/?ordering=object\_class  | Ascending      |
| object\_class  | /api/sequences/?ordering=-object\_class | Descending (-) |
| created\_at    | /api/?ordering=created\_at              | Ascending      |
| created\_at    | /api/?ordering=-created\_at             | Descending (-) |
| modified\_at   | /api/?ordering=modified\_at             | Ascending      |
| modified\_at   | /api/?ordering=-modified\_at            | Descending (-) |

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter             | Type     |
|-----------------------|----------|
| id                    | int      |
| name                  | string   |
| object\_class          | enum     |
| task\_group\_templates  | set      |
| created\_at            | datetime |
| created\_by            | user     |
| modified\_at           | datetime |
| modified\_by           | user     |

### Errors

| Error                         | Response code   | Message                                                                             |
|-------------------------------|-----------------|-------------------------------------------------------------------------------------|
| Wrong ordering value          | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."] |

## GET /api/sequences/`id`

Returns single sequence by `id`.

### Permissions

Requires `authentication` and `sequence.view` permission.

### URL parameters

| Key                      | Type     | Notes |
|--------------------------|----------|-------|
| id                       | id       |       |

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Location: /api/sequences/1/
Authorization: JWT access_token
```

### Response

| Key               | Type     | Notes                                    |
|-------------------|----------|------------------------------------------|
| id                | int      | Automatically generated by the backend.  |
| name              | string   |                                          |
| description       | string   |                                          |
| object\_class      | int      |                                          |
| state             | string   |                                          |
| is\_debug\_enabled  | boolean  |                                          |
| created\_at        | datetime |                                          |
| created\_by        | user     |                                          |
| modified\_at       | datetime |                                          |
| modified\_by       | user     |                                          |
| \_meta.labels      | Object   | Object containing labels for attributes. |
| \_meta.permissions | Object   | Object describing permissions.           |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": <int>,
    "name": <string>,
    "description": <string>,
    "object_class": <int>,
    "state": <string>,
    "is_debug_enabled": <bool>,
    "created_at": <datetime>,
    "created_by": <user,
    "modified_at": <datetime>,
    "modified_by": <user>,
    "_meta": {
        "labels": {
            "object_class": <string>,
            "state": <string>
        },
        "permissions": {
            "list": <bool>,
            "view": <bool>,
            "create": <bool>,
            "edit": <bool>,
            "delete": <bool>,
            "run": <bool>,
            "design": <bool>
        }
    }
}
```

### Errors

| Error                             | Response code | Message                                                        |
|-----------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions          | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Sequence with "id" does not exist | 404 Not Found | "detail": "Not found."                                         |

## PATCH /api/sequences/`id`/

Updates single sequence.

### Permissions

Requires `authentication` and `sequence.edit` permission.

### Allowed parameters

| Key              | Type    | Notes |
|------------------|---------|-------|
| name             | string  |       |
| description      | string  |       |
| state            | string  |       |
| is\_debug\_enabled | boolean |       |

Any parameter not listed above are silently ignored if passed.

### Request

* Headers

```
Request Method: PATCH
Content-Type: application/json
Location: /api/sequences/1/
Authorization: JWT access_token
```

* Sample request body

```json
{
    "name": <string>,
    "description": <string>,
    "state": <string>,
    "is_debug_enabled": <bool>,
}
```

### Response

| Key               | Type     | Notes                                    |
|-------------------|----------|------------------------------------------|
| id                | int      | Automatically generated by the backend.  |
| name              | string   |                                          |
| description       | string   |                                          |
| object\_class      | int      |                                          |
| state             | string   |                                          |
| is\_debug\_enabled  | boolean  |                                          |
| created\_at        | datetime |                                          |
| created\_by        | user     |                                          |
| modified\_at       | datetime |                                          |
| modified\_by       | user     |                                          |
| \_meta.labels      | Object   | Object containing labels for attributes. |
| \_meta.permissions | Object   | Object describing permissions.           |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": <int>,
    "name": <string>,
    "description": <string>,
    "object_class": <int>,
    "state": <string>,
    "is_debug_enabled": <bool>,
    "created_at": <datetime>,
    "created_by": <user,
    "modified_at": <datetime>,
    "modified_by": <user>,
    "_meta": {
        "labels": {
            "object_class": <string>,
            "state": <string>
        },
        "permissions": {
            "list": <bool>,
            "view": <bool>,
            "create": <bool>,
            "edit": <bool>,
            "delete": <bool>,
            "run": <bool>,
            "design": <bool>
        }
    }
}
```

### Errors

| Cause                                            | Response code    | Message                                                               |
|--------------------------------------------------|------------------|-----------------------------------------------------------------------|
| "name" is missing                                | 400 Bad Request  | "name": \["This field is required."]                                   |
| "name" is not unique                             | 400 Bad Request  | "name": \["This field must be unique."]                                |
| "name" has > 100 chars                           | 400 Bad Request  | "name": \["Ensure this field has no more than 100 characters."]        |
| "description" is too long                        | 400 Bad Request  | "description": \["Ensure this field has no more than 500 characters."] |
| "object\_class" is required                       | 400 Bad Request  | "object\_class": \["This field is required."]                           |
| "object\_class" doesn't exists                    | 400 Bad Request  | "object\_class": \["Invalid pk "99900" - object does not exist."]     |
| "object\_class" not owned by user                 | 403 Forbidden    | "object\_class": "You are not an owner of this Object Class."          |
| Insufficient permissions                         | 403 Forbidden    | "detail": "You do not have permission to perform this action."        |

## DELETE /api/sequences/`id`/

Deletes single sequence.

### Permissions

Requires `authentication` and `sequence.delete` permission.

### Request

* Headers

```
Request Method: DELETE
Content-Type: application/json
Location: /api/sequences/1/
Authorization: JWT access_token
```

### Response

* Successful status `204 No Content`

### Errors

| Error                             | Response code | Message                                                        |
|-----------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions          | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Sequence with "id" does not exist | 404 Not Found | "detail": "Not found."                                         |

## OPTIONS /sequences/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Request Method: OPTIONS
Content-Type: application/json
Location: /api/sequences/
Authorization: JWT access_token
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "name",
                "type": "string",
                "predicates": [
                    "exact",
                    "iexact",
                    "contains",
                    "icontains",
                    "startswith",
                    "istartswith",
                    "endswith",
                    "iendswith"
                ],
                "sort_ok": true
            },
            {
                "alias": "description",
                "type": "string",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "object_class",
                "type": "enum",
                "predicates": [
                    "exact",
                    "isnull",
                    "in"
                ],
                "sort_ok": true,
                "autocomplete": "/api/object-classes/autocomplete/?text__icontains="
            },
            {
                "alias": "task_group_templates",
                "type": "set",
                "predicates": [
                    "isnull",
                    "containsall",
                    "containssome"
                ],
                "sort_ok": false,
                "autocomplete": "/api/task-group-templates/autocomplete/?text__icontains="
            },
            {
                "alias": "state",
                "type": "enum",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "values": [
                    {
                        "value": "p",
                        "text": "Paused"
                    },
                    {
                        "value": "r",
                        "text": "Running"
                    }
                ]
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "modified_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "modified_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            }
        ]
    },
    "details": {
        "schema": [
            {
                "alias": "name",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "description",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 500
                    }
                ]
            },
            {
                "alias": "state",
                "type": "enum",
                "required": false,
                "values": [
                    {
                        "value": "p",
                        "text": "Paused"
                    },
                    {
                        "value": "r",
                        "text": "Running"
                    }
                ]
            },
            {
                "alias": "is_debug_enabled",
                "type": "bool",
                "required": false,
                "validators": []
            },
            {
                "alias": "object_class",
                "type": "enum",
                "required": true,
                "autocomplete": "/api/object-classes/autocomplete/owned/?text__icontains="
            }
        ]
    },
    "restrictions": {
        "limit_items": 1000
    }
}
```

## POST /api/sequences/`id`/defaults/task-stages/stage\_1/assignees/

Designate selected standard users as default Task assignees to stage 1 of Tasks created by the Sequencer.

### Permissions

Requires `authentication` and `sequence.edit` permission.

### Request

* Headers

```
Request Method: POST
Content-Type: application/json
Location: /api/sequences/1/defaults/task-stages/stage_1/assignees/
Authorization: JWT access_token
```

* Body

| Key   | Type   | Required | Notes           |
|-------|--------|----------|-----------------|
| users | list   | True     | Users ids list  |

### Sample request body

```json
{
    "users": [user_id_1, user_id_2]
}
```

### Response

| Key   | Type  | Notes                  |
|-------|-------|------------------------|
| users | Array | Array of users objects |

* Successful status `201 Created`
* Response body schema

```json
{
    "users": [
        {
           "id": <user_id>,
           "first_name": <string>,
           "last_name":  <string>,
           "username": <string>,
           "company_name": <string>,
           "account_type": <enum>
        }
    ]
}
```

### Errors

| Error                                                                                              | Response code      | Message                                                                                                                        |
|----------------------------------------------------------------------------------------------------|--------------------|--------------------------------------------------------------------------------------------------------------------------------|
| Insufficient permissions                                                                           | 403 Forbidden      | "detail": "You do not have permission to perform this action."                                                                 |
| Sequence with "id" does not exist                                                                  | 404 Not Found      | "detail": \["Not found."]                                                                                                       |
| Invalid payload schema                                                                             | 400 Bad Request    | "detail": \["Invalid payload schema"]                                                                                           |
| "users" list is empty                                                                              | 400 Bad Request    | "detail": \["This list of assignees may not be empty."]                                                                         |
| "users" list contains different type than integer                                                  | 400 Bad Request    | "detail": \["Incorrect type. Expected pk value, received {type}."]                                                              |
| User with given ID does not exist                                                                  | 400 Bad Request    | "detail": \["Invalid pk "{id}" - object does not exist."]                                                                     |
| Exceeded max batch size                                                                            | 400 Bad Request    | "detail": \["Up to {BATCH\_LIMIT} items allowed."]                                                                               |
| Exceeded max number of standard assignees                                                          | 400 Bad Request    | "detail": \["Limit of 100 standard assignees has been exceeded."]                                                               |
| 1TC user sent in request's body                                                                    | 400 Bad Request    | "detail": \["1 Time Completion users are not allowed."]                                                                         |
| Request user does not have "users.list" permission for the user to be set as default task assignee | 400 Bad Request    | "detail": \["You do not have permission to select user "{user\_id}" as a default task assignee for Sequence "{sequence\_id}"."]   |

## DELETE /api/sequences/`id`/defaults/task-stages/stage\_1/assignees/

Remove selected standard users from default Task assignees from stage 1 of Tasks created by the Sequencer

### Permissions

Requires `authentication` and `sequence.edit` permission.

### Request

* Headers

```
Request Method: DELETE
Content-Type: application/json
Location: /api/sequences/1/defaults/task-stages/stage_1/assignees/
Authorization: JWT access_token
```

* Body

| Key   | Type   | Required | Notes           |
|-------|--------|----------|-----------------|
| users | list   | True     | Users ids list  |

### Sample request body

```json
{
    "users": [user_id_1, user_id_2]
}
```

### Response

| Key   | Type  | Notes                  |
|-------|-------|------------------------|
| users | Array | Array of users objects |

* Successful status `204 NO CONTENT`

### Errors

| Error                                             | Response code   | Message                                                           |
|---------------------------------------------------|-----------------|-------------------------------------------------------------------|
| Insufficient permissions                          | 403 Forbidden   | "detail": "You do not have permission to perform this action."    |
| Sequence with "id" does not exist                 | 404 Not Found   | "detail": \["Not found."]                                          |
| Invalid payload schema                            | 400 Bad Request | "detail": \["Invalid payload schema"]                              |
| "users" list is empty                             | 400 Bad Request | "detail": \["This list of assignees may not be empty."]            |
| "users" list contains different type than integer | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."] |
| Exceeded max batch size                           | 400 Bad Request | "detail": \["Up to {BATCH\_LIMIT} items allowed."]                  |

## OPTIONS /api/sequences/`id`/defaults/task-stages/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Request Method: OPTIONS
Content-Type: application/json
Location: /api/sequences/1/defaults/task-stages/
Authorization: JWT access_token
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "batch": {
        "type": "set",
        "required": true,
        "autocomplete": "/api/users/autocomplete/?account_type!=one_time_completion&text__icontains="
    },
    "restrictions": {
        "limit_assignees_standard": 100,
        "limit_assignees_one_time_completion": 0,
        "limit_items_in_batch": 100
    }
}
```

## GET /api/sequences/`id`/defaults/task-stages/

Returns users designated as default assignees for to stage 1 of Tasks crated automatically by Sequencer.

### Permissions

Requires `authentication` and `sequence.view` permission.

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Location: /api/sequences/1/defaults/task-stages/
Authorization: JWT access_token
```

### Response

List of results described in the table below.

| Key            | Type   | Notes                                                                              |
|----------------|--------|------------------------------------------------------------------------------------|
| name           | string | Stage name                                                                         |
| assignees      | Object |                                                                                    |

### Response `assignees` array

| Key   | Type  | Notes               |
|-------|-------|---------------------|
| users | Array | Array of users ids. |

* Successful status `200 OK`
* Response body schema

```json
[
   {
      "name": <string>,
      "assignees":{
         "users":[
            {
               "id": <user_id>,
               "first_name": <string>,
               "last_name": <string>,
               "username": <string>,
               "company_name": <string>,
               "account_type": <enum>
            }
         ]
      }
   }
]
```

### Errors

| Error                             | Response code   | Message                                                           |
|-----------------------------------|-----------------|-------------------------------------------------------------------|
| Insufficient permissions          | 403 Forbidden   | "detail": "You do not have permission to perform this action."    |
| Sequence with "id" does not exist | 404 Not Found   | "detail": \["Not found."]                                          |

---

---
url: /knowledgebase/system-configuration/sequences.md
---
# Sequences

**Browse the sections below:**

* [Adding Conditions For Sequence Commencement](/knowledgebase/system-configuration/sequences/adding-conditions-for-sequence-commencement/)
* [Creating A Sequence](/knowledgebase/system-configuration/sequences/creating-a-sequence/)
* [Editing A Sequence   Design](/knowledgebase/system-configuration/sequences/editing-a-sequence---design/)
* [Editing A Sequence   Properties](/knowledgebase/system-configuration/sequences/editing-a-sequence---properties/)
* [Navigation And Menus](/knowledgebase/system-configuration/sequences/navigation-and-menus/)
* [Sequences List](/knowledgebase/system-configuration/sequences/sequences-list/)
* [What Is The Sequencer](/knowledgebase/system-configuration/sequences/what-is-the-sequencer/)

---

---
url: /knowledgebase/system-configuration/sequences-for-relational-records.md
---
# Sequences For Relational Records

**Browse the sections below:**

* [A Guide To Using The Relation Lookup And Sequence Runner Actors Together](/knowledgebase/system-configuration/sequences-for-relational-records/a-guide-to-using-the-relation-lookup-and-sequence-runner-actors-together/)
* [Using The Sequence Runner Actor For One Object Class](/knowledgebase/system-configuration/sequences-for-relational-records/using-the-sequence-runner-actor-for-one-object-class/)
* [What Can You Do With Relational Records In A Sequence](/knowledgebase/system-configuration/sequences-for-relational-records/what-can-you-do-with-relational-records-in-a-sequence/)

---

---
url: /knowledgebase/system-configuration/sequences/sequences-list.md
---

# Sequences list

Firstly, for those of you who don't know what our Sequencer does, click **[HERE](/knowledgebase/system-configuration/sequences/what-is-the-sequencer/).**

Sequences can be **created, edited, run, or paused** from the Sequences list.

## Visibility

The Sequences list will only be visible to Users who meet one of the options below:

|  |  |
| --- | --- |
| - have a Super Admin account - have a Role where the system permissions under the Sequencer tab have been enabled for create and edit or edit only   NB although you do not have to be the Object class Owner to edit the Sequence properties, you must have this additional permission in order to edit the design. | mceclip0.png |

## List features

This list has all the usual features of lists in your system. More details about those can be found **[HERE](/knowledgebase/finding-your-way-around/ui-and-navigation/list-pages/)**.

## Default columns

The default columns in this list are as follows:

* **ID** - a unique number given to the Sequence which is automatically applied by the system on creation of the Sequence. This is useful for aiding recognition when debugging, etc. when you have a number of Sequences with similar names.
* **Name** - the Name given to the Sequence on creation or when last edited.
* **Object class** - shows the Object class for which the Sequence has been created and thus determines which Object records it may be run against.
* **Task group templates** - this column displays the Name(s) of any Task group template(s) included in the Sequence design.
* **State** - shows the current state of the sequence. States are:
  * **Paused** - all newly created Sequences will be in this state until they are set to a state of running when the option to **Resume** is selected in the Actions menu.
  * **Running** - the Sequence is "live". Depending on the starting conditions for the Sequence, it will run against Object records when they are created or when fields in the Record are updated.

## Actions

**Actions** - Super admin Users, and Users with a Role permission which allows them to Edit Sequences, will see the following options:

* **Edit properties** - this will allow you to change the Sequence Name, Description and Default task assignees. Click [**HERE**](/knowledgebase/system-configuration/sequences/editing-a-sequence---properties/) for more information.

**Additional visibility for actions**

Super admin Users, and Users with a Role permission which allows them to Edit Sequences and who are the Object class Owner, will see the following options:

* **Resume or Pause** - if the Sequence is running, the option to Pause it will be shown; if the Sequence is paused, the option to Resume it will be shown. When a Sequence is paused, any Tasks which have already been created can still be completed. However, their completion will not cause the next Task to be created or will not trigger an API call or an Update record to occur because connecting triggers will be dormant. When a Sequence which was paused is resumed, the completion of a Task which had already been created would cause the connecting trigger to fire and therefore the next action would occur.
* **Edit design** - this will allow you to change your workflow by adding or removing Task templates, task group templates and Sequence Actors such API calls and Send messages. Click **[HERE](/knowledgebase/system-configuration/sequences/editing-a-sequence---design/)** for more information.

![mceclip1.png](/knowledgebase/images/img_6231905755677_1776895994.png)

![mceclip2.png](/knowledgebase/images/img_6231905755677_1776895994.png)

## Other useful columns

Other particularly useful columns which you might want to add to the list are:

* **# of API actors** - this will tell you the number of API actors present in each Sequence.
* **API actor names** - if API actors are present in the Sequence, this column will show the names of each API actor. This is the Name configured in the API actor as shown below:

![API\_call\_name.jpg](/knowledgebase/images/img_6231905755677_1776895995.jpg)

![api\_name.jpg](/knowledgebase/images/img_6231905755677_1776895995.jpg)

## Useful info

1. The maximum number of Sequences you can create in your system is 1,000.

---

---
url: /knowledgebase/administration/all-about-users/service-accounts.md
---

# Service Accounts

Service Accounts are dedicated user accounts designed for integrations, API clients and automated processes.

Unlike standard user accounts, Service Accounts are not intended for individual users. They provide a secure identity for applications and services that need to authenticate with Catalyst without relying on a named person's credentials.

One of the main benefits of Service Accounts is that they continue to support **username and password authentication** even when **Single Sign-on (SSO)** is enabled and password-based authentication has been disabled for standard users. This allows integrations and automated processes to continue operating without affecting your organisation's authentication policy.

There are two Service Account types:

* Internal Service account
* External Service account

## Internal and External Service Accounts

### Internal Service Account

An Internal Service Account is intended for trusted internal integrations and automation.

Typical uses include:

* internal API integrations
* scheduled automation
* administration scripts
* automated user management
* managing User groups
* system-to-system communication

Internal Service Accounts automatically receive permissions equivalent to a Super Admin account.

Each Catalyst environment can contain **one Internal Service Account**.

### External Service Accounts

External Service Accounts are designed for third-party integrations and external services.

Typical uses include:

* CRM integrations
* document management systems
* DocuSign webhook processing
* middleware platforms
* external API clients

Unlike Internal Service Accounts, External Service Accounts have **no permissions by default**.

You must explicitly grant any required Object Class or Record permissions, or assign the account to appropriate User groups.

Each Catalyst environment can contain **up to five External Service Accounts**.

## Creating Service Accounts

Service Accounts can be created using the API.

One simple approach is to temporarily configure an API Call actor in a Sequence.

Configure the API call as shown below.

![API Call actor configured to create a Service Account](../../../images2/zendesk_5471769553823_001_3d80f68593f4.png)

Use the following request body.

```json
{
  "username": "[email address]",
  "account_type": "service_external",
  "first_name": "[first name]",
  "last_name": "[last name]",
  "password": "[password]"
}
```

To create an Internal Service Account, change the account type to:

```json
"account_type": "service_internal"
```

An example request is shown below.

![Example API request creating a Service Account](../../../images2/zendesk_5471769553823_002_a94ba6e91d4e.png)

> **Tip:** You do not need to attach the API Call actor to a live Sequence. Simply configure the actor, test it against any record ID to execute the request, confirm that the Service Account has been created, then delete the actor if it is no longer required.

Alternatively, you can use any API client, such as **Postman**, to submit the same request.

Once created, the account appears in the **Users** list with the appropriate account type.

![Users list showing Internal and External Service Accounts](../../../images2/zendesk_5471769553823_003_fcb0f342d38b.png)

## Password management

Service Accounts cannot use the **Forgot your password** option on the login page.

Only a Super Admin can reset or change the password of a Service Account.

Passwords can be updated using the following endpoint.

**Endpoint**

```text
{{client_url}}/api/users/[userID]
```

**Request body**

```json
{
  "password": "[new password]"
}
```

> **Important:** If you change the password of an Internal Service Account that is currently being used by an Authentication Object or integration, remember to update those credentials immediately. A Service Account cannot be used to change its own password.

## Converting an existing Service Account

If you already have an integration account that you want to convert to one of the dedicated Service Account types, submit a PATCH request using one of the following request bodies.

**External Service Account**

```json
{
  "account_type": "service_external"
}
```

**Internal Service Account**

```json
{
  "account_type": "service_internal"
}
```

## Things to remember

1. Internal Service Accounts automatically receive Super Admin permissions.
2. External Service Accounts have no permissions until they are explicitly assigned.
3. Service Accounts always support username and password authentication, even when SSO is enforced for standard users.
4. Newly created Service Accounts are automatically activated and never receive an activation email.
5. There is no **Resend activation email** option for Service Accounts.
6. Service Account passwords must satisfy your system's current password complexity requirements.
7. Each Catalyst environment supports one Internal Service Account and up to five External Service Accounts.

---

---
url: >-
  /knowledgebase/using-help-and-support/we're-here-to-help/service-levels-and-escalation.md
---

# Service levels and escalation

---

---
url: /knowledgebase/system-configuration/sequence-actors/set-task-actor.md
---

# Set Task Actor

## **What does the Set Task actor do?**

The Set Task actor has two functions relating to task templates of the "Automatic" Task creation mechanism. It can be used to:

* Re-create a task which has already been created and completed
* Delete a task, irrespective of whether it is completed

## **How do I use the Set Task actor?**

Click, drag and drop the Set Task actor onto your sequence workspace.

Right click on it and select Configure. The Set task configuration modal will open.

### **Select the task template**

Click into the **Search for task templates** drop-down.

Available task templates will be displayed in alphabetical order by name.

"Available task templates" means those of the Update object record type which have been created for the sequence object class and those of the "Complete self contained form" type. The latter task templates are available for use in any object class sequence.

You can either scroll through the list or start typing to find the required task template.

![Screenshot 2026-04-15 at 19.15.57.png](/knowledgebase/images/img_5643520204063_1776895829.png)

Click on the template name, then select the required action.

### **Choose the action**

* **Re-create** - having selected this option the configuration is complete.

  ![Screenshot 2026-04-15 at 19.16.52.png](/knowledgebase/images/img_5643520204063_1776895829.png)

  Save the configuration.

* **Delete** - having selected this option a further field with 6 (single-select) options is presented.

  ![Screenshot 2026-04-16 at 09.31.13.png](/knowledgebase/images/img_5643520204063_1776895829.png)

  The options are fairly self-explanatory but clearly **only apply to the selected task template and the record which triggers this actor**:

  * **All tasks** - all tasks which have been created, irrespective of status, will be deleted
  * **All outstanding tasks** - all incomplete tasks will be deleted
  * **All completed tasks** - all completed tasks will be deleted
  * **Most recent task** - the most recently created task, irrespective of status, will be deleted
  * **Most recent outstanding task** - If the most recent task is completedthe condition will be ignored
  * **Most recent completed task** - if the most recent task is outstandingthe condition will be ignored

  Make your selection and save the configuration.

### **Rename the actor**

As with all other sequence actors, it is best practice to replace the default actor name with something more descriptive or meaningful.

Right click on the actor and select Properties. Enter the new label in the Name field and save.

![Screenshot 2026-04-15 at 19.34.40.png](/knowledgebase/images/img_5643520204063_1776895829.png)

|  |  |
| --- | --- |
| The new label will appear under the Set Task actor.  If the label is too long it will be truncated but can be viewed by hovering over the name. | Screenshot 2026-04-15 at 19.47.36.png |

When the Set Task actor has completed, the new task is created. This will trigger any onward processing where the original Create Task outgoing trigger is "When Task Created".

## **Useful info**

A Set Task actor will normally be preceded by a [**Task Assignment actor**](/knowledgebase/system-configuration/sequence-actors/task-assignment-actor/) and can be followed by any other sequence actor. However, it is most common that a Set Task actor **does not** have any object following it as the sequence will pick up from the original Create Task actor.

---

---
url: /api/catalyst/resources/authentication/sso-config.md
---
# Single Sign On Configuration

## Permissions

| Permission | Manageable via Roles | Description                                 |
|------------|----------------------|---------------------------------------------|
| list       | true                 | Allow list SSO configurations               |
| view       | true                 | Allow view single SSO configuration details |
| create     | true                 | Allow create SSO configurations             |
| edit       | true                 | Allow edit SSO configurations               |
| delete     | true                 | Allow delete SSO configurations             |

Permissions for SSO Config can be checked by:

| Context                  | Endpoint                        | Location            | Available perms                             |
|--------------------------|---------------------------------|---------------------|---------------------------------------------|
| Global scope             | `GET /api/users/permissions/`   | `single_sign_on`    | `list`, `view`, `edit`, `create`, `delete`  |
| Specific single\_sign\_on  | `GET /api/single-sign-on/{id}/` | `_meta.permissions` | `list`, `view`, `edit`, `create`, `delete`  |

## References

* [SSO Technical Design](https://autologyx.sharepoint.com/:w:/s/Dev/EWl9gMkIDtROjN9m8tiHUrwBr5PYLB0WDjWVFFejSLVulQ?e=Z0ZuYA)

## POST /api/single-sign-on/

Creates Single Sign On Configuration.

### Permissions

Requires `authentication` and `single_sign_on.create` permission.

### Request

* Body parameters

| Key                        | Type      | Notes                                                                                                                                                                              |
|----------------------------|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **name**                   | string    | Displayed name                                                                                                                                                                     |
| **client\_id**              | string    | Client ID                                                                                                                                                                          |
| **tenant\_id**              | string    | Provider specific: Azure: Azure tenant identifierOkta: Okta tenant (organization) domain (for example, acme.okta.com) |
| **provider**               | enum      | Provider (one of `azure`, `okta`)                                                                                                                                                  |
| **is\_enabled**             | bool      | Enabled flag                                                                                                                                                                       |
| **auto\_create\_user**       | bool      | If should create user when it does not exists                                                                                                                                      |
| **roles**                  | enum      | Attached roles ID's after create user                                                                                                                                              |
| \***is\_word\_addin\_enabled** | bool      | If configuration supports Word Addin (optional)                                                                                                                                    |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/single-sign-on/ 

{
  "name": <string>,
  "client_id":  <string>,  
  "client_secret":  <string>, 
  "tenant_id":  <string>,  
  "provider":  <string>,  
  "is_enabled": <bool>,  
  "auto_create_user":  <bool>, 
  "roles":  <enum>,  
  "is_word_addin_enabled": <bool>
} 
```

### Validations

* Max 25 objects
* name
  * Max length: 100
  * Case insensitive unique
* client\_id
  * Max length: 255
  * \[a-zA-Z0-9-]
* client\_secret
  * Max length: 255
  * \[a-zA-Z0-9-]
* tenant\_id
  * Max length: 255
  * \[a-zA-Z0-9-]
* providers
  * one of (`azure`, `okta`)
* is\_word\_addin\_enabled
  * only with `provider` = `azure`
  * only one per each azure application SSO, with set as `True`. Only one Azure application SSO with the same client\_id and tenant\_id can have `is_word_addin_enabled` set as `True`.

### Response

| Key                   | Type       | Notes                                                                                                                                                                              |
|-----------------------|------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| id                    | id         | Automatically generated by the backend.                                                                                                                                            |
| name                  | string     | Displayed name                                                                                                                                                                     |
| client\_id             | string     | Client ID                                                                                                                                                                          |
| tenant\_id             | string     | Provider specific: Azure: Azure tenant identifierOkta: Okta tenant (organization) domain (for example, acme.okta.com) |
| provider              | enum       | Provider (one of `azure`, `okta`)                                                                                                                                                  |
| is\_enabled            | bool       | Enabled flag                                                                                                                                                                       |
| auto\_create\_user      | bool       | If should create user when it does not exists                                                                                                                                      |
| is\_word\_addin\_enabled | enum       | If configuration supports Word Addin                                                                                                                                               |
| roles                 | enum       | Attached roles ID's after create user                                                                                                                                              |
| redirect\_uri          | url        | Login callback URL                                                                                                                                                                 |
| created\_at            | datetime   |                                                                                                                                                                                    |
| created\_by            | user       |                                                                                                                                                                                    |
| modified\_at           | datetime   |                                                                                                                                                                                    |
| modified\_by           | user       |                                                                                                                                                                                    |
| logout\_url            | url        | Logout callback URL                                                                                                                                                                |
| \_meta.labels          | Object     | Object containing labels for attributes.                                                                                                                                           |
| \_meta.permissions     | Object     | Object describing permissions.                                                                                                                                                     |

* Successful status `201 Created`
* Response body schema

```json
{  
   "id": <int>,  
   "name": <string>, 
   "client_id": <string>, 
   "tenant_id": <string>, 
   "is_enabled": <bool>,  
   "is_word_addin_enabled": <bool>,  
   "auto_create_user": <bool>,  
   "roles": <enum>,  
   "provider": <string>,  
   "redirect_uri": <url>, 
   "created_at": <datetime>,  
   "created_by": <user>, 
   "modified_at": <datetime>,  
   "modified_by": <user>,
   "logout_url": <url>, 
  "_meta": { 
      "labels": { 
          "roles": <enum> 
      }, 
      "permissions": <set> 
  } 
} 
```

### Errors

| Cause                                                                        | Response code    | Message                                                                                      |
|------------------------------------------------------------------------------|------------------|----------------------------------------------------------------------------------------------|
| Using is\_word\_addin\_enabled param when provider is not azure                 | 400 Bad Request  | "is\_word\_addin\_enabled": "Provider must be "azure"."                                       |
| Max 25 SSO Config exceeded                                                   | 400 Bad Request  | "detail": \["Limit of 25 SSO configurations has been exceeded."]                              |

## GET /api/single-sign-on/

Returns list of Single Sign On Configurations.

### Permissions

Requires `authentication` and `single_sign_on.list` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/single-sign-on/ 
```

### Response

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

#### Response `results` array

| Key                   | Type       | Notes                                                                                                                                                                              |
|-----------------------|------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| id                    | id         | Automatically generated by the backend.                                                                                                                                            |
| name                  | string     | Displayed name                                                                                                                                                                     |
| client\_id             | string     | Client ID                                                                                                                                                                          |
| tenant\_id             | string     | Provider specific: Azure: Azure tenant identifierOkta: Okta tenant (organization) domain (for example, acme.okta.com) |
| provider              | enum       | Provider (one of `azure`)                                                                                                                                                          |
| is\_enabled            | bool       | Enabled flag                                                                                                                                                                       |
| auto\_create\_user      | bool       | If should create user when it does not exists                                                                                                                                      |
| is\_word\_addin\_enabled | enum       | If configuration supports Word Addin                                                                                                                                               |
| roles                 | enum       | Attached roles ID's after create user                                                                                                                                              |
| created\_at            | datetime   |                                                                                                                                                                                    |
| created\_by            | user       |                                                                                                                                                                                    |
| modified\_at           | datetime   |                                                                                                                                                                                    |
| modified\_by           | user       |                                                                                                                                                                                    |
| \_meta.labels          | Object     | Object containing labels for attributes.                                                                                                                                           |
| \_meta.permissions     | Object     | Object describing permissions.                                                                                                                                                     |

* Successful status `200 OK`
* Response body schema

```json
{
   "limit": <int>,  
   "offset": <int>,  
   "filtered_count": <int>,  
   "total_count": <int>,  
   "next": <url>,  
   "previous": <url>,  
   "results": [
     {
       "id": <int>,
       "name": <string>,
       "client_id": <string>,
       "tenant_id": <string>,
       "is_enabled": <bool>,
       "is_word_addin_enabled": <string>,
       "auto_create_user": <bool>,
       "roles": <enum>,
       "provider": <string>,
       "redirect_uri": <url>,
       "created_at": <datetime>,
       "created_by": <user>,
       "modified_at": <datetime>,
       "modified_by": <user>,
       "_meta": {
         "labels": {
           "roles": <enum>
         },
         "permissions": <set>
       }
     }
   ]
}
```

### Sorting

| Parameter   | Example                              | Notes          |
|-------------|--------------------------------------|----------------|
| id          | /{%endpoint%}/?ordering=id           | Ascending      |
| id          | /{%endpoint%}/?ordering=-id          | Descending (-) |
| name        | /{%endpoint%}/?ordering=name         | Ascending      |
| name        | /{%endpoint%}/?ordering=-name        | Descending (-) |
| created\_at  | /{%endpoint%}/?ordering=created\_at   | Ascending      |
| created\_at  | /{%endpoint%}/?ordering=-created\_at  | Descending (-) |
| modified\_at | /{%endpoint%}/?ordering=modified\_at  | Ascending      |
| modified\_at | /{%endpoint%}/?ordering=-modified\_at | Descending (-) |

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter              | Type     |
|------------------------|----------|
| id                     | int      |
| name                   | string   |
| provider               | enum     |
| is\_enabled             | bool     |
| auto\_create\_user       | bool     |
| is\_word\_addin\_enabled  | bool     |
| created\_at             | datetime |
| created\_by             | user     |
| modified\_at            | datetime |
| modified\_by            | user     |

### Errors

| Error                         | Response code   | Message                                                                             |
|-------------------------------|-----------------|-------------------------------------------------------------------------------------|
| Wrong ordering value          | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."] |

## GET /api/single-sign-on/ `id`/

Returns single SSO Config by `id`.

### Permissions

Requires `authentication` and `single_sign_on.view` permission.

### Request

* URL parameters

| Key | Type | Notes       |
|-----|------|-------------|
| id  | int  |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/single-sign-on/ `id`/
```

### Response

| Key                   | Type         | Notes                                                                                                                                                                              |
|-----------------------|--------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| id                    | id           | Automatically generated by the backend.                                                                                                                                            |
| name                  | string       | Displayed name                                                                                                                                                                     |
| client\_id             | string       | Client ID                                                                                                                                                                          |
| tenant\_id             | string       | Provider specific: Azure: Azure tenant identifierOkta: Okta tenant (organization) domain (for example, acme.okta.com) |
| provider              | enum         | Provider (one of `azure`)                                                                                                                                                          |
| is\_enabled            | bool         | Enabled flag                                                                                                                                                                       |
| auto\_create\_user      | bool         | If should create user when it does not exists                                                                                                                                      |
| is\_word\_addin\_enabled | enum         | If configuration supports Word Addin                                                                                                                                               |
| roles                 | enum         | Attached roles ID's after create user                                                                                                                                              |
| redirect\_uri          | url          | Login callback URL                                                                                                                                                                 |
| created\_at            | datetime     |                                                                                                                                                                                    |
| created\_by            | user         |                                                                                                                                                                                    |
| modified\_at           | datetime     |                                                                                                                                                                                    |
| logout\_url            | url          | Logout callback URL                                                                                                                                                                |
| \_meta.labels          | Object       | Object containing labels for attributes.                                                                                                                                           |
| \_meta.permissions     | Object       | Object describing permissions.                                                                                                                                                     |

* Successful status `200 OK`
* Response body schema:

```json
{
  "id": <int>,  
   "name": <string>, 
   "client_id": <string>, 
   "tenant_id": <string>, 
   "is_enabled": <bool>,  
   "is_word_addin_enabled": <bool>,  
   "auto_create_user": <bool>,  
   "roles": <enum>,  
   "provider": <string>,  
   "redirect_uri": <url>, 
   "created_at": <datetime>,  
   "created_by": <user>, 
   "modified_at": <datetime>,  
   "modified_by": <user>, 
   "logout_url": <url>, 
  "_meta": { 
      "labels": { 
          "roles": <enum> 
      }, 
      "permissions": <set> 
  } 
}
```

### Errors

| Error                               | Response code | Message                                                        |
|-------------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions            | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| SSO Config with "id" does not exist | 404 Not Found | "detail": "Not found."                                         |

## PATCH /api/single-sign-on/ `id`/

Updates single SSO Config.

### Permissions

Requires `authentication` and `single_sign_on.edit` permission.

### Request

* URL parameters

| Key | Type | Notes       |
|-----|------|-------------|
| id  | int  |             |

* Body parameters

| Key                   | Type       | Notes                                                                                                                                                                              |
|-----------------------|------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| name                  | string     | Displayed name                                                                                                                                                                     |
| client\_id             | string     | Client ID                                                                                                                                                                          |
| tenant\_id             | string     | Provider specific: Azure: Azure tenant identifierOkta: Okta tenant (organization) domain (for example, acme.okta.com) |
| is\_enabled            | bool       | Enabled flag                                                                                                                                                                       |
| auto\_create\_user      | bool       | If should create user when it does not exists                                                                                                                                      |
| roles                 | enum       | Attached roles ID's after create user                                                                                                                                              |
| is\_word\_addin\_enabled | enum       | If configuration supports Word Addin                                                                                                                                               |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
PATCH /api/single-sign-on/ `id`/

{
  "name": <string>,
  "client_id":  <string>,  
  "client_secret":  <string>, 
  "tenant_id":  <string>,  
  "is_enabled": <bool>,  
  "auto_create_user":  <bool>, 
  "roles":  <enum>,  
  "is_word_addin_enabled": <bool>
  ...
} 
```

### Response

| Key                   | Type      | Notes                                                                                                                                                                              |
|-----------------------|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| id                    | id        | Automatically generated by the backend.                                                                                                                                            |
| name                  | string    | Displayed name                                                                                                                                                                     |
| client\_id             | string    | Client ID                                                                                                                                                                          |
| tenant\_id             | string    | Provider specific: Azure: Azure tenant identifierOkta: Okta tenant (organization) domain (for example, acme.okta.com) |
| provider              | enum      | Provider (one of `azure`)                                                                                                                                                          |
| is\_enabled            | bool      | Enabled flag                                                                                                                                                                       |
| auto\_create\_user      | bool      | If should create user when it does not exists                                                                                                                                      |
| is\_word\_addin\_enabled | enum      | If configuration supports Word Addin                                                                                                                                               |
| roles                 | enum      | Attached roles ID's after create user                                                                                                                                              |
| redirect\_uri          | url       | Login callback URL                                                                                                                                                                 |
| created\_at            | datetime  |                                                                                                                                                                                    |
| created\_by            | user      |                                                                                                                                                                                    |
| modified\_at           | datetime  |                                                                                                                                                                                    |
| modified\_by           | user      |                                                                                                                                                                                    |
| logout\_url            | url       | Logout callback URL                                                                                                                                                                |
| \_meta.labels          | Object    | Object containing labels for attributes.                                                                                                                                           |
| \_meta.permissions     | Object    | Object describing permissions.                                                                                                                                                     |

* Successful status `200 OK`
* Response body schema:

```json
{
   "id": <int>,  
   "name": <string>, 
   "client_id": <string>, 
   "tenant_id": <string>, 
   "is_enabled": <bool>,  
   "is_word_addin_enabled": <bool>,  
   "auto_create_user": <bool>,  
   "roles": <enum>,  
   "provider": <string>,  
   "redirect_uri": <url>, 
   "created_at": <datetime>,  
   "created_by": <user>, 
   "modified_at": <datetime>,  
   "modified_by": <user>, 
   "logout_url": <url>, 
  "_meta": { 
      "labels": { 
          "roles": <enum> 
      }, 
      "permissions": <set> 
  } 
} 
```

### Errors

| Cause                                                                        | Response code    | Message                                                                                      |
|------------------------------------------------------------------------------|------------------|----------------------------------------------------------------------------------------------|
| Using is\_word\_addin\_enabled param when provider is not azure                 | 400 Bad Request  | "is\_word\_addin\_enabled": "Provider must be "azure"."                                       |

## DELETE /api/single-sign-on/`id`/

Deletes single SSO Config.

### Permissions

Requires `authentication` and `single_sign_on.delete` permission.

### Request

* URL parameters

| Key | Type | Notes       |
|-----|------|-------------|
| id  | int  |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
DELETE /api/single-sign-on/`id`/
```

### Response

* Successful status `204 No Content`

## OPTIONS /api/single-sign-on/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/single-sign-on/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
  "list": {  
        "columns": [  
            {  
                "alias": "id",  
                "type": "int",  
                "predicates": [  
                    "exact",  
                    "gt",  
                    "gte",  
                    "lt",  
                    "lte",  
                    "range"  
                ],  
                "sort_ok": false  
            },  
            {  
                "alias": "name",  
                "type": "string",  
                "predicates": [  
                    "exact",  
                    "iexact",  
                    "contains",  
                    "icontains",  
                    "startswith",  
                    "istartswith",  
                    "endswith",  
                    "iendswith"  
                ],  
                "sort_ok": true  
            },  
            {  
                "alias": "provider",  
                "type": "enum",  
                  "predicates": [  
                    "exact",  
                    "in"  
                ],  
                "sort_ok": false,  
                "values": [  
                    {  
                        "value": "azure",  
                        "text": "Microsoft Azure"  
                    },
                    {
                        "value": "okta",
                        "text": "Okta" 
                    }
                ] 
            },  
            {  
                "alias": "is_enabled",  
                "type": "boolean",  
                "predicates": ["exact"],  
                "sort_ok": false  
            },
            {  
                "alias": "is_word_addin_enabled",  
                "type": "boolean",  
                "predicates": ["exact"],  
                "sort_ok": false  
            },
            {  
                "alias": "auto_create_user",  
                "type": "boolean",  
                "predicates": ["exact"],  
     
                "sort_ok": false  
            },  
            {  
                "alias": "created_at",  
                "type": "datetime",  
                "predicates": [  
                    "exact",  
                    "gt",  
                    "gte",  
                    "lt",  
                    "lte",  
                    "range"  
                ],  
                "sort_ok": true  
            },  
            {  
                "alias": "created_by",  
                "type": "enum",  
                "predicates": [  
                    "exact",  
                    "in"  
                ],  
                "sort_ok": false,  
                "autocomplete": "/api/users/autocomplete/?text__icontains="  
            },  
            {  
                "alias": "modified_at",  
                "type": "datetime",  
                "predicates": [  
                    "exact",  
                    "gt",  
                    "gte",  
                    "lt",  
                    "lte",  
                    "range"  
                ],  
                "sort_ok": true  
            },  
            {  
                "alias": "modified_by",  
                "type": "enum",  
                "predicates": [  
                    "exact",  
                    "in"  
                ],  
                "sort_ok": false,  
                "autocomplete": "/api/users/autocomplete/?text__icontains="  
            }  
        ]  
    },  
    "details": {  
        "schema": [  
            {  
                "alias": "name",  
                "type": "string",  
                "required": true,  
                "validators": [  
                    {  
                        "type": "max_length",  
                        "length": 100  
                    }  
                ]  
            },  
            {  
                "alias": "provider",  
                "type": "enum",  
                "required": true,  
                "values": [  
                    {  
                        "value": "azure",  
                        "text": "Microsoft Azure"  
                    },
                    {
                      "value": "okta",
                      "text": "Okta" 
                    }
                ]  
            }, 
            {  
                "alias": "client_id",  
                "type": "string",  
                "required": true,  
                "validators": [  
                    {  
                        "type": "max_length",  
                        "length": 256  
                    }  
                ]  
            },  
            {  
                "alias": "client_secret",  
                "type": "string",  
                "required": true,  
                "validators": [  
                    {  
                        "type": "max_length",  
                        "length": 256  
                    }  
                ]  
            },  
            {  
                "alias": "tenant_id",  
                "type": "string",  
                "required": true,  
                "validators": [  
                    {  
                        "type": "max_length",  
                        "length": 256  
                    }  
                ]  
            },  
            {  
                "alias": "is_enabled",  
                "type": "bool",  
                "required": false  
            },
            {
                "alias": "is_word_addin_enabled",  
                "type": "bool",  
                "required": false  
            },
            {  
                "alias": "auto_create_user",  
                "type": "bool",  
                "required": false  
            },  
            {  
                "alias": "roles",  
                "type": "set",  
                "required": false,  
                "autocomplete": "/api/roles/autocomp?text__icontains=",  
                "validators": [  
                    {  
                        "type": "max_items",  
                        "items": 10  
                    }  
                ] 
            }  
        ]  
    },  
    "restrictions": {  
        "limit_items": 25  
    }
} 
```

## POST /api/single-sign-on/login/

Retrieve provider authorization url.

### Permissions

Public access endpoint.

### Request

* Body parameters

| Key | Type | Notes       |
|-----|------|-------------|
| id  | int  |             |

* Headers

```
Content-Type: application/json
```

* Schema

POST /api/single-sign-on/login/

```json
{
  "id": <int>,
} 
```

### Response

| Key          | Type   | Notes |
|--------------|--------|-------|
| redirect\_uri | url    |       |

* Successful status `200 OK`
* Response body:

```json
{ 
    "redirect_uri": "https://example-tenant.okta.com/oauth2/default/v1/authorize?client_id=YOUR_CLIENT_ID&response_type=code&scope=openid+profile+email&response_mode=query&token_endpoint_auth_method=client_secret_post&redirect_uri=https%3A%2F%2Fyour-app-domain.com%2Fsingle-sign-on%2Fcallback%2F1%2F&state=EXAMPLE_STATE_TOKEN"
}
```

### Errors

| Cause                | Response code    | Message                                                     |
|----------------------|------------------|-------------------------------------------------------------|
| No **id** in request | 400 Bad Request  | "detail": {"id":\["This field is required."]}            |
| No request body      | 400 Bad Request  | "detail": {"id":\["This field is required."]}            |
| Wrong type of data   | 400 Bad Request  | "detail": Invalid data. Expected a dictionary, but got str. |
| Invalid `id` in URL  | 404 Not Found    | "detail": \["Not found."]                                  |

## POST /api/single-sign-on/callback/`id`/

Retrieve the access and refresh tokens.

### Permissions

Public access endpoint is secured only with an SSO state parameter (CSRF protection only).

### Request

* Body parameters

| Key                | Type   | Notes                                                                                                                                                                                                                                                                                                                                                   |
|--------------------|--------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **id**             | int    |                                                                                                                                                                                                                                                                                                                                                         |
| **code**           | string | A temporary [authorization code](https://developer.okta.com/docs/guides/implement-grant-type/authcode/main/#about-the-authorization-code-grant) received from Okta that will be exchanged for an access token. Valid for a short time period and can only be used once when exchange it for tokens.                                                     |
| **state**          | string | An arbitrary alphanumeric string that the authorization server reproduces when redirecting the user agent back to the client. [authorization parameters](https://developer.okta.com/docs/guides/implement-grant-type/authcode/main/#request-an-authorization-code). This is used to help prevent cross-site request forgery. (optional)                 |
| **session\_state**  | string | Session State. JSON \[RFC7159] string that represents the End-User's login state at the OP. This value is opaque to the RP. [authorization parameters](https://learn.microsoft.com/en-us/previous-versions/azure/dn645542\(v=azure.100\)?redirectedfrom=MSDN#authorization-code-response). This is REQUIRED if session management is supported. (optional) |

* Headers

```
Content-Type: application/json
```

* Schema

POST /api/single-sign-on/callback/`id`/

```json
{
  "code": <string>,
  "state": <string>,  
  "session_state": <string>,
} 
```

### Response

| Key           | Type          | Notes |
|---------------|---------------|-------|
| refresh       | string        |       |
| access        | string        |       |

* Successful status `200 OK`
* Response body:

```json
{ 
    "refresh": "REFRESH_TOKEN", 
    "access": "ACCESS_TOKEN"
}
```

### Errors

| Cause                                                                 | Response code   | Message                                                                       |
|-----------------------------------------------------------------------|-----------------|-------------------------------------------------------------------------------|
| no **code** in request                                                | 400 Bad Request | "detail": {"code": \["This field is required."]}                           |
| One of parameters is blank                                            | 400 Bad Request | "detail": { "field": \["This field may not be blank."]}                    |
| One of parameters is null                                             | 400 Bad Request | "detail": { "field": \["This field may not be null."]}                     |
| Insufficient data, invalid code etc.                                  | 403 Forbidden   | "detail": "You do not have permission to perform this action."                |
| Login not allowed for account type restricted to password login only  | 403 Forbidden   | "detail": "This user account is not allowed to log in using Single Sign-On."  |
| Invalid `id` in URL                                                   | 404 Not Found   | "detail": \["Not found."]                                                    |

---

---
url: /api/catalyst/resources/outbound-mail-setup/smtp-settings.md
---
# SMTP Settings

Configuration of the SMTP server used for sending outbound emails from the tenant.

## OPTIONS /api/administration/smtp-settings/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/administration/smtp-settings/ 
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "details": {
        "schema": [
            {
                "alias": "password",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 128
                    }
                ]
            },
            {
                "alias": "host",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 63
                    }
                ]
            },
            {
                "alias": "port",
                "required": true,
                "type": "int"
            },
            {
                "alias": "tls",
                "type": "bool"
            },
            {
                "alias": "username",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 254
                    }
                ]
            },
            {
                "alias": "from_email",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "email"
                    },
                    {
                        "type": "max_length",
                        "length": 254
                    }
                ]
            },
            {
                "alias": "failure_email",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 255
                    },
                    {
                        "type": "max_value",
                        "length": 10
                    }
                ]
            },
            {
                "alias": "authorization_method",
                "type": "enum",
                "required": false,
                "values": [
                    {
                        "value": "username_and_password",
                        "text": "Username and Password"
                    },
                    {
                        "value": "microsoft_client_credentials",
                        "text": "Microsoft Client Credentials"
                    }
                ],
                "schema_by_authorization_method": [
                    {
                        "authorization_method": "username_and_password",
                        "schema": [
                            {
                                "alias": "password",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "max_length",
                                        "length": 128
                                    }
                                ]
                            }
                        ]
                    },
                    {
                        "authorization_method": "microsoft_client_credentials",
                        "schema": [
                            {
                                "alias": "authentication_object",
                                "type": "enum",
                                "required": true,
                                "autocomplete": "/api/authentication-objects/?provider=microsoft_client_credentials"
                            }
                        ]
                    }
                ]
            }
        ]
    }
}
```

## GET /api/administration/smtp-settings/

### Permissions

Requires `authentication` and `outbound_mail_setup.view` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/administration/smtp-settings/ 
```

### Response

| Key                   | Type   | Notes                                                       |
|-----------------------|--------|-------------------------------------------------------------|
| username              | string |                                                             |
| port                  | int    |                                                             |
| tls                   | bool   |                                                             |
| host                  | string |                                                             |
| from\_email            | string |                                                             |
| failure\_email         | string |                                                             |
| authorization\_method  | enum   | Values: username\_and\_password, microsoft\_client\_credentials |
| authentication\_object | int    |                                                             |

* Successful status `200 OK`
* Response body schema:

```json
{ 
 "username": "ticket.branch.mailserver@autologyx.net", 
 "port": 10587, 
 "tls": true, 
 "host": "clust.mx.nwc.xxx", 
 "from_email": "example1@email.com", 
 "failure_email": "example2@email.com, example9@email.com, example10@email.com, example11@email.com",
 "authorization_method": "username_and_password", 
 "authentication_object": null
} 
```

### Errors

| Error                                                | Response code | Message                                                        |
|------------------------------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions                             | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## PATCH /api/administration/smtp-settings/

### Permissions

Requires `authentication` and `outbound_mail_setup.edit` permission.

### Request

| Key                   | Type   | Notes                                                                  |
|-----------------------|--------|------------------------------------------------------------------------|
| password              | string |                                                                        |
| username              | string |                                                                        |
| port                  | int    |                                                                        |
| tls                   | bool   |                                                                        |
| host                  | string |                                                                        |
| from\_email            | string |                                                                        |
| failure\_email         | string |                                                                        |
| authorization\_method  | enum   | Values: username\_and\_password, microsoft\_client\_credentials            |
| authentication\_object | int    | Required when `authorization_method` is `microsoft_client_credentials` |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
PATCH /api/administration/smtp-settings/ 

{ 
   "password": "Passwod", 
   "username": "ticket.branch.mailserver@autologyx.net", 
   "port": 10587, 
   "tls": true, 
   "host": "clust.mx.nwc.xxx", 
   "from_email": "example1@email.com", 
   "failure_email": "example6@email.com, example7@email.com",
   "authorization_method": "microsoft_client_credentials",
   "authentication_object": 1
} 
```

### Response

| Key                   | Type   | Notes                                    |
|-----------------------|--------|------------------------------------------|
| username              | string |                                          |
| port                  | int    |                                          |
| tls                   | bool   |                                          |
| host                  | string |                                          |
| from\_email            | string |                                          |
| failure\_email         | string |                                          |
| authorization\_method  | string |                                          |
| authentication\_object | int    |                                          |

* Successful status `200 OK`
* Response body schema:

```json
{ 
 "username": "ticket.branch.mailserver@autologyx.net", 
 "port": 10587, 
 "tls": true, 
 "host": "clust.mx.nwc.xxx", 
 "from_email": "example1@email.com", 
 "failure_email": "example6@email.com, example7@email.com",
 "authorization_method": "microsoft_client_credentials",
 "authentication_object": 1
} 
```

### Errors

| Cause                                                                                           | Response code   | Message                                                                 |
|-------------------------------------------------------------------------------------------------|-----------------|-------------------------------------------------------------------------|
| "username" is empty string                                                                      | 400 Bad Request | "username": \["This field may not be blank."]                            |
| "username" is null                                                                              | 400 Bad Request | "username": \["This field may not be null."]                             |
| "username" has > 254 chars                                                                      | 400 Bad Request | "username": \["Ensure this field has no more than 254 characters."]      |
| "password" is empty string                                                                      | 400 Bad Request | "password": \["This field may not be blank."]                            |
| "password" is null                                                                              | 400 Bad Request | "password": \["This field may not be null."]                             |
| "password" has > 128 chars                                                                      | 400 Bad Request | "password": \["Ensure this field has no more than 128 characters."]      |
| "port" is required                                                                              | 400 Bad Request | "port": \["This field is required."]                                     |
| "port" is invalid                                                                               | 400 Bad Request | "port": \["A valid integer is required."]                                |
| "port" < 0                                                                                      | 400 Bad Request | "port": \["Ensure this value is greater than or equal to 0."]            |
| "port" > 65535                                                                                  | 400 Bad Request | "port": \["Ensure this value is less than or equal to 65535."]           |
| "tls" invalid                                                                                   | 400 Bad Request | "tls": \["Must be a valid boolean."]                                     |
| "host" is required                                                                              | 400 Bad Request | "host": \["This field is required."]                                     |
| "host" has > 63 chars                                                                           | 400 Bad Request | "host": \["Ensure this field has no more than 63 characters."]           |
| "from\_email" has > 254 chars                                                                    | 400 Bad Request | "from\_email": \["Ensure this field has no more than 254 characters."]    |
| "failure\_email" has > 255 chars                                                                 | 400 Bad Request | "failure\_email": \["Ensure this field has no more than 255 characters."] |
| "failure\_email" has > 10 comma separated items                                                  | 400 Bad Request | "failure\_email": \["Up to 10 items allowed."]                            |
| "authorization\_method" has invalid value                                                        | 400 Bad Request | "authorization\_method": \["{value} is not a valid choice."]              |
| "authentication\_object" is absent when "authorization\_method" is "microsoft\_client\_credentials" | 400 Bad Request | "authentication\_object": \["This field is required."]                    |
| "authentication\_object" has the wrong provider type for a given "authorization\_method"          | 400 Bad Request | "authentication\_object": \["{value} is not a valid choice."]             |
| Insufficient permissions                                                                        | 403 Forbidden   | "detail": "You do not have permission to perform this action."          |

## POST /api/administration/smtp-settings/test/

### Permissions

Requires `authentication` and `outbound_mail_setup.edit` permission.

### Request

| Key              | Type   | Notes |
|------------------|--------|-------|
| password         | string |       |
| username         | string |       |
| port             | int    |       |
| tls              | bool   |       |
| host             | string |       |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/administration/smtp-settings/test/ 

{ 
   "password": "Passwod", 
   "username": "ticket.branch.mailserver@autologyx.net", 
   "port": 10587, 
   "tls": true, 
   "host": "clust.mx.nwc.xxx",
   "authorization_method": "username_and_password"	
} 
```

### Response

| Key            | Type      | Notes                                    |
|----------------|-----------|------------------------------------------|
| status         | string    |                                          |
| msg            | string    |                                          |

* Successful status `200 OK`
* Response body schema:

```json
{
  "status":"OK",
  "msg":"Connection successfully tested."
}
```

### Errors

| Cause                                                | Response code   | Message                                                                                |
|------------------------------------------------------|-----------------|----------------------------------------------------------------------------------------|
| "username" is empty string                           | 400 Bad Request | "username": \["This field may not be blank."]                                           |
| "username" is null                                   | 400 Bad Request | "username": \["This field may not be null."]                                            |
| "username" has > 254 chars                           | 400 Bad Request | "username": \["Ensure this field has no more than 254 characters."]                     |
| "password" is empty string                           | 400 Bad Request | "password": \["This field may not be blank."]                                           |
| "password" is null                                   | 400 Bad Request | "password": \["This field may not be null."]                                            |
| "password" has > 128 chars                           | 400 Bad Request | "password": \["Ensure this field has no more than 128 characters."]                     |
| "port" is required                                   | 400 Bad Request | "port": \["This field is required."]                                                    |
| "port" is invalid                                    | 400 Bad Request | "port": \["A valid integer is required."]                                               |
| "port" < 0                                           | 400 Bad Request | "port": \["Ensure this value is greater than or equal to 0."]                           |
| "port" > 65535                                       | 400 Bad Request | "port": \["Ensure this value is less than or equal to 65535."]                          |
| "tls" invalid                                        | 400 Bad Request | "tls": \["Must be a valid boolean."]                                                    |
| "host" is required                                   | 400 Bad Request | "host": \["This field is required."]                                                    |
| "host" has > 63 chars                                | 400 Bad Request | "host": \["Ensure this field has no more than 63 characters."]                          |
| Failure during Ms Graph testing                      | 400 Bad Request | "detail": "Error. Please check username, authentication object and MS Graph settings"  |
| Insufficient permissions                             | 403 Forbidden   | "detail": "You do not have permission to perform this action."                         |

---

---
url: /knowledgebase/finding-your-way-around/some-things-you-might-find-useful.md
---
# Some Things You Might Find Useful

**Browse the sections below:**

* [Autologyx Terminology](/knowledgebase/terminology/)

---

---
url: /knowledgebase/release-notes/release-notes-1.3/sorting-records.md
---

# Sorting records

We are always striving to provide our customers with the best possible tools to streamline their workflows and increase productivity. That's why we are announcing the release of our latest feature: **sorting**.

![Sorting\_main.gif](/knowledgebase/images/img_11877905313181_1776895696.png)

## Overview

**Sorting** is a powerful tool that allows you to effortlessly organise your data based on different field types. Whether you're dealing with a disorganised records list or simply need to quickly find specific information, sorting can save you valuable time and effort.

**With the sorting feature,** you can easily arrange your data in ascending or descending order based on specific field types, such as integer, date, text, single select, or phone and e-mail. This provides you with a clear and concise view of your data, making it easier to identify patterns, trends, and outliers.

**As well as saving time,** sorting also provides greater clarity to your workflow. By organising your data in a logical and consistent manner, you can make more informed decisions and take action with confidence.

With the sorting tool in your arsenal, you'll be able to tackle any task with confidence and efficiency.

---

---
url: /knowledgebase/system-configuration/merge-fields/syntax-for-merge-fields.md
---

# Syntax for merge fields

Object class fields can be merged into Document Templates, Send Message Actors, Local Variables and API calls. Document templates are created for specific Object classes, as are sequences which contain these actors. A Word .docx document forms the basis of a document template.

Fields from the Object class can be merged into the template so that it can be personalised for individual records.

Fields from any related Object classes can also be merged into the template.

The Word Add-in can be used to help configure your merge fields, IF Statements, if required, and other functions such as For or Group Statements.

However, if you don't have access to the Word Add-in, you can still create a comprehensive template by manually adding the merge fields. You just need to know the correct syntax for your merges.

## Example relational model

As an example, the template for a Lease Agreement is to be created; the document template will be configured against the Lease object class. The relational model is shown below:

![Screenshot 2024-01-15 at 19.28.41.png](/knowledgebase/images/img_16109388382877_1776895799.png)

**The model consists of the following Object classes:**

* **Site** (parent) - object class ID 11
* **Lease** (child) - object class ID 14 - this is where the Lease document will be generated
* **Landlord** (child) - object class ID 51
* **Tenant** (grandchild) - object class ID 52

## Merge field syntax examples

### From object class **Lease**

When merging fields from object class Lease, these will take the following format:

```jinja
{{record.field\_start\_date}}
```

### From object class **Site**

When merging fields from object class Site, which is the parent of Lease, the format will be slightly different:

```jinja
{{record.related\_records\_11[0].field\_site\_name}}
```

```jinja
{{record.related\_records\_11[0].field\_site\_address}}
```

### From object class **Tenant**

This format is also used when merging fields from object class Tenant (a child of Lease):

```jinja
{{record.related\_records\_52[0].field\_tenant\_first\_name}}
```

```jinja
{{record.related\_records\_52[0].field\_tenant\_last\_name}}
```

### From object class **Landlord**

However, when merging fields from object class Landlord, the following will be required as there is no direct link between Lease and Landlord:

```jinja
{{record.related\_records\_11[0].related\_records\_51[0].field\_landlord\_contact\_first\_name}}
```

```jinja
{{record.related\_records\_11[0].related\_records\_51[0].field\_landlord\_contact\_last\_name}}
```

## How to read the syntax

In the relational merge fields, the **\[0]** denotes the most recently related record. This is the index. You can see from the relational model that a Site can have more than one Lease and more than one Landlord, while a Lease can have more than one Tenant. The number preceding **\[0]** is the object class ID.

## Using a guard clause

Unless you are absolutely certain at the point of generating the document that all indexed related records are in place, you should make use of a **guard clause** in the form of an IF Statement wrapped around the merge field. This ensures that the process is not broken.

**Example:**

```jinja
{%if record.related\_records\_11
```

and

record.related\_records\_11\[0].related\_records\_51

and

record.related\_records\_11\[0].related\_records\_51\[0].field\_status == active%}

```jinja
{{record.related\_records\_11[0].related\_records\_51[0].field\_landlord\_address }}
```

```jinja
{%else%}
```

'Landlord absent'

```jinja
{%endif%}
```

## Useful info

1. Jinja2 is a templating engine used in Autologyx to dynamically generate content using data, logic, and expressions.
2. The maximum number of parent/child levels for any relationship is **5**. This limit is from the root parent (or top object class) down to the deepest descendent.
3. The maximum number of child object classes another object class can have is **5**.
4. Fields from any object class in the relationship can be included in a document template created for any object class in the same relationship.
5. A guard clause is also known as "existing checking" or "null checking".

---

---
url: >-
  /knowledgebase/finding-your-way-around/some-things-you-might-find-useful/system-areas.md
---

# System areas

---

---
url: /knowledgebase/system-configuration.md
---
# System Configuration

**System Configuration** is where Autologyx is configured to solve a business problem.

It is most relevant to **Config Admins**, analysts, solution designers, and other builders who are responsible for shaping how the platform behaves. This is where you define the data model, design workflows, configure tasks, automate document handling, connect external systems, and shape the user experience for the people using the solution.

**In contrast:**

* the **Workspace** is where end users carry out day-to-day work with records, tasks, and documents
* **Administration** is where system-wide settings such as users, groups, roles, authentication, and security-related configuration are managed

**System Configuration** is about building the solution itself.

## What you will find in this section

### Understand the area

**Start here** if you want an overview of what System Configuration is for and how it fits into the wider platform.

* [About System Configuration](/knowledgebase/system-configuration/about-system-configuration/)

### Build the data model

These areas define the structure of your application and the data it works with.

* [Create and manage your data model](/knowledgebase/system-configuration/create-and-manage-your-data-model/)
* [Object Classes](/knowledgebase/system-configuration/object-classes/)
* [Object class relationships](/knowledgebase/system-configuration/object-class-relationships/)
* [Relational Modeller](/knowledgebase/system-configuration/relational-modeller/)

### Design workflow and automation

These areas are about configuring process logic, task orchestration, and workflow automation.

* [Sequences](/knowledgebase/system-configuration/sequences/)
* [Sequence Actors](/knowledgebase/system-configuration/sequence-actors/)
* [Sequences for relational records](/knowledgebase/system-configuration/sequences-for-relational-records/)
* [Task Templates](/knowledgebase/system-configuration/task-templates/)
* [Task Group Templates](/knowledgebase/system-configuration/task-group-templates/)
* [Task Management](/knowledgebase/system-configuration/task-management/)

### Configure documents, variables, and integrations

These areas help you work with dynamic values, generated outputs, APIs, and external services.

* [Working with Document Templates](/knowledgebase/system-configuration/working-with-document-templates/)
* [Document Automation](/knowledgebase/system-configuration/document-automation/)
* [Merge Fields](/knowledgebase/system-configuration/merge-fields/)
* [APIs and Variables](/knowledgebase/system-configuration/apis-and-variables/)
* [Using DocuSign with Catalyst](/knowledgebase/system-configuration/using-docusign-with-catalyst/)

### Shape the user experience

These areas control how the configured solution is presented to users.

* [Landing page](/knowledgebase/system-configuration/landing-page/)
* [Landing page and Theme](/knowledgebase/system-configuration/landing-page-and-theme/)
* [Theme](/knowledgebase/system-configuration/theme/)

### Advanced and specialist capabilities

These pages cover more specialist configuration features.

* [AppliedAI](/knowledgebase/applied-ai/)

## Suggested path

If you are building a new solution in Autologyx, a sensible order is:

1. define the data model
2. configure workflow and task behaviour
3. add documents, variables, and integrations
4. shape the user experience for end users

## Notes

::: info
System Configuration is focused on building and maintaining solutions in Autologyx, rather than carrying out operational work in the Workspace or managing global administration settings.
:::

::: tip
If you are new to building in Autologyx, a good place to begin is **About System Configuration**, then **Object Classes**, **Relational Modeller**, and **Sequences**.
:::

---

---
url: /knowledgebase/release-notes/release-notes-1.5/task-assignment-actor.md
---

# Task assignment actor

Efficiency is the backbone of any successful business, and Autologyx Catalyst 1.5 is here to deliver just that.

The Task assignment actor offers a revolutionary way to optimize task assignment within the Sequencer. It allows Sequence designers to configure task assignees effortlessly, ensuring that tasks are directed to the right individuals or teams with utmost efficiency.

## Configuration options

The **Task assignment actor** comes with a powerful configuration, featuring options to **override or append default task assignees**.

You can customize task assignees based on users or users selected in a user-type field, tailoring task management to fit your unique workflow needs.

Additionally, the **Task assignment actor** goes a step further by enabling you to **set the task owner**, selected either from users or designated within User type fields.

![TaskAsignees1\_article.gif](../../../images2/zendesk_12725892635165_001_289975365388.gif)

## Error handling

We've paid special attention to **error handling** to ensure a smooth experience. The actor validates your selections and highlights any missing or incorrect fields, helping you avoid potential hiccups during configuration.

![TaskAsignees2\_article.gif](../../../images2/zendesk_12725892635165_002_d1450afaa2cd.gif)

## Integration with Create task actor

**Connecting actors**

Maximize task efficiency and accountability by connecting the Task assignment actor's outgoing triggers to the Create task actor. This targeted approach ensures tasks are directed to the right recipients, enhancing overall task management.

Whether you're new to workflow automation or a seasoned pro, the **Task assignment actor** is designed to enhance your experience. Step into the future of task management with the new Task assignment actor, the latest star of our Sequencer lineup!

---

---
url: /knowledgebase/system-configuration/sequence-actors/task-assignment-actor.md
---

# Task Assignment Actor

## What does the Task Assignment actor do?

The Task Assignment actor is used before a [**Create Task**](/knowledgebase/system-configuration/sequence-actors/create-task-actor/) or [**Set Task**](/knowledgebase/system-configuration/sequence-actors/set-task-actor/) actor to allow the selection of a user to be the Task Owner or Users to become Task Assignees. It is designed to ensure that tasks are efficiently directed to the appropriate individuals or teams.

The Task Owner or any Task Assignee can complete the task.

Depending on whatever other class or record permissions you may have set up, you can restrict task completion to only users who are made the owner or an assignee of a task via this actor.

## How do I use the Task Assignment actor?

Click, drag and drop the Task Assignment actor onto your sequence workspace.

Right click on the Task Assignment actor and select Configure. The Task Assignment Configuration window will open.

![Screenshot 2026-04-13 at 17.55.02.png](/knowledgebase/images/img_5634236848415_1776895831.png)

The default configuration has **Configure task assignees** ticked and **Override task assignees** selected, as it is the most commonly used. This can be unticked if not required.

### Configure task assignees

#### Override task assignees

This option will **REMOVE** any default task assignees/owners defined in the Sequence Properties and replace them with the users specified in the actor for this task.

Users can be selected **By users** or **By field**.

### By users

Tick the box and start typing the name of the required user. The user list will filter accordingly.

![Screenshot 2026-04-14 at 12.56.03.png](/knowledgebase/images/img_5634236848415_1776895831.png)

Click on the required user and either save the configuration or, if more than one assignee is appropriate, start typing again. You can of course scroll through the list if you prefer.

![Screenshot 2026-04-14 at 12.57.58.png](/knowledgebase/images/img_5634236848415_1776895831.png)

Continue selecting users and save the configuration.

Note that you have the option to select the **Record owner**, if required.

![Screenshot 2026-04-14 at 14.24.59.png](/knowledgebase/images/img_5634236848415_1776895831.png)

### By field

Tick the box and click into the **Search for field** drop down.

All user type fields associated with the sequence's object class will be shown.

![Screenshot 2026-04-14 at 13.01.33.png](/knowledgebase/images/img_5634236848415_1776895832.png)

This is a single selection; only one field can be chosen. Click on it and save the configuration.

If one user has been selected in this field on the record, they will become a task assignee and will be able to view and complete the task.

If several users have been selected in this field on the record, they will all become task assignees and any one of them will be able to view and complete the task.

It is possible to use a combination of task assignment **By users** and **By field**. All users selected will become task assignees:

![Screenshot 2026-04-14 at 16.56.08.png](/knowledgebase/images/img_5634236848415_1776895832.png)

#### Append task assignees

This option will add the specified users **in addition to** any defaults defined in the sequence properties.

![Screenshot 2026-04-15 at 14.46.25.png](/knowledgebase/images/img_5634236848415_1776895832.png)

### Configure task ownership

**Set task owner** is the only option in this section.

The **Record owner** can be selected as the task owner.

Task ownership can also be configured **By users** or **By field**, but **not both**.

Only one task owner can be assigned.

![Screenshot 2026-04-14 at 16.59.35.png](/knowledgebase/images/img_5634236848415_1776895833.png)

However this is configured, the selected user will become both the task owner and a task assignee.

**Best practice:** As with all other sequence actors, it is best practice to replace the default actor name with something more descriptive or meaningful.

Right click on the actor and select Properties. Enter the new label and save.

![Screenshot 2026-04-15 at 15.15.19.png](/knowledgebase/images/img_5634236848415_1776895833.png)

|  |  |
| --- | --- |
| The new label will appear under the Task Assignment actor. | Screenshot 2026-04-15 at 15.20.08.png |

**Note:** In addition to Users, User Groups can also be made Assignees of tasks to allow any User within that User Group to complete the task. However, currently this is configured using an API call after the Task is created.

## Useful info

1. A task assignee can take ownership and a task owner can give up ownership of a task, but they will still remain a task assignee.
2. A Task Assignment actor can follow any sequence actor (other than a Sequence Runner) but should precede only a Create Task actor or Set Task actor.

---

---
url: /api/websockets/resources/tasks.md
---
# Task Events

This page documents the WebSocket endpoint used to receive real-time Task change events in Catalyst.

The endpoint broadcasts Task-related events so that connected clients can reflect changes without polling or refreshing the page. It is intended for real-time UI updates and event-driven integrations that need to track Task creation, updates, ownership changes, assignment changes, and deletion.

::: warning
This section documents technical and service-level WebSocket APIs. It should be used as implementation reference material and not treated as end-user documentation.
:::

## Endpoint overview

This page covers the following endpoint:

* `GET /ws/events/tasks/`

## GET /ws/events/tasks/

Subscribes the client to a stream of Task change events.

The endpoint broadcasts updates for up to 1,000 tasks every 5 seconds.

### Permissions

Requires `authentication`.

Authentication is based on the `uuid` query string parameter used when establishing the WebSocket connection.

### Request

#### Upgrade request example

```text
Request Method: GET
Connection: Upgrade
Upgrade: websocket
```

### Response

After the connection is established, the server sends a list of Task change events.

Each list item contains the following fields:

| Key | Type | Notes |
|---|---|---|
| task\_id | int | Task identifier |
| object\_class\_id | int | Related Object Class identifier |
| event | string | Task event type |
| timestamp | datetime | Time the event was created |

### Available events

The following event values are supported:

* `task_created`
* `task_value_changed`
* `task_status_changed`
* `task_owner_added`
* `task_owner_removed`
* `task_assignee_added`
* `task_assignee_removed`
* `task_deleted`

### Success

* WebSocket upgrade status: `101 Switching Protocols`

#### Example payload

```json
[
  {
    "task_id": 1,
    "object_class_id": 1,
    "event": "task_created",
    "timestamp": "2025-01-16T11:07:57.954470+00:00"
  },
  {
    "task_id": 1,
    "object_class_id": 1,
    "event": "task_status_changed",
    "timestamp": "2025-01-16T11:07:57.934931+00:00"
  },
  {
    "task_id": 1,
    "object_class_id": 1,
    "event": "task_deleted",
    "timestamp": "2025-01-16T11:08:07.444085+00:00"
  }
]
```

## Ordering and delivery

Sorting cannot be controlled by the client.

By default, events are delivered in creation order. Where results are chunked, events are ordered in ascending order by event timestamp.

## Errors

| Error | Response code / close status | Message |
|---|---|---|
| Incorrect WebSocket URL path | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_INCORRECT_URL", "detail":"Incorrect WebSocket URL."` |
| Invalid UUID | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_INVALID_UUID", "detail":"A valid UUID is required."` |
| Sending messages to this WebSocket is not supported | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "RECEIVE_NOT_SUPPORTED", "detail": "This WebSocket connection does not support receiving messages."` |
| Rate limit exceeded | `Close: 1000 Normal Closure` | `"type": "error", "error_code": "ERR_RATE_LIMIT_EXCEEDED", "detail":"The rate limit for requests has been exceeded. Please wait before trying again."` |
| Error during the handshake | `500 Internal Server Error` | |

## Notes

WebSocket standard close/error definitions are described in [RFC 6455](https://datatracker.ietf.org/doc/html/rfc6455#section-7.4.1).

---

---
url: >-
  /knowledgebase/record-and-task-forms/formbuilder-components/task-form-fields-and-how-to-configure-them.md
---

# Task Form fields and how to configure them

This article helps you create better Task templates by explaining the standalone field types available in Task forms and how they can be configured.

## Field types available in Task Templates

There are two types of fields available in Task Templates:

* **Standalone fields** - available in both types of Task template
* **Object class fields** - available only in Task templates of the Update object record type

This article focuses on **Standalone fields**, which are specific to the Task template in which they are configured.

In a Task template of the Update object record type, you can use a mixture of Standalone fields and Object class fields.

[Find out more about Object class fields](/knowledgebase/system-configuration/object-classes/object-class-field-types-uses-and-attributes/).

## Properties common to all field types

The following properties are common to most Standalone field types.

* **Label** - the name of the field as it appears on the form. Unlike labels for Object class fields, these labels do not have to be unique.
* **Alias** - automatically populated from the field label. The alias must be unique. If you have more than one field with the same label, you must append a number or change the alias. If you save without changing a duplicate alias, Catalyst automatically changes it to `new_input_#`.
* **Required** - makes the field mandatory on the Task form. The user completing the task cannot submit the form without providing a value. This option is not available for JSON fields.
* **Read-only** - greys out the field so the user completing the form cannot enter or change a value.
* **Description** - allows you to add instructional text below the field input.

Aliases for Standalone fields in Task templates are used as keys in Task responses. They are also used in conditions for defining Conditional Visibility on form sections.

![Alias field configuration in a Task template field properties panel](/knowledgebase/images/records-and-tasks/task-form-fields-1.png)

Descriptions appear below the field in the Task template configuration.

![Description text configured below a Task template field](/knowledgebase/images/records-and-tasks/task-form-fields-2.png)

The same description is shown to the user on the Task form.

![Description text displayed below a field on the Task form](/knowledgebase/images/records-and-tasks/task-form-fields-3.png)

## Standalone field types

The following Standalone field types are available in Task Templates.

### Textbox

The **Textbox** field allows the user to enter freeform text.

It is useful for gathering non-specific information, such as a witness statement. It is less useful for management information reporting because the content entered by users may be inconsistent.

The input type can be set to:

* **Single line**
* **Multi line**

![Single line and multi line Textbox fields displayed on a Task form](/knowledgebase/images/records-and-tasks/task-form-fields-4.png)

You can enter a default value, which can be overwritten by the user completing the form.

The validation options allow you to set a maximum number of characters. The validation is shown on the **Default value** field.

![Textbox field configuration showing default value and validation settings](/knowledgebase/images/records-and-tasks/task-form-fields-5.png)

### Numeric

The **Numeric** field type allows you to capture whole numbers and numbers with decimal places.

The **Precision** setting controls the number of decimal places and can be set from 0 to 10.

Validation allows you to set a minimum and/or maximum value.

![Numeric field displayed on a Task form](/knowledgebase/images/records-and-tasks/task-form-fields-6.png)

With the settings shown below, the user cannot enter a value outside the specified range.

![Numeric field configuration showing precision and validation settings](/knowledgebase/images/records-and-tasks/task-form-fields-7.png)

### Date / Time picker

The **Date / Time picker** field type has three input types:

* **Date**
* **Date and time**
* **Time**

The **Date** input type presents a calendar widget on the Task form.

![Date picker field displayed with a calendar widget](/knowledgebase/images/records-and-tasks/task-form-fields-8.png)

The **Date and time** input type presents a calendar and time picker.

If your account language preference is set to English (UK), the time picker uses a 24-hour clock. If your language preference is English (USA), the time picker uses a 12-hour clock with AM and PM options.

This is useful for meeting details and other time-sensitive event data.

![Date and time picker field displayed on a Task form](/knowledgebase/images/records-and-tasks/task-form-fields-9.png)

![Date and time picker configuration settings](/knowledgebase/images/records-and-tasks/task-form-fields-10.png)

The **Time** input type presents a time picker using either a 12-hour or 24-hour clock, depending on the user's preferences.

![Time picker field displayed on a Task form](/knowledgebase/images/records-and-tasks/task-form-fields-11.png)

![Time picker configuration settings](/knowledgebase/images/records-and-tasks/task-form-fields-12.png)

The input types that include time also have a **Now** option, which populates the field with the current date and time or the current time.

Validation allows you to specify that only dates in the future are acceptable.

### Checkbox

The **Checkbox** field type presents a checkbox on the Task form, with the field label shown to the right.

![Checkbox field displayed on a Task form](/knowledgebase/images/records-and-tasks/task-form-fields-13.png)

As with other field types, the Description is displayed underneath.

Checkboxes are commonly used to confirm, affirm, agree, or opt out.

If you make a Checkbox field required, the user cannot submit the Task form without ticking it.

![Checkbox field configuration settings](/knowledgebase/images/records-and-tasks/task-form-fields-14.png)

### Single select and Multi select

The maximum number of options that can be configured is 100.

**Single select** options can be presented as:

* radio buttons
* a dropdown list

**Multi select** options are presented as a checkbox list.

![Single select options displayed as radio buttons](/knowledgebase/images/records-and-tasks/task-form-fields-15.png)

![Single select options displayed as a dropdown list](/knowledgebase/images/records-and-tasks/task-form-fields-16.png)

![Single select field configuration settings](/knowledgebase/images/records-and-tasks/task-form-fields-17.png)

On Single select fields, you can set a default value.

![Single select default value configuration](/knowledgebase/images/records-and-tasks/task-form-fields-18.png)

On Multi select fields, you can set the minimum and maximum number of options allowed.

![Multi select field displayed as a checkbox list](/knowledgebase/images/records-and-tasks/task-form-fields-19.png)

![Multi select validation settings](/knowledgebase/images/records-and-tasks/task-form-fields-20.png)

### Email

The **Email** field type is displayed on the Task form with an **@** symbol at the end.

It includes built-in validation and expects a recognised email format, such as `prefix@domain.xx`.

![Email field validation message on a Task form](/knowledgebase/images/records-and-tasks/task-form-fields-21.png)

The user completing the form must correct the error before the submit button is enabled.

![Email field configuration settings](/knowledgebase/images/records-and-tasks/task-form-fields-22.png)

### Country selector

The **Country selector** field presents a searchable alphabetical single-select dropdown list.

![Country selector dropdown displayed on a Task form](/knowledgebase/images/records-and-tasks/task-form-fields-23.png)

It is useful for address details and application forms.

![Country selector field configuration settings](/knowledgebase/images/records-and-tasks/task-form-fields-24.png)

### Phone number

The **Phone number** field type is displayed on the Task form with a phone symbol at the end.

![Phone number field displayed on a Task form](/knowledgebase/images/records-and-tasks/task-form-fields-25.png)

The field is restricted to 15 characters.

For example, a UK mobile number can be entered in formats such as:

* `+44 7890 123456`
* `07890 123456`
* `07890123456`

![Phone number field configuration settings](/knowledgebase/images/records-and-tasks/task-form-fields-26.png)

### File upload

The **File upload** field type is used to collect documents in a task.

The field validation allows you to set the maximum number of files that can be uploaded, from 1 to 10.

When the field is displayed on the Task form, the user is told how many files can be uploaded. Drag and drop and browse functions are supported.

![File upload field displayed on a Task form](/knowledgebase/images/records-and-tasks/task-form-fields-27.png)

Documents uploaded in error can be removed with the **delete** button.

![Uploaded file shown with delete button](/knowledgebase/images/records-and-tasks/task-form-fields-28.png)

![File upload field configuration settings](/knowledgebase/images/records-and-tasks/task-form-fields-29.png)

There is no restriction on file type, but the maximum file size is 50MB.

### URL

The **URL** field type is used to capture website, form, or other web addresses.

This field has front-end validation, which means that the form cannot be saved if the entry does not use the correct URL format.

![URL field validation message on a Task form](/knowledgebase/images/records-and-tasks/task-form-fields-30.png)

![URL field configuration settings](/knowledgebase/images/records-and-tasks/task-form-fields-31.png)

### JSON

The **JSON** field type allows you to store complex data structures within a single field in a Task form.

![JSON field displayed on a Task form](/knowledgebase/images/records-and-tasks/task-form-fields-32.png)

![JSON field configuration settings](/knowledgebase/images/records-and-tasks/task-form-fields-33.png)

## Things to remember

1. Each Task form can have up to 2,000 fields, which means you can create detailed and comprehensive forms.
2. The system limit for Task templates is 10,000.
3. Standalone field aliases must be unique within the Task template.
4. Required fields must be completed before the Task form can be submitted.
5. Some field types include validation rules that control what users can enter.

---

---
url: /api/catalyst/resources/tasks/task-group-templates.md
---
# Task Group Templates

### References

# Task Group Templates API

## POST /api/task-group-templates/

Creates Task Group Template.

### Permissions

Requires `authentication` and `task_group_templates.create` permission.

### Request

* Body parameters

| Key            | Type     | Notes       |
|----------------|----------|-------------|
| name           | str      |             |
| object\_classes | Array    |             |
| task\_templates | Array    |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/task-group-templates/

{
    "name": "Test Task Group Template",
    "object_classes": [
        1
    ],
    "task_templates": [
        1
    ]
}
```

### Validations

* name
  * is string
  * is required
  * is not null
  * is not blank
  * is unique (case insensitive)
  * max length is 100
* description
  * is string
  * max length is 500
* object\_classes
  * is required
  * is list of Object Classes ids
  * is not empty
* task\_templates
  * is required
  * is list of manual type Task Templates ids
  * is not empty

### Response

| Key               | Type   | Notes                                                              |
|-------------------|--------|--------------------------------------------------------------------|
| id                | uuid   |                                                                    |
| name              | string |                                                                    |
| description       | string |                                                                    |
| object\_classes    | Array  |                                                                    |
| task\_templates    | Array  |                                                                    |
| created\_at        | date   |                                                                    |
| created\_by        | user   |                                                                    |
| modified\_at       | date   |                                                                    |
| modified\_by       | user   |                                                                    |
| \_meta             | Object | [\_meta](#response-meta-object) result     |

### Response `_meta` object

| Key                     | Type          | Notes |
|-------------------------|---------------|-------|
| permission              | Object        |       |
| labels.object\_classes   | Array         |       |
| labels.task\_templates   | Array         |       |

* Successful status `201 Created`
* Response body schema

```json
{
  "id": 1,
  "name": "Test 1",
  "description": "Desc for Test 1",
  "object_classes": [
    1
  ],
  "task_templates": [],
  "created_at": "2022-05-17T13:18:49.312474+02:00",
  "created_by": {
    "id": 2,
    "first_name": "John",
    "last_name": "Kowalsky",
    "username": "John.Kowalsky@autologyx.com",
    "company_name": "",
    "is_deleted": false
  },
  "modified_at": "2022-05-17T13:18:49.312496+02:00",
  "modified_by": null,
  "_meta": {
    "permissions": {
      "list": true,
      "view": true,
      "create": true,
      "edit": true,
      "delete": true
    },
    "labels": {
      "object_classes": [
        "Object test name"
      ],
      "task_templates": []
    }
  }
}
```

### Errors

| Cause                       | Response code   | Message                                                                  |
|-----------------------------|-----------------|--------------------------------------------------------------------------|
| "name" is missing           | 400 Bad Request | "name": \["This field is required."]                                      |
| "name" is empty             | 400 Bad Request | "name": \["This field may not be blank."]                                 |
| "name" is not unique        | 400 Bad Request | "name": \["This field must be unique."]                                   |
| "name" is too long          | 400 Bad Request | "name": \["Ensure this field has no more than 100 characters."]           |
| "description" is too long   | 400 Bad Request | "description": \["Ensure this field has no more than 500 characters."]    |
| "object\_classes" is missing | 400 Bad Request | "object\_classes": \["This field is required."]                            |
| "object\_classes" is empty   | 400 Bad Request | "object\_classes": \["This list may not be empty."]                        |
| "object\_classes" invalid pk | 400 Bad Request | "object\_classes": \["Invalid pk "pk" - object does not exist."]         |
| "task\_templates" invalid pk | 400 Bad Request | "task\_templates": \["Invalid pk "pk" - object does not exist."]         |
| "task\_templates" is missing | 400 Bad Request | "task\_templates": \["This field is required."]                            |
| "task\_templates" is manual  | 400 Bad Request | "task\_templates": \["Manual task templates can't be used: Name1, Name2."] |
| Insufficient permissions    | 403 Forbidden   | "detail": "You do not have permission to perform this action."           |

## PATCH /api/task-group-templates/`id`/

Updates single Task Group Template.

### Permissions

Requires `authentication` and `task_group_templates.edit` permission.

### Allowed parameters

| Key            | Type     | Notes       |
|----------------|----------|-------------|
| name           | str      |             |
| object\_classes | Array    |             |
| task\_templates | Array    |             |

Any parameter not listed above are silently ignored if passed.

### Request

* Headers

```
Request Method: PATCH
Content-Type: application/json
Location: /api/task-group-templates/1/
Authorization: JWT access_token
```

* Sample request body

```json
{
    "name": "Test Task Group Template",
    "object_classes": [
        1
    ],
    "task_templates": []
}
```

### Validations

* name
  * is string
  * is required
  * is not null
  * is not blank
  * is unique (case insensitive)
  * max length is 100
* description
  * is string
  * max length is 500
* object\_classes
  * is required
  * is list of Object Classes ids
  * is not empty
* task\_templates
  * is required
  * is list of manual type Task Templates ids
  * is not empty

### Response

| Key               | Type   | Notes                                                              |
|-------------------|--------|--------------------------------------------------------------------|
| id                | uuid   |                                                                    |
| name              | string |                                                                    |
| description       | string |                                                                    |
| object\_classes    | Array  |                                                                    |
| task\_templates    | Array  |                                                                    |
| created\_at        | date   |                                                                    |
| created\_by        | user   |                                                                    |
| modified\_at       | date   |                                                                    |
| modified\_by       | user   |                                                                    |
| \_meta             | Object | [\_meta](#response-meta-object) result     |

### Response `_meta` object

| Key                     | Type          | Notes |
|-------------------------|---------------|-------|
| permission              | Object        |       |
| labels.object\_classes   | Array         |       |
| labels.task\_templates   | Array         |       |

* Successful status `200 Ok`
* Response body schema

```json
{
  "id": 1,
  "name": "Test Task Group Template",
  "description": "Desc for Test 1",
  "object_classes": [
    1
  ],
  "task_templates": [],
  "created_at": "2022-05-17T13:18:49.312474+02:00",
  "created_by": {
    "id": 2,
    "first_name": "John",
    "last_name": "Kowalsky",
    "username": "John.Kowalsky@autologyx.com",
    "company_name": "",
    "is_deleted": false
  },
  "modified_at": "2022-05-17T13:18:49.312496+02:00",
  "modified_by": null,
  "_meta": {
    "permissions": {
      "list": true,
      "view": true,
      "create": true,
      "edit": true,
      "delete": true
    },
    "labels": {
      "object_classes": [
        "Object test name"
      ],
      "task_templates": []
    }
  }
}
```

### Errors

| Cause                       | Response code   | Message                                                                  |
|-----------------------------|-----------------|--------------------------------------------------------------------------|
| "name" is missing           | 400 Bad Request | "name": \["This field is required."]                                      |
| "name" is empty             | 400 Bad Request | "name": \["This field may not be blank."]                                 |
| "name" is not unique        | 400 Bad Request | "name": \["This field must be unique."]                                   |
| "name" is too long          | 400 Bad Request | "name": \["Ensure this field has no more than 100 characters."]           |
| "description" is too long   | 400 Bad Request | "description": \["Ensure this field has no more than 500 characters."]    |
| "object\_classes" is missing | 400 Bad Request | "object\_classes": \["This field is required."]                            |
| "object\_classes" is empty   | 400 Bad Request | "object\_classes": \["This list may not be empty."]                        |
| "object\_classes" invalid pk | 400 Bad Request | "object\_classes": \["Invalid pk "pk" - object does not exist."]         |
| "task\_templates" invalid pk | 400 Bad Request | "task\_templates": \["Invalid pk "pk" - object does not exist."]         |
| "task\_templates" is missing | 400 Bad Request | "task\_templates": \["This field is required."]                            |
| "task\_templates" is manual  | 400 Bad Request | "task\_templates": \["Manual task templates can't be used: Name1, Name2."] |
| Insufficient permissions    | 403 Forbidden   | "detail": "You do not have permission to perform this action."           |

## DELETE /api/object-classes/`object_class_id`/

Remove a Task Group Template with checking if no used anywhere.

### Permissions

Requires `authentication` and `task_group_templates.delete` permission.

### Request example

* Headers

```
Request Method: DELETE
Location: /api/task-group-templates/1/
Authorization: JWT access_token
```

### Response example

* Status `204 No Content`
* Body

### Errors

| Error                             | Response code | Message                                                        |
|-----------------------------------|---------------|----------------------------------------------------------------|
| Task Group Template in use        | 400 Forbidden | "detail": "Task Group Template is in use by Sequences."        |
| Insufficient permissions          | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Task template does not exist      | 404 Forbidden | "detail": "Not found"                                          |

## GET /api/task-group-templates/

List Task group templates based on query parameters and caller permissions.

### Permissions

Requires `authentication` and `task_group_templates.list` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/task-group-templates/
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key                    | Type     | Notes                                                          |
|------------------------|----------|----------------------------------------------------------------|
| id                     | id       |                                                                |
| name                   | string   |                                                                |
| description            | string   |                                                                |
| object\_classes         | Array    |                                                                |
| num\_of\_task\_templates  | int      |                                                                |
| created\_at             | datetime |                                                                |
| created\_by             | user     |                                                                |
| modified\_at            | datetime |                                                                |
| modified\_by            | user     |                                                                |
| \_meta                  | Object   | [\_meta](#response-meta-object) result |

### Response `_meta` object

| Key             | Type      | Notes                                                  |
|-----------------|-----------|--------------------------------------------------------|
| permission      | Object    | Object describing permissions.                         |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 2,
  "total_count": 2,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 1,
      "name": "TG 1",
      "description": "Desc for task group 1",
      "object_classes": [
        "OC 1"
      ],
      "num_of_task_templates": 0,
      "created_at": "2022-05-17T13:18:49.312474+02:00",
      "created_by": {
        "id": 2,
        "first_name": "John",
        "last_name": "Kowalsky",
        "username": "John.Kowalsky@autologyx.com",
        "company_name": "",
        "is_deleted": false
      },
      "modified_at": "2022-10-11T11:54:17.541591+02:00",
      "modified_by": {
        "id": 2,
        "first_name": "John",
        "last_name": "Kowalsky",
        "username": "John.Kowalsky@autologyx.com",
        "company_name": "",
        "is_deleted": false
      },
      "_meta": {
        "permissions": {
          "list": true,
          "view": true,
          "create": true,
          "edit": true,
          "delete": true
        }
      }
    }
  ]
}
```

### Sorting

| Parameter              | Example                                               | Notes          |
|------------------------|-------------------------------------------------------|----------------|
| id                     | {build}/api/tasks/?ordering=id                        | Ascending      |
| id                     | {build}/api/tasks/?ordering=-id                       | Descending (-) |
| name                   | {build}/api/tasks/?ordering=name                      | Ascending      |
| name                   | {build}/api/tasks/?ordering=-name                     | Descending (-) |
| num\_of\_task\_templates  | {build}/api/tasks/?ordering=-num\_of\_task\_templates    | Ascending (-)  |
| num\_of\_task\_templates  | {build}/api/tasks/?ordering=-num\_of\_task\_templates    | Descending (-) |
| created\_at             | {build}/api/tasks/?ordering=created\_at                | Ascending      |
| created\_at             | {build}/api/tasks/?ordering=-created\_at               | Descending (-) |
| modified\_at            | {build}/api/tasks/?ordering=modified\_at               | Ascending      |
| modified\_at            | {build}/api/tasks/?ordering=-modified\_at              | Descending (-) |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter    | Predicates        | Example                                                                   |
|--------------|-------------------|---------------------------------------------------------------------------|
| id           | standard pk       | {build}/api/tasks/?id=1                                                   |
| name         | standard string   | {build}/api/tasks/?name\_\_icontains=foobar                                 |
| created\_at   | standard datetime | {build}/api/tasks/?created\_at\_\_gte=2022-01-01                             |
| created\_by   | standard set      | {build}/api/tasks/?created\_by\_\_in=123,234,345                             |
| modified\_at  | standard datetime | {build}/api/tasks/?modified\_at\_\_range=2022-01-01,2022-01-31               |
| modified\_by  | standard set      | {build}/api/tasks/?modified\_by=123                                        |

## GET /api/task-group-templates/`task_group_templates_id`/

### Permissions

Requires `authentication` and `task_group_templates.view` permission.

### Request

* URL parameters

| Key                      | Type    | Notes       |
|--------------------------|---------|-------------|
| task\_group\_templates\_id  | id      |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/task-group-templates/`task_group_templates_id`/
```

### Response

| Key               | Type   | Notes                                                                |
|-------------------|--------|----------------------------------------------------------------------|
| id                | uuid   |                                                                      |
| name              | string |                                                                      |
| description       | string |                                                                      |
| object\_classes    | Array  |                                                                      |
| task\_templates    | Array  |                                                                      |
| created\_at        | date   |                                                                      |
| created\_by        | user   |                                                                      |
| modified\_at       | date   |                                                                      |
| modified\_by       | user   |                                                                      |
| \_meta             | Object | [\_meta](#response-meta-object) result       |

### Response `_meta` object

| Key                     | Type          | Notes                                                                      |
|-------------------------|---------------|--------------------------------------------------------------------------- |
| permission              | Object        |                                                                            |
| labels.object\_classes   | Array         |                                                                            |
| labels.task\_templates   | Array         |                                                                            |

### Response example

* Status `200 OK`
* Body

```json
{
  "id": 1,
  "name": "Test 1",
  "description": "Desc for Test 1",
  "object_classes": [
    1
  ],
  "task_templates": [],
  "created_at": "2022-05-17T13:18:49.312474+02:00",
  "created_by": {
    "id": 2,
    "first_name": "John",
    "last_name": "Kowalsky",
    "username": "John.Kowalsky@autologyx.com",
    "company_name": "",
    "is_deleted": false
  },
  "modified_at": "2022-05-17T13:18:49.312496+02:00",
  "modified_by": {
    "id": 2,
    "first_name": "John",
    "last_name": "Kowalsky",
    "username": "John.Kowalsky@autologyx.com",
    "company_name": "",
    "is_deleted": false
  },
  "_meta": {
    "permissions": {
      "list": true,
      "view": true,
      "create": true,
      "edit": true,
      "delete": true
    },
    "labels": {
      "object_classes": [
        "Object test name"
      ],
      "task_templates": []
    }
  }
}
```

### Sorting

Not supported

### Filtering

Not supported

### Errors

| Error                                                                   | Response code    | Message                                                        |
|-------------------------------------------------------------------------|------------------|----------------------------------------------------------------|
| A non-existent `task_group_templates_id` was given                      | 404 Not Found    | "detail": "Not found."                                         |
| Requesting user is authorized but without view perm for tasks resource  | 403 Forbidden    | "detail": "You do not have permission to perform this action." |
| Requesting user is not authenticated                                    | 401 Unauthorized | "detail": "Authentication credentials were not provided."      |

## GET /api/task-group-templates/autocomplete/

List of Task Group Templates based on query parameters for autocomplete widgets.

### Permissions

Requires `authentication` and `task_group_templates.list` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/task-group-templates/autocomplete/
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        |                                                                                  |
| offset            | int        |                                                                                  |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key          | Type       | Notes                    |
|--------------|------------|--------------------------|
| value        | int        | Task Group Template ID   |
| text         | str        | Task Group Template name |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 20,
  "next": null,
  "previous": null,
  "results": [
    {
      "value": 12,
      "tesst": "Some name"
    }
  ]
}
```

### Sorting

| Parameter   | Example                                              | Notes          |
|-------------|------------------------------------------------------|----------------|
| name        | {build}/api/task-group-templates/?ordering=name      | Ascending      |
| name        | {build}/api/task-group-templates/?ordering=-name     | Descending (-) |
| text        | {build}/api/task-group-templates/?ordering=text      | Ascending      |
| text        | {build}/api/task-group-templates/?ordering=-text     | Descending (-) |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter    | Predicates        | Example                                                      | Values   |
|--------------|-------------------|--------------------------------------------------------------|----------|
| text         | standard string   | {build}/api/task-group-templates/?text\_\_icontains=template   |          |

### Errors

| Error                         | Response code   | Message                                                                                         |
|-------------------------------|-----------------|-------------------------------------------------------------------------------------------------|
| Wrong ordering value          | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."]             |

## GET /api/task-group-templates/`id`/usage/

### Request example

* Headers

```
Request Method: GET
Location: /api/task-group-templates/1/usage/
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| num\_of\_sequences  | int        |                                                                                  |
| sequences         | array      |                                                                                  |

### Response `sequences` array

| Key          | Type       | Notes                                          |
|--------------|------------|------------------------------------------------|
| id           | int        | Sequence id                                    |
| name         | str        | Name of sequence                               |

### Response example

* Status `200 OK`
* Body

```json
{
    "num_of_sequences": 1, 
    "sequences": [
        {
            "id": 3,
            "name": "Sample sequence"
        }
    ]
}
```

### Errors

| Error                         | Response code   | Message                                                            |
|-------------------------------|-----------------|--------------------------------------------------------------------|
| `id` is invalid               | 404 Bad Request | 'detail': "Not found."                                             |
| Unauthorized API call	        | 403 Bad Request | 'detail': "You do not have permission to perform this action."     |

## OPTIONS /api/task-group-templates/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/task-group-templates/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
  "list": {
    "columns": [
      {
        "alias": "id",
        "type": "int",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range"
        ],
        "sort_ok": true
      },
      {
        "alias": "name",
        "type": "string",
        "predicates": [
          "exact",
          "iexact",
          "contains",
          "icontains",
          "startswith",
          "istartswith",
          "endswith",
          "iendswith"
        ],
        "sort_ok": true
      },
      {
        "alias": "description",
        "type": "string",
        "predicates": [],
        "sort_ok": false
      },
      {
        "alias": "object_classes",
        "type": "set",
        "predicates": [
          "containsall",
          "containssome"
        ],
        "sort_ok": false,
        "autocomplete": "/api/object-classes/autocomplete/?text__icontains="
      },
      {
        "alias": "num_of_task_templates",
        "type": "int",
        "predicates": [],
        "sort_ok": true
      },
      {
        "alias": "created_at",
        "type": "datetime",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range"
        ],
        "sort_ok": true
      },
      {
        "alias": "created_by",
        "type": "user",
        "predicates": [
          "exact",
          "in"
        ],
        "sort_ok": false,
        "autocomplete": "/api/users/autocomplete/?text__icontains="
      },
      {
        "alias": "modified_at",
        "type": "datetime",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range"
        ],
        "sort_ok": true
      },
      {
        "alias": "modified_by",
        "type": "user",
        "predicates": [
          "exact",
          "in"
        ],
        "sort_ok": false,
        "autocomplete": "/api/users/autocomplete/?text__icontains="
      }
    ]
  },
  "details": {
    "schema": [
      {
        "alias": "name",
        "type": "string",
        "required": true,
        "validators": [
          {
            "type": "max_length",
            "length": 100
          },
          {
            "type": "min_length",
            "length": 1
          }
        ]
      },
      {
        "alias": "description",
        "type": "string",
        "required": false,
        "validators": [
          {
            "type": "max_length",
            "length": 500
          },
          {
            "type": "min_length",
            "length": 0
          }
        ]
      },
      {
        "alias": "object_classes",
        "type": "set",
        "required": true,
        "autocomplete": "/api/object-classes/autocomplete/?text__icontains="
      },
      {
        "alias": "task_templates",
        "type": "set",
        "required": false,
        "autocomplete": "/api/task-templates/autocomplete/?creation=automatic&text__icontains="
      }
    ]
  },
  "restrictions": {
    "limit_items": 10000
  }
}
```

---

---
url: /knowledgebase/system-configuration/task-group-templates.md
---
# Task Group Templates

Browse the sections below:

* [Editing A Task Group Template](/knowledgebase/system-configuration/task-group-templates/editing-a-task-group-template/)
* [How Do I Create A Task Group Template](/knowledgebase/system-configuration/task-group-templates/how-do-i-create-a-task-group-template/)
* [What Are Task Group Templates](/knowledgebase/system-configuration/task-group-templates/what-are-task-group-templates/)

---

---
url: /knowledgebase/system-configuration/task-management.md
---
# Task Management

**Note:** This section is currently empty or under construction.

---

---
url: /api/catalyst/resources/tasks/task-templates.md
---
# Task Templates

### Permissions

Permissions for Task Templates can be checked

| Context        | Endpoint                        | Location              | Available perms                   |
|----------------|---------------------------------|-----------------------|-----------------------------------|
| Any Class      | `GET /api/users/permissions/`   | `task_templates`      | `list`, `view`, `edit`, `create`  |
| Specific Class | `GET /api/task-templates/{id}/` | `_meta.permissions`   | `list`, `view`, `edit`, `create`  |

### References

# Task Templates API

## POST /api/task-templates/

Creates Task Template.

### Permissions

Requires `authentication` and `task_templates.create` permission.

### Request

* Headers

```
Request Method: POST
Content-Type: application/json
Location: /api/task-templates/
Authorization: JWT access_token
```

* Body

| Key                    | Type    | Required | Notes |
|------------------------|---------|----------|-------|
| name                   | string  | true     |       |
| complete\_by            | enum    | true     |       |
| plugin\_config          | Object  | true     |       |
| complete\_by\_date       | date    | false    |       |
| complete\_by\_time\_unit  | enum    | false    |       |
| complete\_by\_time\_value | int     | false    |       |
| description            | string  | false    |       |
| expiry                 | enum    | false    |       |
| expiry\_time\_unit       | enum    | false    |       |
| expiry\_time\_value      | int     | false    |       |
| expiry\_time\_rel\_to     | enum    | false    |       |
| expiry\_date            | date    | false    |       |
| expiry\_day             | int     | false    |       |
| expiry\_periodic\_day    | int     | false    |       |
| expiry\_periodic\_month  | int     | false    |       |
| reminders              | Object  | false    |       |
| renewals               | Object  | false    |       |
| task\_creation          | enum    | false    |       |

### Request `plugin_config` array

| Key                 | Type   | Required |
|---------------------|--------|----------|
| task\_type           | enum   | true     |
| configuration       | Json   | true     |
| approval\_conditions | Object | false    |

### Request `reminders` array

| Key          | Type | Required |
|--------------|------|----------|
| notice\_type  | enum | true     |
| time\_unit    | enum | true     |
| time\_value   | int  | true     |

### Request `renewals` array

| Key                 | Type | Required |
|---------------------|------|----------|
| renewal\_time\_unit   | enum | false    |
| renewal\_time\_value  | int  | false    |

#### Validations

Information about validators for individual fields is included in OPTIONS /api/task-templates/

### Sample request body

```json
{
    "name": "test_template",
    "complete_by": "asap",
    "plugin_config": {
        "task_type": "tt_form",
        "configuration": {
            "name": "some name"
        }
    }
}
```

### Response

| Key                    | Type     | Notes                                   |
|------------------------|----------|-----------------------------------------|
| id                     | int      | Automatically generated by the backend. |
| name                   | string   |                                         |
| task\_creation          | enum     |                                         |
| description            | string   |                                         |
| created\_at             | datetime |                                         |
| created\_by             | user     |                                         |
| modified\_at            | datetime |                                         |
| modified\_by            | user     |                                         |
| num\_of\_tasks\_created   | int      |                                         |
| last\_task\_created      | datetime |                                         |
| instructions           | string   |                                         |
| complete\_by            | enum     |                                         |
| complete\_by\_date       | date     |                                         |
| complete\_by\_time\_unit  | enum     |                                         |
| complete\_by\_time\_value | int      |                                         |
| complete\_by\_time\_unit  | enum     |                                         |
| reminders              | Object   |                                         |
| expiry                 | enum     |                                         |
| expiry\_time\_unit       | enum     |                                         |
| expiry\_time\_value      | int      |                                         |
| expiry\_time\_rel\_to     | enum     |                                         |
| expiry\_date            | date     |                                         |
| expiry\_day             | int      |                                         |
| expiry\_periodic\_day    | int      |                                         |
| expiry\_periodic\_month  | int      |                                         |
| plugin\_config          | Object   |                                         |
| renewals               | Object   |                                         |
| \_meta.permissions      | Object   | Object describing permissions.          |

### Response `plugin_config` array

| Key                 | Type   | Required |
|---------------------|--------|----------|
| task\_type           | enum   | true     |
| configuration       | Json   | true     |
| approval\_conditions | Object | false    |

### Response `reminders` array

| Key          | Type | Required |
|--------------|------|----------|
| notice\_type  | enum | true     |
| time\_unit    | enum | true     |
| time\_value   | int  | true     |

### Response `renewals` array

| Key                 | Type | Required |
|---------------------|------|----------|
| renewal\_time\_unit   | enum | false    |
| renewal\_time\_value  | int  | false    |

* Successful status `201 Created`
* Response body schema

```json
{
    "id": 10,
    "name": "test_template",
    "task_creation": "automatic",
    "description": "",
    "created_at": "2023-07-26T10:49:43.842177+02:00",
    "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_at": "2023-07-26T10:49:43.842202+02:00",
    "num_of_tasks_created": 0,
    "last_task_created": null,
    "instructions": "",
    "complete_by": "asap",
    "complete_by_date": null,
    "complete_by_time_unit": null,
    "complete_by_time_value": null,
    "reminders": [],
    "expiry": null,
    "expiry_time_unit": null,
    "expiry_time_value": null,
    "expiry_time_rel_to": null,
    "expiry_date": null,
    "expiry_day": null,
    "expiry_periodic_day": null,
    "expiry_periodic_month": null,
    "plugin_config": {
        "prompt": "",
        "allow_comment": false,
        "task_type": "tt_form",
        "approval_required": false,
        "approval_conditions": [],
        "_meta": {
            "labels": {
                "task_type": "Complete standalone form"
            }
        },
        "configuration": {
            "name": "some name"
        }
    },
    "renewals": [],
    "modified_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "_meta": {
        "permissions": {
            "list": true,
            "view": true,
            "create": true,
            "edit": true,
            "delete": true
        }
    }
}
```

## PATCH /api/task-templates/'id'

Update single Task Template.

### Permissions

Requires `authentication` and `task_templates.edit` permission.

### Request

* Headers

```
Request Method: PATCH
Content-Type: application/json
Location: /api/task-templates/1
Authorization: JWT access_token
```

* Body

| Key                    | Type    | Required | Notes |
|------------------------|---------|----------|-------|
| name                   | string  | true     |       |
| complete\_by            | enum    | true     |       |
| complete\_by\_date       | date    | false    |       |
| complete\_by\_time\_unit  | enum    | false    |       |
| complete\_by\_time\_value | int     | false    |       |
| description            | string  | false    |       |
| expiry                 | enum    | false    |       |
| expiry\_time\_unit       | enum    | false    |       |
| expiry\_time\_value      | int     | false    |       |
| expiry\_time\_rel\_to     | enum    | false    |       |
| expiry\_date            | date    | false    |       |
| expiry\_day             | int     | false    |       |
| expiry\_periodic\_day    | int     | false    |       |
| expiry\_periodic\_month  | int     | false    |       |
| reminders              | Object  | false    |       |
| renewals               | Object  | false    |       |

Any parameter not listed above are silently ignored if passed.

### Request `plugin_config` array

| Key                 | Type   | Required |
|---------------------|--------|----------|
| task\_type           | enum   | true     |
| configuration       | Json   | true     |
| approval\_conditions | Object | false    |

### Request `reminders` array

| Key          | Type | Required |
|--------------|------|----------|
| notice\_type  | enum | true     |
| time\_unit    | enum | true     |
| time\_value   | int  | true     |

### Request `renewals` array

| Key                 | Type | Required |
|---------------------|------|----------|
| renewal\_time\_unit   | enum | false    |
| renewal\_time\_value  | int  | false    |

#### Validations

Information about validators for individual fields is included in OPTIONS /api/task-templates/

### Sample request body

```json
{
    "name": "test_template",
    "description": "some description"
}
```

### Response

| Key                    | Type     | Notes                                   |
|------------------------|----------|-----------------------------------------|
| id                     | int      | Automatically generated by the backend. |
| name                   | string   |                                         |
| task\_creation          | enum     |                                         |
| description            | string   |                                         |
| created\_at             | datetime |                                         |
| created\_by             | user     |                                         |
| modified\_at            | datetime |                                         |
| modified\_by            | user     |                                         |
| num\_of\_tasks\_created   | int      |                                         |
| last\_task\_created      | datetime |                                         |
| instructions           | string   |                                         |
| complete\_by            | enum     |                                         |
| complete\_by\_date       | date     |                                         |
| complete\_by\_time\_unit  | enum     |                                         |
| complete\_by\_time\_value | int      |                                         |
| complete\_by\_time\_unit  | enum     |                                         |
| reminders              | Object   |                                         |
| expiry                 | enum     |                                         |
| expiry\_time\_unit       | enum     |                                         |
| expiry\_time\_value      | int      |                                         |
| expiry\_time\_rel\_to     | enum     |                                         |
| expiry\_date            | date     |                                         |
| expiry\_day             | int      |                                         |
| expiry\_periodic\_day    | int      |                                         |
| expiry\_periodic\_month  | int      |                                         |
| plugin\_config          | Object   |                                         |
| renewals               | Object   |                                         |
| \_meta.permissions      | Object   | Object describing permissions.          |

### Response `plugin_config` array

| Key                 | Type   | Required |
|---------------------|--------|----------|
| task\_type           | enum   | true     |
| configuration       | Json   | true     |
| approval\_conditions | Object | false    |

### Response `reminders` array

| Key          | Type | Required |
|--------------|------|----------|
| notice\_type  | enum | true     |
| time\_unit    | enum | true     |
| time\_value   | int  | true     |

### Response `renewals` array

| Key                 | Type | Required |
|---------------------|------|----------|
| renewal\_time\_unit   | enum | false    |
| renewal\_time\_value  | int  | false    |

* Successful status `200 OK`
* Response body schema

```json
{
    "id": 10,
    "name": "test_template",
    "task_creation": "automatic",
    "description": "some description",
    "created_at": "2023-07-26T10:49:43.842177+02:00",
    "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_at": "2023-07-26T10:49:43.842202+02:00",
    "num_of_tasks_created": 0,
    "last_task_created": null,
    "instructions": "",
    "complete_by": "asap",
    "complete_by_date": null,
    "complete_by_time_unit": null,
    "complete_by_time_value": null,
    "reminders": [],
    "expiry": null,
    "expiry_time_unit": null,
    "expiry_time_value": null,
    "expiry_time_rel_to": null,
    "expiry_date": null,
    "expiry_day": null,
    "expiry_periodic_day": null,
    "expiry_periodic_month": null,
    "plugin_config": {
        "prompt": "",
        "allow_comment": false,
        "task_type": "tt_form",
        "approval_required": false,
        "approval_conditions": [],
        "_meta": {
            "labels": {
                "task_type": "Complete standalone form"
            }
        },
        "configuration": {
            "name": "some name"
        }
    },
    "renewals": [],
    "modified_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "_meta": {
        "permissions": {
            "list": true,
            "view": true,
            "create": true,
            "edit": true,
            "delete": true
        }
    }
}
```

## OPTIONS /api/task-templates/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Request Method: OPTIONS
Content-Type: application/json
Location: /api/task-templates/
Authorization: JWT access_token
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "name",
                "type": "string",
                "predicates": [
                    "exact",
                    "iexact",
                    "contains",
                    "icontains",
                    "startswith",
                    "istartswith",
                    "endswith",
                    "iendswith"
                ],
                "sort_ok": true
            },
            {
                "alias": "task_type",
                "type": "enum",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "values": [
                    {
                        "value": "tt_form",
                        "text": "Complete standalone form"
                    },
                    {
                        "value": "tt_object_record_update",
                        "text": "Object Record update"
                    }
                ]
            },
            {
                "alias": "plugin_config",
                "schema": [
                    {
                        "alias": "task_type",
                        "type": "enum",
                        "predicates": [
                            "exact",
                            "in"
                        ],
                        "sort_ok": false,
                        "values": [
                            {
                                "value": "tt_form",
                                "text": "Complete standalone form"
                            },
                            {
                                "value": "tt_object_record_update",
                                "text": "Object Record update"
                            }
                        ]
                    }
                ],
                "schema_by_type": [
                    {
                        "task_type": "tt_form",
                        "schema": []
                    },
                    {
                        "task_type": "tt_object_record_update",
                        "schema": [
                            {
                                "alias": "object_class",
                                "type": "enum",
                                "predicates": [
                                    "exact",
                                    "isnull",
                                    "in"
                                ],
                                "sort_ok": true,
                                "autocomplete": "/api/object-classes/autocomplete/?text__icontains="
                            }
                        ]
                    }
                ]
            },
            {
                "alias": "task_creation",
                "type": "enum",
                "predicates": [
                    "exact"
                ],
                "sort_ok": false,
                "values": [
                    {
                        "value": "automatic",
                        "text": "Automatic"
                    },
                    {
                        "value": "manual",
                        "text": "Manual"
                    }
                ]
            },
            {
                "alias": "description",
                "type": "string",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "modified_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "modified_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "num_of_tasks_created",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "last_task_created",
                "type": "datetime",
                "predicates": [],
                "sort_ok": true
            }
        ]
    },
    "details": {
        "schema": [
            {
                "alias": "name",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "min_length",
                        "length": 1
                    },
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "complete_by",
                "type": "enum",
                "required": true,
                "values": [
                    {
                        "value": "asap",
                        "text": "ASAP"
                    },
                    {
                        "value": "date",
                        "text": "Date"
                    },
                    {
                        "value": "time_frame",
                        "text": "Time frame"
                    }
                ]
            },
            {
                "alias": "complete_by_date",
                "type": "date",
                "required": false,
                "validators": [
                    {
                        "type": "date_in_future"
                    }
                ]
            },
            {
                "alias": "complete_by_time_unit",
                "type": "enum",
                "required": false,
                "values": [
                    {
                        "value": "days",
                        "text": "days"
                    },
                    {
                        "value": "weeks",
                        "text": "weeks"
                    },
                    {
                        "value": "months",
                        "text": "months"
                    }
                ]
            },
            {
                "alias": "complete_by_time_value",
                "type": "int",
                "required": false,
                "validators": [
                    {
                        "type": "min_value",
                        "value": 0
                    },
                    {
                        "type": "max_value",
                        "value": 100
                    }
                ]
            },
            {
                "alias": "plugin_config",
                "schema": [
                    {
                        "alias": "task_type",
                        "editable": false,
                        "type": "enum",
                        "required": true,
                        "values": [
                            {
                                "value": "tt_form",
                                "text": "Complete standalone form"
                            },
                            {
                                "value": "tt_object_record_update",
                                "text": "Object Record update"
                            }
                        ]
                    },
                    {
                        "alias": "approval_conditions",
                        "required": false,
                        "schema": [
                            {
                                "alias": "name",
                                "type": "string",
                                "required": true,
                                "validators": [
                                    {
                                        "type": "min_length",
                                        "length": 1
                                    },
                                    {
                                        "type": "max_length",
                                        "length": 255
                                    }
                                ]
                            }
                        ],
                        "validators": [
                            {
                                "type": "max_length",
                                "length": 20
                            }
                        ]
                    }
                ],
                "schema_by_type": [
                    {
                        "task_type": "tt_form",
                        "schema": []
                    },
                    {
                        "task_type": "tt_object_record_update",
                        "schema": [
                            {
                                "alias": "object_class",
                                "type": "enum",
                                "required": true,
                                "editable": false,
                                "autocomplete": "/api/object-classes/autocomplete/owned/?text__icontains="
                            }
                        ]
                    }
                ]
            },
            {
                "alias": "description",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 500
                    }
                ]
            },
            {
                "alias": "expiry",
                "type": "enum",
                "required": false,
                "values": [
                    {
                        "value": "time_frame",
                        "text": "Time frame"
                    },
                    {
                        "value": "date",
                        "text": "Date"
                    },
                    {
                        "value": "monthly",
                        "text": "Monthly"
                    },
                    {
                        "value": "annually",
                        "text": "Annually"
                    }
                ]
            },
            {
                "alias": "expiry_time_unit",
                "type": "enum",
                "required": false,
                "values": [
                    {
                        "value": "days",
                        "text": "days"
                    },
                    {
                        "value": "weeks",
                        "text": "weeks"
                    },
                    {
                        "value": "months",
                        "text": "months"
                    }
                ]
            },
            {
                "alias": "expiry_time_value",
                "type": "int",
                "required": false,
                "validators": [
                    {
                        "type": "min_value",
                        "value": 0
                    },
                    {
                        "type": "max_value",
                        "value": 100
                    }
                ]
            },
            {
                "alias": "expiry_time_rel_to",
                "type": "enum",
                "required": false,
                "values": [
                    {
                        "value": "completed",
                        "text": "Completed"
                    },
                    {
                        "value": "assigned",
                        "text": "Assigned"
                    }
                ]
            },
            {
                "alias": "expiry_date",
                "type": "date",
                "required": false,
                "validators": [
                    {
                        "type": "date_in_future"
                    }
                ]
            },
            {
                "alias": "expiry_day",
                "type": "int",
                "required": false,
                "validators": [
                    {
                        "type": "min_value",
                        "value": 1
                    },
                    {
                        "type": "max_value",
                        "value": 31
                    }
                ]
            },
            {
                "alias": "expiry_periodic_day",
                "type": "int",
                "required": false,
                "validators": [
                    {
                        "type": "min_value",
                        "value": 1
                    },
                    {
                        "type": "max_value",
                        "value": 31
                    }
                ]
            },
            {
                "alias": "expiry_periodic_month",
                "type": "int",
                "required": false,
                "validators": [
                    {
                        "type": "min_value",
                        "value": 1
                    },
                    {
                        "type": "max_value",
                        "value": 12
                    }
                ]
            },
            {
                "alias": "reminders",
                "schema": [
                    {
                        "alias": "notice_type",
                        "type": "enum",
                        "required": true,
                        "values": [
                            {
                                "value": "task_complete_by",
                                "text": "Task to Complete by"
                            },
                            {
                                "value": "task_overdue",
                                "text": "Task Overdue"
                            },
                            {
                                "value": "task_expiry",
                                "text": "Task Expiry"
                            }
                        ]
                    },
                    {
                        "alias": "time_unit",
                        "type": "enum",
                        "required": true,
                        "values": [
                            {
                                "value": "days",
                                "text": "days"
                            },
                            {
                                "value": "weeks",
                                "text": "weeks"
                            },
                            {
                                "value": "months",
                                "text": "months"
                            }
                        ]
                    },
                    {
                        "alias": "time_value",
                        "type": "int",
                        "required": true,
                        "validators": [
                            {
                                "type": "min_value",
                                "value": 0
                            },
                            {
                                "type": "max_value",
                                "value": 100
                            }
                        ]
                    }
                ],
                "validators": [
                    {
                        "type": "max_length",
                        "length": 1,
                        "apply_to": {
                            "alias": "notice_type",
                            "value": "task_complete_by"
                        }
                    },
                    {
                        "type": "max_length",
                        "length": 10,
                        "apply_to": {
                            "alias": "notice_type",
                            "value": "task_overdue"
                        }
                    },
                    {
                        "type": "max_length",
                        "length": 10,
                        "apply_to": {
                            "alias": "notice_type",
                            "value": "task_expiry"
                        }
                    }
                ]
            },
            {
                "alias": "renewals",
                "schema": [
                    {
                        "alias": "renewal_time_unit",
                        "type": "enum",
                        "required": false,
                        "values": [
                            {
                                "value": "days",
                                "text": "days"
                            },
                            {
                                "value": "weeks",
                                "text": "weeks"
                            },
                            {
                                "value": "months",
                                "text": "months"
                            }
                        ]
                    },
                    {
                        "alias": "renewal_time_value",
                        "type": "int",
                        "required": false,
                        "validators": [
                            {
                                "type": "min_value",
                                "value": 0
                            },
                            {
                                "type": "max_value",
                                "value": 100
                            }
                        ]
                    }
                ]
            },
            {
                "alias": "task_creation",
                "type": "enum",
                "required": false,
                "values": [
                    {
                        "value": "automatic",
                        "text": "Automatic"
                    },
                    {
                        "value": "manual",
                        "text": "Manual"
                    }
                ]
            }
        ]
    },
    "restrictions": {
        "limit_items": 10000
    }
}
```

## GET /api/task-templates/

Returns list of Task Templates.

### Permissions

### Request example

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key               | Type   | Notes                                                                              |
|-------------------|--------|------------------------------------------------------------------------------------|
| limit             | int    |                                                                                    |
| offset            | int    |                                                                                    |
| total\_count       | int    | Total number of results visible to the user (based on permissions).                |
| filtered\_count    | int    | Number of results visible to the user (based on permissions) with filters applied. |
| next              | url    | Next page URL (null if there is no next page)                                      |
| previous          | url    | Previous page URL (null if there is no previous page)                              |
| results           | Array  | List of results. Described in the next table.                                      |

#### Response `results` array

| Key                  | Type      | Notes                               |
|----------------------|-----------|-------------------------------------|
| id                   | int       |                                     |
| name                 | str       |                                     |
| task\_type            | str       | Task response type                  |
| plugin\_config        | Object    | Object describing task type details |
| task\_creation        | str       | Task creation type automatic/manual |
| description          | str       |                                     |
| created\_at           | datetime  |                                     |
| created\_by           | user      |                                     |
| modified\_at          | datetime  |                                     |
| modified\_by          | user      |                                     |
| num\_of\_tasks\_created | int       |                                     |
| last\_task\_created    | datetime  |                                     |
| \_meta.permissions    | Object    | Object describing permissions.      |

* Successful status `200 OK`
* Response body schema

```json
{
    "limit": 100,
    "offset": 0,
    "filtered_count": 2,
    "total_count": 2,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": 1,
            "name": "test_name",
            "task_type": "tt_form",
            "plugin_config": {
                "task_type": "tt_form",
                "_meta": {
                    "labels": {
                        "task_type": "Complete standalone form"
                    }
                }
            },
            "task_creation": "automatic",
            "description": "some test description",
            "created_at": "2022-06-01T09:43:39.659685+02:00",
            "created_by": {
                "id": 2,
                "first_name": "ALX",
                "last_name": "Developer",
                "username": "alx.dev@autologyx.com",
                "company_name": "",
                "is_deleted": false,
                "account_type": "super_admin"
            },
            "modified_by": {
                "id": 2,
                "first_name": "ALX",
                "last_name": "Developer",
                "username": "alx.dev@autologyx.com",
                "company_name": "",
                "is_deleted": false,
                "account_type": "super_admin"
            },
            "modified_at": "2022-06-01T09:43:39.659715+02:00",
            "num_of_tasks_created": 0,
            "last_task_created": null,
            "_meta": {
                "permissions": {
                    "list": true,
                    "view": true,
                    "create": true,
                    "edit": true,
                    "delete": true
                }
            }
        }
    ]
}
```

### Sorting

Will be completed in the future

### Filtering

Will be completed in the future

### Errors

Will be completed in the future

## GET /task-templates/`id`/

Returns single task templates by `id`.

### Permissions

Requires `authentication` and `task_templates.view` permission.

### URL parameters

| Key                    | Type | Notes                         |
|------------------------|------|-------------------------------|
| id                     | int  |                               |

### Request example

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Response

| Key                   | Type     | Notes                               |
|-----------------------|----------|-------------------------------------|
| id                    | int      |                                     |
| name                  | str      |                                     |
| task\_type             | str      | Task response type                  |
| plugin\_config         | Object   | Object describing task type details |
| task\_creation         | str      | Task creation type automatic/manual |
| description           | str      |                                     |
| created\_at            | datetime |                                     |
| created\_by            | user     |                                     |
| modified\_at           | datetime |                                     |
| modified\_by           | user     |                                     |
| num\_of\_tasks\_created  | int      |                                     |
| instructions          | str      |                                     |
| complete\_by           | str      |                                     |
| complete\_by\_date      | date     |                                     |
| complete\_by\_time\_unit | str      |                                     |
| reminders:            | Array    |                                     |
| expiry                | str      |                                     |
| expiry\_time\_unit      | str      |                                     |
| expiry\_time\_value     | int      |                                     |
| expiry\_time\_rel\_to    | str      |                                     |
| expiry\_date           | date     |                                     |
| expiry\_day            | int      |                                     |
| expiry\_periodic\_month | int      |                                     |
| last\_task\_created     | datetime |                                     |
| renewals              | Array    |                                     |
| \_meta.permissions     | Object   | Object describing permissions.      |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": 1,
    "name": "test_name",
    "task_creation": "automatic",
    "description": "some test description",
    "created_at": "2022-06-01T09:43:39.659685+02:00",
    "created_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_at": "2022-06-01T09:43:39.659715+02:00",
    "num_of_tasks_created": 0,
    "last_task_created": null,
    "instructions": "",
    "complete_by": "time_frame",
    "complete_by_date": null,
    "complete_by_time_unit": "months",
    "complete_by_time_value": 1,
    "reminders": [],
    "expiry": "time_frame",
    "expiry_time_unit": "weeks",
    "expiry_time_value": 2,
    "expiry_time_rel_to": "assigned",
    "expiry_date": null,
    "expiry_day": null,
    "expiry_periodic_day": null,
    "expiry_periodic_month": null,
    "plugin_config": {
        "prompt": "",
        "allow_comment": false,
        "task_type": "tt_form",
        "approval_required": false,
        "approval_conditions": [],
        "_meta": {
            "labels": {
                "task_type": "Complete standalone form"
            }
        },
        "configuration": {
            "name": "some name"
        }
    },
    "renewals": [],
    "modified_by": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "_meta": {
        "permissions": {
            "list": true,
            "view": true,
            "create": true,
            "edit": true,
            "delete": true
        }
    }
}
```

### Errors

| Error                                  | Response code | Message                                                        |
|----------------------------------------|---------------|----------------------------------------------------------------|
| task\_template with "id" does not exist | 404 Not Found | "detail": "Not found."                                         |
| Insufficient permissions               | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## DELETE /api/task-templates/`id`/

Remove a Task Template with checking if no used anywhere.

### Permissions

Requires `authentication` and `task_templates.delete` permission.

### Request example

* Headers

```
Request Method: DELETE
Location: /api/task-templates/1/
Authorization: JWT access_token
```

### Response example

* Status `204 No Content`
* Body

### Errors

| Error                           | Response code | Message                                                         |
|---------------------------------|---------------|-----------------------------------------------------------------|
| Target template in use          | 400 Forbidden | "detail": "Criteria is in use by Sequences."                    |
| Insufficient permissions        | 403 Forbidden | "detail": "You do not have permission to perform this action."  |
| Task template does not exist    | 404 Forbidden | "detail": "Not found"                                           |

## GET /api/task-templates/autocomplete/

Lists Task Templates based on query parameters for autocomplete widgets.

### Permissions

Requires `authentication` and returns all items for any authenticated users.

### Request example

* Headers

```
Request Method: GET
Location: /api/task-templates/autocomplete
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        |                                                                                  |
| offset            | int        |                                                                                  |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key          | Type       | Notes                                                                                        |
|--------------|------------|----------------------------------------------------------------------------------------------|
| value        | int        | Task Template ID                                                                             |
| text         | str        | Task Template representation text                                                            |
| object\_class | int        | Object Class ID for `tt_object_record_update` Task Templates type. Is empty for other types. |
| task\_type    | str        | Task Template type                                                                           |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 20,
  "next": null,
  "previous": null,
  "results": [
    {
      "value": "12",
      "tesst": "Task Template 12",
      "object_class": 235,
      "task_type": "tt_object_record_update"
    }
  ]
}
```

### Sorting

| Parameter   | Example                                               | Notes          |
|-------------|-------------------------------------------------------|----------------|
| name        | {build}/api/object-class-forms/?ordering=name         | Ascending      |
| name        | {build}/api/object-class-forms/?ordering=-name        | Descending (-) |
| text        | {build}/api/object-class-forms/?ordering=text         | Ascending      |
| text        | {build}/api/object-class-forms/?ordering=-text        | Descending (-) |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter    | Predicates        | Example                                                           | Values                           |
|--------------|-------------------|-------------------------------------------------------------------|----------------------------------|
| text         | standard string   | {build}/api/object-class-forms/?text\_\_icontains=template          |                                  |
| creation     | standard enum     | {build}/api/object-class-forms/?creation=automatic                | automatic, manual                |
| object\_class | standard set      | {build}/api/object-class-forms/?object\_class\_\_in=5,10,15          |                                  |
| task\_type    | standard enum     | {build}/api/object-class-forms/?task\_type=tt\_object\_record\_update | tt\_form, tt\_object\_record\_update |

### Errors

| Error                         | Response code   | Message                                                                                         |
|-------------------------------|-----------------|-------------------------------------------------------------------------------------------------|
| Wrong ordering value          | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."]             |
| Invalid object\_class          | 400 Bad Request | "object\_class": \[ "'Select a valid choice. That choice is not one of the available choices." ]  |

## GET /api/task-templates/`id`/usage/

### Request example

* Headers

```
Request Method: GET
Location: /api/task-templates/1/usage/
Authorization: JWT access_token
```

### Response

| Key                         | Type       | Notes                           |
|-----------------------------|------------|---------------------------------|
| num\_of\_sequences            | int        |                                 |
| num\_of\_task\_group\_templates | int        |                                 |
| sequences                   | array      |                                 |
| task\_group\_templates        | array      |                                 |

### Response `sequences` array

| Key          | Type       | Notes                                          |
|--------------|------------|------------------------------------------------|
| id           | int        | Sequence id                                    |
| name         | str        | Name of sequence                               |

### Response `task_group_templates` array

| Key          | Type       | Notes                                          |
|--------------|------------|------------------------------------------------|
| id           | int        | Target Group Templates id                      |
| name         | str        | Name of Target Group Template                  |

### Response example

* Status `200 OK`
* Body

```json
{
  "sequences": [
    {
      "id": 3,
      "name": "Sample sequence"
    }
  ],
  "task_group_templates": [
    {
      "id": 3,
      "name": "Sample sequence"
    }
  ],
  "num_of_sequences": 1,
  "num_of_task_group_templates": 1
}
```

### Errors

| Error                         | Response code   | Message                                                            |
|-------------------------------|-----------------|--------------------------------------------------------------------|
| `id` is invalid               | 404 Bad Request | 'detail': "Not found."                                             |
| Unauthorized API call         | 403 Bad Request | 'detail': "You do not have permission to perform this action."     |

---

---
url: /knowledgebase/system-configuration/task-templates.md
---
# Task Templates

**Browse the sections below:**

* [Editing A Task Template](/knowledgebase/system-configuration/task-templates/editing-a-task-template/)
* [How Do I Create A Task Template](/knowledgebase/system-configuration/task-templates/how-do-i-create-a-task-template/)
* [Response Configuration   Task Type   Complete Self Contained Form](/knowledgebase/system-configuration/task-templates/response-configuration---task-type---complete-self-contained-form/)
* [Response Configuration   Task Type   Update Object Record](/knowledgebase/system-configuration/task-templates/response-configuration---task-type---update-object-record/)
* [What Are Task Templates](/knowledgebase/system-configuration/task-templates/what-are-task-templates/)

---

---
url: /api/catalyst/resources/tasks/tasks.md
---
# Tasks

Initial implementation of Tasks was based on the original “v4” architecture. This document describes the new architecture. The key changes include:

Creating Tasks directly from Task Templates (in addition to creating them via Task Group Templates).

Creating multiple Tasks from the same Task Template and Object Record.

1. Assigning Tasks to users (assignees).
2. Designating Task owners.
3. Locking Tasks.
4. New Task statuses and response states.

### References

* [Object Classes](/api/catalyst/resources/object-classes/object-classes)
* [Object Records](/api/catalyst/resources/object-records/object-records)
* [Task Templates](/api/catalyst/resources/tasks/task-templates)

# Tasks API

## POST /api/tasks/

### Permissions

Requires `authentication` and any of:

1. `tasks.create` permission, for `task_type` == `tt_object_record_update` `object_record.edit` is required
2. Object Record Ownership
3. Object Class Ownership
4. Object Record Permission Set permission

### Request example

* Headers

```
Request Method: POST
Location: /api/tasks/
Authorization: JWT access_token
```

* Body

```json
{
  "name": "Sample Task",
  "object_record":"1",
  "task_template":1,
  "due_date":null,
  "task_type":"tt_object_record_update"
}
```

### Response

| Key           | Type    | Notes                                                 |
|---------------|---------|-------------------------------------------------------|
| id            | uuid    |                                                       |
| name          | string  |                                                       |
| task\_template | int     |                                                       |
| object\_class  | int     |                                                       |
| object\_record | int     |                                                       |
| instructions  | string  |                                                       |
| configuration | array   | Copy of [Task template](/api/catalyst/resources/tasks/task-templates) object   |
| status        | enum    |                                                       |
| created\_at    | date    |                                                       |
| created\_by    | user    |                                                       |
| modified\_at   | date    |                                                       |
| modified\_by   | user    |                                                       |
| due\_date      | date    |                                                       |
| expiry\_date   | date    |                                                       |
| completed\_at  | date    |                                                       |
| completed\_by  | user    |                                                       |
| response      | Array   | [Response](#response-response-array) result |
| stages        | Array   | [Stages](#response-stages-array) result     |
| next\_actions  | Array   | [Actions](#response-actions-array) schema   |
| \_meta         | Object  | [\_meta](#response-meta-object) result       |

### Response `response` array

| Key             | Type          | Notes      |
|-----------------|---------------|------------|
| id              | uuid          |            |
| state           | enum          |            |
| data            | Array         |            |
| files           | Array         |            |
| modified\_at     | Array         |            |
| modified\_by     | user          |            |
| \_meta.labels    | Object        |            |

#### `data` for Response type `Object Record Update`

::: When `task_type` is `tt_object_record_update` the `data` contains

* If task is `initial` and was never saved before: values are taken from recent Object Record related field values.
* If task was saved with given field: `data` will contain this field and value from the saved task.
* If task was saved before and given field was not saved in there: value is taken from recent Object Record related field value.
  :::

### Response `stages` array

| Key             | Type          | Notes                         |
|-----------------|---------------|-------------------------------|
| name            | enum          |                               |
| status          | enum          |                               |
| owner           | user          |                               |
| assignees.users | Array         | List of [users](/api/catalyst/resources/users/users)   |

### Response `_meta` object

| Key           | Type   | Notes |
|---------------|--------|-------|
| labels.status | enum   |       |
| labels.files  | Object |       |
| permission    | Object |       |

### Response `actions` array

| Owner               | Assign              | Complete            | Next actions                                              |
|---------------------|---------------------|---------------------|-----------------------------------------------------------|
| :heavy\_check\_mark:  | :heavy\_check\_mark:  | :heavy\_check\_mark:  | view, save, complete, give\_up\_ownership, change\_ownership |
| :heavy\_check\_mark:  |                     | :heavy\_check\_mark:  | view, save, complete, give\_up\_ownership                   |
|                     | :heavy\_check\_mark:  | :heavy\_check\_mark:  | view, save, complete, take\_ownership, change\_ownership    |
|                     |                     | :heavy\_check\_mark:  | view, save, complete, take\_ownership                      |
|                     |                     |                     | view                                                      |

### Response example

* Status `200 OK`
* Body

```json
{
  "id": 1,
  "name": "Test",
  "task_template": 2,
  "object_class": 1,
  "object_record": 1,
  "instructions": "",
  "configuration": {
    "expiry": "date",
    "renewals": [],
    "reminders": [],
    "expiry_day": null,
    "complete_by": "asap",
    "description": "",
    "expiry_date": "2022-05-21",
    "modified_by": {
      "id": 2,
      "username": "John.Kowalsky@autologyx.com",
      "last_name": "Kowalsky",
      "first_name": "John",
      "is_deleted": false,
      "company_name": ""
    },
    "instructions": "",
    "plugin_config": {
      "prompt": "",
      "task_type": "tt_form",
      "allow_comment": false,
      "configuration": {},
      "approval_required": false,
      "approval_conditions": []
    },
    "task_creation": "automatic",
    "complete_by_date": null,
    "expiry_time_unit": null,
    "expiry_time_value": null,
    "expiry_time_rel_to": null,
    "expiry_periodic_day": null,
    "task_group_templates": [],
    "complete_by_time_unit": null,
    "expiry_periodic_month": null,
    "complete_by_time_value": null
  },
  "status": "completed",
  "created_at": "2022-05-17T13:49:06.100636+02:00",
  "created_by": {
    "id": 2,
    "first_name": "John",
    "last_name": "Kowalsky",
    "username": "John.Kowalsky@autologyx.com",
    "company_name": "",
    "is_deleted": false
  },
  "modified_at": "2022-05-17T13:49:37.246827+02:00",
  "modified_by": {
    "id": 2,
    "first_name": "John",
    "last_name": "Kowalsky",
    "username": "John.Kowalsky@autologyx.com",
    "company_name": "",
    "is_deleted": false
  },
  "due_date": null,
  "expiry_date": null,
  "completed_at": "2022-05-17T13:49:37.243158+02:00",
  "completed_by": {
    "id": 2,
    "first_name": "John",
    "last_name": "Kowalsky",
    "username": "John.Kowalsky@autologyx.com",
    "company_name": "",
    "is_deleted": false
  },
  "response": null,
  "stages": [
    {
      "name": "stage_1",
      "status": "outstanding",
      "assignees": {
        "users": [
          {
            "id": 2,
            "first_name": "John",
            "last_name": "Kowalsky",
            "username": "John.Kowalsky@autologyx.com",
            "company_name": "",
            "is_deleted": false
          }
        ],
      },
      "owner": {
        "id": 2,
        "first_name": "John",
        "last_name": "Kowalsky",
        "username": "John.Kowalsky@autologyx.com",
        "company_name": "",
        "is_deleted": false
      }
    }
  ],
  "next_actions": [
    "view",
    "save",
    "complete",
    "give_up_ownership",
    "change_ownership" 
  ],
  "_meta": {
    "labels": {
      "status": "Completed"
    },
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "delete": true,
      "create": true,
      "complete": true,
      "assign": true
    }
  }
}
```

### Sorting

Not supported

### Filtering

Not supported

### Errors

| Error                                                                   | Response code       | Message                                                                                    |
|-------------------------------------------------------------------------|---------------------|--------------------------------------------------------------------------------------------|
| `name` is to long                                                       | 400 Bad Request     | "detail": {"name": "Ensure this field has no more than 100 characters."}                   |
| `task_template` is not set                                              | 400 Bad Request     | "detail": {"task\_template": \["This field is required."]}                                 |
| `object_record` is not set                                              | 400 Bad Request     | "detail": {"object\_record": \["This field is required."]}                                 |
| `task_template` is set with empty value                                 | 400 Bad Request     | "detail": {"task\_template": \["This field may not be null."]}                             |
| `object_record` is set with empty value                                 | 400 Bad Request     | "detail": {"object\_record": \["This field may not be null."]}                             |
| `task_template` value is different than expected                        | 400 Bad Request     | "detail": {"task\_template": \["Incorrect type. Expected pk value, received list."]}       |
| `object_record` value is different than expected                        | 400 Bad Request     | "detail": {"object\_record": \["Incorrect type. Expected pk value, received list."]}       |
| `task_template` not exists                                              | 400 Bad Request     | "detail": {"task\_template": \["Invalid pk "\<task\_template\_id>" - object does not exist."]}|
| `object_record` not exists                                              | 400 Bad Request     | "detail": {"object\_record": \["Invalid pk "\<object\_record\_id>" - object does not exist."]}|
| `object_record` and `task_template` set is not unique                   | 400 Bad Request     | "detail": "The fields task\_template, object\_record must make a unique set."                |
| Task template configuration class is different than object record class | 400 Bad Request     | "detail": "This task cannot be created for this record."                                   |
| Requesting user is authorized but without view perm for tasks resource  | 403 Forbidden       | "detail": "You do not have permission to perform this action."                             |
| Requesting user is not authenticated                                    | 401 Unauthorized    | "detail": "Authentication credentials were not provided."                                  |

## GET /api/tasks/

List Tasks based on query parameters and caller permissions.

### Permissions

Requires `authentication`.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/tasks/
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key               | Type     | Notes                                                                                                                                                                                                                                                                                                                                                  |
|-------------------|----------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| id                | id       |                                                                                                                                                                                                                                                                                                                                                        |
| name              | string   |                                                                                                                                                                                                                                                                                                                                                        |
| task\_template     | int      |                                                                                                                                                                                                                                                                                                                                                        |
| object\_class      | int      |                                                                                                                                                                                                                                                                                                                                                        |
| object\_record     | int      |                                                                                                                                                                                                                                                                                                                                                        |
| object\_name       | string   | Value equal to Object Record name. If the user that calls GET /api/tasks/ does not have object\_record: view permissions for the records the tasks were created for, the object\_name returns `null`.  Object Record identifier is `object_record_id` if the Object class from which the Record was created does not have an identifier field. |
| status            | bool     | Values: not\_created, not\_started, in\_progress, completed, etc.                                                                                                                                                                                                                                                                                         |
| due\_date          | datetime |                                                                                                                                                                                                                                                                                                                                                        |
| expiry\_date       | datetime |                                                                                                                                                                                                                                                                                                                                                        |
| configuration     | array    | Copy of [Task template](/api/catalyst/resources/tasks/task-templates) object                                                                                                                                                                                                                                                                                                    |
| expiry\_at         | datetime |                                                                                                                                                                                                                                                                                                                                                        |
| created\_at        | datetime |                                                                                                                                                                                                                                                                                                                                                        |
| completed\_at      | datetime |                                                                                                                                                                                                                                                                                                                                                        |
| completed\_by      | user     |                                                                                                                                                                                                                                                                                                                                                        |
| modified\_by       | user     |                                                                                                                                                                                                                                                                                                                                                        |
| current\_owner     | user     |                                                                                                                                                                                                                                                                                                                                                        |
| current\_assignees | array    | Contains list of assigneed Users and UserGroups                                                                                                                                                                                                                                                                                                        |
| \_meta             | Object   | [\_meta](#response-meta-object) result                                                                                                                                                                                                                                                                                                                  |

### Response `_meta` object

| Key                 | Type   | Notes                          |
|---------------------|--------|--------------------------------|
| permission          | Object | Object describing permissions. |
| labels.object\_class | string | Object Class name              |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 10,
  "offset": 0,
  "filtered_count": 566,
  "total_count": 566,
  "next": "{build}/api/tasks/?limit=10&offset=10&ordering=-id",
  "previous": null,
  "results": [
    {
      "id": 2251,
      "name": "New task JW",
      "task_template": 513,
      "object_class": 5422,
      "object_record": 2274,
      "object_name": "Details restricted due to permissions.",
      "status": "overdue",
      "due_date": "2022-07-31",
      "expiry_date": null,
      "configuration": {
        "plugin_config": {
          "task_type": "tt_form",
          "_meta": {
            "labels": {
              "task_type": "Complete standalone form"
            }
          }
        }
      },
      "completed_at": null,
      "completed_by": null,
      "current_owner": null,
      "current_assignees": {
          "users": [
              {
                  "id": 2,
                  "first_name": "ALX",
                  "last_name": "Developer",
                  "username": "alx.dev@autologyx.com",
                  "company_name": "",
                  "is_deleted": false,
                  "account_type": "super_admin"
              }
          ],
          "user_groups": [
              {
                  "id": 256,
                  "name": "ALX Group" 
              }
          ]
      }
      "created_at": "2022-08-17T10:37:10.721179+02:00",
      "modified_at": "2022-08-17T10:37:10.728901+02:00",
      "_meta": {
        "permissions": {
          "list": true,
          "view": true,
          "edit": true,
          "delete": true,
          "create": true,
          "complete": true,
          "assign": true
        }
      }
    },
    {
      "id": 2250,
      "name": "Update Record Form",
      "task_template": 864,
      "object_record": 1120,
      "status": "outstanding",
      "due_date": null,
      "expiry_date": null,
      "configuration": {
        "plugin_config": {
          "task_type": "tt_object_record_update",
          "_meta": {
            "labels": {
              "task_type": "Object Record update"
            }
          }
        }
      },
      "completed_at": null,
      "completed_by": null,
      "current_owner": null,
      "current_assignees": null,
      "created_at": "2022-08-17T08:13:20.842772+02:00",
      "modified_at": "2022-08-17T08:13:20.853851+02:00",
      "_meta": {
        "permissions": {
          "list": true,
          "view": true,
          "edit": true,
          "delete": true,
          "create": true,
          "complete": true,
          "assign": true
        },
        "labels": {
          "object_class": "Object Class name"
        }
      }
    }
  ]
}
```

### Sorting

| Parameter     | Example                                    | Notes           |
|---------------|--------------------------------------------|-----------------|
| id            | {build}/api/tasks/?ordering=id             | Ascending       |
| id            | {build}/api/tasks/?ordering=-id            | Descending (-)  |
| name          | {build}/api/tasks/?ordering=name           | Ascending       |
| name          | {build}/api/tasks/?ordering=-name          | Descending (-)  |
| object\_class  | {build}/api/tasks/?ordering=object\_class   | Ascending       |
| object\_class  | {build}/api/tasks/?ordering=-object\_class  | Descending (-)  |
| object\_record | {build}/api/tasks/?ordering=object\_record  | Ascending       |
| object\_record | {build}/api/tasks/?ordering=-object\_record | Descending (-)  |
| task\_template | {build}/api/tasks/?ordering=task\_template  | Ascending       |
| task\_template | {build}/api/tasks/?ordering=-task\_template | Descending (-)  |
| expiry\_at     | {build}/api/tasks/?ordering=expiry\_at      | Ascending       |
| expiry\_at     | {build}/api/tasks/?ordering=-expiry\_at     | Descending (-)  |
| due\_date      | {build}/api/tasks/?ordering=due\_date       | Ascending       |
| due\_date      | {build}/api/tasks/?ordering=-due\_date      | Descending (-)  |
| created\_at    | {build}/api/tasks/?ordering=created\_at     | Ascending       |
| created\_at    | {build}/api/tasks/?ordering=-created\_at    | Descending (-)  |
| modified\_at   | {build}/api/tasks/?ordering=modified\_at    | Ascending       |
| modified\_at   | {build}/api/tasks/?ordering=-modified\_at   | Descending (-)  |
| completed\_at  | {build}/api/tasks/?ordering=completed\_at   | Ascending       |
| completed\_at  | {build}/api/tasks/?ordering=-completed\_at  | Descending (-)  |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter                      | Predicates                        | Example                                                               |
|--------------------------------|-----------------------------------|-----------------------------------------------------------------------|
| id                             | standard pk                       | {build}/api/tasks/?id=1                                               |
| name                           | standard string                   | {build}/api/tasks/?name\_\_icontains=foobar                             |
| task\_template                  | standard set                      | {build}/api/tasks/?task\_template\_\_in=3,33,333                         |
| expiry\_date                    | standard datetime                 | {build}/api/tasks/?expiry\_date\_\_gte=2022-01-01                        |
| created\_at                     | standard datetime                 | {build}/api/tasks/?created\_at\_\_gte=2022-01-01                         |
| completed\_at                   | standard datetime                 | {build}/api/tasks/?completed\_at\_\_gte=2022-01-01                       |
| completed\_by                   | standard set                      | {build}/api/tasks/?completed\_by\_\_in=123,234,345                       |
| status                         | standard set                      | {build}/api/tasks/?status\_\_in=completed,created                       |
| task\_type                      | standard set                      | {build}/api/tasks/?task\_type=tt\_form                                  |
| object\_class                   | standard pk with in predicate     | {build}/api/tasks/?object\_class\_\_in=3,33,333                          |
| object\_record                  | standard set                      | {build}/api/tasks/?object\_record\_\_in=3,33,333                         |
| due\_date                       | standard datetime                 | {build}/api/tasks/?due\_date\_\_range=2022-01-01,2022-01-31              |
| created\_at                     | standard datetime                 | {build}/api/tasks/?created\_at\_\_gte=2022-01-01                         |
| created\_by                     | standard set                      | {build}/api/tasks/?created\_by\_\_in=123,234,345                         |
| modified\_at                    | standard datetime                 | {build}/api/tasks/?modified\_at\_\_range=2022-01-01,2022-01-31           |
| modified\_by                    | standard set                      | {build}/api/tasks/?modified\_by=123                                    |
| current\_owner                  | standard set                      | {build}/api/tasks/?current\_owner=12                                   |
| current\_assignees\_\_users       | isnull, containsall, containssome | {build}/api/tasks/?current\_assignees\_\_users\_\_containssome=12,48       |
| current\_assignees\_\_user\_groups | isnull, containsall, containssome | {build}/api/tasks/?current\_assignees\_\_user\_groups\_\_containssome=12,48 |

#### Complex filtering

Filtering using a JSON-like structure in the query string see [Complex Filtering Technical Design](https://autologyx.sharepoint.com/:w:/s/Dev/EXOa9GmKXbhFpIOkffrWNeYBjqIa952BMg2EQRQhTh91ig?e=QtwRaL) .
A specified query parameter that contains JSON data representing filtering logic, allowing for both (AND, OR) conditions to be combined in a flexible manner.
Performance degradation in case of very complex queries is possible especially if the query contains multiple `or` conditions.
For example, to filter tasks with a name containing "foo" and a status of "completed", you can use the following query:

```json
{
  "filter": {
    "and": [
      {
        "name__icontains": "foo"
      },
      {
        "status": "completed"
      },
    ]
  },
}
```

#### Sample usage in url:

```json
/api/tasks/?filters={ 
  "or": [ 
           {"current_assignees__users__containsall": "2,31"}, 
           {"current_assignees__user_groups__containssome": "1,2"} 
  ] 
} 
```

In the example above, the JSON in query param is shown in raw form for better readability.
The JSON must be URL-encoded to be transmitted correctly over the HTTP protocol.
The above example would be sent as:

```json
?filters=%7B%22or%22%3A+%5B%7B%22current_assignees__users__containsall%22%3A+%222%2C31%22%7D%2C+%7B%22current_assignees__user_groups__containssome%22%3A+%221%2C2%22%7D%5D%7D 
```

It could be mixed with regular filters.

```json
?id=1&filters=%7B%22or%22%3A+%5B%7B%22current_assignees__users__containsall%22%3A+%222%2C31%22%7D%2C+%7B%22current_assignees__user_groups__containssome%22%3A+%221%2C2%22%7D%5D%7D 
```

##### Special cases

Not recommended but supported in the API in that way:

* if the same key is used multiple times (duplicated keys) in the same filter
  ```json
  /api/tasks/?filters={ 
    "or": [ 
             {"current_assignees__users__containsall": "2,31"}, 
             {"current_assignees__users__containsall": "1,2"} 
    ] 
  } 
  ```
  only last one will be used, all previous occurrences will be ignored
  ```json
  {"current_assignees__users__containsall": "1,2"}
  ```
* if single condition entry contains multiple conditions
  ```json
  /api/tasks/?filters={ 
    "or": [ 
             {"current_assignees__users__containsall": "2,31", "id": "1"}, 
             {"current_assignees__user_groups__containssome": "1,2"} 
    ] 
  } 
  ```
  first multiple condition entry will be used with operator `and` and the result will be combined with second entry with operator `or`
  ```json
  {"current_assignees__users__containsall": "2,31", "id": "1"}
  (current_assignees__users__containsall = "2,31" and id = "1") or current_assignees__user_groups__containssome = "1,2"
  ```
* nested conditions support is possible but strongly not recommended.
  ```json
  /api/tasks/?filters={ 
    "or": [ 
             {"current_assignees__users__containsall": "2,31"}, 
             {"current_assignees__user_groups__containssome": "1,2", "and": [{"id": "1"}, {"name": "foo"}]} 
    ] 
  } 
  ```
  will be used as:
  ```json
  {"current_assignees__users__containsall": "2,31"} or (current_assignees__user_groups__containssome = "1,2" and id = "1" and name = "foo")
  ```

### Errors

| Error                                  | Response code     | Message                                                                                                  |
|----------------------------------------|-------------------|----------------------------------------------------------------------------------------------------------|
| Requesting user is not authenticated   | 401 Unauthorized  | "detail": "Authentication credentials were not provided."                                                |
| Filter task type is not a valid choice | 400 Bad Request   | "detail": {"task\_type":  \["Select a valid choice. fake\_type is not one of the available choices."]}    |
| Invalid date/time in date field filter | 400 Bad Request   | "detail": {"created\_at": \["Enter a valid date/time."]}                                                 |
| Filter completed\_by with wrong user id | 400 Bad Request   | "detail": {"task\_type":  \["Select a valid choice. completed\_by is not one of the available choices."]} |
| Filter invalid object                  | 400 Bad Request   | {"filters": \["Value must be a JSON object."]}                                                          |
| Filter invalid single operator         | 400 Bad Request   | {"filters": \["JSON must contain exactly one key: 'or' or 'and'."]}                                     |
| Filter invalid list                    | 400 Bad Request   | {"filters": \["The value of "logic\_key" must be a list."]}                                            |
| Filter max items exceeded              | 400 Bad Request   | {"filters": \["List cannot contain more than 10 elements."]}                                            |
| Filter invalid single key              | 400 Bad Request   | {"filters": \["Value must have exactly one key."]}                                                      |
| Filter invalid nested operators        | 400 Bad Request   | {"filters": \["Nested logical operators are not allowed."]}                                             |

## OPTIONS /api/tasks/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/tasks/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "name",
                "type": "string",
                "predicates": [
                    "exact",
                    "iexact",
                    "contains",
                    "icontains",
                    "startswith",
                    "istartswith",
                    "endswith",
                    "iendswith"
                ],
                "sort_ok": true
            },
            {
                "alias": "task_template",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "object_class",
                "type": "enum",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/object-classes/autocomplete/?text__icontains="
            },
            {
                "alias": "object_record",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "object_name",
                "type": "string",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "status",
                "type": "enum",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "values": [
                    {
                        "value": "outstanding",
                        "text": "Outstanding"
                    },
                    {
                        "value": "overdue",
                        "text": "Overdue"
                    },
                    {
                        "value": "completed",
                        "text": "Completed"
                    }
                ]
            },
            {
                "alias": "due_date",
                "type": "date",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range",
                    "isnull"
                ],
                "sort_ok": true
            },
            {
                "alias": "expiry_date",
                "type": "date",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range",
                    "isnull"
                ],
                "sort_ok": true
            },
            {
                "alias": "configuration",
                "schema": {
                    "alias": "plugin_config",
                    "schema": [
                        {
                            "alias": "task_type",
                            "type": "enum",
                            "predicates": [
                                "exact",
                                "in"
                            ],
                            "sort_ok": false,
                            "values": [
                                {
                                    "value": "tt_form",
                                    "text": "Complete standalone form"
                                },
                                {
                                    "value": "tt_object_record_update",
                                    "text": "Object Record update"
                                }
                            ]
                        }
                    ]
                }
            },
            {
                "alias": "current_owner",
                "type": "user",
                "predicates": [
                    "exact",
                    "in",
                    "isnull"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "current_assignees",
                "type": "user_and_group",
                "predicates": [
                    "containsall",
                    "containssome",
                    "isnull"
                ],
                "sort_ok": false,
                "autocomplete_users": "/api/users/autocomplete/?text__icontains=",
                "autocomplete_user_groups": "/api/user-groups/autocomplete/?text__icontains="
            },
            {
                "alias": "completed_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range",
                    "isnull"
                ],
                "sort_ok": true
            },
            {
                "alias": "completed_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in",
                    "isnull"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "modified_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            }
        ]
    },
    "details": {
        "schema": [
            {
                "alias": "name",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "min_length",
                        "length": 1
                    },
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "task_template",
                "type": "int",
                "required": true,
                "autocomplete": "/api/task-templates/autocomplete/?creation=manual&text__icontains="
            },
            {
                "alias": "expiry_date",
                "type": "date",
                "required": false
            },
            {
                "alias": "configuration",
                "schema": {
                    "alias": "plugin_config",
                    "schema": [
                        {
                            "alias": "task_type",
                            "editable": false,
                            "type": "enum",
                            "required": true,
                            "values": [
                                {
                                    "value": "tt_form",
                                    "text": "Complete standalone form"
                                },
                                {
                                    "value": "tt_object_record_update",
                                    "text": "Object Record update"
                                }
                            ]
                        }
                    ],
                    "schema_by_type": [
                        {
                            "task_type": "tt_form",
                            "schema": [
                                {
                                    "autocomplete": "/api/task-templates/autocomplete/?task_type=tt_form&creation=manual&text__icontains="
                                }
                            ]
                        },
                        {
                            "task_type": "tt_object_record_update",
                            "schema": [
                                {
                                    "autocomplete": "/api/task-templates/autocomplete/?task_type=tt_object_record_update&object_class={object_id}&creation=manual&text__icontains="
                                }
                            ]
                        }
                    ]
                }
            },
            {
                "alias": "due_date",
                "type": "date",
                "required": false
            }
        ]
    }
}
```

## GET /api/tasks/`task_id`/

### Permissions

Requires `authentication` and any of

1. `tasks.view` permission
2. Object Record Ownership
3. Object Class Ownership
4. Object Record Permission Set permission
5. Object Class Permission Set permission

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| task\_id        | id      |             |

* Headers

```
<!-- Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/tasks/`task_id`/
```

### Response

| Key           | Type    | Notes                                               |
|---------------|---------|-----------------------------------------------------|
| id            | uuid    |                                                     |
| name          | string  |                                                     |
| task\_template | int     |                                                     |
| object\_class  | int     |                                                     |
| object\_record | int     |                                                     |
| instructions  | string  |                                                     |
| configuration | array   | Copy of [Task template](/api/catalyst/resources/tasks/task-templates) object |
| status        | enum    |                                                     |
| created\_at    | date    |                                                     |
| created\_by    | user    |                                                     |
| modified\_at   | date    |                                                     |
| modified\_by   | user    |                                                     |
| due\_date      | date    |                                                     |
| expiry\_date   | date    |                                                     |
| completed\_at  | date    |                                                     |
| completed\_by  | user    |                                                     |
| response      | Array   | [Response](#response-response-array) result         |
| stages        | Array   | [Stages](#response-stages-array) result             |
| next\_actions  | Array   | [Actions](#response-actions-array) schema           |
| \_meta         | Object  | [\_meta](#response-meta-object) result               |

### Response `response` array

| Key               | Type          | Notes                    |
|-------------------|---------------|--------------------------|
| id                | uuid          |                          |
| state             | enum          |                          |
| data              | Array         |                          |
| files             | Array         |                          |
| modified\_at       | Array         |                          |
| modified\_by       | user          |                          |
| \_meta.labels      | Object        |                          |
| \_meta.users       | Object        | Only for User field type |
| \_meta.user\_groups | Object        | Only for User field type |

#### `data` for Response type `Object Record Update`

::: When `task_type` is `tt_object_record_update` the `data` contains

* If task is `initial` and was never saved before: values are taken from recent Object Record related field values.
* If task was saved with given field: `data` will contain this field and value from the saved task.
* If task was saved before and given field was not saved in there: value is taken from recent Object Record related field value.
  :::

### Response `stages` array

| Key                   | Type         | Notes                 |
|-----------------------|--------------|-----------------------|
| name                  | enum         |                       |
| status                | enum         |                       |
| owner                 | user         |                       |
| assignees.users       | Array        | List of users         |
| assignees.user\_groups | Array        | List of user\_groups   |

### Response `_meta` object

| Key           | Type   | Notes |
|---------------|--------|-------|
| labels.status | enum   |       |
| labels.files  | Object |       |
| permission    | Object |       |

### Response `actions` array

| Owner               | Assign              | Complete            | Next actions                                              |
|---------------------|---------------------|---------------------|-----------------------------------------------------------|
| :heavy\_check\_mark:  | :heavy\_check\_mark:  | :heavy\_check\_mark:  | view, save, complete, give\_up\_ownership, change\_ownership |
| :heavy\_check\_mark:  |                     | :heavy\_check\_mark:  | view, save, complete, give\_up\_ownership                   |
|                     | :heavy\_check\_mark:  | :heavy\_check\_mark:  | view, save, complete, take\_ownership, change\_ownership    |
|                     |                     | :heavy\_check\_mark:  | view, save, complete, take\_ownership                      |
|                     |                     |                     | view                                                      |

### Response example

* Status `200 OK`
* Body

```json
{
  "id": 1,
  "name": "Test",
  "task_template": 2,
  "object_class": 1,
  "object_record": 1,
  "instructions": "",
  "configuration": {
    "expiry": "date",
    "renewals": [],
    "reminders": [],
    "expiry_day": null,
    "complete_by": "asap",
    "description": "",
    "expiry_date": "2022-05-21",
    "modified_by": {
      "id": 2,
      "username": "John.Kowalsky@autologyx.com",
      "last_name": "Kowalsky",
      "first_name": "John",
      "is_deleted": false,
      "company_name": ""
    },
    "instructions": "",
    "plugin_config": {
      "prompt": "",
      "task_type": "tt_form",
      "allow_comment": false,
      "configuration": {},
      "approval_required": false,
      "approval_conditions": []
    },
    "task_creation": "automatic",
    "complete_by_date": null,
    "expiry_time_unit": null,
    "expiry_time_value": null,
    "expiry_time_rel_to": null,
    "expiry_periodic_day": null,
    "task_group_templates": [],
    "complete_by_time_unit": null,
    "expiry_periodic_month": null,
    "complete_by_time_value": null
  },
  "status": "completed",
  "created_at": "2022-05-17T13:49:06.100636+02:00",
  "created_by": {
    "id": 2,
    "first_name": "John",
    "last_name": "Kowalsky",
    "username": "John.Kowalsky@autologyx.com",
    "company_name": "",
    "is_deleted": false
  },
  "modified_at": "2022-05-17T13:49:37.246827+02:00",
  "modified_by": {
    "id": 2,
    "first_name": "John",
    "last_name": "Kowalsky",
    "username": "John.Kowalsky@autologyx.com",
    "company_name": "",
    "is_deleted": false
  },
  "due_date": null,
  "expiry_date": "2022-05-21",
  "completed_at": "2022-05-17T13:49:37.243158+02:00",
  "completed_by": {
    "id": 2,
    "first_name": "John",
    "last_name": "Kowalsky",
    "username": "John.Kowalsky@autologyx.com",
    "company_name": "",
    "is_deleted": false
  },
  "response": {
    "id": 30,
    "state": "saved",
    "data": {},
    "files": {},
    "modified_at": "2022-07-14T23:41:11.912516+02:00",
    "modified_by": {
      "id": 2,
      "first_name": "John",
      "last_name": "Kowalsky",
      "username": "John.Kowalsky@autologyx.com",
      "company_name": "",
      "is_deleted": false,
      "account_type": "full"
    },
    "_meta": {
      "labels": {
        "state": "Saved",
        "files": null
      }
    }
  },
  "stages": [
    {
      "name": "stage_1",
      "status": "outstanding",
      "assignees": {
        "users": [
          {
            "id": 2,
            "first_name": "John",
            "last_name": "Kowalsky",
            "username": "John.Kowalsky@autologyx.com",
            "company_name": "",
            "is_deleted": false
          }
        ],
        "user_groups": [
          {
            "id": 222,
            "name": "Group 222" 
          }
        ]
      },
      "owner": {
        "id": 2,
        "first_name": "John",
        "last_name": "Kowalsky",
        "username": "John.Kowalsky@autologyx.com",
        "company_name": "",
        "is_deleted": false
      }
    }
  ],
  "next_actions": [
    "view",
    "save",
    "complete",
    "give_up_ownership",
    "change_ownership" 
  ],
  "_meta": {
    "labels": {
      "status": "Completed"
    },
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "delete": true,
      "create": true,
      "complete": true,
      "assign": true
    }
  }
}
```

### Sorting

Not supported

### Filtering

Not supported

### Errors

| Error                                                                    | Response code    | Message                                                        |
|--------------------------------------------------------------------------|------------------|----------------------------------------------------------------|
| A non-existent `task_id` was given                                       | 404 Not Found    | "detail": "Not found."                                         |
| Requesting user is authorized but without view perm for tasks resource   | 403 Forbidden    | "detail": "You do not have permission to perform this action." |
| Requesting user is not authenticated                                     | 401 Unauthorized | "detail": "Authentication credentials were not provided."      |

## PATCH /api/tasks/`task_id`/

### Permissions

Requires `authentication` and any of:

1. `tasks.edit` permission
2. Object Record Ownership
3. Object Class Ownership
4. Object Record Permission Set permission

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| task\_id        | id      |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Body

| Key          | Type   | Required  | Notes           |
|--------------|--------|-----------|-----------------|
| due\_date     | date   | false     |                 |

* Schema

```json
PATCH /api/tasks/`task_id`/
```

### Response

| Key             | Type   | Notes                                               |
|-----------------|--------|-----------------------------------------------------|
| id              | uuid   |                                                     |
| name            | string |                                                     |
| task\_template   | int    |                                                     |
| object\_class    | int    |                                                     |
| object\_record   | int    |                                                     |
| instructions    | string |                                                     |
| configuration   | array  | Copy of [Task template](/api/catalyst/resources/tasks/task-templates) object |
| status          | enum   |                                                     |
| created\_at      | date   |                                                     |
| created\_by      | user   |                                                     |
| modified\_at     | date   |                                                     |
| modified\_by     | user   |                                                     |
| due\_date        | date   |                                                     |
| expiry\_date     | date   |                                                     |
| completed\_at    | date   |                                                     |
| completed\_by    | user   |                                                     |
| response        | Array  | [Response](#response-response-array) result         |
| stages          | Array  | [Stages](#response-stages-array) result             |
| next\_actions    | Array  | [Actions](#response-actions-array) schema           |
| \_meta           | Object | [\_meta](#response-meta-object) result               |

### Response `response` array

| Key             | Type          | Notes      |
|-----------------|---------------|------------|
| id              | uuid          |            |
| state           | enum          |            |
| data            | Array         |            |
| files           | Array         |            |
| modified\_at     | Array         |            |
| modified\_by     | user          |            |
| \_meta.labels    | Object        |            |

#### `data` for Response type `Object Record Update`

::: When `task_type` is `tt_object_record_update` the `data` contains

* If task is `initial` and was never saved before: values are taken from recent Object Record related field values.
* If task was saved with given field: `data` will contain this field and value from the saved task.
* If task was saved before and given field was not saved in there: value is taken from recent Object Record related field value.
  :::

### Response `stages` array

| Key                   | Type          | Notes                |
|-----------------------|---------------|----------------------|
| name                  | enum          |                      |
| status                | enum          |                      |
| owner                 | user          |                      |
| assignees.users       | Array         | List of users        |
| assignees.user\_groups | Array         | List of user\_groups  |

### Response `_meta` object

| Key           | Type   | Notes |
|---------------|--------|-------|
| labels.status | enum   |       |
| labels.files  | Object |       |
| permission    | Object |       |

### Response `actions` array

| Owner               | Assign              | Complete            | Next actions                                              |
|---------------------|---------------------|---------------------|-----------------------------------------------------------|
| :heavy\_check\_mark:  | :heavy\_check\_mark:  | :heavy\_check\_mark:  | view, save, complete, give\_up\_ownership, change\_ownership |
| :heavy\_check\_mark:  |                     | :heavy\_check\_mark:  | view, save, complete, give\_up\_ownership                   |
|                     | :heavy\_check\_mark:  | :heavy\_check\_mark:  | view, save, complete, take\_ownership, change\_ownership    |
|                     |                     | :heavy\_check\_mark:  | view, save, complete, take\_ownership                      |
|                     |                     |                     | view                                                      |

### Response example

* Status `200 OK`
* Body

```json
{
  "id": 1,
  "name": "Test",
  "task_template": 2,
  "object_class": 1,
  "object_record": 1,
  "instructions": "",
  "configuration": {
    "expiry": "date",
    "renewals": [],
    "reminders": [],
    "expiry_day": null,
    "complete_by": "asap",
    "description": "",
    "expiry_date": "2022-05-21",
    "modified_by": {
      "id": 2,
      "username": "John.Kowalsky@autologyx.com",
      "last_name": "Kowalsky",
      "first_name": "John",
      "is_deleted": false,
      "company_name": ""
    },
    "instructions": "",
    "plugin_config": {
      "prompt": "",
      "task_type": "tt_form",
      "allow_comment": false,
      "configuration": {},
      "approval_required": false,
      "approval_conditions": []
    },
    "task_creation": "automatic",
    "complete_by_date": null,
    "expiry_time_unit": null,
    "expiry_time_value": null,
    "expiry_time_rel_to": null,
    "expiry_periodic_day": null,
    "task_group_templates": [],
    "complete_by_time_unit": null,
    "expiry_periodic_month": null,
    "complete_by_time_value": null
  },
  "status": "completed",
  "created_at": "2022-05-17T13:49:06.100636+02:00",
  "created_by": {
    "id": 2,
    "first_name": "John",
    "last_name": "Kowalsky",
    "username": "John.Kowalsky@autologyx.com",
    "company_name": "",
    "is_deleted": false
  },
  "modified_at": "2022-05-17T13:49:37.246827+02:00",
  "modified_by": {
    "id": 2,
    "first_name": "John",
    "last_name": "Kowalsky",
    "username": "John.Kowalsky@autologyx.com",
    "company_name": "",
    "is_deleted": false
  },
  "due_date": null,
  "expiry_date": "2022-05-21",
  "completed_at": "2022-05-17T13:49:37.243158+02:00",
  "completed_by": {
    "id": 2,
    "first_name": "John",
    "last_name": "Kowalsky",
    "username": "John.Kowalsky@autologyx.com",
    "company_name": "",
    "is_deleted": false
  },
  "response": {
    "id": 30,
    "state": "saved",
    "data": {},
    "files": {},
    "modified_at": "2022-07-14T23:41:11.912516+02:00",
    "modified_by": {
      "id": 2,
      "first_name": "John",
      "last_name": "Kowalsky",
      "username": "John.Kowalsky@autologyx.com",
      "company_name": "",
      "is_deleted": false,
      "account_type": "full"
    },
    "_meta": {
      "labels": {
        "state": "Saved",
        "files": null
      }
    }
  },
  "stages": [
    {
      "name": "stage_1",
      "status": "outstanding",
      "assignees": {
        "users": [
          {
            "id": 2,
            "first_name": "John",
            "last_name": "Kowalsky",
            "username": "John.Kowalsky@autologyx.com",
            "company_name": "",
            "is_deleted": false
          }
        ],
        "user_groups": [
          {
            "id": 222,
            "name": "Group 222" 
          }
        ]
      },
      "owner": {
        "id": 2,
        "first_name": "John",
        "last_name": "Kowalsky",
        "username": "John.Kowalsky@autologyx.com",
        "company_name": "",
        "is_deleted": false
      }
    }
  ],
  "next_actions": [
    "view",
    "save",
    "complete",
    "give_up_ownership",
    "change_ownership" 
  ],
  "_meta": {
    "labels": {
      "status": "Completed"
    },
    "permissions": {
      "list": true,
      "view": true,
      "edit": true,
      "delete": true,
      "create": true,
      "complete": true,
      "assign": true
    }
  }
}
```

### Sorting

Not supported

### Filtering

Not supported

### Errors

| Error                                                                 | Response code     | Message                                                                  |
|-----------------------------------------------------------------------|-------------------|--------------------------------------------------------------------------|
| `name` is to long                                                     | 400 Bad Request   | "detail": {"name": "Ensure this field has no more than 100 characters."} |
| A non-existent `task_id` was given                                    | 404 Not Found     | "detail": "Not found."                                                   |
| Requesting user is authorized but without perm for tasks resource     | 403 Forbidden     | "detail": "You do not have permission to perform this action."           |
| Requesting user is not authenticated                                  | 401 Unauthorized  | "detail": "Authentication credentials were not provided."                |

## DELETE /api/tasks/`task_id`/

Remove a Task.

### Permissions

Requires `authentication` and any of:

1. `tasks.delete` permission
2. Object Record Ownership
3. Object Class Ownership
4. Object Record Permission Set permission

### Request example

* Headers

```
Request Method: DELETE
Location: /api/tasks/1/
Authorization: JWT access_token
```

### Response example

* Status `204 No Content`
* Body

### Errors

| Error                                                             | Response code     | Message                                                                  |
|-------------------------------------------------------------------|-------------------|--------------------------------------------------------------------------|
| A non-existent `task_id` was given                                | 404 Not Found     | "detail": "Not found."                                                   |
| Requesting user is authorized but without perm for tasks resource | 403 Forbidden     | "detail": "You do not have permission to perform this action."           |
| Requesting user is not authenticated                              | 401 Unauthorized  | "detail": "Authentication credentials were not provided."                |

## POST /api/tasks/`id`/complete/

Complete task.

::: tip Automatic Task ownership assignment

* If the Task does not have an owner, the caller is automatically assigned as the Task owner.
* If the Task does have an owner, the current Task owner remains unchanged.
  :::

### Permissions

Requires `authentication` and `task complete` permission, records in classes where user owns.

The following table contains supported values of `task_type` field:

* [tt\_form](#response-type-form)
* [tt\_object\_record\_update](#response-type-object-record-update)

## POST /api/tasks/`id`/save/

Save settings for task.

::: tip Automatic Task ownership assignment

* If the Task does not have an owner, the caller is automatically assigned as the Task owner.
* If the Task does have an owner, the current Task owner remains unchanged.
  :::

### Permissions

Requires `authentication` and `task complete` permission, records in classes where user owns.

The following table contains supported values of `task_type` field:

* [tt\_form](#response-type-form)
* [tt\_object\_record\_update](#response-type-object-record-update)

Save task for `tt_object_record_update`.

### Request

* Body parameters

| Key             | Type   | Notes                     |
|-----------------|--------|---------------------------|
| data            | json   | Structure contains fields |
| files.file\_list | Array  |                           |

Any parameter not listed above are silently ignored if passed.

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/tasks/`id`/save/

{
    "data": {
        "field_test_string": <str>,
        "field_test_integer": <integer>,
        "field_test_datetime": <datetime>,
        "field_test_user": <user>,
        "other_2": <str>,
    },
    "files": {
        "field_test_4": <document>
    },
}
```

### Response

| Key             | Type      | Notes                                   |
|-----------------|-----------|-----------------------------------------|
| id              | uuid      | Automatically generated by the backend. |
| state           | string    |                                         |
| data            | Object    |                                         |
| files           | Object    |                                         |
| modified\_at     | datetime  |                                         |
| modified\_by     | user      |                                         |
| \_meta.labels    | Object    | "object\_class": {class name}            |

### Response example

* Status `201 CREATED`
* Body

```json
{
    "id": 1,
    "state": "saved",
    "data": {
        "field_test_string": "John",
        "field_test_integer": 1,
        "field_test_user": '{"users": [13], "user_groups": [1]}',
        "other_2": "Test",
    },
    "files": {
        "field_test_4": [1]
    },
    "modified_at": "2022-03-04T09:20:38.357221Z",
    "modified_by": {
        "id": 1,
        "first_name": "Firstname",
        "last_name": "Lastname",
        "username": "username",
        "company_name": "alx",
        "is_deleted": false
    },
    "_meta": {
        "labels": {
            "state": "Saved",
            "files": {
                "1": {
                    "name": "file1.pdf",
                    "url": "https://test.test/api/files/response/file/3ec2175c-fcc5-4afa-922d-d52460866411/",
                    "size": "13264",
                    "type": "application/pdf" 
                }
            }
        }
    }
}
```

### Restriction

* Maximum number of fields: 2000.

### Errors

| Error                                                                             | Response code     | Message                                                                         |
|-----------------------------------------------------------------------------------|-------------------|---------------------------------------------------------------------------------|
| `files` invalid data                                                              | 400 Bad Request   | 'files': {'file\_slug': "Invalid data. Expected a list, but got /type/."}      |
| `files` invalid token                                                             | 400 Bad Request   | 'files': {'file\_slug': \["Invalid token /token/."] }                           |
| `files` invalid id                                                                | 400 Bad Request   | 'files': {'file\_slug': \["Invalid file\_id /id/."] }                            |
| `files` duplicates                                                                | 400 Bad Request   | {'files': \["'file\_slug' cannot contain duplicates."]}                         |
| Insufficient permissions                                                          | 403 Forbidden     | "detail": "You do not have permission to perform this action."                  |

### Field type Errors

| Cause                                                                                      | Response code   | Message                                                                                                                    |
|--------------------------------------------------------------------------------------------|-----------------|----------------------------------------------------------------------------------------------------------------------------|
| string is too long                                                                         | 400 Bad Request | "field\_{string}": \["Ensure this field has no more than {max} characters."]                                               |
| string is required                                                                         | 400 Bad Request | "field\_{string}": \["This field is required."]                                                                            |
| string is not unique                                                                       | 400 Bad Request | "field\_{string}": \["This field must be unique."]                                                                         |
| integer value is invalid                                                                   | 400 Bad Request | "field\_{integer}": \["A valid integer is required."]                                                                      |
| integer is required                                                                        | 400 Bad Request | "field\_{integer}": \["This field is required."]                                                                           |
| integer value is below the limit                                                           | 400 Bad Request | "field\_{integer}": \["Ensure this value is greater than or equal to {min}."]                                              |
| integer value is above the limit                                                           | 400 Bad Request | "field\_{integer}": \["Ensure this value is less than or equal to {max}."]                                                 |
| integer is not unique                                                                      | 400 Bad Request | "field\_{integer}": \["This field must be unique."]                                                                        |
| float value is invalid                                                                     | 400 Bad Request | "field\_{float}": \["A valid number is required."]                                                                         |
| float is required                                                                          | 400 Bad Request | "field\_{float}": \["This field is required."]                                                                             |
| float value is below the limit                                                             | 400 Bad Request | "field\_{float}": \["Ensure this value is greater than or equal to {min}."]                                                |
| float value is above the limit                                                             | 400 Bad Request | "field\_{float}": \["Ensure this value is less than or equal to {max}."]                                                   |
| float is not unique                                                                        | 400 Bad Request | "field\_{float}": \["This field must be unique."]                                                                          |
| bool value is invalid                                                                      | 400 Bad Request | "field\_{bool}": \["Must be a valid boolean."]                                                                             |
| bool value different than required                                                         | 400 Bad Request | "field\_{bool}": \["Field contains a value other than required."]                                                          |
| email value is invalid                                                                     | 400 Bad Request | "field\_{email}": \["Enter a valid email address."]                                                                        |
| email is required                                                                          | 400 Bad Request | "field\_{email}": \["This field is required."]                                                                             |
| email value is above the limit                                                             | 400 Bad Request | "field\_{email}": \["Ensure this field has no more than {max} characters."]                                                |
| email is not unique                                                                        | 400 Bad Request | "field\_{email}": \["This field must be unique."]                                                                          |
| phone value is invalid                                                                     | 400 Bad Request | "field\_{phone}": \["Enter a valid email address."]                                                                        |
| phone is required                                                                          | 400 Bad Request | "field\_{phone}": \["This field is required."]                                                                             |
| phone value is above the limit                                                             | 400 Bad Request | "field\_{phone}": \["Ensure this field has no more than {max} characters."]                                                |
| phone is not unique                                                                        | 400 Bad Request | "field\_{phone}": \["This field must be unique."]                                                                          |
| date value is in wrong format                                                              | 400 Bad Request | "field\_{date}": \["Date has wrong format. Use one of these formats instead: YYYY-MM-DD."]                                 |
| date is required                                                                           | 400 Bad Request | "field\_{date}": \["This field is required."]                                                                              |
| date is not unique                                                                         | 400 Bad Request | "field\_{date}": \["This field must be unique."]                                                                           |
| time value is in wrong format                                                              | 400 Bad Request | "field\_{time}": \["Time has wrong format. Use one of these formats instead: hh:mm\[:ss\[.uuuuuu]]."]                    |
| time is required                                                                           | 400 Bad Request | "field\_{time}": \["This field is required."]                                                                              |
| time is not unique                                                                         | 400 Bad Request | "field\_{time}": \["This field must be unique."]                                                                           |
| datetime value is in wrong format                                                          | 400 Bad Request | "field\_{datetime}": \["Datetime has wrong format. Use one of these formats instead: YYYY-MM-DDThh:mm\[:ss\[.uuuuuu]]\[+HH:MM |-HH:MM|Z]."]|
| datetime is required                                                                       | 400 Bad Request | "field\_{datetime}": \["This field is required."]                                                                          |
| datetime is not unique                                                                     | 400 Bad Request | "field\_{datetime}": \["This field must be unique."]                                                                       |
| enum value is invalid                                                                      | 400 Bad Request | "field\_{enum}": \["{value} is not a valid choice.]                                                                        |
| enum is required                                                                           | 400 Bad Request | "field\_{enum}": \["This field is required."]                                                                              |
| enum is not unique                                                                         | 400 Bad Request | "field\_{enum}": \["This field must be unique."]                                                                           |
| set value is invalid                                                                       | 400 Bad Request | "field\_{set}": \["Value must be valid Set."]                                                                              |
| set is not a list                                                                          | 400 Bad Request | "field\_{set}": \["Value must be valid Set."]                                                                              |
| set value is below the limit                                                               | 400 Bad Request | "field\_{set}": \["The number of elements must be greater than or equal to {min}."]                                        |
| set value is above the limit                                                               | 400 Bad Request | "field\_{set}": \["The number of elements must be less than or equal to {max}."]                                           |
| url value is invalid                                                                       | 400 Bad Request | "field\_{url}": \["Enter a valid URL."]                                                                                    |
| url is required                                                                            | 400 Bad Request | "field\_{url}": \["This field is required."]                                                                               |
| url value is above the limit                                                               | 400 Bad Request | "field\_{url}": \["Ensure this field has no more than {max} characters."]                                                  |
| url is not unique                                                                          | 400 Bad Request | "field\_{url}": \["This field must be unique."]                                                                            |
| json value is invalid                                                                      | 400 Bad Request | "field\_{json}": \["Value must be valid JSON."]                                                                            |
| json is required                                                                           | 400 Bad Request | "field\_{json}": \["This field is required."]                                                                              |
| json value is above the limit                                                              | 400 Bad Request | "field\_{json}": \["Ensure this field has no more than {max} characters."]                                                 |
| json is not unique                                                                         | 400 Bad Request | "field\_{json}": \["This field must be unique."]                                                                           |
| document value is invalid                                                                  | 400 Bad Request | "field\_{document}": \["Value must be valid list."]                                                                        |
| document token is invalid                                                                  | 400 Bad Request | "field\_{document}": \["Invalid token {token}."]                                                                           |
| document number files is above the limit                                                   | 400 Bad Request | "field\_{document}": \["The number of elements must be less than or equal to {max}."]                                      |
| user is not a object                                                                       | 400 Bad Request | "field\_{user}": \["Expected a dictionary of items but got type "{type}"."]                                              |
| user value  not in the class field definition or not existing user ID (users)              | 400 Bad Request | "field\_{user}": \[""{value}" is not a valid choice."]                                                                   |
| user value is below the limit (users)                                                      | 400 Bad Request | "field\_{user}": \["The number of users elements must be greater than or equal to {min}."]                                 |
| user value is above the limit (users)                                                      | 400 Bad Request | "field\_{user}": \["The number of users elements must be less than or equal to {max}."]                                    |
| user value is not an array of integers (users)                                             | 400 Bad Request | "field\_{user}": {"users": \["The value must be an array of integers."]}                                                   |
| user value  not in the class field definition or not existing users group ID (user\_groups) | 400 Bad Request | "field\_{user}": \[""{value}" is not a valid choice."]                                                                   |
| user value is below the limit (user\_groups)                                                | 400 Bad Request | "field\_{user}": \["The number of user\_groups elements must be greater than or equal to {min}."]                           |
| user value is above the limit (user\_groups)                                                | 400 Bad Request | "field\_{user}": \["The number of user\_groups elements must be less than or equal to {max}."]                              |
| user value is not an array of integers (user\_groups)                                       | 400 Bad Request | "field\_{user}": {"user\_groups": \["The value must be an array of integers."]}                                             |
| user field - attempted to pass values in the user\_groups field when it was not permitted   | 400 Bad Request | "field\_{user}":  \["user\_groups field is not allowed."]                                                                   |
| user field - attempted to pass values in the users field when it was not permitted         | 400 Bad Request | "field\_{user}": \["users field is not allowed."]                                                                          |

### Response type `Form`

Complete task for `tt_form`.

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| id             | id      |             |

* Body parameters

| Key             | Type    | Notes                                                                      |
|-----------------|---------|----------------------------------------------------------------------------|
| data            | Object  | Structure contains field	                                                  |
| files.file\_list | Array   |                                                                            |

Any parameter not listed above are silently ignored if passed.

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/tasks/`id`/complete/

{
    "data": {
        "first_name": "John",
        "last_name": "Doe"
    },
    "files": {
        "file_list": [“e4e633c6-8abb-4756-9ba6-4b9be539e956”]
    }
}
```

### Response

| Key          | Type       | Notes                                   |
|--------------|------------|-----------------------------------------|
| id           | uuid       | Automatically generated by the backend. |
| state        | string     |                                         |
| data         | Object     |                                         |
| files        | Object     |                                         |
| modified\_at  | datetime   |                                         |
| modified\_by  | user       |                                         |
| \_meta.labels | Object     | "object\_class": {class name}            |

### Response example

* Status `201 CREATED`
* Body

```json
{
    "id": 1,
    "state": "accepted",
    "data": {
        "first_name": "John",
        "last_name": "Doe"
    },
    "files": {
        "file_list": [1]
    },
    "modified_at": "2022-03-04T09:20:38.357221Z",
    "modified_by": {
        "id": 1,
        "first_name": "Firstname",
        "last_name": "Lastname",
        "username": "username",
        "company_name": "alx",
        "is_deleted": false
    },
    "_meta": {
        "labels": {
            "state": "Accepted",
            "files": {
                "1": {
                    "name": "file1.pdf",
                    "url": "https://test.test/api/files/response/file/3ec2175c-fcc5-4afa-922d-d52460866411/",
                    "size": "13264",
                    "type": "application/pdf" 
                }
            }
        }
    }
}
```

### Errors

| Error                    | Response code     | Message                                                                   |
|--------------------------|-------------------|---------------------------------------------------------------------------|
| `data` value missing     | 400 Bad Request   | "data": \["This field is required."]                                     |
| `data` value is NULL     | 400 Bad Request   | "data": \["This list may not be null."]                                  |
| `files` invalid data     | 400 Bad Request   | 'files': {'file\_slug': "Invalid data. Expected a list, but got /type/."}|
| `files` invalid token    | 400 Bad Request   | 'files': {'file\_slug': \["Invalid token /token/."] }                     |
| `files` invalid id       | 400 Bad Request   | 'files': {'file\_slug': \["Invalid file\_id /id/."] }                      |
| `files` duplicates       | 400 Bad Request   | {'files': \["'file\_slug' cannot contain duplicates."]}                   |
| Insufficient permissions | 403 Forbidden     | "detail": "You do not have permission to perform this action."            |

### Response type `Object Record Update`

Complete task for `tt_object_record_update`.

### Request

* Body parameters

| Key             | Type   | Notes                     |
|-----------------|--------|---------------------------|
| data            | json   | Structure contains fields |
| files.file\_list | Array  |                           |

Any parameter not listed above are silently ignored if passed.

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/tasks/`id`/complete/

{
    "data": {
        "field_test_string": <str>,
        "field_test_integer": <integer>,
        "field_test_datetime": <datetime>,
        "field_test_user": <user>,
        "other_2": <str>,
    },
    "files": {
        "field_test_4": <document>
    },
}
```

### Response

| Key             | Type      | Notes                                   |
|-----------------|-----------|-----------------------------------------|
| id              | uuid      | Automatically generated by the backend. |
| state           | string    |                                         |
| data            | Object    |                                         |
| files           | Object    |                                         |
| modified\_at     | datetime  |                                         |
| modified\_by     | user      |                                         |
| \_meta.labels    | Object    | "object\_class": {class name}            |

### Response example

* Status `201 CREATED`
* Body

```json
{
    "id": 1,
    "state": "completed",
    "data": {
        "field_test_string": "John",
        "field_test_integer": 1,
        "field_test_user": '{"users": [13], "user_groups": [1]}',
        "other_2": "Test",
    },
    "files": {
        "field_test_4": [1]
    },
    "modified_at": "2022-03-04T09:20:38.357221Z",
    "modified_by": {
        "id": 1,
        "first_name": "Firstname",
        "last_name": "Lastname",
        "username": "username",
        "company_name": "alx",
        "is_deleted": false
    },
    "_meta": {
        "labels": {
            "state": "Completed",
            "files": {
                "1": {
                    "name": "file1.pdf",
                    "url": "https://test.test/api/files/response/file/3ec2175c-fcc5-4afa-922d-d52460866411/",
                    "size": "13264",
                    "type": "application/pdf" 
                }
            }
        }
    }
}
```

### Restriction

* Maximum number of fields: 2000.

### Errors

| Error                                                                             | Response code     | Message                                                                         |
|-----------------------------------------------------------------------------------|-------------------|---------------------------------------------------------------------------------|
| `data` value missing                                                              | 400 Bad Request   | "data": \["This field is required."]                                           |
| `data` value is NULL                                                              | 400 Bad Request   | "data": \["This list may not be null."]                                        |
| `data` does not contain all record fields required by task template configuration | 400 Bad Request   | "data": {"field\_{alias}": \["Field is required"]}                              |
| `data` value is different type than a list                                        | 400 Bad Request   | "data": \["Expected a list of items but got type "{type}"."]                 |
| `data` contains more than 2000 items                                              | 400 Bad Request   | 'data': {'non\_field\_errors': \['Up to 2000 items allowed.']}                   |
| `data` contains invalid date in some field.                                       | 400 Bad Request   | "data": {"field\_{alias}": ""}                                                 |
| `files` invalid data                                                              | 400 Bad Request   | 'files': {'file\_slug': "Invalid data. Expected a list, but got /type/."}      |
| `files` invalid token                                                             | 400 Bad Request   | 'files': {'file\_slug': \["Invalid token /token/."] }                           |
| `files` invalid id                                                                | 400 Bad Request   | 'files': {'file\_slug': \["Invalid file\_id /id/."] }                            |
| `files` duplicates                                                                | 400 Bad Request   | {'files': \["'file\_slug' cannot contain duplicates."]}                         |
| Insufficient permissions                                                          | 403 Forbidden     | "detail": "You do not have permission to perform this action."                  |

### Field type Errors

| Cause                                                                                      | Response code   | Message                                                                                                                    |
|--------------------------------------------------------------------------------------------|-----------------|----------------------------------------------------------------------------------------------------------------------------|
| string is too long                                                                         | 400 Bad Request | "field\_{string}": \["Ensure this field has no more than {max} characters."]                                               |
| string is required                                                                         | 400 Bad Request | "field\_{string}": \["This field is required."]                                                                            |
| string is not unique                                                                       | 400 Bad Request | "field\_{string}": \["This field must be unique."]                                                                         |
| integer value is invalid                                                                   | 400 Bad Request | "field\_{integer}": \["A valid integer is required."]                                                                      |
| integer is required                                                                        | 400 Bad Request | "field\_{integer}": \["This field is required."]                                                                           |
| integer value is below the limit                                                           | 400 Bad Request | "field\_{integer}": \["Ensure this value is greater than or equal to {min}."]                                              |
| integer value is above the limit                                                           | 400 Bad Request | "field\_{integer}": \["Ensure this value is less than or equal to {max}."]                                                 |
| integer is not unique                                                                      | 400 Bad Request | "field\_{integer}": \["This field must be unique."]                                                                        |
| float value is invalid                                                                     | 400 Bad Request | "field\_{float}": \["A valid number is required."]                                                                         |
| float is required                                                                          | 400 Bad Request | "field\_{float}": \["This field is required."]                                                                             |
| float value is below the limit                                                             | 400 Bad Request | "field\_{float}": \["Ensure this value is greater than or equal to {min}."]                                                |
| float value is above the limit                                                             | 400 Bad Request | "field\_{float}": \["Ensure this value is less than or equal to {max}."]                                                   |
| float is not unique                                                                        | 400 Bad Request | "field\_{float}": \["This field must be unique."]                                                                          |
| bool value is invalid                                                                      | 400 Bad Request | "field\_{bool}": \["Must be a valid boolean."]                                                                             |
| bool value different than required                                                         | 400 Bad Request | "field\_{bool}": \["Field contains a value other than required."]                                                          |
| email value is invalid                                                                     | 400 Bad Request | "field\_{email}": \["Enter a valid email address."]                                                                        |
| email is required                                                                          | 400 Bad Request | "field\_{email}": \["This field is required."]                                                                             |
| email value is above the limit                                                             | 400 Bad Request | "field\_{email}": \["Ensure this field has no more than {max} characters."]                                                |
| email is not unique                                                                        | 400 Bad Request | "field\_{email}": \["This field must be unique."]                                                                          |
| phone value is invalid                                                                     | 400 Bad Request | "field\_{phone}": \["Enter a valid email address."]                                                                        |
| phone is required                                                                          | 400 Bad Request | "field\_{phone}": \["This field is required."]                                                                             |
| phone value is above the limit                                                             | 400 Bad Request | "field\_{phone}": \["Ensure this field has no more than {max} characters."]                                                |
| phone is not unique                                                                        | 400 Bad Request | "field\_{phone}": \["This field must be unique."]                                                                          |
| date value is in wrong format                                                              | 400 Bad Request | "field\_{date}": \["Date has wrong format. Use one of these formats instead: YYYY-MM-DD."]                                 |
| date is required                                                                           | 400 Bad Request | "field\_{date}": \["This field is required."]                                                                              |
| date is not unique                                                                         | 400 Bad Request | "field\_{date}": \["This field must be unique."]                                                                           |
| time value is in wrong format                                                              | 400 Bad Request | "field\_{time}": \["Time has wrong format. Use one of these formats instead: hh:mm\[:ss\[.uuuuuu]]."]                    |
| time is required                                                                           | 400 Bad Request | "field\_{time}": \["This field is required."]                                                                              |
| time is not unique                                                                         | 400 Bad Request | "field\_{time}": \["This field must be unique."]                                                                           |
| datetime value is in wrong format                                                          | 400 Bad Request | "field\_{datetime}": \["Datetime has wrong format. Use one of these formats instead: YYYY-MM-DDThh:mm\[:ss\[.uuuuuu]]\[+HH:MM |-HH:MM|Z]."]|
| datetime is required                                                                       | 400 Bad Request | "field\_{datetime}": \["This field is required."]                                                                          |
| datetime is not unique                                                                     | 400 Bad Request | "field\_{datetime}": \["This field must be unique."]                                                                       |
| enum value is invalid                                                                      | 400 Bad Request | "field\_{enum}": \["{value} is not a valid choice.]                                                                        |
| enum is required                                                                           | 400 Bad Request | "field\_{enum}": \["This field is required."]                                                                              |
| enum is not unique                                                                         | 400 Bad Request | "field\_{enum}": \["This field must be unique."]                                                                           |
| set value is invalid                                                                       | 400 Bad Request | "field\_{set}": \["Value must be valid Set."]                                                                              |
| set is not a list                                                                          | 400 Bad Request | "field\_{set}": \["Value must be valid Set."]                                                                              |
| set value is below the limit                                                               | 400 Bad Request | "field\_{set}": \["The number of elements must be greater than or equal to {min}."]                                        |
| set value is above the limit                                                               | 400 Bad Request | "field\_{set}": \["The number of elements must be less than or equal to {max}."]                                           |
| url value is invalid                                                                       | 400 Bad Request | "field\_{url}": \["Enter a valid URL."]                                                                                    |
| url is required                                                                            | 400 Bad Request | "field\_{url}": \["This field is required."]                                                                               |
| url value is above the limit                                                               | 400 Bad Request | "field\_{url}": \["Ensure this field has no more than {max} characters."]                                                  |
| url is not unique                                                                          | 400 Bad Request | "field\_{url}": \["This field must be unique."]                                                                            |
| json value is invalid                                                                      | 400 Bad Request | "field\_{json}": \["Value must be valid JSON."]                                                                            |
| json is required                                                                           | 400 Bad Request | "field\_{json}": \["This field is required."]                                                                              |
| json value is above the limit                                                              | 400 Bad Request | "field\_{json}": \["Ensure this field has no more than {max} characters."]                                                 |
| json is not unique                                                                         | 400 Bad Request | "field\_{json}": \["This field must be unique."]                                                                           |
| document value is invalid                                                                  | 400 Bad Request | "field\_{document}": \["Value must be valid list."]                                                                        |
| document token is invalid                                                                  | 400 Bad Request | "field\_{document}": \["Invalid token {token}."]                                                                           |
| document number files is above the limit                                                   | 400 Bad Request | "field\_{document}": \["The number of elements must be less than or equal to {max}."]                                      |
| user is not a object                                                                       | 400 Bad Request | "field\_{user}": \["Expected a dictionary of items but got type "{type}"."]                                              |
| user value  not in the class field definition or not existing user ID (users)              | 400 Bad Request | "field\_{user}": \[""{value}" is not a valid choice."]                                                                   |
| user value is below the limit (users)                                                      | 400 Bad Request | "field\_{user}": \["The number of users elements must be greater than or equal to {min}."]                                 |
| user value is above the limit (users)                                                      | 400 Bad Request | "field\_{user}": \["The number of users elements must be less than or equal to {max}."]                                    |
| user value is not an array of integers (users)                                             | 400 Bad Request | "field\_{user}": {"users": \["The value must be an array of integers."]}                                                   |
| user value  not in the class field definition or not existing users group ID (user\_groups) | 400 Bad Request | "field\_{user}": \[""{value}" is not a valid choice."]                                                                   |
| user value is below the limit (user\_groups)                                                | 400 Bad Request | "field\_{user}": \["The number of user\_groups elements must be greater than or equal to {min}."]                           |
| user value is above the limit (user\_groups)                                                | 400 Bad Request | "field\_{user}": \["The number of user\_groups elements must be less than or equal to {max}."]                              |
| user value is not an array of integers (user\_groups)                                       | 400 Bad Request | "field\_{user}": {"user\_groups": \["The value must be an array of integers."]}                                             |
| user field - attempted to pass values in the user\_groups field when it was not permitted   | 400 Bad Request | "field\_{user}":  \["user\_groups field is not allowed."]                                                                   |
| user field - attempted to pass values in the users field when it was not permitted         | 400 Bad Request | "field\_{user}": \["users field is not allowed."]                                                                          |

## GET /api/tasks/`task_id`/class-fields/

Lists Object Class fields used in the task.

### Permissions

Requires `authentication` and `view` for a specific task and `task_type = tt_object_record_update`.

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| task\_id        | id      |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/tasks/`task_id`/class-fields/
```

### Response

| Key             	| Type        	| Notes                                                                             	|
|-----------------	|-------------	|-----------------------------------------------------------------------------------	|
| limit           	| int         	|                                                                                   	|
| offset          	| int         	|                                                                                   	|
| total\_count     	| int         	| Total number of forms visible to the user (based on permissions).                 	|
| filtered\_count  	| int         	| Number of forms visible to the user (based on permissions) with filters applied.  	|
| next            	| url / null  	| Next page URL (null if there is no next page)                                     	|
| previous        	| url / null  	| Previous page URL (null if there is no previous page)                             	|
| results         	| Array       	| List of fields                                                  |

### Response example

* Status `200 OK`
* Body

```json
{ 
  "limit": 100, 
  "offset": 0, 
  "filtered_count": 3, 
  "total_count": 3, 
  "next": null, 
  "previous": null, 
  "results": [ 
    { 
      "id": 13, 
      "label": "JSON", 
      "type": "json", 
      "alias": "json", 
      "is_required": false, 
      "is_unique": false, 
      "is_identifier": false, 
      "sort_ok": false,
      "order": 0, 
      "extras": {} 
    }, 
    { 
      "id": 12, 
      "label": "URL", 
      "type": "url", 
      "alias": "url", 
      "is_required": false, 
      "is_unique": false, 
      "is_identifier": false, 
      "sort_ok": false,
      "order": 1, 
      "extras": {} 
    }, 
    { 
      "id": 11, 
      "label": "Time", 
      "type": "time", 
      "alias": "time", 
      "is_required": false, 
      "is_unique": false, 
      "is_identifier": false, 
      "sort_ok": false,
      "order": 2, 
      "extras": {}
    },
    { 
      "id": 14, 
      "label": "User", 
      "type": "user", 
      "alias": "user", 
      "is_required": false, 
      "is_unique": false, 
      "is_identifier": false,
      "sort_ok": false,
      "order": 3, 
      "extras": {
        "options" {
            "users": [1],
            "user_groups": []
         }
        "allow_members_selection": false
        "allow_sync": false
      } 
    }, 
  ] 
} 
```

### Sorting

Not supported

### Filtering

| Parameter          | Type       | Example                                                              |
|--------------------|------------|----------------------------------------------------------------------|
| id                 | int + enum | {build}/api/object-records/?id\_\_in=1,2                               |

### Errors

| Error                     	| Response code  	| Message                                                         	|
|---------------------------	|----------------	|-----------------------------------------------------------------	|
| Given {task\_id} is for task of different task\_type than tt\_object\_record\_update  	| 404 Not Found  	|   	        |
| Requesting user is authorized but without view perm for tasks resource  	       | 403 Forbidden  	| "detail": "You do not have permission to perform this action."  	|
| Requesting user is not authenticated                                          | 401 Unauthorized  |   	        |

## OPTIONS /api/tasks/`task_id`/stages/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Request Method: OPTIONS
Content-Type: application/json
Location: /api/tasks/1/stages/
Authorization: JWT access_token
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "details": {
        "schema": [
            {
                "alias": "owner",
                "type": "user",
                "required": false
            }
        ]
    }
}
```

## POST /api/tasks/`task_id`/stages/`stage_id`/assignees/users/

Assign additional users to stage 1 of a Task

### Permissions

Requires `authentication`, and `task.assign` permissions.

### Validations

* Invalid task\_id
* Invalid payload schema
* list is empty
* list contains different type than integer
* Exceeded max batch size
* Insufficient permissions
* 1TC user sent in request's body

### Request

* Headers

```
Request Method: POST
Content-Type: application/json
Location: /api/tasks/1/stages/stage_1/assignees/users/
Authorization: JWT access_token
```

* Body

### Sample request body

```json
   [user_id_1, user_id_2]
```

### Response

| Key   | Type  | Notes                  |
|-------|-------|------------------------|
| users | Array | Array of users objects |

* Successful status `201 Created`
* Response body schema

```json
[
   {
      "name": <string>,
      "status": <string>,
      "assignees":{
         "users":[
            {
               "id": <user_id>,
               "first_name": <string>,
               "last_name": <string>,
               "username": <string>,
               "company_name": <string>,
               "account_type": <enum>
            }
         ]
      },
      "owner":{
         "id": <user_id>,
         "first_name": <string>,
         "last_name": <string>,
         "username": <string>,
         "company_name": <string>,
         "account_type": <enum>
      }
   }
]
```

### Errors

| Error                                                                                     | Response code     | Message                                                                                                      |
|-------------------------------------------------------------------------------------------|-------------------|--------------------------------------------------------------------------------------------------------------|
| Insufficient permissions                                                                  | 403 Forbidden     | "detail": "You do not have permission to perform this action."                                               |
| Invalid task\_id                                                                           | 404 Not Found     | "detail": \["Not found."]                                                                                   |
| Invalid payload schema                                                                    | 400 Bad Request   | "detail": \["Invalid payload schema"]                                                                       |
| list is empty                                                                             | 400 Bad Request   | "detail": \["This list of assignees may not be empty."]                                                     |
| list contains different type than integer                                                 | 400 Bad Request   | "detail": \["Incorrect type. Expected pk value, received {type}."]                                          |
| User with given ID does not exist                                                         | 400 Bad Request   | "detail": \["Invalid pk "{id}" - object does not exist."]                                                 |
| Exceeded max batch size                                                                   | 400 Bad Request   | "detail": \["Up to {BATCH\_LIMIT} items allowed."]                                                           |
| Exceeded max number of standard assignees                                                 | 400 Bad Request   | "detail": \["Limit of 100 standard assignees has been exceeded."]                                           |
| 1TC user sent in request's body                                                           | 400 Bad Request   | "detail": \["1 Time Completion users are not allowed."]                                                     |
| 1TC user sent when group added as assignees                                               | 400 Bad Request   | "detail": \["1 Time Completion user is not allowed because there is at least one group added as assignees."]|
| Request user does not have "users.list" permission for some users passed in the payload   | 400 Bad Request   | “detail”: \["You do not have permission to assign user "{user\_id}" to the task "{task\_id}"."]               |

## DELETE /api/tasks/`task_id`/stages/`stage_id`/assignees/users/

Unassign users from stage 1 of a Task

### Permissions

Requires `authentication`, and `task.assign` permissions.

### Request

* Headers

```
Request Method: DELETE
Content-Type: application/json
Location: /api/tasks/1/stages/stage_1/assignees/users/
Authorization: JWT access_token
```

* Body

### Sample request body

```json
  [user_id_1, user_id_2]
```

### Response

* Successful status `204 NO CONTENT`

### Errors

| Error                                             | Response code   | Message                                                            |
|---------------------------------------------------|-----------------|--------------------------------------------------------------------|
| Insufficient permissions                          | 403 Forbidden   | "detail": "You do not have permission to perform this action."     |
| Invalid task\_id                                   | 404 Not Found   | "detail": \["Not found."]                                         |
| Invalid payload schema                            | 400 Bad Request | "detail": \["Invalid payload schema"]                             |
| "users" list is empty                             | 400 Bad Request | "detail": \["This list of assignees may not be empty."]           |
| "users" list contains different type than integer | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]|
| Exceeded max batch size                           | 400 Bad Request | "detail": \["Up to {BATCH\_LIMIT} items allowed."]                 |

## OPTIONS /api/tasks/`task_id`/stages/`stage_id`/assignees/users/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Request Method: OPTIONS
Content-Type: application/json
Location: /api/tasks/1/stages/stage_1/assignees/users/
Authorization: JWT access_token
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "batch": {
        "type": "set",
        "required": true,
        "autocomplete": "/api/users/autocomplete/?text__icontains="
    },
    "restrictions": {
        "limit_assignees_standard": 100,
        "limit_assignees_one_time_completion": 1,
        "limit_items_in_batch": 100
    }
}
```

## POST /api/tasks/`task_id`/stages/`stage_id`/assignees/user-groups/

Assign users group to stage 1 of a Task

### Permissions

Requires `authentication`, and `task.assign` permissions.

### Validations

* Invalid task\_id
* Invalid payload schema
* Users group with given ID does not exist
* "user\_groups" list is empty
* "user\_groups" list contains different type than integer
* "user\_groups" is passed when 1TC user is already an assignee
* Exceeded max batch size
* Insufficient permissions to specific Users Group

### Request

* Headers

```
Request Method: POST
Content-Type: application/json
Location: /api/tasks/1/stages/stage_1/assignees/user-groups/
Authorization: JWT access_token
```

* Body

### Sample request body

```json
    [group_id_1, group_id_2]
```

### Response

| Key         | Type  | Notes                        |
|-------------|-------|------------------------------|
| user-groups | Array | Array of users-group objects |

* Successful status `201 Created`
* Response body schema

```json
[
   {
      "name": <string>,
      "status": <string>,
      "assignees":{
         "user_groups":[
            {
               "id": <group_id>,
               "name": <string>
            }
         ]
      },
      "owner":{
         "id": <user_id>,
         "first_name": <string>,
         "last_name": <string>,
         "username": <string>,
         "company_name": <string>,
         "account_type": <enum>
      }
   }
]
```

### Errors

| Error                                                        | Response code   | Message                                                                             |
|--------------------------------------------------------------|-----------------|-------------------------------------------------------------------------------------|
| Insufficient permissions                                     | 403 Forbidden   | "detail": "You do not have permission to perform this action."                      |
| Invalid task\_id                                              | 404 Not Found   | "detail": \["Not found."]                                                          |
| Invalid payload schema                                       | 400 Bad Request | "detail": \["Invalid payload schema"]                                              |
| "user\_groups" is passed when 1TC user is already an assignee | 400 Bad Request | "detail": \["One 1 Time Completion user already in assignees.]                     |
| "user\_groups" list is empty                                  | 400 Bad Request | "detail": \["This list of assignees may not be empty."]                            |
| "user\_groups" list contains different type than integer      | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]                 |
| Users Group with given ID does not exist                     | 400 Bad Request | "detail": \["Invalid pk "{id}" - object does not exist."]                        |
| Insufficient permissions to Users Group                      | 400 Bad Request | "detail": \["Invalid pk "{id}" - You do not have permission for this Group."]    |
| Exceeded max batch size                                      | 400 Bad Request | "detail": \["Up to 10 items allowed."]                                             |
| Exceeded max number of Users Group assignees                 | 400 Bad Request | "detail": \["Limit of 10 group assignees has been exceeded."]                      |

## DELETE /api/tasks/`task_id`/stages/`stage_id`/assignees/user-groups/

Unassign user groups from stage 1 of a Task

### Permissions

Requires `authentication`, and `task.assign` permissions.

### Request

* Headers

```
Request Method: DELETE
Content-Type: application/json
Location: /api/tasks/1/stages/stage_1/assignees/user-groups/
Authorization: JWT access_token
```

* Body

### Sample request body

```json
   [group_id_1, group_id_2]
```

### Response

* Successful status `204 NO CONTENT`

### Errors

| Error                                                   | Response code   | Message                                                            |
|---------------------------------------------------------|-----------------|--------------------------------------------------------------------|
| Insufficient permissions                                | 403 Forbidden   | "detail": "You do not have permission to perform this action."     |
| Invalid task\_id                                         | 404 Not Found   | "detail": \["Not found."]                                         |
| Invalid payload schema                                  | 400 Bad Request | "detail": \["Invalid payload schema"]                             |
| "user-groups" list is empty                             | 400 Bad Request | "detail": \["This list of assignees may not be empty."]           |
| "user-groups" list contains different type than integer | 400 Bad Request | "detail": \["Incorrect type. Expected pk value, received {type}."]|
| Exceeded max batch size                                 | 400 Bad Request | "detail": \["Up to {BATCH\_LIMIT} items allowed."]                 |

## OPTIONS /api/tasks/`task_id`/stages/`stage_id`/assignees/user-groups/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Request Method: OPTIONS
Content-Type: application/json
Location: /api/tasks/1/stages/stage_1/assignees/user-groups/
Authorization: JWT access_token
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "batch": {
        "type": "set",
        "required": true,
        "autocomplete": "/api/user-groups/autocomplete/?text__icontains="
    },
    "restrictions": {
        "limit_items": 10,
        "limit_items_in_batch": 10
    }
}
```

## PATCH /api/task/`task_id`/stages/`stage_id`/owner/

Creates/Modified task owner.

### Permissions

Requires `authentication`, `task.assign` and `task.complete` permissions.

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| task\_id        | id      |             |
| stage\_id       | id      |             |

* Body parameters

| Key           | Type | Required | Notes |
|---------------|------|----------|-------|
| owner         | int  | True     |       |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
PATCH /api/task/`task_id`/stages/`stage_id`/owner/me/

{
  "owner": <int>,
}
```

### Validations

* owner
  * Valid user ID with `task.complete` permission.

### Sample request body

```json
{
  "owner": <int>
}
```

### Response

| Key               | Type | Notes                               |
|-------------------|------|-------------------------------------|
| name              | str  | Stage name. Ex. `stage_1`           |
| status            | str  | Task status                         |
| owner             | user |                                     |

* Successful status `200 OK`
* Response body schema

```json
{
    "name": "stage_1",
    "status": "outstanding",
    "owner": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    }
}
```

### Errors

| Cause                                                                                          | Response code    | Message                                                                                             |
|------------------------------------------------------------------------------------------------|------------------|-----------------------------------------------------------------------------------------------------|
| “owner” is missing                                                                             | 400 Bad Request  | “owner”: \[“This field is required.”]                                                              |
| “owner” is not an integer                                                                      | 400 Bad Request  | “owner”: \["Incorrect type. Expected pk value, received {type}."]                                  |
| Invalid user ID                                                                                | 400 Bad Request  | “owner”: \["Invalid pk {id} - object does not exist."]                                             |
| Request user does not have "users.list" permission for the user to be set as task stage owner  | 400 Bad Request  | “owner”: \["You do not have permission to make user "{user\_id}" the owner of Task "{task\_id}"."]   |
| “owner” does not have “complete task” permission and assignee limit exceed                     | 400 Bad Request  | “detail”: "Limit of 100 standard assignees has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED"  |
| Stage is completed                                                                             | 400 Bad Request  | “detail”: \["Stage {stage name} is completed. Owner cannot be changed.”]                           |
| Insufficient permissions                                                                       | 403 Forbidden    | "detail": "You do not have permission to perform this action."                                      |

## PATCH /api/task/`task_id`/stages/`stage_id`/owner/me/

Assigning the caller as task owner.

### Permissions

Requires `authentication` and `task.complete` permissions.

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| task\_id        | id      |             |
| stage\_id       | id      |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
PATCH /api/task/`task_id`/stages/`stage_id`/owner/me/
```

### Response

| Key               | Type | Notes                               |
|-------------------|------|-------------------------------------|
| name              | str  | Stage name. Ex. `stage_1`           |
| status            | str  | Task status                         |
| owner             | user |                                     |

* Successful status `200 OK`
* Response body schema

```json
{
    "name": "stage_1",
    "status": "outstanding",
    "owner": {
        "id": 2,
        "first_name": "ALX",
        "last_name": "Developer",
        "username": "alx.dev@autologyx.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    }
}
```

### Errors

| Cause                                          | Response code    | Message                                                                             |
|------------------------------------------------|------------------|-------------------------------------------------------------------------------------|
| Stage is completed                             | 400 Bad Request  | “detail”: \["Stage {stage name} is completed. Owner cannot be changed.”]           |
| Insufficient permissions                       | 403 Forbidden    | "detail": "You do not have permission to perform this action."                      |

## DELETE /api/task/`task_id`/stages/`stage_id`/owner/me/

API for removing the caller as task owner.

### Permissions

Requires `authentication` and `task.complete` permissions.

### Request

* URL parameters

| Key            | Type    | Notes       |
|----------------|---------|-------------|
| task\_id        | id      |             |
| stage\_id       | id      |             | -->

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
DELETE /api/task/`task_id`/stages/`stage_id`/owner/me/
```

### Response

* Successful status `204 No Content`

### Errors

| Error                     | Response code   | Message                                                        |
|---------------------------|-----------------|----------------------------------------------------------------|
| Insufficient permissions  | 403 Forbidden   | "detail": "You do not have permission to perform this action." |
| Caller is not the owner   | 400 Bad Request | "detail": \["You are not the owner of {stage name} stage.”]   |

## GET /api/tasks/1tc/`token`/

### Permissions

Requires valid `token` matching one time completion user and task. Token is sent by email message to a user on assigning him to a task (as task assignee).

### Request

* URL parameters

| Key   | Type   | Notes       |
|-------|--------|-------------|
| token | string |             |

* Headers

```
Content-Type: application/json
```

* Schema

```json
GET /api/tasks/1tc/`token`/
```

### Response

| Key               | Type    | Notes                                                                            |
|-------------------|---------|----------------------------------------------------------------------------------|
| id                | uuid    |                                                                                  |
| name              | string  |                                                                                  |
| task\_template     | int     |                                                                                  |
| object\_record     | int     |                                                                                  |
| instructions      | string  |                                                                                  |
| configuration     | array   | Copy of [Task template](/api/catalyst/resources/tasks/task-templates) object                              |
| status            | enum    |                                                                                  |
| due\_date          | date    |                                                                                  |
| response          | Array   | [Response](#response-response-array) result                            |
| \_meta             | Object  | [\_meta](#response-meta-object) result. Does not contain `permissions`. |

### Response `response` array

| Key             | Type          | Notes      |
|-----------------|---------------|------------|
| id              | uuid          |            |
| state           | enum          |            |
| data            | Array         |            |
| files           | Array         |            |
| modified\_at     | Array         |            |
| modified\_by     | user          |            |
| \_meta.labels    | Object        |            |

### Response `_meta` object

| Key           | Type   | Notes |
|---------------|--------|-------|
| labels.status | enum   |       |

### Response example

* Status `200 OK`
* Body

```json
{
    "id": 58,
    "name": "Some task",
    "task_template": 37,
    "object_record": 191211,
    "instructions": "",
    "configuration": {
        "expiry": null,
        "renewals": [],
        "reminders": [],
        "expiry_day": null,
        "complete_by": "user_defined",
        "description": "",
        "expiry_date": null,
        "instructions": "",
        "plugin_config": {
            "_meta": {
                "labels": {
                    "task_type": "Object Record update",
                    "object_class": "some class"
                }
            },
            "prompt": "",
            "task_type": "tt_object_record_update",
            "object_class": 9542,
            "allow_comment": false,
            "configuration": {},
            "approval_required": false,
            "approval_conditions": [],
            "object_class_fields": [
                41,
                43,
                44
            ]
        },
        "task_creation": "manual",
        "complete_by_date": null,
        "expiry_time_unit": null,
        "expiry_time_value": null,
        "expiry_time_rel_to": null,
        "expiry_periodic_day": null,
        "complete_by_time_unit": null,
        "expiry_periodic_month": null,
        "complete_by_time_value": null
    },
    "status": "outstanding",
    "due_date": null,
    "response": {
        "id": 38,
        "state": "initial",
        "data": {
            "field_enum": null
        },
        "modified_at": "2023-02-16T11:09:19.958434+01:00",
        "modified_by": null,
        "_meta": {
            "labels": {
                "state": "initial",
                "files": {
                    "177": {
                        "name": "doc.docx",
                        "url": "https://alx.test/api/files/response/file/18d5168c-c058-4d95-8ef8-a2bf89f7bd40/doc.docx",
                        "size": "111303",
                        "type": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
                    }
                }
            }
        },
        "files": {
            "field_doc1": [
                177
            ]
        }
    },
    "_meta": {
        "labels": {
            "status": "Outstanding"
        }
    }
}
```

### Sorting

Not supported

### Filtering

Not supported

### Errors

| Error                         | Response code   | Message                                                                   |
|-------------------------------|-----------------|---------------------------------------------------------------------------|
| Task has been reassigned.     | 400 Bad Request | "detail": "Task no longer available.", "error\_code": "ERR\_INVALID\_TOKEN"  |
| Task has been completed.      | 400 Bad Request | "detail": "Task no longer available.", "error\_code": "ERR\_INVALID\_TOKEN"  |
| Task has been deleted.        | 403 Forbidden   | "detail": "You do not have permission to perform this action."            |
| Token has been tampered with. | 403 Forbidden   | "detail": "You do not have permission to perform this action."            |

## GET /api/tasks/1tc/`token`/class-fields/

Returns class fields used in specific Update Object Record task.
`token` contains task's id.

### Permissions

Requires valid `token` matching one time completion user and task.

### Request

* URL parameters

| Key   | Type   | Notes       |
|-------|--------|-------------|
| token | string |             |

* Headers

```
Content-Type: application/json
```

* Schema

```json
GET /api/tasks/1tc/`token`/class-fields/
```

### Response

| Key            | Type       | Notes                                                                           |
|----------------|------------|---------------------------------------------------------------------------------|
| limit          | int        |                                                                                 |
| offset         | int        |                                                                                 |
| total\_count    | int        | Total number of fields visible to the user.                                     |
| filtered\_count | int        | Number of fields visible to the user with filters applied.                      |
| next           | url / null | Next page URL (null if there is no next page)                                   |
| previous       | url / null | Previous page URL (null if there is no previous page)                           |
| results        | Array      | List of fields used in specific Update Object Record task |

### Response example

* Status `200 OK`
* Body

```json
{ 
  "limit": 100, 
  "offset": 0, 
  "filtered_count": 3, 
  "total_count": 3, 
  "next": null, 
  "previous": null, 
  "results": [ 
    { 
      "id": 13, 
      "label": "JSON", 
      "type": "json", 
      "alias": "json", 
      "is_required": false, 
      "is_unique": false, 
      "is_identifier": false, 
      "order": 0, 
      "extras": {} 
    }, 
    { 
      "id": 12, 
      "label": "URL", 
      "type": "url", 
      "alias": "url", 
      "is_required": false, 
      "is_unique": false, 
      "is_identifier": false, 
      "order": 1, 
      "extras": {} 
    }
  ] 
} 
```

### Sorting

Not supported

### Filtering

List can be Filtered by `id` parameter.

| Parameter          | Type       | Example                                                          |
|--------------------|------------|------------------------------------------------------------------|
| id                 | int + enum | {build}/api/tasks/1tc/4b48-1m-736...b86/class-fields/?id\_\_in=1,2 |

Allowed predicates:

| Predicate | Query param | Allowed value  |
|-----------|-------------|----------------|
| =         | id=         | int            |
| !=        | id!=        | int            |
| in        | id\_\_in=     | array of ints  |
| not in    | id\_\_in!=    | array of ints  |

### Errors

| Error                                   | Response code   | Message                                                                   |
|-----------------------------------------|-----------------|---------------------------------------------------------------------------|
| Task has been reassigned.               | 400 Bad Request | "detail": "Task no longer available.", "error\_code": "ERR\_INVALID\_TOKEN"  |
| Task has been completed.                | 400 Bad Request | "detail": "Task no longer available.", "error\_code": "ERR\_INVALID\_TOKEN"  |
| Task has been deleted.                  | 403 Forbidden   | "detail": "You do not have permission to perform this action."            |
| Token has been tampered with.           | 403 Forbidden   | "detail": "You do not have permission to perform this action."            |
| Task type is "Complete standalone form" | 404 Not Found   | "detail": "Not found."                                                    |

## POST /api/tasks/1tc/`token`/upload/

Uploads single file as temporary file to be used in other places in the ALX system.
Unique token is returned in a response, to identify file on backend side.
The token can be used for any compatible endpoint supporting uploaded files.

### References

* [File uploads](https://docs.autologyx.com/api/files.html#post-api-files-upload)

### Permissions

Requires valid `token` matching one time completion user and task. Token is sent by email message to a user on assigning him to a task (as task assignee).

### Request

* URL parameters

| Key   | Type   | Notes       |
|-------|--------|-------------|
| token | string |             |

* Body parameters

Request's body contains binary data of uploaded file.

* Headers

```
Content-Disposition: attachment; filename=<filename>
```

* Schema

```json
POST /api/tasks/1tc/`token`/upload/

<binary data>
```

### Validations

* [Allowed File Extensions](/api/catalyst/resources/files#allowed-file-extensions)
* Content-Disposition header:
  * filename is required
* Binary data:
  * cannot be empty
  * file extension should be allowed
  * max size 50 MB

### Response

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| token             | string   | Automatically generated by the backend. |

* Successful status `201 Created`
* Response body schema

```json
{
  "token": <string>
} 
```

### Errors

| Cause                                            | Response code    | Message                                                                                                         |
|--------------------------------------------------|------------------|-----------------------------------------------------------------------------------------------------------------|
| Binary data is empty                             | 400 Bad Request  | "detail": \["Empty content."]                                                                                  |
| Missing Content-Disposition header with filename | 400 Bad Request  | "detail": \["Missing filename. Request should include a Content-Disposition header with a filename parameter."]|
| Not allowed file extension                       | 400 Bad Request  | "detail": \["File extension “\<extension>” is not allowed. Allowed extensions are: \<allowed\_extensions>."]  |
| Task has been reassigned.                        | 400 Bad Request  | "detail": "Task no longer available.", "error\_code": "ERR\_INVALID\_TOKEN"                                        |
| Task has been completed.                         | 400 Bad Request  | "detail": "Task no longer available.", "error\_code": "ERR\_INVALID\_TOKEN"                                        |
| Size of file is too big                          | 400 Bad Request  | "detail": \["Max file size is 50.0 MB."]                                                                       |
| Task has been deleted.                           | 403 Forbidden    | "detail": "You do not have permission to perform this action."                                                  |
| Token has been tampered with.                    | 403 Forbidden    | "detail": "You do not have permission to perform this action."                                                  |
| Timeout                                          | 504 Timeout      |                                                                                                                 |

## POST /api/tasks/1tc/`token`/save/

Saves response for task before completing it.

### Permissions

Requires valid `token` matching one time completion user and task. Token is sent by email message to a user on assigning him to a task (as task assignee).

### Request

* URL parameters

| Key   | Type   | Notes       |
|-------|--------|-------------|
| token | string |             |

* Body parameters

| Key    | Type   | Notes                     |
|--------|--------|---------------------------|
| data   | json   | Structure contains fields |
| files  | Array  |                           |

Any parameter not listed above are silently ignored if passed.

* Headers

```
Content-Type: application/json
```

* Schema

```json
POST /api/tasks/1tc/`token`/save/

{
    "data": {
        "field_name": <str>,
        "field_number": <integer>,
        "field_some_date": <datetime>,
        "other_2": <str>,
    },
    "files": {
        "field_test_4": <document>
    },
}
```

Fields from above example depend on task template configuration.

### Response

| Key                | Type     | Notes                                   |
|--------------------|----------|-----------------------------------------|
| id                 | uuid     | Automatically generated by the backend. |
| state              | string   |                                         |
| data               | Object   |                                         |
| files              | Object   |                                         |
| modified\_at        | datetime |                                         |
| modified\_by        | user     |                                         |
| \_meta.labels.state | string   |                                         |
| \_meta.labels.files | Object   |                                         |

### Response example

* Status `201 CREATED`
* Body

```json
{
    "id": 1,
    "state": "saved",
    "data": {
        "field_name": "John",
        "field_surname": "Doe",
        "other_field": "Test"
    },
    "files": {
        "field_test_4": [1]
    },
    "modified_at": "2022-03-04T09:20:38.357221Z",
    "modified_by": {
        "id": 1,
        "first_name": "Firstname",
        "last_name": "Lastname",
        "username": "username",
        "company_name": "Company",
        "is_deleted": false
    },
    "_meta": {
        "labels": {
            "state": "Saved",
            "files": {
                  "file_list": [{"name": "file1.jpg",  "url": "http://test.test/api/files/response/file/4fef1510-7b0b-46fd-84d4-7b933d3b6f72/sample.docx"}]
           }
        }
    }
}
```

### Restriction

* Maximum number of fields: 2000.

### Errors

| Error                                                 | Response code     | Message                                                                                 |
|-------------------------------------------------------|-------------------|-----------------------------------------------------------------------------------------|
| Task has been reassigned.                             | 400 Bad Request   | "detail": "Task no longer available.", "error\_code": "ERR\_INVALID\_TOKEN"                |
| Task has been completed.                              | 400 Bad Request   | "detail": "Task no longer available.", "error\_code": "ERR\_INVALID\_TOKEN"                |
| Task has been deleted.                                | 403 Forbidden     | "detail": "You do not have permission to perform this action."                          |
| Token has been tampered with.                         | 403 Forbidden     | "detail": "You do not have permission to perform this action."                          |
| `files` invalid data                                  | 400 Bad Request   | "files": {"file\_slug": "Invalid data. Expected a list, but got /type/."}              |
| `files` invalid token                                 | 400 Bad Request   | "files": {"file\_slug": \["Invalid token /token/."] }                                   |
| `files` invalid id                                    | 400 Bad Request   | "files": {"file\_slug": \["Invalid file\_id /id/."] }                                    |
| `files` duplicates                                    | 400 Bad Request   | "files": \["file\_slug cannot contain duplicates."]                                     |
| `data` value is different type than an object or NULL | 400 Bad Request   | "data": {"non\_field\_errors": \["Invalid data. Expected a dictionary, but got /type/."]}|
| `data` contains more than 2000 items                  | 400 Bad Request   | "data": {"non\_field\_errors": \["Up to 2000 items allowed."]}                           |

## POST /api/tasks/1tc/`token`/complete/

Complete task.

### Permissions

Requires valid `token` matching one time completion user and task. Token is sent by email message to a user on assigning him to a task (as task assignee).

### Request

* URL parameters

| Key   | Type   | Notes       |
|-------|--------|-------------|
| token | string |             |

* Body parameters

| Key    | Type   | Notes                     |
|--------|--------|---------------------------|
| data   | json   | Structure contains fields |
| files  | Array  |                           |

Any parameter not listed above are silently ignored if passed.

* Headers

```
Content-Type: application/json
```

* Schema

```json
POST /api/tasks/1tc/`token`/complete/

{
    "data": {
        "field_name": <str>,
        "field_number": <integer>,
        "field_some_date": <datetime>,
        "other_2": <str>,
    },
    "files": {
        "field_test_4": <document>
    },
}
```

Fields from above example depend on task template configuration.

### Response

| Key                | Type     | Notes                                   |
|--------------------|----------|-----------------------------------------|
| id                 | uuid     | Automatically generated by the backend. |
| state              | string   |                                         |
| data               | Object   |                                         |
| files              | Object   |                                         |
| modified\_at        | datetime |                                         |
| modified\_by        | user     |                                         |
| \_meta.labels.state | string   |                                         |
| \_meta.labels.files | Object   |                                         |

### Response example

* Status `201 CREATED`
* Body

```json
{
    "id": 1,
    "state": "accepted",
    "data": {
        "field_name": "John",
        "field_surname": "Doe",
        "other_field": "Test"
    },
    "files": {
        "field_test_4": [1]
    },
    "modified_at": "2022-03-04T09:20:38.357221Z",
    "modified_by": {
        "id": 1,
        "first_name": "Firstname",
        "last_name": "Lastname",
        "username": "username",
        "company_name": "Company",
        "is_deleted": false
    },
    "_meta": {
        "labels": {
            "state": "Saved",
            "files": {
                  "file_list": [{"name": "file1.jpg",  "url": "http://test.test/api/files/response/file/4fef1510-7b0b-46fd-84d4-7b933d3b6f72/sample.docx"}]
           }
        }
    }
}
```

### Restriction

* Maximum number of fields: 2000.

### Errors

| Error                                                 | Response code     | Message                                                                                 |
|-------------------------------------------------------|-------------------|-----------------------------------------------------------------------------------------|
| Task has been reassigned.                             | 400 Bad Request   | "detail": "Task no longer available.", "error\_code": "ERR\_INVALID\_TOKEN"                |
| Task has been completed.                              | 400 Bad Request   | "detail": "Task no longer available.", "error\_code": "ERR\_INVALID\_TOKEN"                |
| Task has been deleted.                                | 403 Forbidden     | "detail": "You do not have permission to perform this action."                          |
| Token has been tampered with.                         | 403 Forbidden     | "detail": "You do not have permission to perform this action."                          |
| `files` invalid data                                  | 400 Bad Request   | "files": {"file\_slug": "Invalid data. Expected a list, but got /type/."}              |
| `files` invalid token                                 | 400 Bad Request   | "files": {"file\_slug": \["Invalid token /token/."] }                                   |
| `files` invalid id                                    | 400 Bad Request   | "files": {"file\_slug": \["Invalid file\_id /id/."] }                                    |
| `files` duplicates                                    | 400 Bad Request   | "files": \["/file\_slug/ cannot contain duplicates."]                                   |
| `data` value is NULL                                  | 400 Bad Request   | "detail": "This field may not be null."                                                 |
| `data` value is different type than an object or NULL | 400 Bad Request   | "data": {"non\_field\_errors": \["Invalid data. Expected a dictionary, but got /type/."]}|
| `data` contains more than 2000 items                  | 400 Bad Request   | "data": {"non\_field\_errors": \["Up to 2000 items allowed."]}                           |
| `data.field_/alias/` is missing                       | 400 Bad Request   | "data": {"/alias/": \["This field is required."]}                                      |

## GET /api/tasks/`task_id`/field/`field_alias`

Task response field details based on query parameters and caller permissions.

### Permissions

Requires `authentication` and `view` for a specific task.

### Request

* URL parameters

| Key         | Type | Notes                                       |
|-------------|------|---------------------------------------------|
| task\_id     | id   |                                             |
| field\_alias | slug | field\_alias used in a task configuration.   |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/tasks/1/field/field_user
```

### Response

| Key           | Type   | Notes                           |
|---------------|--------|---------------------------------|
| id            | id     | Task id                         |
| name          | string | Task name                       |
| task\_template | int    |                                 |
| object\_record | int    |                                 |
| field\_`alias` | Object | Structure depends on field type |
| \_meta         | Object |                                 |

### Response `_meta` array

| Key                           | Type   | Notes                             |
|-------------------------------|--------|-----------------------------------|
| id                            | uuid   |                                   |
| state                         | enum   |                                   |
| data                          | Array  |                                   |
| files                         | Array  |                                   |
| modified\_at                   | Array  |                                   |
| modified\_by                   | user   |                                   |
| \_meta.labels.status           | enum   |                                   |
| \_meta.labels.files            | Object |                                   |
| \_meta.users                   | Object | Returned only for User field type |
| \_meta.user\_groups             | Object | Returned only for User field type |
| \_meta.is\_min\_users\_fulfilled  | bool   | Returned only for User field type |

### Response example

* Status `200 OK`
* Body

```json
{
  "id": 1,
  "name": "Test",
  "task_template": 2,
  "object_record": 1,
  "field_user": {
     "users": [
       520,
       642
     ],
     "user_groups": [
       761
     ]
   },
  },
  "_meta": {
      "is_min_users_fulfilled": true,
      "users": {
        "520": {
          "id": 520,
          "first_name": "Kamille",
          "last_name": "Kohler",
          "username": "kamille.kohler11@example.com",
          "company_name": "",
          "is_deleted": false,
          "account_type": "full" 
        },
        "642": {
          "id": 642,
          "first_name": "a",
          "last_name": "b",
          "username": "ab@example.test",
          "company_name": "",
          "is_deleted": false,
          "account_type": "full" 
        },
     ...
      }
    },
      "user_groups": {
        "761": {
          "id": 761,
          "name": "54fd57" 
        }
      }
   }  
}
```

### Errors

| Error                                                                           | Response code      | Message                                                        |
|---------------------------------------------------------------------------------|--------------------|----------------------------------------------------------------|
| Given {task\_id} is for task of different task\_type than tt\_object\_record\_update | 404 Not Found      |                                                                |
| Given {task\_id} is not exists                                                   | 404 Not Found      |                                                                |
| Given {field\_alis} is not a class field                                         | 404 Not Found      |                                                                |
| Given {field\_alis} is not used in task configuration                            | 404 Not Found      |                                                                |
| Given {field\_alis} is not exists                                                | 404 Not Found      |                                                                |
| Requesting user is authorized but without view perm for tasks resource  	      | 403 Forbidden      | "detail": "You do not have permission to perform this action." |
| Requesting user is not authenticated                                            | 401 Unauthorized   |                                                                |

---

---
url: /knowledgebase/workspace/tasks.md
---

# Tasks

Tasks are used in Catalyst to assign, track, and complete pieces of work linked to records.

Depending on your permissions, you may be able to view tasks, complete tasks, reassign tasks, create manual tasks, and manage task-related activity from the Workspace.

The following articles explain the most common task-related actions and features.

## Working with tasks

### Finding and viewing tasks

* [Tasks list](/knowledgebase/workspace/tasks/tasks-list/)

These articles explain how to find tasks, open them, review task information, and complete assigned work.

### Creating and managing tasks

* [Creation of a manual task for an Object record](/knowledgebase/workspace/tasks/creation-of-a-manual-task-for-an-object-record/)

These articles explain how users can create manual tasks from a record and reassign existing tasks where permissions allow.

## Things to remember

* Task visibility depends on your permissions and assignment.
* Some tasks are created manually, while others are created automatically by workflows.
* Tasks are usually linked to an Object record.
* Completed tasks may still be available to view, depending on your permissions.
* Reassignment options depend on user visibility and access settings.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.2/tasks-for-one---time-completion-users.md
---

# Tasks for one - time completion users

We are thrilled to announce a major update to the Autologyx platform: one-time completion users can now complete tasks.

This new feature provides more flexibility in task delegation and streamlines the workflow, helping you get more done in less time.

![1TC\_creating\_task\_article.gif](/knowledgebase/images/img_10872389133597_1776895709.png)

**How it works**

Once a task has been assigned to a one-time completion user, they will receive an email containing a unique token for the task's form - either a Standalone form or Update record.

All they need to do is click the link provided in the email to be redirected to the task form.

One-time completion users can complete their assigned tasks without having to create an account or log in to the system, saving time and effort.

**On the form**

The user will find all the relevant information for the task, including:

* the due date, if applicable
* the task name
* instructions
* selected fields to be completed

The user can save their progress at any time by clicking the "Save progress" button, allowing them to edit the form at a later time if needed.

When the one-time completion user is ready to complete the task, they simply click the "complete" button.

![1TC\_completing\_task\_article.gif](/knowledgebase/images/img_10872389133597_1776895710.png)

**Why this is useful**

Tasks assigned to one-time completion users can be used to collect data from them or to update a specific record.

This feature makes it easy to delegate tasks to people who are not part of your team but who need to complete specific tasks.

We believe that this new feature will revolutionize the way you manage tasks and increase productivity.

---

---
url: /knowledgebase/workspace/tasks/tasks-list.md
---

# Tasks list

All users have access to the Tasks menu item in the Workspace left-hand menu.

Depending on their permissions, this list may be empty.

The list can also be empty if the user has applied filters that return no results.

Users who meet one of the following requirements can see tasks in this list:

* have a Super Admin account type
* are an Object class Owner
* have an Object class Permission Set with **Tasks > View all** enabled as a minimum
* are a Record Owner
* are a task assignee

## Default column headers

**ID** - a unique number that is automatically applied by the system when the task is created for an Object record.

**Name** - the name given to the task in the Task Template from which it was created.

**Status** - the current status of the task, which can be **Outstanding**, **Overdue**, or **Completed**.

**Actions** - depending on permissions and task status, available actions may include **View** or **Complete**.

### View

The **View** option appears for completed tasks.

A user can also view incomplete tasks, such as Outstanding or Overdue tasks, when they are not an assignee but have the **Tasks > View any tasks** permission enabled.

Double-clicking the task in the list also opens it in read-only mode.

When **View** is clicked, the original task page is shown in the main content area in read-only format. The page opens with a fly-out animation.

### Complete

The **Complete** option appears for incomplete tasks, such as Outstanding or Overdue tasks, when:

* the user is the assignee of the task
* the user is not the assignee but has the **Tasks > Complete any tasks** permission enabled

When **Complete** is clicked, the edit task response page opens in the main content area. The page opens with a fly-out animation.

## Additional column headers

**Completed** - displays the date and time the task was completed.

**Completed by** - displays the name of the user who completed the task.

**Template** - displays the ID of the Task Template from which the task was created.

**Record** - displays the ID of the Object record associated with the task.

### Due Date

Displays the due date calculated from the Due Date configuration in the Task Template Lifecycle settings.

![Tasks list showing the Due Date column](/knowledgebase/images/workspace/task-list-1.png)

### Expiry Date

Displays the date on which the task is due to expire.

This date is configured in the Task Template Lifecycle settings under **Expiry rules**.

![Tasks list showing the Expiry Date column](/knowledgebase/images/workspace/task-list-2.png)

In the example above, the task expires 12 months after it is completed.

## List features

The Tasks list includes all standard Catalyst list functionality, including:

* searching
* filtering
* sorting
* column configuration
* pagination

For more information, see [List pages](/knowledgebase/finding-your-way-around/ui-and-navigation/list-pages/).

## Things to remember

1. The Tasks list only displays tasks that your permissions allow you to see.
2. Filters can result in an empty list even when tasks exist.
3. Available actions depend on both your permissions and the task status.
4. Due Dates and Expiry Dates are configured in the Task Template Lifecycle settings.
5. Double-clicking a task opens it directly from the list.

---

---
url: /knowledgebase/release-notes/release-notes-1.5/templates-panel.md
---

# Templates panel

If you're manually creating and managing documents for your records, you know how time-consuming and tedious it can be to fill in the data, format the layout, and save the files. That's why we're excited to introduce our new feature: Templates panel, which allows you to swiftly generate customized documents based on pre-defined templates, saving valuable time and effort.

**Generate documents more efficiently**

Put an end to the laborious task of crafting documents from scratch or the monotonous job of copying and pasting data. The **Templates panel** empowers you to quickly generate documents for selected records. With just a click, you can create flawless documents based on templates. Autologyx automates the process, ensuring accuracy and efficiency.

![Templates1\_article.gif](/knowledgebase/images/img_12552239821725_1776895681.png)

**Streamline document management**

The **Templates panel** also helps streamline your document management process. By automatically saving the generated documents to the designated field within the corresponding record, you can effortlessly organize and access important files. No more searching through countless folders or struggling to locate specific documents. Everything is neatly stored and readily accessible whenever you need it.

![Templates2\_article.gif](/knowledgebase/images/img_12552239821725_1776895682.png)

**Try it today**

Try the **Templates panel** today and see how it simplifies your document creation, saves you time, and helps you focus on what truly matters. Whether you need to draft contracts, agreements, or legal briefs, this intuitive and user-friendly tool can become your go-to solution.

---

---
url: /api/event-history/resources/tenants.md
---
# Tenants

This page documents the tenant-management endpoints in the Event History API microservice.

The Event History service uses tenant records to map a client instance to its corresponding history database. During client creation in the main Autologyx system, a client-specific ClickHouse database is created for history data, and a matching tenant entry is created in the default ClickHouse database. That tenant entry is then used to resolve the correct client database from the `client_id`.

::: warning
This section documents technical and service-level Event History APIs and is intended for internal platform use and controlled engineering workflows. It should not be treated as part of the main general-purpose external Catalyst integration surface. This area is outside general support coverage, so please contact your Customer Success team if you need guidance.
:::

## API overview

This page covers the following endpoints:

* `POST /api/initialize-tenant`
* `DELETE /api/delete-tenant`

***

## POST /api/initialize-tenant

Initialises a tenant connection and creates the related tenant entry for the Event History service.

### Permissions

Requires `authentication`.

### Request

#### Headers

```text
Request Method: POST
Location: /api/initialize-tenant
Content-Type: application/json
X-API-Key: API_KEY
```

#### Body schema

```json
{
  "database_name": "<string>",
  "client_label": "<string>"
}
```

### Validations

* `database_name`
  * maximum length: 64 characters

### Response

#### Success

* Status: `201 Created`

| Key | Type | Notes |
|---|---|---|
| client\_id | string | Unique client identifier |
| client\_secret | string | Client secret key |
| database\_name | string | Database name created in the Event History microservice |

#### Response schema

```json
{
  "client_id": "<string>",
  "client_secret": "<string>",
  "database_name": "<string>"
}
```

### Errors

| Error | Response code | Message |
|---|---|---|
| Client tenant entry already exists | `400 Bad Request` | `"detail": "Client already exist."` |
| Wrong API key | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |
| Missing authorization header | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |
| Missing `database_name` parameter | `422 Unprocessable Entity` | `"detail": [{'loc': ['body', 'database_name'], 'msg': 'field required', 'type': 'value_error.missing'}]` |
| `database_name` is too long | `422 Unprocessable Entity` | `"detail": [{'loc': ['body', 'database_name'], 'msg': 'ensure this value has at most 64 characters', 'type': 'value_error.any_str.max_length', 'ctx': {'limit_value': 64}}]` |
| Missing `client_label` parameter | `422 Unprocessable Entity` | `"detail": [{'loc': ['body', 'client_label'], 'msg': 'field required', 'type': 'value_error.missing'}]` |

***

## DELETE /api/delete-tenant

Deletes the tenant connection and the related database. The tenant is identified through the `client_id` header.

### Permissions

Requires `authentication` and `client_id` in the request header.\
`client_id` must be a UUID v4 value.

### Request

#### Headers

```text
Request Method: DELETE
Location: /api/delete-tenant
Content-Type: application/json
X-API-Key: API_KEY
X-Client-Id: client_id
```

### Response

#### Success

* Status: `204 No Content`

### Errors

| Error | Response code | Message |
|---|---|---|
| Client ID header is missing | `400 Bad Request` | `"detail": "Unauthorized Client."` |
| Client from header does not match any tenant | `400 Bad Request` | `"detail": "Failed to connect to tenant db."` |
| AWS S3 error during file storage cleanup | `400 Bad Request` | `"detail": "Tenant:<client_name> files not deleted."` |
| Wrong API key | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |
| Missing authorization header | `401 Unauthorized` | `"detail": "Unauthorized API Key."` |
| Any request method other than DELETE is used | `405 Method Not Allowed` | |

---

---
url: /helps/environments/tenants.md
---
# Tenants

## Prerequisites

::: tip
Envirnoment is configured and ready for use
:::

* Kubernetes techops
* envirnment is configured and stable
* global database exists

**if not create global database with name from vault**

```sql
CREATE DATABASE <database_name>;
```

**deploy application and apply migrations on it**

```sh
python manage.py migrate
```

* domain is added to DNS's

## Create client in existed namespace

Below is an example of how you can create client in ALX platform when namespace and other builds already exists.

```sh
python manage.py create_client --subdomain=<subdomain> --client_name="Tester Master" --last_name="Last Name" --first_name="First Name" --email="test@test.test"
```

### Parameters:

1. `-subdomain` -> client subdomain for should be assigned to the client. (required)\`
2. Sample domain: subdomain.autologyx.com
3. `-client_name` -> Client display name, this name will be used to create unique client identifier as well. (required)
4. `-last_name` -> Client admin user detail. (optional)
5. `-first_name` -> Client admin user detail. (optional)
6. `-email` -> Client admin user unique identifier. (required)

## Create first client new namespace

Below is an example of how you can create client in ALX platform

1. Create new namespace, vault and other required stuff.
2. Create manually global database name

```sql
CREATE DATABASE <database_name>;
```

3. Deploy application on new namespace.
4. Initialize global database migrations on any pod

```sh
source /vault/secrets/env
python manage.py migrate
```

5. Now we are ready to create client. Follow steps described in
   [Create client in existed namespace](#create-client-in-existed-namespace)

### Parameters:

1. `database_name` -> global database name.\`

## List clients

Below is an example of how you check clients ids and statuses

```sh
python manage.py list_clients
```

### Response Sample:

```
CLIENT_ID: 1 DOMAIN: https://subdomain.domain.com STATUS: active
CLIENT_ID: 2 DOMAIN: https://subdomain2.domain.com STATUS: deactivated at: 2022-06-21 07:06:11.227451+00:00
```

## De-activate client

Below is an example of how you can de-activate client(instead of remove), something like pause

```sh
python manage.py deactivate_client --client_id=<client_id> --deactivation_purpose=<deactivation_purpose>
```

### Parameters:

1. `--client_id` -> client#id unique identifier from global database tenants\_client table. (required)
2. `--deactivation_purpose` -> Text. (optional)

## Activate client

Below is an example of how you can activate client previously de-activated

```sh
python manage.py activate_client --client_id=<client_id>
```

### Parameters:

1. `--client_id` -> client#id unique identifier from global database tenants\_client table. (required)
2. Edit this section
3. Delete client
4. Below is an example of how you can deactivate client(instead of remove)

```sh
python manage.py delete_client --client_id=<client_id>
```

Confirmation is required.

### Parameters:

1. `--client_id` -> client#id unique identifier from global database tenants\_client table. (required)
2. `--noinput` -> Skip confirmation for automation purposes.

## Delete client

Below is an example of how you can permanently remove client.

```sh
python manage.py delete_client --client_id=<client_id>
```

Confirmation is required.

⚠️WARNING⚠️ Client connection could be cached in this case reload application might be required!

### Parameters:

1. `--client_id `-> client#id unique identifier from global database tenants\_client table. (required)
2. `--noinput` -> Skip confirmation for automation purposes.

## Create empty client database

1. If You need deliver empty database structure first follow steps described in
   [Create client in existed namespace](#create-client-in-existed-namespace) for any already configured dev namespace.
2. Connect to database and execute dump command

```sh
PGPASSWORD=<db_pass> pg_dump -U <db_user> -h <db_host> -p <db_port> -d <db_name> > <dump_file_name>.sql
```

3. If database is dumped properly and build is not needed any more then probably [Delete client](#delete-client)
   might be required.

### Parameters:

1. `db_pass` -> database password
2. `db_user` -> database user
3. `db_port` -> database port
4. `db_name` -> database name

---

---
url: >-
  /knowledgebase/finding-your-way-around/some-things-you-might-find-useful/the-new-product-name-ui.md
---

# The new product name UI

---

---
url: /knowledgebase/record-and-task-forms/the-form-builder.md
---
# The Form Builder

This section explains how to design and configure forms in Autologyx.

The form builder is used to create practical, structured form experiences for users working with Object Records and Tasks. It helps builders decide how information should be captured, how fields should be arranged, and how a form should support the wider workflow and user experience.

Use this section to understand how forms are put together in practice, especially where users need to create, update, or complete information clearly and efficiently.

## What you will find in this section

* [Things to remember when designing an intake or other record creation form](/knowledgebase/record-and-task-forms/the-form-builder/things-to-remember-when-designing-an-intake-or-other-record-creation-form/)

## Notes

::: info
This section is focused on practical form design rather than the individual component settings inside the formbuilder.
:::

::: tip
When designing a form, think about what the user needs to understand, what information is essential, and how the form fits into the wider process.
:::

---

---
url: /knowledgebase/release-notes/release-notes-1.13/the-loop-actor.md
---

# The Loop actor

Legal operations are driven by lists: batches of contracts, file sets pulled from document management systems, arrays of matters from CRM exports. The Loop actor turns those lists into real, repeatable work - one item at a time, fully controlled and auditable. Use it to send each contract to DocuSign, create a tailored summary for every matter returned from Salesforce, or route iManage documents through an AI classifier that tags risk and files the result automatically.

Below you’ll find what you can connect it to, how to prepare your data, the filtering tools you get, how execution works for different downstream actors, and practical notes on error handling and merge fields. Read on to see how to turn lists into reliable workflows.

## Loop actor configuration

You can attach a Loop actor to one of three sources:

1. **Document Picker:** Loop over every selected document. Use this when users upload files or pick record-attached documents.
2. **API Call** (JSON array output): Loop over an array returned by a tested API Call. **Important:** the API Call must be tested first. Only tested calls will populate into the Loop configuration.
3. **Local Variable:** Loop over an array stored in a local variable. Again, the variable must be present and tested/saved so the Loop can read its structure.

## JSON Explorer - fast, visual array selection

When a tested API Call or Local Variable is connected, the Loop configuration loads the response and displays a readable JSON panel with a tree view below. Arrays are highlighted; click an array node and the JSON Path field fills automatically.

This visual approach keeps things safe and simple - no manual JSON pasting, no malformed paths. It makes it easy, even for users without technical training, to work with data coming in from services like Salesforce, iManage, or contract intelligence tools and to loop through each item without second-guessing what’s going on under the hood.

![loop 1.gif](../../../images2/zendesk_4901780528799_001_feb2234cd2e6.gif)

## Filters (API Call & Local Variable)

Once your array is selected, you’ll often want to narrow the scope; maybe you only want to loop through open matters or documents of a certain status.

For sources based on API Calls or Local Variables, the Loop actor lets you add filter conditions to refine what gets processed. Just define a property path (e.g.`loop_item.status`), choose a comparison operator (`equals` or `not equals`), and set the target value. Multiple filters can be combined using either “all following rules” or “any following rules” logic.

This is particularly useful when working with CRM exports, compliance systems, or dynamic data sources where only a subset of records require follow-up. With filtering in place, your loop stays focused and efficient, running only on the data that actually matters.

![loop filters.gif](../../../images2/zendesk_4901780528799_002_414dc3ad175b.gif)

## Trigger types - how Loop connects to the rest of your flow

The Loop actor exposes two trigger behaviours that control downstream orchestration:

**When Loop Item Processed**\
This trigger runs for each item. The Loop takes the next item, routes it down every connected branch that uses this trigger, waits for those branches to complete, then proceeds to the next item. Use it for per-item actions: one envelope per contract, one document per AI enrichment task, or creating one task per matter.

**When Actor Completed**\
This trigger fires after the entire loop finishes processing all items, that is, when all item-level branches have completed. It’s useful for a final summary, audit log update, or a single notification once the batch is done. **Note:** if branches include time-based delays, those delays will not hold up the Actor Completed trigger.

![loop triggers.gif](../../../images2/zendesk_4901780528799_003_8e4e6680108b.gif)

## Execution behaviour

While configuring a Loop actor is straightforward, it’s equally important to understand what actually happens when your loop runs: how data moves, what each iteration looks like, and how it behaves based on its source.

### General execution rules

1. **Sequential iteration:** Loop always processes the array in strict order: item 1, then 2, then 3, etc.
2. **Parallel branches per item:** If multiple branches start with **When Loop Item Processed**, *all* of them execute for each iteration.
3. **Failures skip only the current item:** If an iteration fails at any point (e.g., an API call returns an error), the Loop **skips that item** and moves to the next one.
4. **The “When Actor Completed” trigger only fires after all loop-driven branches finish.** But it **does not wait** for time-delayed triggers inside those branches.

Depending on whether your loop is connected to a Document Picker, API Call, or Local Variable, each item flows slightly differently through the system. Here’s what to expect in each scenario.

### Looping over documents (Document Picker source)

Each document selected becomes its own `loop_item`, giving you access to its metadata in the next actor. This setup is perfect when you need to send documents individually, for example, triggering one DocuSign envelope per contract, or routing each file through an AI review pipeline.

Loop items that represent documents carry a standard document object structure. For example:

```json
{  
  "id": 9698,  
  "name": "CONFIDENTIALITY AGREEMENT.docx",  
  "size": 32272,  
  "uuid": "81984d91-184d-4dc7-873a-df24cbec85fd",  
  "mimetype": "application/vnd.openxmlformats-officedocument.wordprocessingml.document",  
  "context\_id": "675fb09c-d42e-4bad-bf40-78783a867436"  
}
```

**Document objects always have the following properties:**

* **id** - Unique numeric identifier for the document in the system database
* **name** - Original filename of the uploaded document, including its extension
* **size** - File size in bytes representing the total size of the document
* **uuid** - Universally unique identifier (UUID) used for referencing and retrieving the document
* **mimetype** - MIME type specification that defines the document format
* **context\_id** - Security token that ties the document to a valid context in the platform; included as a security measure to ensure document references cannot be forged via merge-field manipulation

**In practice:**

* The file itself can be attached to any other actor that allows it, for example, in the Send Message or API Call actor.
* Document metadata is exposed via merge fields like {{loop\_item.name}}.

![loop variable.gif](../../../images2/zendesk_4901780528799_004_fa3b6ad5b987.gif)

### Looping over data from an API Call

APIs often return large, structured datasets - think of a list of matters from Salesforce, contacts from your compliance system, or document metadata from an external DMS. Looping lets you treat each of those entries as its own processing unit.

When your JSON includes something like:

```json
{
"matters": [
{"id": "M001", "status": "active"},
{"id": "M002", "status": "archived"}
]
}
```

You select the `matters` array in the Loop actor configuration, and each object becomes a `loop_item`.

**This lets you:**

* Pass individual records to an API Call actor (e.g. one API request per matter)
* Feed details into a DocAuto actor (e.g. generate a cover sheet per active case)
* Combine with Filters to only loop through, say, active or incomplete items

### Looping over data from a Local Variable

Sometimes you don’t fetch data from an external service; you already have it stored locally in a variable. As long as the value is an array, the Loop actor treats it the same way as any API response.

Each entry becomes a `loop_item`. From there, you can:

* Generate a document per client with DocAuto
* Send custom messages using {{loop\_item }} merge field
* Trigger tasks, approvals, or downstream logic per entry

## Merge field: {{loop\_item}}

At the core of every looped step is the {{loop\_item}} merge field - your handle on the data being processed in the current iteration. It only becomes available in actors directly downstream from a Loop actor, and always references the loop that precedes it.

It appears in the merge field dropdown as **"Loop Item"** and automatically reflects the shape of the source data.

![loop config.gif](../../../images2/zendesk_4901780528799_005_a30cfb3e2c4a.gif)

For document-based loops (from Document Picker), the structure is the same as the one that the document object has in the Document type variable.

You can use values like {{loop\_item.name}} to personalise filenames, API requests, or messages.

For JSON-based sources like API Calls or Local Variables, the `loop_item` reflects the shape of each object in the array. Nested fields are fully supported, so you can reference deeply embedded properties using standard dot notation, such as {{loop\_item.case.matter\_number}} or {{loop\_item.contacts\[1].email}}.

**You can apply {{loop\_item}} in:**

* **API Calls** → in request body or parameters (e.g. {{loop\_item.matter\_id}})
* **Send Message** → use in message body or file name (`"Attached: NDA for `{{loop\_item.client\_name}}`"`)
* **Local Variables** → extract or transform values ({{loop\_item.type}})
* **Doc Auto** → for dynamic templates (`Matter Overview - `{{loop\_item.title}}\`\`)
* **AI Actors** → in prompts or context (`"Analyze the risk level for `{{loop\_item.counterparty\_name}}`"`)

Keep in mind: if the actor isn’t connected to a Loop actor upstream, {{loop\_item}} will be empty.

## Summary

Legal workflows rarely revolve around single files or individual matters - they’re driven by lists. Dozens of contracts queued for signature. Client records fetched from Salesforce. Matter updates pulled from iManage. The Loop actor enables you to act on each item in those lists without repetitive configuration or brittle branching logic.

Sending out a batch of NDAs for signing, generating a unique summary per client engagement, or syncing only those records that meet specific criteria - the Loop actor handles each item individually. It understands your data structure, filters what matters, and provides granular control over how and when each item passes into the rest of your Catalyst workflow.

And because it integrates seamlessly with all core actors from API Calls to AI enrichment and Doc Auto - you’re free to build automations that match the complexity of legal operations, without compromising on clarity or reliability.

The outcome: consistency at scale, precision without friction, and automations that adapt to your data rather than forcing the reverse.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.6/the-new-type-of-variable-–-json-type.md
---

# The new type of variable – JSON type

In a data-driven world, having a flexible and efficient means to manage complex data structures is invaluable. That's where JSON type variables step into the light, opening the doors to a wide array of possibilities for data management.

![JSONVariable\_article.gif](/knowledgebase/images/img_14581416096925_1776895666.png)

**Handle larger volumes of data**

The ability to store up to 250,000 characters in a single variable expands your capacity to handle large volumes of data. This feature becomes particularly crucial in scenarios where detailed information, extensive records, or comprehensive datasets are involved.

**Integrate data across actors**

A JSON type variable seamlessly integrates with other actors, offering a dynamic flow of data across your sequences. This enhances your automation capabilities, allowing you to connect, transfer, and utilize data with ease.

As you embrace this innovative feature, consider the countless possibilities it unlocks for your automation processes. Upgrade your data with our spacious JSON variable solution!

---

---
url: /knowledgebase/system-configuration/theme.md
---
# Theme

**Browse the sections below:**

* [About The Theme](/knowledgebase/system-configuration/theme/about-the-theme/)
* [Creating The Theme](/knowledgebase/system-configuration/theme/creating-the-theme/)

---

---
url: >-
  /knowledgebase/record-and-task-forms/the-form-builder/things-to-remember-when-designing-an-intake-or-other-record-creation-form.md
---

# Things to remember when designing an intake or other record creation form

You have two types of record creation form in Autologyx Catalyst, both of which are designed specific to an object class:

**The Create and edit view** – configured under the Display tab of the object class – only logged-in users with the appropriate permission will have access to this form to create records. The same form is presented when a user edits a record in their Records list.

**A standalone form** – configured under the Forms tab of the object class. This has a URL which can be made available to both users or non-users for record creation. This is the option you are more likely to choose.

Both forms use the same Catalyst form-builder which allows the designer to present class fields in sections with up to 3 columns. There is also the ability to use conditional logic to display columns on the basis of inputs into previous fields.

If you think of an intake form as a checklist, you should be able to get all the information required to start the process along the appropriate route. Clever use of different field types and instructions will mean that the data will be in the correct format – that’s really important for sub-processes in your automated workflow and, of course, for any reporting you might provide to the business either during or after the event.

People generally dislike filling in forms. However, there are some really basic rules to follow when designing your forms which will lessen the annoyance of the user. At the risk of stating the obvious, these include:

1. **Ask everything needed.** As a minimum, the form needs to capture all the information needed to start the process, including data used in system decision-making as to who or which team it should be assigned, as well as which tasks must be created for it. It’s not a great use of anyone’s time to sequence a task or automate an email to the form submitter because they haven’t provided all the required information.
2. **Use conditional logic.** Use the conditional logic feature so that you only present relevant questions based on the answers to previous questions. In addition, avoid asking questions where the answer is already known – even if it is held in a different object class.
3. **Use familiar terminology.** Use terminology that the user is familiar with and keep questions as short and precise as possible.
4. **Keep instructions short and clear.** Use the Instruction widget to add notes where they will help the user, but keep these short and clear. The action button at the bottom of our stand alone forms is labelled “Submit”. You might consider using an instruction to explain what will happen when the form is submitted.
5. **Present questions in a logical order.** Present the questions in a logical order so that the user isn’t jumping about to find information. Some people suggest starting with easy, quick-to-complete type questions to make the user feel as if they are making good progress.
6. **Make workflow-driving questions mandatory.** Questions where you are collecting information which will determine the appropriate automated workflow route (via your sequences) must be mandatory.
7. **Include space for anything else relevant.** An open question at the end of the form is useful for the user to provide any other relevant information. A short while after the form goes into live use, you might find it useful to review these answers and either amend or add questions to allow a more efficient data capture of the type of information given.

[View our article describing the field types available in record creation forms](/knowledgebase/system-configuration/object-classes/object-class-field-types-uses-and-attributes/).

## In the meantime, some considerations which should aid your form design

### **Choose the right field type**

Catalyst has a number of different field types. It should go without saying, but ensure that you use field types which allow you to validate, ie Date fields to capture dates. We also have a Date/Time field type which is useful for meeting confirmations, etc. There are two Number type fields: Integer for whole numbers and Decimal for those which are not. The same applies with email addresses to be captured in the Email type field and all phone numbers in the Phone type field. Consider the appropriate field type for data capture in Catalyst if it is to be passed via API to a third party system or to be merged into documents or email messages.

### **Use text fields appropriately**

The least useful as far as determining the workflow automation route is “Text”. However, this is useful for capturing supplementary information or for providing fields for names or other information which cannot be chosen or pre-determined. One thing to bear in mind is to choose “Single line” for one word or short sentences and “Multi line” where you are expecting more detail.

### **Think about how options are displayed**

Single select fields can be displayed as a drop-down list, which will save space, or radio buttons. People like to see options, but if you have more than four, the form can become ugly, so the drop-down is preferable on these occasions. Our multi select fields are always displayed as tick boxes so that all users can clearly see which options have been chosen.

Checkboxes in Catalyst are always used for one option. They are useful to get the form submitter to confirm or agree to a statement.

### **Remember the limitation on placeholder text**

Catalyst fields don’t support placeholder text. This isn’t necessarily a bad thing, as it can be confusing. However, we often create single select fields, displayed as a drop-down, with a first option which prompts the user about making their selection, eg “Choose the option which most closely describes the current status of the claim”.

### **Consider making a field unique**

One final but really important thing to consider is marking one field as unique – most commonly a text field. This will prevent duplication of records.

## Testing the form

### **Start with internal testing**

Internal users should test the form first. They will be able to provide feedback on the logic, spelling and grammar, and all the obvious issues which you as the form designer won’t be able to see.

### **Then test with less familiar users**

Following this, ask colleagues from a different team or those who aren’t familiar with the use case to test for you. It can be useful to watch these user complete the form so that you can see where they find it difficult or get stuck.

### **Finally, test with external users**

Move on to testing with friendly external users and don’t stop until one flies through it without issue of query.

When the form does go-live, you could consider including a field asking for optional feedback or suggestions for improving the form. Just because it's live, that doesn’t mean it’s the best it can be!

---

---
url: /knowledgebase/finding-your-way-around/ui-and-navigation.md
---
# UI And Navigation

**Browse the sections below:**

* [Column Configuration On List Pages](/knowledgebase/finding-your-way-around/ui-and-navigation/column-configuration-on-list-pages/)
* [List Page Filter Editor](/knowledgebase/finding-your-way-around/ui-and-navigation/list-page-filter-editor/)
* [List Pages](/knowledgebase/finding-your-way-around/ui-and-navigation/list-pages/)

---

---
url: /api/catalyst/resources/landing-page/ui-config.md
---
# UI Config

> API for setup and use configuration for UI components.

## Permissions

Permissions for UI Config can be checked by:

| Context                        | Endpoint                      | Location    | Available perms  |
|--------------------------------|-------------------------------|-------------|------------------|
| Global scope                   | `GET /api/users/permissions/` | `ui_config` | `view`, `create` |

## POST /ui-config/`component`/

Creates or update UI Config for given `component`.
In case that UI Config already exists for given `component`, existing component content will be overridden by sent payload.

### Permissions

Requires `authentication` and `ui_config.create` permission.

### Request

* URL parameters

| Key       | Type | Notes                                             |
|-----------|------|---------------------------------------------------|
| component | str  | Unique component name. Value is case insensitive. |

In case the component name will contain big letters, all phrase will be saved as lowercase.

* Body parameters

| Key                   | Type  | Notes                                           |
|-----------------------|-------|-------------------------------------------------|
| content               | str   | Content must be a JSON compatible.              |
| custom\_components     | array | Custom Components ids used in UI configuration. |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /ui-config/`component`/

{
    "content": "{"key": {"value": "value", "value2": "value2"}}",
    "custom_components": [1, 2, 3],
    "upload_component": [
        {
            "object_class": 564,
            "class_field": 12
        }
    ]
}
<json> 
```

### Validations

* component
  * Max length: 50
  * contains only latin letters, digits and dash (a-z0-9-)
* custom\_components
  * is a integer
  * is optional
  * values are unique
  * max length: 100
* upload\_component
  * is optional
  * max length: 10
  * object\_class
    * is required
    * is integer
    * exists in DB
  * class\_field
    * is required
    * is integer
    * exists in DB
    * belongs to given object\_class
    * is of type 'document'

### Response

| Key               | Type  | Notes                                                        |
|-------------------|-------|--------------------------------------------------------------|
| content           | str   | Contain the same payload which was sent in request.          |

* Successful status `201 Created`
* Response body schema

```json
{"key": {"value": "value", "value2": "value2"}}
```

### Errors

| Cause                                              | Response code     | Message                                                                                            |
|----------------------------------------------------|-------------------|----------------------------------------------------------------------------------------------------|
| Incorrect component in URL                         | 400 Bad Request   | "component": \["Enter a valid value."]                                                              |
| Max length 50 cars of component exceeded           | 400 Bad Request   | 'component': \["Ensure this field has no more than 50 characters."]                                 |
| Invalid payload format                             | 400 Bad Request   | "detail": "JSON parse error - \<error\_text>"                                                        |
| Null value in payload                              | 400 Bad Request   | "content": \["This field may not be null."]                                                         |
| Size of payload JSON > 65K characters              | 400 Bad Request   | "content": \["Ensure this value has at most 65000 characters (it has \<len(json)>)."]                |
| Number of components > 100                         | 400 Bad Request   | "detail": \["Limit of 100 UI Config has been exceeded."]                                            |
| custom\_components.component missing                | 400 Bad Request   | "custom\_components": {"component": \["This field is required."]}                                  |
| custom\_components.component is empty               | 400 Bad Request   | "custom\_components": {"component": \["This field may not be blank."]}                             |
| custom\_components.component is null                | 400 Bad Request   | "custom\_components": {"component": \["This field may not be null."]}                              |
| custom\_components.component doesn't exists         | 400 Bad Request   | "custom\_components": {"component": \["Invalid pk "99900" - object does not exist."]}              |
| custom\_components.component is not enabled         | 400 Bad Request   | "custom\_components": \["Custom component 1 - object not enabled.",]                                 |
| Insufficient permissions                           | 403 Forbidden     | "detail": "You do not have permission to perform this action."                                     |
| object\_class is invalid                            | 400 Bad Request   | "object\_class": \["Invalid pk "99999" - object does not exist."]                                  |
| object\_class is not int                            | 400 Bad Request   | "object\_class": \["Incorrect type. Expected pk value, received str."]                               |
| object\_class is required                           | 400 Bad Request   | "object\_class": \["This field is required."]                                                        |
| object\_class is empty                              | 400 Bad Request   | "object\_class": \["This field may not be null."]                                                    |
| object\_class\_field is invalid                      | 400 Bad Request   | "object\_class\_field": \["Invalid pk "99999" - object does not exist."]                            |
| object\_class\_field is not int                      | 400 Bad Request   | "object\_class\_field": \["Incorrect type. Expected pk value, received str."]                         |
| object\_class\_field is required                     | 400 Bad Request   | "object\_class\_field": \["This field is required."]                                                  |
| object\_class\_field is empty                        | 400 Bad Request   | "object\_class\_field": \["This field may not be null."]                                              |
| object\_class\_field is not document type            | 400 Bad Request   | "object\_class\_field": \["Invalid type - field "field name" is not Document type."]                |
| object\_class\_field does not belong to object\_class | 400 Bad Request   | "details": \["Object Class Field ID "field\_id" does not belong to Object Class ID "class\_id"."] |
| upload component list has duplicatest          | 400 Bad Request   | "non\_field\_errors": \["The fields object\_class, object\_class\_field must make a unique set."]        |

## GET /ui-config/`component`/

Returns UI Config for given `component`.

### Permissions

Requires `authentication` and `ui_config.view` permission.
Some `component` names are public and don't require any authentication.

* Public `component`

  * theme

### Request

* URL parameters

| Key       | Type | Notes                           |
|-----------|------|---------------------------------|
| component | str  | Case insensitive component name |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /ui-config/`component`/
```

### Response

* Successful status `200 OK`
* Response body schema:

```json
<json>
```

### Errors

| Error                                | Response code | Message                                                        |
|--------------------------------------|---------------|----------------------------------------------------------------|
| Undefined component in URL           | 404 Not Found | "detail": "Not found."                                         |
| Missing component in URL (wrong url) | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Insufficient permissions             | 403 Forbidden | "detail": "You do not have permission to perform this action." |

---

---
url: >-
  /knowledgebase/system-configuration/merge-fields/understanding-namespace-in-jinja2-for-document-templates.md
---

# Understanding Namespace in Jinja2 for Document Templates

*Author: Logan Oliver*

*Manage variables across loops and blocks in Autologyx Sequencer and Document Templates*

## What is a Namespace?

In Jinja2, namespaces allow you to keep track of variables across loops or blocks without losing their values. This is helpful in Autologyx for tasks like document templating and sequencer logic, where calculations or counters need to persist.

## Why Use Namespace?

* **Document templating** – When merging fields and performing calculations across a list of items.
* **Sequencer** – Keeping a running total or condition across multiple loop iterations in API calls and local variables.

## Examples

![A screenshot of a computer Description automatically generated](../../../images2/zendesk_4641564905503_001_6a306d468cbe.png)

In our examples, we will use the above simple example relational model. Here, we have a parent object class for the various departments within a business, and child records for the suppliers that they engage. For reference:

**Department:** Object Class ID 1\
**Suppliers:** Object Class ID 2

### Set vs. Namespace

In this first example, we want check how many contracts across all of our suppliers are up for renewal within the next 30 days.

![A screenshot of a computer Description automatically generated](../../../images2/zendesk_4641564905503_002_c9b7d89a6e66.png) **The following example shows the limitations of `set` in Jinja2 when looping through this data.**

**Using `set` (Incorrect):**

```jinja
{% set total = 0 %}

{% for agreements in record.related_records_2 %}
  {% set total = total + agreements.field_number_of_contracts %}
{% endfor %}

{{ total }}
```

**Why this doesn't work:**\
In Jinja2, using `set` inside a loop or block creates a new variable for each iteration. This means `total` resets every time, so the final output of the above code is 0, even though there are 29 contracts up for renewal.

**Using namespace (Correct):**

```jinja
{% set calculation = namespace(total=0) %}

{% for agreements in record.related_records_2 %}
  {% set calculation.total = calculation.total + agreements.field_number_of_contracts %}
{% endfor %}

{{ calculation.total }}
```

**Why this works:**\
The namespace creates an object that persists outside the loop. Each iteration updates `calculation.total` without resetting, resulting in the correct accumulated value of 29.

### Adding Objects or Dictionaries to Namespace

Namespaces can also store more complex data, like dictionaries or lists. This is useful when you need to track multiple values or dynamically build objects during loops. For example, if you're creating a summary report that collects specific properties from items, you can use a dictionary within the namespace. In this example, we are trying to generate a list of data pertaining to documents within our child records.

```jinja
{% set documents = namespace(documents_list=[]) %}

{% for doc in record.related_records_2 %}
  {% set new_entry = {
    'document_Id': doc.field_document_id,
    'name': doc.field_document_name,
    'document': doc.field_document[0]
  } %}

  {% set documents.documents_list = documents.documents_list + [new_entry] %}
{% endfor %}

{{ documents.documents_list }}
```

**Expected output:**

![A screen shot of a computer Description automatically generated](../../../images2/zendesk_4641564905503_003_c8276793c1a4.png)

**How this works:**

This example demonstrates how to build a list of dictionaries within a Jinja2 loop using a namespace.

1. **Initialize the namespace:**\
   A namespace is created with an empty list (`documents_list`) to store document entries.
2. **Loop through records:**\
   For each record in `related_records_2`, a new dictionary (`new_entry`) is created containing the document ID, name, and the first document within the document field.
   * **NB:** Remember to use Guard Clauses if you’re referencing an index! [See here for more information.](/knowledgebase/system-configuration/merge-fields/syntax-for-merge-fields/)
3. **Add to the list:**\
   Each dictionary (`new_entry`) is appended to the `documents_list`, preserving all previous entries by combining lists.
   * **NB:** You cannot use statements like “append” in Autologyx. You should always instead use a combination of “Set” and “+” when building lists in your namespace.

This technique is ideal for accumulating structured data, such as generating lists for reports or dynamic document generation.

## Conclusion

Using namespace in Jinja2 provides a practical solution for managing variables that need to persist across loops or blocks. This is particularly valuable in Autologyx’s document templating and sequencer environments, where dynamic calculations or accumulations are required. By understanding the limitations of `set` and leveraging namespace, you can ensure more reliable and accurate outputs in your templates and processes. Additionally, storing objects or dictionaries within namespaces adds flexibility, enabling more complex data handling directly within Jinja2 templates.

---

---
url: >-
  /knowledgebase/system-configuration/apis-and-variables/understanding-namespace-in-jinja2-for-local-variables.md
---

# Understanding Namespace in Jinja2 for local variables

*Author: Logan Oliver*

*Manage variables across loops and blocks in Autologyx Sequencer and Document Templates*

## What is a Namespace?

In Jinja2, namespaces allow you to keep track of variables across loops or blocks without losing their values. This is helpful in Autologyx for tasks like document templating and sequencer logic, where calculations or counters need to persist.

## Why use Namespace?

* **Document templating** – When merging fields and performing calculations across a list of items.
* **Sequencer** – Keeping a running total or condition across multiple loop iterations in API calls and local variables.

## Examples

![Screenshot](../../../images2/zendesk_4641567730847_001_6a306d468cbe.png)

In our examples, we will use the above simple example relational model. Here, we have a parent object class for the various departments within a business, and child records for the suppliers that they engage. For reference:

* **Department:** Object Class ID 1
* **Suppliers:** Object Class ID 2

### Set vs. Namespace

In this first example, we want check how many contracts across all of our suppliers are up for renewal within the next 30 days.

![Screenshot](../../../images2/zendesk_4641567730847_002_c9b7d89a6e66.png)

The following example shows the limitations of Set in Jinja2 when looping through this data.

**Using set (Incorrect):**

```jinja
{% set total = 0 %}

{% for agreements in record.related\_records\_2 %}

  {% set total = total + agreements.field\_number\_of\_contracts %}

{% endfor %}
```

```jinja
{{ total }}
```

**Why this doesn't work:**\
In Jinja2, using Set inside a loop or block creates a new variable for each iteration. This means total resets every time, so the final output of the above code is 0, even though there are 29 contracts up for renewal.

**Using namespace (Correct):**

```jinja
{% set calculation = namespace(total=0) %}

{% for agreements in record.related\_records\_2 %}

  {% set calculation.total = calculation.total + agreements.field\_number\_of\_contracts %}

{% endfor %}
```

```jinja
{{ calculation.total }}
```

**Why this works:**\
The namespace creates an object that persists outside the loop. Each iteration updates calculation.total without resetting, resulting in the correct accumulated value of 29.

### Adding Objects or Dictionaries to Namespace

Namespaces can also store more complex data, like dictionaries or lists. This is useful when you need to track multiple values or dynamically build objects during loops. For example, if you're creating a summary report that collects specific properties from items, you can use a dictionary within the namespace. In this example, we are trying to generate a list of data pertaining to documents within our child records.

```jinja
{%set documents = namespace(documents\_list=[])%}

{% for doc in record.related\_records\_2 %}

    {% set new\_entry = {

      'document\_Id': doc.field\_document\_id,

      'name': doc.field\_document\_name,

      'document': doc.field\_document[0]

    } %}

    {% set documents.documents\_list = documents.documents\_list + [new\_entry] %}

{% endfor %}
```

```jinja
{{documents.documents\_list}}
```

**Final output:**

![Screenshot](../../../images2/zendesk_4641567730847_003_c8276793c1a4.png)

This example demonstrates how to build a list of dictionaries within a Jinja2 loop using a namespace.

1. **Initialize the namespace**\
   A namespace is created with an empty list (documents\_list) to store document entries.
2. **Loop through records**\
   For each record in related\_records\_2, a new dictionary (new\_entry) is created containing the document ID, name, and the first document within the document field.
   * **NB:** Remember to use Guard Clauses if you’re referencing an index! [See here for more information.](/knowledgebase/system-configuration/merge-fields/syntax-for-merge-fields/)
3. **Add to list**\
   Each dictionary (new\_entry) is appended to the documents\_list, preserving all previous entries by combining lists.
   * **NB:** You cannot use statements like “append” in Autologyx. You should always instead use a combination of “Set” and “+” when building lists in your Namespace.

**When this is useful:**\
This technique is ideal for accumulating structured data, such as generating lists for reports or dynamic document generation.

## Conclusion

Using namespace in Jinja2 provides a practical solution for managing variables that need to persist across loops or blocks. This is particularly valuable in Autologyx’s document templating and sequencer environments, where dynamic calculations or accumulations are required. By understanding the limitations of set and leveraging namespace, you can ensure more reliable and accurate outputs in your templates and processes. Additionally, storing objects or dictionaries within namespaces adds flexibility, enabling more complex data handling directly within Jinja2 templates.

---

---
url: /knowledgebase/getting-started/performing-work-delivery.md
---


---

---
url: /knowledgebase/system-configuration/sequence-actors/update-record-actor.md
---

# Update Record Actor

## What does the Update Record actor do?

The Update Record actor can be used to update one or more fields on a record at any point in your workflow. It will update any field type other than a user field.

## How do I use the Update Record actor?

Drag and drop the Update Record actor onto your sequence.

Right click on the actor and select **Configure**.

Click into the **Set Field** area. All available object class fields will be displayed in alphabetical order. User fields will not be included.

![](../../../images2/zendesk_5306363034015_001_2124a3c2e990.png)

Select the field you want to update.

**Choose how to set the field value**

* **Static value** to enter data
* **No value/default** to blank the field or set it to Null

In the screenshot below, the field **Status** is being updated. It is a single select field. All options are shown and one can be selected.

![](../../../images2/zendesk_5306363034015_002_14ed8d284ad1.png)

If you want to update more than one field with the same actor, simply click the **+** button to reveal a new configuration row.

![](../../../images2/zendesk_5306363034015_003_ec7cc9c0baa8.png)

## Finish configuration

Save the configuration.

It is good practice to label all actors to allow other users to gain a better understanding of what your sequence is doing. Right click on the Update record actor again and select **Properties**.

![](../../../images2/zendesk_5306363034015_004_a1faa418e10f.png)

In the **Name** field overwrite Update Record with something to explain its use. Click **Save**. The new label will appear in white text on the actor.

![](../../../images2/zendesk_5306363034015_005_90e1911d48fb.png)

## Activity log

All updates made by the Update Record actor will be recorded in the record Activity log as a "Field value updated" type. These will be date/time stamped and show the sequence ID.

![](../../../images2/zendesk_5306363034015_006_461e76ea9ba8.png)

In the workflow below, you can see that a status field has been set in various stages of the process to **Approved**, **Denied** and **Deployed**.

![](../../../images2/zendesk_5306363034015_007_89b547498cbc.png)

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.14/user-experience-interface-improvements.md
---

# User Experience & Interface Improvements

## Introducing Markdown

With the growing adoption of AI-powered workflows, we’ve enhanced text fields to give you greater flexibility in how content is created and displayed.

You can now choose to display text fields as **Markdown**, rather than being limited to standard single or multiline formats.

![Screenshot 2026-03-31 at 17.13.21.png](../../../images2/zendesk_5585443696927_001_2fe8dbc75f81.png)

When working in create/edit record forms or task forms, Markdown content can be viewed in two ways, depending on your needs:

* **As source code** — ideal for editing and maintaining structure

![Screenshot 2026-03-31 at 17.23.23.png](../../../images2/zendesk_5585443696927_002_3f9cd4947c68.png)

* **As beautifully rendered text** — making content easier to read and consume

![Screenshot 2026-03-31 at 17.19.29.png](../../../images2/zendesk_5585443696927_003_c3c6a696dce3.png)

Across the rest of the platform, such as when Markdown fields are used in record list columns, the content will default to displaying the source code.

![Screenshot 2026-03-31 at 17.28.48.png](../../../images2/zendesk_5585443696927_004_a34b9e18d11d.png)

## Improved form usability

We’ve made several enhancements to form layouts to improve readability and create a more seamless editing experience.

**More space for content**

Multiline and Markdown textboxes for text and JSON fields in the Create/Edit record form now expand to the full width of their containing column, giving you more space to view and work with your content.

![Screenshot 2026-04-01 at 10.45.45.png](../../../images2/zendesk_5585443696927_005_2e3b01727849.png)

**Single-line text fields** remain unchanged, ensuring consistency where it matters.

**Automatic height adjustment**

To further enhance usability, **Multiline and Markdown fields** now automatically adjust their height to fit content—supporting up to 500 lines—so you can focus on your data without unnecessary scrolling.

## Refined UI consistency

We’ve standardised UI components across the platform, creating a more cohesive and polished look and feel throughout your experience.

---

---
url: /knowledgebase/administration/user-groups/user-group-list.md
---

# User Group List

The User Group List displays the User Groups you have permission to view.

From this page, authorised users can:

* open a User Group
* view where a User Group is used
* delete a User Group, where permitted
* create new User Groups, where permitted
* review ownership, membership, and activity information

## Default columns

The default User Group List contains the following columns.

### ID

The unique ID number assigned to the User Group.

This is useful when several User Groups have similar names.

### Name

The name of the User Group.

This field is mandatory when creating a new User Group and must be unique.

### Description

An optional description explaining what the User Group is used for.

### Actions

The options available in the **Actions** menu depend on your account type and relationship to the User Group.

## Actions available to Super Admin users

If your user account type is Super Admin, you can see all User Groups in the system.

For each User Group, the **Actions** menu contains:

* **Open**
* **View usage**
* **Delete**

![User Group List showing available User Groups](../../../images2/zendesk_4649792856479_001_ad0f8db8c9c7.png)

## Actions available to User Group Owners

A User Group Owner with a Config Admin account type will have links for **User Groups** and **Users** in the main navigation menu.

They will only see User Groups where they are either an Owner or a Member.

For User Groups they own, the **Actions** menu contains:

* **Open**
* **View usage**
* **Delete**

![User Groups visible to a Config Admin User Group Owner](../../../images2/zendesk_4649792856479_002_23485f0ba0b8.png)

![Actions menu available to a User Group Owner](../../../images2/zendesk_4649792856479_003_97d4a4be5995.png)

## Actions available to User Group Members

A user who is a Member of a User Group, but not an Owner, has more limited options.

For these User Groups, the **Actions** menu contains:

* **Open**
* **View usage**

![Actions menu available to a User Group Member](../../../images2/zendesk_4649792856479_004_014459cc9dca.png)

## Additional columns

The **Column configuration** control allows you to add the following columns to the User Group List.

| Column | Description |
| --- | --- |
| **# Members** | Displays the total number of Members in the User Group, including Owners. |
| **# Owners** | Displays the number of Members who are Owners. |
| **Created** | Shows the date and time the User Group was created. |
| **Created by** | Shows the first and last name of the user who created the User Group. |
| **Last edited** | Shows the date and time the User Group was last edited. |
| **Last edited by** | Shows the first and last name of the user who last edited the User Group. |

![Column configuration showing additional User Group columns](../../../images2/zendesk_4649792856479_005_71afbd151752.png)

## Related articles

* [Editing a User Group](/knowledgebase/administration/user-groups/editing-a-user-group/)
* [User Group Permissions](/knowledgebase/administration/user-groups/user-group-permissions/)
* [Editing User Group Permissions](/knowledgebase/administration/user-groups/editing-user-group-permissions/)
* [List Pages](/knowledgebase/finding-your-way-around/ui-and-navigation/list-pages/)
* [List Page Filter Editor](/knowledgebase/finding-your-way-around/ui-and-navigation/list-page-filter-editor/)

## Things to remember

1. Super Admin users can see all User Groups in the system.
2. Config Admin users see only User Groups where they are an Owner or Member.
3. Only Owners and Super Admin users can delete User Groups.
4. The available **Actions** menu options depend on your permissions.
5. Additional columns can be added using Column configuration.
6. User Group names must be unique.

---

---
url: /api/catalyst/resources/user-groups/user-group-permission-sets.md
---
# User Group Permission Sets

This document describes API endpoints for managing User Group Permission Sets. Theirs setup is configurable at User Group level.

Endpoints for assigning users for Custom User Group Permission Set of specific User Group are described in separated [document](/api/catalyst/resources/user-groups/user-group-permission-set-assignees).

## Permissions

| Permission                 | Manageable via Roles | Manageable via other ways                                              | Description        |
|----------------------------|----------------------|------------------------------------------------------------------------|--------------------|
| user\_groups.view          | true                 | User Group owner`view` by User Group permission sets | Allows access list |
| user\_groups.edit\_perm\_set | false                | User Group owner                                              |                    |

Permissions for User Group Permission Sets can be checked by:

| Context               | Endpoint                                 | Location              | Available perms         |
|-----------------------|------------------------------------------|-----------------------|-------------------------|
| Specific User Group | `GET /api/user-groups/{user_group_id}/ ` | `_meta.permissions`   | `view`, `edit_perm_set` |

## User Group Permission Set types

When a User Group is created, the system automatically creates two special permission sets. The first one is automatically assigned to all standard users. The second one is automatically assigned to all group members.
Request to create new User Group Permission Set with name `everyone` or `members` will be rejected.
While creating User Group Permission Set, the system checks if the name is not reserved for special permission sets.
Create Custom User Group Permission Set will only create a new permission set with one `custom` type.

To fit this requirements:

```
A User Group can have multiple Custom Permission Sets.
A User Group must have only one MEMBERS Permission Sets.
A User Group must have only one EVERYONE Permission Sets.
```

## References

* [User Groups Permission Sets - Technical Design](https://autologyx.sharepoint.com/:w:/s/Dev/EVXcrsoacx5Ek38G44xQJbkBqiUgbh5ZPJo1OiqUHl7knw).

## GET /api/user-groups/`user_group_id`/permission-sets/

Returns list of User Group Permission Sets for specific User Group.

### Permissions

Requires `authentication` and `user_groups.view` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/user-groups/`user_group_id`/permission-sets/
```

### Response

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

#### Response `results` array

| Key         | Type     | Notes                                                                                                             |
|-------------|----------|-------------------------------------------------------------------------------------------------------------------|
| id          | int      |                                                                                                                   |
| name        | string   |                                                                                                                   |
| type        | string   | Is one of `everyone`, `members`, `custom`.                                                                        |
| permissions | Object   | Complex object containing enabled permissions for resources.                                                      |
| created\_at  | datetime |                                                                                                                   |
| created\_by  | user     | user (object) who created the set OR null for restricted system sets.                                             |
| modified\_at | datetime |                                                                                                                   |
| modified\_by | user     | user (object) who last modified the set OR null for already created restricted system sets and not modified yet.  |

* Successful status `200 OK`
* Response body schema

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str>,
  "previous": <str>,
  "results": [
    {
      "id": <int>,  
      "name": <str>, 
      "type": <str>,
      "permissions": {
        "user_groups": [<str>],
      },
      "created_at": <datetime>,
      "created_by": <user>,
      "modified_at": <datetime>,
      "modified_by": <user>
    }
  ]  
}
```

### Sorting

Not available.

### Filtering

Not available.

### Errors

| Error                                       | Response code | Message                                                        |
|---------------------------------------------|---------------|----------------------------------------------------------------|
| User Group for {user\_group\_id} not found.   | 404 Not found |                                                                |
| Insufficient permissions                    | 403 Forbidden | "detail": "You do not have permission to perform this action." |

## POST /api/user-groups/`user_group_id`/permission-sets/

Creates single User Group Permission Set.

### Permissions

Requires `authentication` and `user_groups.edit_perm_sets` permission.

### Request

* URL parameters

| Key             | Notes         |
|-----------------|---------------|
| user\_group\_id   | User Group ID |

* Body parameters

| Key           | Type   | Notes                                                                                       |
|---------------|--------|---------------------------------------------------------------------------------------------|
| name          | string | Unique (case insensitive) for the given User Group.                                         |
| permissions   | Object | Optional. Complex object containing configuration for resources' permissions to be enabled. |

Available resources for `permissions`:

* `user_groups`

`user_groups` key contain list of actions. By default, permissions are disabled if not given in request's body.

Valid actions for user\_groups resource:

* edit
* view
* delete

Sent permissions are converted with dependencies described in [technical doc](https://autologyx.sharepoint.com/:w:/s/Dev/EebO80osrJhLsOEjzwdbXIkBTX2Zb5NHewLL-HaAlyYT9g?e=fSCdF9\&nav=eyJoIjoiMTA3MjIwNDc1OSJ9).

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/user-groups/'user_group_id'/permission-sets/

{
  "name": <str>, 
  "permissions": {
    "user_groups": [<str>],
  } 
}
```

* Request example

```json
{
  "name": "PermSet", 
  "permissions": {
    "user_groups": ["edit"],
  } 
} 
```

### Validations

* name
  * Max length: 100
  * Unique: for specific User Group
  * Reserved: is reserved for Special Permission Sets (e.g. `owners`, `everyone`, `members`)
* Maximum number of User Group Permission Sets per specific User Group: 10  (includes special permission sets).

### Response

| Key         | Type     | Notes                                                                |
|-------------|----------|----------------------------------------------------------------------|
| id          | int      | Automatically generated by the backend.                              |
| name        | string   |                                                                      |
| type        | string   | In the POST response Only `custom` Permission Set type is displayed. |
| permissions | Object   | Complex object contains saved permissions' configuration.            |
| created\_at  | datetime |                                                                      |
| created\_by  | user     |                                                                      |
| modified\_at | datetime |                                                                      |
| modified\_by | user     |                                                                      |

* Successful status `201 Created`
* Response body schema

```json
{
  "id": <int>, 
  "name": <str>, 
  "type": <str>, 
  "permissions": {
    "user_groups": [<str>],
  }, 
  "created_at": <datetime>, 
  "created_by": <user>, 
  "modified_at": <datetime>, 
  "modified_by": <user> 
} 
```

### Errors

| Error                                               | Response code   | Message                                                                                                   |
|-----------------------------------------------------|-----------------|-----------------------------------------------------------------------------------------------------------|
| "name" is missing                                   | 400 Bad Request | "name": \[ "This field is required." ]                                                                     |
| "name" is empty string                              | 400 Bad Request | "name": \[ "This field may not be blank." ]                                                                |
| "name" is null                                      | 400 Bad Request | "name": \[ "This field may not be null." ]                                                                 |
| "name" has > 100 chars                              | 400 Bad Request | "name": \[ "Ensure this field has no more than 100 characters." ]                                          |
| "name" is not unique for specific User Group        | 400 Bad Request | "name": \[ "This field must be unique." ]                                                                  |
| "name" is reserved for Special Permission Set names | 400 Bad Request | "name": \[ "Name \\"{name}\\" is reserved and cannot be used." ]                                           |
| Given NULL for `permissions`                        | 400 Bad Request | "permissions": \["This field may not be null."]                                                            |
| Given wrong resource name for `permissions`         | 400 Bad Request | "permissions": \["Invalid resource \\"{given\_wrong\_resource\_name}\\"."]                                    |
| Given NULL for resource in `permissions`            | 400 Bad Request | "permissions": {"{resource\_name}": \["This field may not be null."] }                                      |
| Given wrong value for resource in `permissions`     | 400 Bad Request | "permissions": {"{resource\_name}": \["Invalid actions \\"{given\_wrong\_value}\\"."] }                       |
| Max 10 Permission Sets per user group exceeded      | 400 Bad Request | "detail": "Limit of 10 User Group Permission Sets has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED" |
| User Group with {user\_group\_id} does not exist      | 404 Not found   | 	                                                                                                         |
| Insufficient permissions                            | 403 Forbidden   | "detail": "You do not have permission to perform this action."                                            |

## PATCH /api/user-groups/'user\_group\_id'/permission-sets/`id`/

Updates single User Group Permission Set.

### Permissions

Requires `authentication` and `user_groups.edit_perm_set` permission.

### Request

* URL parameters

| Key            | Notes                       |
|----------------|-----------------------------|
| user\_group\_id  | User Group ID               |
| id             | UserGroup Permission Set ID |

* Body parameters

| Key         | Type   | Notes                                                                                 |
|-------------|--------|---------------------------------------------------------------------------------------|
| name        | string | Unique (case insensitive) for the given User Group. Max length = 100 (configurable)   |
| permissions | Object | Complex object containing configuration for resources' permissions to be enabled.     |

Any parameter not listed above are silently ignored if passed.

Available resource keys for `permissions`:

* `user_groups`

`user_groups` keys contain list of actions. All are optional. If some resource is omitted then permissions for it will not be modified.
Actions `edit` and `delete` cannot be set for the restricted system set `Everyone`.

Valid actions for resources according to type:

| everyone        | members                                   | custom                                    |
|-----------------|-------------------------------------------|-------------------------------------------|
| view   | editviewdelete | editviewdelete |

Sent permissions are converted with dependencies described in [technical doc](https://autologyx.sharepoint.com/:w:/s/Dev/EebO80osrJhLsOEjzwdbXIkBTX2Zb5NHewLL-HaAlyYT9g?e=fSCdF9\&nav=eyJoIjoiMTA3MjIwNDc1OSJ9).

> :warning: If less actions will be sent than are already in setup, not mentioned actions will be **removed** if they do not depend on other enabled actions.
>
> For instance:
>
> Current actions: `["view", "edit"]`. Sent actions: `["view"]`. Result actions: `["view"]`.

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
PATCH /api/user-groups/'user_group_id'/permission-sets/`id`/

{
  "name": <str>, 
  "permissions": {
    "user_groups": [<str>]
  } 
} 
```

* Request example

```json
{
  "name": "PermSet", 
  "permissions": {
    "user_groups": ["view", "edit"]
  } 
} 
```

### Response

| Key         | Type     | Notes                               |
|-------------|----------|-------------------------------------|
| id          | int      |                                     |
| name        | string   |                                     |
| type        | string   | Permission Set type is displayed.   |
| permissions | Object   |                                     |
| created\_at  | datetime |                                     |
| created\_by  | user     |                                     |
| modified\_at | datetime |                                     |
| modified\_by | user     |                                     |

* Successful status `200 OK`
* Response body schema:

```json
{
  "id": <int>, 
  "name": <str>, 
  "type": <str>, 
  "permissions": {
    "user_groups": [<str>],
  },
  "created_at": <datetime>, 
  "created_by": <user>, 
  "modified_at": <datetime>, 
  "modified_by": <user> 
} 
```

### Errors

| Error                                                             | Response code      | Message                                                                                                   |
|-------------------------------------------------------------------|--------------------|-----------------------------------------------------------------------------------------------------------|
| "name" is missing                                                 | 400 Bad Request    | "name": \[ "This field is required." ]                                                                     |
| "name" is empty string                                            | 400 Bad Request    | "name": \[ "This field may not be blank." ]                                                                |
| "name" is null                                                    | 400 Bad Request    | "name": \[ "This field may not be null." ]                                                                 |
| "name" has > 100 chars                                            | 400 Bad Request    | "name": \[ "Ensure this field has no more than 100 characters." ]                                          |
| "name" is not unique for specific User Group                      | 400 Bad Request    | "name": \[ "This field must be unique." ]                                                                  |
| "name" is reserved for Special Permission Set names               | 400 Bad Request    | "name": \[ "Name \\"{name}\\" is reserved and cannot be used." ]                                           |
| "name" is reserved for Special Permission Set names               | 400 Bad Request    | "name": \[ "Name \\"{name}\\" is reserved and cannot be used." ]                                           |
| Attempt to change the name of the Special Permission Set          | 400 Bad Request    | "name": \[ "Name \\"{name}\\" is reserved and cannot be changed." ]                                        |
| Given NULL for `permissions`                                      | 400 Bad Request    | "permissions": \["This field may not be null."]                                                            |
| Given wrong resource name for `permissions`                       | 400 Bad Request    | "permissions": \["Invalid resource \\"{given\_wrong\_resource\_name}\\"."]                                    |
| Given NULL for resource in `permissions`                          | 400 Bad Request    | "permissions": {"{resource\_name}": \["This field may not be null."] }                                      |
| Given wrong value for resource in `permissions`                   | 400 Bad Request    | "permissions": {"{resource\_name}": \["Invalid actions \\"{given\_wrong\_value}\\"."] }                       |
| Attempt to set `edit` or `delete` permissions for `Everyone` set  | 400 Bad Request    | "permissions": {"{resource\_name}": \["Invalid actions \\"{given\_wrong\_value}\\"."] }                       |
| Max 10 Permission Sets per user group exceeded                    | 400 Bad Request    | "detail": "Limit of 10 User Group Permission Sets has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED" |
| User Group with {user\_group\_id} does not exist                    | 404 Not found      | 	                                                                                                         |
| Insufficient permissions                                          | 403 Forbidden      | "detail": "You do not have permission to perform this action."                                            |

## DELETE /api/user-groups/'user\_group\_id'/permission-sets/`id`/

Deletes single User Group Permission Set. Special Permission Sets cannot be deleted.

### Permissions

Requires `authentication` and `user_groups.edit_perm_sets` permission.

### Request

* URL parameters

| Key            | Notes                          |
|----------------|--------------------------------|
| user\_group\_id  | User Group ID                  |
| id             | User Group Permission Set ID   |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
DELETE /api/user-groups/'user_group_id'/permission-sets/`id`/
```

### Response

* Successful status `204 No Content`

### Errors

| Error                                                        | Response code    | Message                                                                          |
|--------------------------------------------------------------|------------------|----------------------------------------------------------------------------------|
| User Group Permission Set with "{id}" is of type everyone    | 400 Bad Request  | "detail": "User Group type "Everyone" is restricted and cannot be deleted."  	 |
| User Group Permission Set with "{id}" is of type members     | 400 Bad Request  | "detail": "User Group type "Members" is restricted and cannot be deleted."  	  |
| User Group  with "{user\_group\_id}" does not exist            | 404 Not found    | 	                                                                                |
| User Group Permission Set with "{id}" does not exist         | 404 Not Found    | 	                                                                                |
| Insufficient permissions                                     | 403 Forbidden    | "detail": "You do not have permission to perform this action."                   |

## OPTIONS /api/user-groups/'user\_group\_id'/permission-sets/

### Permissions

Requires `authentication` only.

### Request

* URL parameters

| Key            | Notes          |
|----------------|----------------|
| user\_group\_id  | Users Group ID |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/user-groups/'user_group_id'/permission-sets/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
  "details":{
    "schema":[
      {
        "alias":"name",
        "required":true,
        "reserved":[
          "owners",
          "everyone",
          "members"
        ],
        "type":"string",
        "validators":[
          {
            "length":1,
            "type":"min_length"
          },
          {
            "length":100,
            "type":"max_length"
          }
        ]
      },
      {
        "alias":"type",
        "required":true,
        "type":"enum",
        "values":[
          {
            "system":true,
            "text":"Everyone",
            "value":"everyone"
          },
          {
            "system":true,
            "text":"Members",
            "value":"members"
          },
          {
            "system":false,
            "text":"Custom",
            "value":"custom"
          },
          {
            "system":true,
            "text":"Owners",
            "value":"owners"
          }
        ]
      },
      {
        "alias":"permissions",
        "required":false,
        "schema":[
          {
            "actions":[
              "view",
              "edit",
              "delete"
            ],
            "resource":"user_groups",
            "restrictions":[
              {
                "available":[
                  
                ],
                "default":[
                  
                ],
                "type":"owners"
              },
              {
                "available":[
                  "view"
                ],
                "default":[
                  
                ],
                "type":"everyone"
              },
              {
                "available":[
                  "view",
                  "edit",
                  "delete"
                ],
                "default":[
                  "view"
                ],
                "type":"members"
              },
              {
                "available":[
                  "view",
                  "edit",
                  "delete"
                ],
                "default":[
                  
                ],
                "type":"custom"
              }
            ]
          }
        ],
        "type":"permissions"
      }
    ]
  },
  "list":{
    "columns":[
      {
        "alias":"id",
        "predicates":[
          
        ],
        "sort_ok":false,
        "type":"int"
      },
      {
        "alias":"name",
        "predicates":[
          
        ],
        "sort_ok":false,
        "type":"string"
      },
      {
        "alias":"type",
        "predicates":[
          
        ],
        "sort_ok":false,
        "type":"enum"
      },
      {
        "alias":"permissions",
        "predicates":[
          
        ],
        "sort_ok":false,
        "type":"permissions"
      },
      {
        "alias":"created_at",
        "predicates":[
          
        ],
        "sort_ok":false,
        "type":"datetime"
      },
      {
        "alias":"created_by",
        "predicates":[
          
        ],
        "sort_ok":false,
        "type":"user"
      },
      {
        "alias":"modified_at",
        "predicates":[
          
        ],
        "sort_ok":false,
        "type":"datetime"
      },
      {
        "alias":"modified_by",
        "predicates":[
          
        ],
        "sort_ok":false,
        "type":"user"
      }
    ]
  },
  "restrictions":{
    "limit_items":10
  }
}
```

### Errors

| Error                                        | Response code    | Message |
|----------------------------------------------|------------------|---------|
| Users Group for `user_group_id` not found.   | 404 Not Found    |         |

## Not allowed endpoints

### GET /api/user-groups/'user\_group\_id'/permission-sets/`id`/

#### Response

* Status `405 Method Not Allowed`

---

---
url: /knowledgebase/release-notes/release-notes-1.8/user-group-permissions.md
---

# User group permissions

## Overview

With our newly released feature - User Group Permissions, you're no longer confined to generic permission settings. Instead, you gain the power to create custom permission sets that precisely define actions within each group. Breaking new ground, Catalyst allows the creation of custom permission sets concerning group access. This feature enables you to tailor permissions according to your unique requirements, enhancing the system's adaptability to diverse organisational structures.

Within the realm of user group permissions, you gain the power to intricately tailor the visibility of a group and its members. The options are extensive, allowing you to decide who can see the group, who can edit it, or who has the authority to delete it.

![User group permissions\_1.gif](/knowledgebase/images/img_16324169025437_1776895660.png)

## Default permission sets

**Default permission sets** provide the foundation for access control.

Different permission levels can now be set for various groups. Group owners automatically wield comprehensive access to all actions within their groups. Upon creating each group, two additional permission sets - "Members" for group members and "Everyone" for users outside the group - are automatically generated.

These sets provide the foundation for assigning permissions to group members and other system users, ensuring that access is granted where it's needed and denied where it's not.

## Group-based assignment

**Group-based assignment** is where the feature becomes especially powerful.

You can add not only individual users but also other groups to the group permission sets. By including groups in the selection options, members of the chosen group automatically acquire the assigned permissions. Conversely, permissions are promptly revoked if they are withdrawn from the group or if a user ceases to be a member.

![User group permissions\_2.gif](/knowledgebase/images/img_16324169025437_1776895661.png)

## Future expansion

**Future expansion** is already anticipated.

This marks the first of many spaces where group selection is feasible, and rest assured, this is just the beginning. In subsequent releases, we envision expanding the capability to include groups in many more areas within Catalyst, further enhancing the versatility and impact of this groundbreaking feature.

Embrace the future of secure collaboration with Catalyst's User Groups Permissions - a revolutionary leap towards a more nuanced, flexible, and powerful user management experience. Security is not just a feature - it's a journey, and we're committed to leading the way.

---

---
url: /knowledgebase/administration/user-groups/user-group-permissions.md
---

# User Group Permissions

User Group permissions determine who can view, edit, and manage a User Group.

Users with a Super Admin account type and User Group Owners can access the **Permissions** tab to manage default permissions and create additional User Group Permission Sets.

For information about User Group ownership and administration limitations, see [Editing a User Group](/knowledgebase/administration/user-groups/editing-a-user-group/).

## Accessing User Group permissions

Open the required User Group and select the **Permissions** tab.

## Default User Group permission sets

Every User Group contains three default Permission Sets.

### Owners

The **Owners** permission set cannot be modified.

Users assigned to this set automatically receive permission to:

* View
* Edit
* Delete

the User Group.

### Everyone

The **Everyone** permission set applies to all users in the system except 1-time completion users, who do not log in.

All permissions are disabled by default.

### Members

The **Members** permission set applies to all members of the User Group who are not Owners.

By default, Members can view the User Group and access the Membership and Permissions tabs, but cannot make changes.

![Default User Group permission sets showing Owners, Everyone and Members](/knowledgebase/images/administration/user-group-permissions-1.png)

## Creating additional permission sets

Additional permission sets can be created when different groups of users require different levels of access.

For example:

* a Team Leader may need permission to manage membership
* a departmental administrator may need visibility of the User Group without becoming an Owner
* a user outside the User Group may need temporary access

In the example below, Fiona Kensington is already a member of the User Group but requires additional permissions to perform management activities.

![Custom permission set assigned to a User Group member](/knowledgebase/images/administration/user-group-permissions-2.png)

## Create a User Group permission set

*(The screenshots below were taken using a Super Admin account.)*

Click **+ Add permission set**.

**Note:** While a permission set is being created, the button is temporarily disabled.

Enter a name for the permission set and enable the required permissions.

![Creating a new User Group permission set](/knowledgebase/images/administration/user-group-permissions-3.png)

Click the tick icon to save.

The new permission set is created and displays an **Add assignees** link.

![New permission set showing the Add assignees option](/knowledgebase/images/administration/user-group-permissions-4.png)

## Add assignees

Click **Add assignees**.

You can assign:

* individual users
* User Groups

### Add individual users

Click the **Users** tab and select the **+** button.

![Manage assignees dialog showing Users and User Groups tabs](/knowledgebase/images/administration/user-group-permissions-5.png)

Either:

* scroll through the available users
* begin typing a user's name to filter the list

Click a user tile to select it.

![Selecting users to add to a permission set](/knowledgebase/images/administration/user-group-permissions-6.png)

Selected users become greyed out and display **Already selected**.

Continue selecting users as required and click **+ Add**.

![Users selected and ready to be added to the permission set](/knowledgebase/images/administration/user-group-permissions-7.png)

A green success toast confirms the assignment.

Close the Manage assignees panel when you are finished.

![Success message confirming users were added to the permission set](/knowledgebase/images/administration/user-group-permissions-8.png)

## Viewing assignees

Assigned users are displayed as avatars within the permission set.

**Note:** Avatars are shown only for the **Owners** permission set and custom permission sets.

![Permission set displaying assigned user avatars](/knowledgebase/images/administration/user-group-permissions-9.png)

If a User Group is assigned to a permission set, the User Group avatar is displayed before any user avatars.

Selecting the avatar displays:

* the User Group description
* the number of members in the User Group

User Group avatars can be distinguished from user avatars by their shape.

![User Group avatar displayed within a permission set](/knowledgebase/images/administration/user-group-permissions-10.png)

## Editing default permissions

The permissions assigned to the default **Members** permission set can be modified.

The example below shows how Member permissions can be updated.

![Editing permissions for the default Members permission set](/knowledgebase/images/administration/user-group-permissions-11.gif)

**Important:** Permissions take effect immediately when a user or User Group is assigned to a permission set.

Users do not need to sign out and back in again, although a page refresh may occasionally be required before changes become visible.

## Related articles

* [Editing a User Group](/knowledgebase/administration/user-groups/editing-a-user-group/)
* [Editing User Group Permissions](/knowledgebase/administration/user-groups/editing-user-group-permissions/)

## Things to remember

1. A user can belong to multiple User Groups.
2. A user can belong to more than one permission set within a User Group.
3. A User Group can have up to 10 Owners.
4. A User Group can contain up to 1,000,000 Members.
5. A maximum of 1,000 User Groups can exist in a system.
6. Permission changes take effect immediately after assignment.
7. The Owners permission set cannot be modified.

---

---
url: /api/catalyst/resources/user-groups/user-groups.md
---
# User Groups

This technical design describes implementation and API for User Groups.

# User Groups API

## POST /api/user-groups/

Creates Users Group.

### Permissions

Requires `authentication` and `user_groups.create` permission.

### Request

* Headers

```
Request Method: POST
Content-Type: application/json
Location: /api/user-groups/
Authorization: JWT access_token
```

* Body

| Key           | Type     | Required | Notes           |
|---------------|----------|----------|-----------------|
| name          | string   | true     |                 |
| description   | string   | false    |                 |

#### Validations

* name
  * This field is required.
  * This field must be unique.
  * This field may not be blank.
  * Ensure this field has no more than 80 characters.
* description
  * Ensure this field has no more than 500 characters.
  * This field may not be null

### Sample request body

```json
{
    "name": "test_group",
    "description": "Sample description"
}
```

### Response

| Key               | Type     | Notes                                    |
|-------------------|----------|------------------------------------------|
| id                | int      | Automatically generated by the backend.  |
| name              | string   |                                          |
| description       | string   |                                          |
| created\_at        | datetime |                                          |
| created\_by        | user     |                                          |
| modified\_at       | datetime |                                          |
| modified\_by       | user     |                                          |
| num\_of\_members    | int      |                                          |
| num\_of\_owners     | int      |                                          |
| \_meta.permissions | Object   | Object describing permissions.           |

* Successful status `201 Created`
* Response body schema

```json
{
    "id": 1,
    "name": "test_group",
    "description": "Sample description",
    "created_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "num_of_members": 0,
    "num_of_owners": 0,
    "created_at": "2022-04-22T09:14:46.990000+02:00",
    "modified_at": "2022-04-22T09:14:46.990000+02:00",
    "_meta": {
        "permissions": {
            "create": true,
            "list": true,
            "view": true,
            "edit": true,
            "delete": true,
            "edit_perm_sets": true,
            "edit_members": true,
            "edit_owners": true
        }
    }
}
```

### Errors

| Cause                     | Response code   | Message                                                               |
|---------------------------|-----------------|-----------------------------------------------------------------------|
| "name" is missing         | 400 Bad Request | "name": \["This field is required."]                                   |
| "name" is not unique      | 400 Bad Request | "name": \["This field must be unique."]                                |
| "name" is blank           | 400 Bad Request | "name": \["This field may not be blank."]                              |
| "name" is not too long    | 400 Bad Request | "name": \["Ensure this field has no more than 80 characters."]         |
| "description" is too long | 400 Bad Request | "description": \["Ensure this field has no more than 500 characters."] |
| "description" is null     | 400 Bad Request | "description": \["This field may not be null."]                        |
| limit exceed              | 400 Bad Request | "detail": "Limit of 1000 Users Groups has been exceeded."             |
| Insufficient permissions  | 403 Forbidden   | "detail": "You do not have permission to perform this action."        |

## PATCH /api/user-groups/`id`/

Updates single Users Group.

### Permissions

Requires `authentication` and `user_groups.edit` permission.

### Request

* Headers

```
Request Method: PATCH
Content-Type: application/json
Location: /api/user-groups/
Authorization: JWT access_token
```

* Body

| Key           | Type     | Required | Notes           |
|---------------|----------|----------|-----------------|
| name          | string   | true     |                 |
| description   | string   | false    |                 |

#### Validations

* name
  * This field must be unique.
  * This field may not be blank.
  * Ensure this field has no more than 80 characters.
* description
  * Ensure this field has no more than 500 characters.
  * This field may not be null

### Sample request body

```json
{
    "name": "test_group",
    "description": "Sample description"
}
```

### Response

| Key               | Type     | Notes                                    |
|-------------------|----------|------------------------------------------|
| id                | int      | Automatically generated by the backend.  |
| name              | string   |                                          |
| description       | string   |                                          |
| created\_at        | datetime |                                          |
| created\_by        | user     |                                          |
| modified\_at       | datetime |                                          |
| modified\_by       | user     |                                          |
| num\_of\_members    | int      |                                          |
| num\_of\_owners     | int      |                                          |
| \_meta.permissions | Object   | Object describing permissions.           |

* Successful status `200 OK`
* Response body schema

```json
{
    "id": 1,
    "name": "test_group",
    "description": "Sample description",
    "created_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "num_of_members": 0,
    "num_of_owners": 0,
    "created_at": "2022-04-22T09:14:46.990000+02:00",
    "modified_at": "2022-04-22T09:14:46.990000+02:00",
    "_meta": {
        "permissions": {
            "create": true,
            "list": true,
            "view": true,
            "edit": true,
            "delete": true,
            "edit_perm_sets": true,
            "edit_members": true,
            "edit_owners": true
        }
    }
}
```

### Errors

| Cause                     | Response code   | Message                                                               |
|---------------------------|-----------------|-----------------------------------------------------------------------|
| "name" is not unique      | 400 Bad Request | "name": \["This field must be unique."]                                |
| "name" is blank           | 400 Bad Request | "name": \["This field may not be blank."]                              |
| "name" is not too long    | 400 Bad Request | "name": \["Ensure this field has no more than 80 characters."]         |
| "description" is too long | 400 Bad Request | "description": \["Ensure this field has no more than 500 characters."] |
| "description" is null     | 400 Bad Request | "description": \["This field may not be null."]                        |
| Insufficient permissions  | 403 Forbidden   | "detail": "You do not have permission to perform this action."        |

## GET /api/user-groups/

Returns list of Users Groups.

### Permissions

Requires `authentication` and `user_groups.list` permission.

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Location: /api/user-groups/
Authorization: JWT access_token
```

### Response

| Key               | Type   | Notes                                                                              |
|-------------------|--------|------------------------------------------------------------------------------------|
| limit             | int    |                                                                                    |
| offset            | int    |                                                                                    |
| total\_count       | int    | Total number of results visible to the user (based on permissions).                |
| filtered\_count    | int    | Number of results visible to the user (based on permissions) with filters applied. |
| next              | url    | Next page URL (null if there is no next page)                                      |
| previous          | url    | Previous page URL (null if there is no previous page)                              |
| results           | Array  | List of results. Described in the next table.                                      |

### Response `results` array

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| id                | int      | Automatically generated by the backend. |
| name              | string   |                                         |
| description       | string   |                                         |
| created\_at        | datetime |                                         |
| created\_by        | user     |                                         |
| modified\_at       | datetime |                                         |
| modified\_by       | user     |                                         |
| num\_of\_members    | int      |                                         |
| num\_of\_owners     | int      |                                         |
| \_meta.permissions | Object   | Object describing permissions.          |

* Successful status `200 OK`
* Response body schema

```json
{
    "limit": 50,
    "offset": 0,
    "filtered_count": 2,
    "total_count": 2,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": 1,
            "name": "test_user_group",
            "description": "",
            "created_by": {
                "id": 11,
                "first_name": "ALX User Super Admin",
                "last_name": "Full permissions",
                "username": "api.alx.user+super_admin_new@gmail.com",
                "company_name": "",
                "is_deleted": false,
                "account_type": "super_admin"
            },
            "modified_by": {
                "id": 11,
                "first_name": "ALX User Super Admin",
                "last_name": "Full permissions",
                "username": "api.alx.user+super_admin_new@gmail.com",
                "company_name": "",
                "is_deleted": false,
                "account_type": "super_admin"
            },
            "num_of_members": 0,
            "num_of_owners": 0,
            "created_at": "2022-04-22T09:14:46.990000+02:00",
            "modified_at": "2022-04-22T09:14:46.990000+02:00",
            "_meta": {
                "permissions": {
                    "create": true,
                    "list": true,
                    "view": true,
                    "edit": true,
                    "delete": true,
                    "edit_perm_sets": true
                }
            }
        },
        {
            "id": 2,
            "name": "test_user_group1",
            "description": "",
            "created_by": {
                "id": 11,
                "first_name": "ALX User Super Admin",
                "last_name": "Full permissions",
                "username": "api.alx.user+super_admin_new@gmail.com",
                "company_name": "",
                "is_deleted": false,
                "account_type": "super_admin"
            },
            "modified_by": {
                "id": 11,
                "first_name": "ALX User Super Admin",
                "last_name": "Full permissions",
                "username": "api.alx.user+super_admin_new@gmail.com",
                "company_name": "",
                "is_deleted": false,
                "account_type": "super_admin"
            },
            "num_of_members": 0,
            "num_of_owners": 0,
            "created_at": "2022-04-22T09:15:04.586000+02:00",
            "modified_at": "2022-04-22T09:15:04.586000+02:00",
            "_meta": {
                "permissions": {
                    "create": true,
                    "list": true,
                    "view": true,
                    "edit": true,
                    "delete": true,
                    "edit_perm_sets": true,
                    "edit_members": true,
                    "edit_owners": true
                }
            }
        }
    ]
}
```

### Sorting

| Parameter        | Example                                      | Notes          |
|------------------|----------------------------------------------|----------------|
| id               | /api/user-groups/?ordering=id                | Ascending      |
| id               | /api/user-groups/?ordering=-id               | Descending (-) |
| name             | /api/user-groups/?ordering=name              | Ascending      |
| name             | /api/user-groups/?ordering=-name             | Descending (-) |
| created\_at       | /api/user-groups/?ordering=created\_at        | Ascending      |
| created\_at       | /api/user-groups/?ordering=-created\_at       | Descending (-) |
| modified\_at      | /api/user-groups/?ordering=modified\_at       | Ascending      |
| modified\_at      | /api/user-groups/?ordering=-modified\_at      | Descending (-) |
| num\_of\_members   | /api/user-groups/?ordering=num\_of\_members    | Ascending      |
| num\_of\_members   | /api/user-groups/?ordering=-num\_of\_members   | Descending (-) |
| num\_of\_owners    | /api/user-groups/?ordering=num\_of\_owners     | Ascending      |
| num\_of\_owners    | /api/user-groups/?ordering=-num\_of\_owners    | Descending (-) |

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter      | Type         |
|----------------|--------------|
| id             | int          |
| name           | string       |
| created\_at     | datetime     |
| created\_by     | user         |
| modified\_at    | datetime     |
| modified\_by    | user         |
| num\_of\_members | int          |
| num\_of\_owners  | int          |
| members        | (exact only) |

### Errors

| Error                         | Response code   | Message                                                                             |
|-------------------------------|-----------------|-------------------------------------------------------------------------------------|
| Wrong ordering value          | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."] |

## GET api/user-groups/`id`/

Returns single Users Group by `id`.

### Permissions

Requires `authentication` and `user_groups.view` permission.

### URL parameters

| Key                      | Type     | Notes |
|--------------------------|----------|-------|
| id                       | id       |       |

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Location: api/user-groups/1/
Authorization: JWT access_token
```

### Response

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| id                | int      | Automatically generated by the backend. |
| name              | string   |                                         |
| description       | string   |                                         |
| created\_at        | datetime |                                         |
| created\_by        | user     |                                         |
| modified\_at       | datetime |                                         |
| modified\_by       | user     |                                         |
| num\_of\_members    | int      |                                         |
| num\_of\_owners     | int      |                                         |
| \_meta.permissions | Object   | Object describing permissions.          |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": 1,
    "name": "test_user_group",
    "description": "",
    "created_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "num_of_members": 0,
    "num_of_owners": 0,
    "created_at": "2022-04-22T09:14:46.990000+02:00",
    "modified_at": "2022-04-22T09:14:46.990000+02:00",
    "_meta": {
        "permissions": {
            "create": true,
            "list": true,
            "view": true,
            "edit": true,
            "delete": true,
            "edit_perm_sets": true,
            "edit_members": true,
            "edit_owners": true
        }
    }
}
```

### Errors

| Error                                | Response code | Message                                                        |
|--------------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions             | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| Users Group with "id" does not exist | 404 Not Found | "detail": "Not found."                                         |

## DELETE /api/user-groups/`users-group_id`/

Remove a Users Group with checking if no used anywhere.

### Permissions

Requires `authentication` and `user_groups.delete` permission.

### Request example

* Headers

```
Request Method: DELETE
Location: /api/user-groups/1/
Authorization: JWT access_token
```

### Response example

* Status `204 No Content`
* Body

### Errors

| Error                                              | Response code | Message                                                             |
|----------------------------------------------------|---------------|---------------------------------------------------------------------|
| Users Group in use - Sequences                     | 400 Forbidden | "detail": "Users Group is in use by Sequences."                     |
| Users Group in use - Permission sets               | 400 Forbidden | "detail": "Users Group is in use by User group permission sets."    |
| Users Group in use - ObjectClassField              | 400 Forbidden | "detail": "Users Group is in use by Object class fields."           |
| Users Group in use - Object Class Permission sets  | 400 Forbidden | "detail": "Users Group is in use by Object Class permission sets."  |
| Users Group in use - Task assignment               | 400 Forbidden | "detail": "Users Group is in use by Task assignment."               |
| Users Group in use - Object Record Permission sets | 400 Forbidden | "detail": "Users Group is in use by Object Record permission sets." |
| Insufficient permissions                           | 403 Forbidden | "detail": "You do not have permission to perform this action."      |
| Users Group does not exist                         | 404 Forbidden | "detail": "Not found"                                               |

## GET /api/user-groups/`users_group_id`/usage/

### Permissions

Requires `authentication` and `user_groups.view` permission.

### Request example

* Headers

```
Request Method: GET
Location: /api/user-groups/1/usage/
Authorization: JWT access_token
```

### Response

| Key                                   | Type       | Notes                           |
|---------------------------------------|------------|---------------------------------|
| sequences                             | array      |                                 |
| num\_of\_sequences                      | int        |                                 |
| user\_groups                           | array      |                                 |
| num\_of\_user\_groups                    | int        |                                 |
| object\_classes\_fields                 | array      |                                 |
| num\_of\_object\_classes\_fields          | int        |                                 |
| object\_classes\_permission\_sets        | array      |                                 |
| num\_of\_object\_classes\_permission\_sets | int        |                                 |
| object\_record\_permission\_sets         | array      |                                 |
| num\_of\_object\_record\_permission\_sets  | int        |                                 |
| num\_of\_tasks                          | int        |                                 |

### Response `sequences` array

| Key          | Type       | Notes                                          |
|--------------|------------|------------------------------------------------|
| id           | int        | Sequence id                                    |
| name         | str        | Name of sequence                               |

### Response `user_groups` array

| Key                     | Type  | Notes                             |
|-------------------------|-------|-----------------------------------|
| id                      | int   | Users Group id                    |
| name                    | str   | Users Group name                  |
| permission\_sets         | array | Users Group Permission sets array |

### Response `permission_sets` array

| Key          | Type       | Notes                |
|--------------|------------|----------------------|
| id           | int        | Permission set id    |
| name         | str        | Permission set  name |

### Response `object_classes_fields` array

| Key               | Type       | Notes                 |
|-------------------|------------|-----------------------|
| id                | int        | ObjectClassField id   |
| name              | str        | ObjectClassField name |
| object\_class\_id   | int        | Field Class id        |
| object\_class\_name | str        | Field Class name      |

### Response `object_classes_permission_sets` array

| Key               | Type       | Notes                      |
|-------------------|------------|----------------------------|
| id                | int        | Permission set id          |
| name              | str        | Permission set name        |
| object\_class\_id   | int        | Permission set Class id    |
| object\_class\_name | str        | Permission set Class name  |

### Response `object_record_permission_sets` array

| Key               | Type       | Notes                      |
|-------------------|------------|----------------------------|
| id                | int        | Permission set id          |
| name              | str        | Permission set name        |
| object\_class\_id   | int        | Permission set Class id    |
| object\_class\_name | str        | Permission set Class name  |

### Response `tasks` array

| Key               | Type       | Notes                      |
|-------------------|------------|----------------------------|
| id                | int        | Permission set id          |
| name              | str        | Permission set name        |

### Response example

* Status `200 OK`
* Body

```json
{
    "sequences": [
        {
            "id": 1,
            "name": "sequence1"
        },
        {
            "id": 7,
            "name": "sequence_test"
        }
    ],
    "num_of_sequences": 2,
    "user_groups": [
        {
            "id": 12,
            "name": "Group12",
            "permission_sets": [
                {
                    "id": 3,
                    "name": "Custom1"
                }
            ]
        }
    ],
    "num_of_user_groups": 1,
    "object_classes_fields": [
        {
            "id": 1,
            "name": "Name1",
            "object_class_id": 2,
            "object_class_name": "Class2"
        },
        {
            "id": 2,
            "name": "Name2",
            "object_class_id": 1,
            "object_class_name": "Class1"
        }
    ],
    "num_of_object_classes_fields": 2,
    "object_classes_permission_sets": [
        {
            "id": 1,
            "name": "PermSet1",
            "object_class_id": 2,
            "object_class_name": "Class2"
        }
    ],
    "num_of_object_classes_permission_sets": 1,
    "object_record_permission_sets": [
        {
            "id": 1,
            "name": "PermSet1",
            "object_class_id": 2,
            "object_class_name": "Class2"
        }
    ],
    "num_of_object_record_permission_sets": 1,
    "num_of_tasks": 1
}
```

### Errors

| Error                 | Response code   | Message                                                        |
|-----------------------|-----------------|----------------------------------------------------------------|
| User Group in use     | 400 Forbidden   | "detail": "Users Group is in use by Sequences."                      |
| `id` is invalid       | 404 Bad Request | 'detail': "Not found."                                         |
| Unauthorized API call | 403 Bad Request | 'detail': "You do not have permission to perform this action." |

## OPTIONS /api/user-groups/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Request Method: OPTIONS
Content-Type: application/json
Location: /api/user-groups/
Authorization: JWT access_token
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "name",
                "type": "string",
                "predicates": [
                    "exact",
                    "iexact",
                    "contains",
                    "icontains",
                    "startswith",
                    "istartswith",
                    "endswith",
                    "iendswith"
                ],
                "sort_ok": true
            },
            {
                "alias": "description",
                "type": "string",
                "predicates": [],
                "sort_ok": false
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "modified_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "num_of_members",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "num_of_owners",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "modified_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            }
        ]
    },
    "details": {
        "schema": [
            {
                "alias": "name",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 80
                    }
                ]
            },
            {
                "alias": "description",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 500
                    }
                ]
            }
        ]
    },
    "restrictions": {
        "limit_items": 1000
    }
}
```

## GET /api/user-groups/autocomplete/

List of User Groups sorted by `name` ascending by default, based on query parameters for autocomplete widgets.

### Permissions

Requires `authentication` only.

### Request example

* Headers

```
Request Method: GET
Location: /api/user-groups/autocomplete/
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        |                                                                                  |
| offset            | int        |                                                                                  |
| total\_count       | int        | Total number of forms visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of forms visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key                     | Type | Notes           |
|-------------------------|------|-----------------|
| value                   | int  | User Group ID   |
| text                    | str  | User Group name |
| num\_of\_members          | int  |                 |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 1,
  "total_count": 20,
  "next": null,
  "previous": null,
  "results": [
    {
      "value": 12,
      "text": "Some group name",
      "num_of_members": 2
    }
  ]
}
```

### Sorting

| Parameter   | Example                                                 | Notes          |
|-------------|---------------------------------------------------------|----------------|
| text        | {build}/api/user-groups/autocomplete/?ordering=text     | Ascending      |
| text        | {build}/api/user-groups/autocomplete/?ordering=-text    | Descending (-) |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter    | Predicates | Example                                                         | Values   |
|--------------|------------|-----------------------------------------------------------------|----------|
| text         | icontains  | {build}/api/user-groups/autocomplete/?text\_\_icontains=template  |          |

### Errors

| Error                         | Response code   | Message                                                                                         |
|-------------------------------|-----------------|-------------------------------------------------------------------------------------------------|
| Wrong ordering value          | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."]             |

## GET /api/user-groups/autocomplete/users-combined/

::: danger Deprecated
⚠️ This endpoint is no longer supported starting from version **11.0.0**.
:::

Returns combined list of users and users groups.

### Permissions

Requires `authentication` and `superadmin` or `standard_user` account type.

### Request example

* Headers

```
Request Method: GET
Location: /api/user-groups/autocomplete/users-combined/
Authorization: JWT access_token
```

### Response

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        |                                                                                  |
| offset            | int        |                                                                                  |
| total\_count       | int        | Total number of items visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of items visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

Users Group result schema

| Key      | Type   | Notes                                                 |
|----------|--------|-------------------------------------------------------|
| id       | id     |                                                       |
| resource | string |                                                       |
| value    | int    |                                                       |
| text     | string |                                                       |

User result schema

| Key          | Type   | Notes                                                 |
|--------------|--------|-------------------------------------------------------|
| id           | id     |                                                       |
| resource     | string |                                                       |
| value        | int    |                                                       |
| text         | string |                                                       |
| first\_name   | string |                                                       |
| last\_name    | string |                                                       |
| company\_name | string |                                                       |
| account\_type | string |                                                       |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 2,
  "total_count": 2,
  "next": null,
  "previous": null,
  "results": [
    {
      "id": 1,
      "resource": "users",
      "value": 345,
      "text": "John Smith (j.smith@alx.test)",
      "username": "j.smith@alx.test",
      "first_name": "John",
      "last_name": "Smith",
      "company_name": "Autologyx",
      "account_type": "full"
    },
    {
      "id": 2,
      "resource": "user_groups",
      "value": 345,
      "text": "Smith group"
    }
  ]
}
```

### Sorting

| Parameter   | Example                                                                    | Notes          |
|-------------|----------------------------------------------------------------------------|----------------|
| text        | {build}/api/user-groups/autocomplete/users-combined/?ordering=text         | Ascending      |
| text        | {build}/api/user-groups/autocomplete/users-combined/?ordering=-text        | Descending (-) |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter     | Type   | Notes      |
|---------------|--------|------------|
| id            | int    |            |
| text          | string |            |
| account\_type  |        | Only exact |

::: tip Important
Specifying by what fields users should be filtered:
Filtering users should be specified by users\_search\_in parameter. It can be applied multiple times.
Each usage of the parameter receives single or multiple comma separated possible values:

1. first\_name
2. last\_name
3. username
4. company\_name

If single usage of the parameter has multi comma separated fields, then they are concatenated by whitespace in the backend.
Each usage of users\_search\_in parameter is joined by OR operator.

> Sample:
> {build}/api/user-groups/autocomplete/users-combined/?users\_search\_in=first\_name,last\_name\&users\_search\_in=username\&text\_\_icontains=smith

Means:
Return users if "smith" (case insensitive) matches to their:
• first\_name + " " + last\_name (for example "John Smith")
• OR username (for example "j.smith@alx.test")
users\_search\_in parameter is optional. If the parameter is not passed, then users are search by text.

:::

### Errors

| Error                                | Response code      | Message                                                                                |
|--------------------------------------|--------------------|----------------------------------------------------------------------------------------|
| Invalid choice                       | 400 Bad request    | {"ordering": "Select a valid choice. first\_name is not one of the available choices."} |
| Wrong field name                     | 400 Bad request    | {"users\_search\_in": "wrong\_field is not one of the available choices."}                |
| Requesting user is not authenticated | 401 Unauthorized   | "detail": "Authentication credentials were not provided."                              |
| Unauthorized API call                | 403 Forbidden      | "detail": "You do not have permission to perform this action."                         |

## OPTIONS /api/user-groups/`id`/users/

### Permissions

Any user.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> OPTIONS /api/user-groups/1/users/

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "username",
                "type": "string",
                "predicates": [
                    "exact",
                    "iexact",
                    "contains",
                    "icontains",
                    "startswith",
                    "istartswith",
                    "endswith",
                    "iendswith"
                ],
                "sort_ok": true
            },
            {
                "alias": "added_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "first_name",
                "type": "string",
                "predicates": [],
                "sort_ok": true
            },
            {
                "alias": "last_name",
                "type": "string",
                "predicates": [],
                "sort_ok": true
            },
            {
                "alias": "membership",
                "type": "enum",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "values": [
                    {
                        "value": "member",
                        "text": "Member"
                    },
                    {
                        "value": "non_member",
                        "text": "Non-member"
                    },
                    {
                        "value": "owner",
                        "text": "Owner"
                    }
                ]
            }
        ]
    },
    "search": "/api/user-groups/1/users/?search=" 
}
```

## GET /api/user-groups/`id`/users/

### Permissions

Requires `authentication` and `user_groups.view`

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> GET /api/user-groups/1/users/

### Response

The response contains only users for which request user has `users.list` permission.

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of items visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of items visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key          | Type     | Notes                                                 |
|--------------|----------|-------------------------------------------------------|
| id           | id       |                                                       |
| username     | string   |                                                       |
| first\_name   | string   |                                                       |
| last\_name    | string   |                                                       |
| company\_name | string   |                                                       |
| membership   | string   |                                                       |
| added\_at     | datetime |                                                       |

* Successful status `200 OK`
* Response body schema

```json
{
    "limit": 50,
    "offset": 0,
    "filtered_count": 2,
    "total_count": 2,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": 2,
            "username": "alx.dev@autologyx.com",
            "added_at": null,
            "first_name": "ALX",
            "last_name": "Developer",
            "company_name": "",
            "membership": "non_member"
        },
        {
            "id": 3,
            "username": "a20211105131728283@yopmail.com",
            "added_at": null,
            "first_name": "Alicja",
            "last_name": "Brzęczyszczykiewicz",
            "company_name": "",
            "membership": "non_member"
        }
    ]
}
```

### Sorting

| Parameter   | Example                                                  | Notes           |
|-------------|----------------------------------------------------------|-----------------|
| id          | {build}/api/user-groups/{id}/users/?ordering=id          | Ascending       |
| id          | {build}/api/user-groups/{id}/users/?ordering=-id         | Descending (-)  |
| username    | {build}/api/user-groups/{id}/users/?ordering=username    | Ascending       |
| username    | {build}/api/user-groups/{id}/users/?ordering=-username   | Descending (-)  |
| added\_at    | {build}/api/user-groups/{id}/users/?ordering=added\_at    | Ascending       |
| added\_at    | {build}/api/user-groups/{id}/users/?ordering=-added\_at   | Descending (-)  |
| first\_name  | {build}/api/user-groups/{id}/users/?ordering=first\_name  | Ascending       |
| first\_name  | {build}/api/user-groups/{id}/users/?ordering=-first\_name | Descending (-)  |
| last\_name   | {build}/api/user-groups/{id}/users/?ordering=last\_name   | Ascending       |
| last\_name   | {build}/api/user-groups/{id}/users/?ordering=-last\_name  | Descending (-)  |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter  | Type      |
|------------|-----------|
| id         | int       |
| username   | string    |
| membership | enum      |
| added\_at   | datetime  |

### Search

Search Functionality based on [DRF SearchFilter](https://www.django-rest-framework.org/api-guide/filtering/#searchfilter)

The search is case-insensitive.
This API endpoint supports searching for users based on the following fields: `first_name`, `last_name`, and `username`.
The search functionality allows for partial matches and can handle quoted phrases as single search terms.
If multiple search terms are used, then objects will be returned to the list only if all the provided terms are matched.
Search Fields

```
first_name
last_name
username
```

Main

Usage

To perform a search, include the search query parameter in your request. The search will be executed against the specified fields.
Examples

#### Search by single term:

```
GET /api/user-groups/1/users/?search=John
```

This will return users whose first\_name, last\_name, or username contains `john`.

#### Search by multiple terms:

```
GET /api/user-groups/1/users/?search=john smith
```

This will return users whose first\_name, last\_name, or username contains both `john` and `smith`.

#### Search by quoted phrase:

```
GET /api/user-groups/1/users/?search="john smith"
```

This will return users whose first\_name, last\_name, or username contains the exact phrase `"john smith"`.

### Errors

| Error                                | Response code      | Message                                                                                |
|--------------------------------------|--------------------|----------------------------------------------------------------------------------------|
| Invalid choice                       | 400 Bad request    | {"ordering": "Select a valid choice. first\_name is not one of the available choices."} |
| Requesting user is not authenticated | 401 Unauthorized   | "detail": "Authentication credentials were not provided."                              |
| Unauthorized API call                | 403 Forbidden      | "detail": "You do not have permission to perform this action."                         |

## POST /api/user-groups/`id`/members/

Batch operation - adds single or multiple users (members) to given group. Duplicates are silently ignored.

*UsersGroup.num\_of\_members*  will  be updated.
*UsersGroup fields modified\_at* and *modified\_by* will be updated.
*UsersGroupMembers.created\_at* and *created\_by* fields will be set if relation does not exist.

### Permissions

Requires `authentication` and `user_groups.edit_members`

### Request

* Headers

```
Request Method: POST
Content-Type: application/json
Location: /api/user-groups/`id`/members/
Authorization: JWT access_token
```

* Schema

> POST /api/user-groups/1/members/

* Body

list of user ids

```json
[
  1, 
  2, 
  3
] 
```

#### Validations

* 1 Time Completion accounts cannot be members.
* body must be a list of user ids.
* user id must be an integer.
* user id must exist in the system.
* up to 50 users can be added at once.
* limit of 1000000 User Group Members cannot be exceeded.

### Sample request body

```json
[
  1, 
  2, 
  3
] 
```

### Response

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| id                | int      | Automatically generated by the backend. |
| name              | string   |                                         |
| description       | string   |                                         |
| created\_at        | datetime |                                         |
| created\_by        | user     |                                         |
| modified\_at       | datetime |                                         |
| modified\_by       | user     |                                         |
| num\_of\_members    | int      |                                         |
| num\_of\_owners     | int      |                                         |
| \_meta.permissions | Object   | Object describing permissions.          |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": 1,
    "name": "test_user_group",
    "description": "",
    "created_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "num_of_members": 3,
    "num_of_owners": 0,
    "created_at": "2022-04-22T09:14:46.990000+02:00",
    "modified_at": "2022-04-22T09:14:46.990000+02:00",
    "_meta": {
        "permissions": {
            "create": true,
            "list": true,
            "view": true,
            "edit": true,
            "delete": true,
            "edit_perm_sets": true,
            "edit_members": true,
            "edit_owners": true
        }
    }
}
```

### Errors

| Cause                                        | Response code      | Message                                                                                      |
|----------------------------------------------|--------------------|----------------------------------------------------------------------------------------------|
| empty list                                   | 400 Bad Request    | "detail": \["This list may not be empty."]                                                    |
| max batch limit exceeded                     | 400 Bad Request    | "detail": \["Up to 50 items allowed."]                                                        |
| null/empty list sent instead of list of ids  | 400 Bad Request    | "detail": \["This list may not be empty"]                                                     |
| Insufficient permissions to user             | 400 Bad Request    | "detail": \["You do not have permission to add user "user\_id" to User Group "group\_id"."] |
| wrong type send instead of list of ids       | 400 Bad Request    | "detail": \["Expected a list of items but got type "type"."]                                |
| wrong type in a list                         | 400 Bad Request    | "detail": \["Incorrect type. Expected pk value, received "type"."]                          |
| not existed user on list                     | 400 Bad Request    | "detail": \["Invalid pk "pk" - object does not exist."]                                     |
| 1 Time Completion accounts cannot be members | 400 Bad Request    | "detail": \["1 Time Completion account "user\_1tc\_id" cannot be member."]                    |
| limit exceed                                 | 400 Bad Request    | "detail": \["Limit of 1000000 User Group Members has been exceeded."]                         |
| Requesting user is not authenticated         | 401 Unauthorized   | "detail": "Authentication credentials were not provided."                                    |
| Insufficient permissions                     | 403 Forbidden      | "detail": \["You do not have permission to perform this action."]                             |

## OPTIONS /api/user-groups/`id`/members/

### Permissions

Requires `authentication`

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> OPTIONS /api/user-groups/1/members/

### Response

* Successful status `200 OK`
* Response body:

```json
{ 
    "batch": { 
        "type": "set", 
        "required": true, 
        "autocomplete": "/api/users/autocomplete/?account_type!=one_time_completion&text__icontains=" 
    }, 
    "restrictions": { 
        "limit_items": 1000000, 
        "limit_items_in_batch": 50 
    } 
} 
```

## DELETE /api/user-groups/`user_group_id`/members/

Batch operation - removes users (members) from a given group. Duplicates are silently ignored.

*UsersGroup.num\_of\_members*  will  be updated.
UsersGroup fields *modified\_at* and *modified\_by* will be updated.

### Permissions

Requires `authentication` and `user_groups.edit_members` permission.

### Request

* URL parameters

| Key            | Notes                          |
|----------------|--------------------------------|
| user\_group\_id  | User Group ID                  |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> DELETE /api/user-groups/1/members/

* Body

list of user ids

```json
[
  1, 
  2, 
  3
] 
```

### Response

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| id                | int      | Automatically generated by the backend. |
| name              | string   |                                         |
| description       | string   |                                         |
| created\_at        | datetime |                                         |
| created\_by        | user     |                                         |
| modified\_at       | datetime |                                         |
| modified\_by       | user     |                                         |
| num\_of\_members    | int      |                                         |
| num\_of\_owners     | int      |                                         |
| \_meta.permissions | Object   | Object describing permissions.          |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": 1,
    "name": "test_user_group",
    "description": "",
    "created_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "num_of_members": 0,
    "num_of_owners": 0,
    "created_at": "2022-04-22T09:14:46.990000+02:00",
    "modified_at": "2022-04-22T09:14:46.990000+02:00",
    "_meta": {
        "permissions": {
            "create": true,
            "list": true,
            "view": true,
            "edit": true,
            "delete": true,
            "edit_perm_sets": true,
            "edit_members": true,
            "edit_owners": true
        }
    }
}
```

### Errors

| Cause                                       | Response code      | Message                                                             |
|---------------------------------------------|--------------------|---------------------------------------------------------------------|
| empty list                                  | 400 Bad Request    | "detail": \["This list may not be empty."]                           |
| max batch limit exceeded                    | 400 Bad Request    | "detail": \["Up to 50 items allowed."]                               |
| null/empty list sent instead of list of ids | 400 Bad Request    | "detail": \["This list may not be empty"]                            |
| wrong type send instead of list of ids      | 400 Bad Request    | "detail": \["Expected a list of items but got type "type"."]       |
| wrong type on a list                        | 400 Bad Request    | "detail": \["Incorrect type. Expected pk value, received "type"."] |
| not existed user on list                    | 400 Bad Request    | "detail": \["Invalid pk "pk" - object does not exist."]            |
| Requesting user is not authenticated        | 401 Unauthorized   | "detail": "Authentication credentials were not provided."           |
| Insufficient permissions                    | 403 Forbidden      | "detail": \["You do not have permission to perform this action."]    |

## GET /api/user-groups/`user_group_id`/members/

Returns list of Users Group members.

### Permissions

Requires `authentication` and `user_groups.view` permission.

### Request example

* Headers

```
Request Method: GET
Content-Type: application/json
Location: /api/user-groups/1/members/
Authorization: JWT access_token
```

### Response

| Key               | Type   | Notes                                                                              |
|-------------------|--------|------------------------------------------------------------------------------------|
| limit             | int    |                                                                                    |
| offset            | int    |                                                                                    |
| total\_count       | int    | Total number of results visible to the user (based on permissions).                |
| filtered\_count    | int    | Number of results visible to the user (based on permissions) with filters applied. |
| next              | url    | Next page URL (null if there is no next page)                                      |
| previous          | url    | Previous page URL (null if there is no previous page)                              |
| results           | Array  | List of results. Described in the next table.                                      |

### Response `results` array

| Key               | Type   | Notes                          |
|-------------------|--------|--------------------------------|
| id                | int    | User id                        |
| username          | string |                                |
| added\_at          | string |                                |
| first\_name        | string |                                |
| last\_name         | string |                                |
| company\_name      | string |                                |
| membership        | string |                                |

* Successful status `200 OK`
* Response body schema

```json
{
    "limit": 50,
    "offset": 0,
    "filtered_count": 1,
    "total_count": 1,
    "next": null,
    "previous": null,
    "results": [
        {
            "id": 1,
            "username": "Name",
            "added_at": "2022-04-22T09:14:46.990000+02:00",
            "first_name": "First",
            "last_name": "Last",
            "company_name": "",
            "membership": "member"
        }
    ]
}
```

### Sorting

| Parameter      | Example                                        | Notes          |
|----------------|------------------------------------------------|----------------|
| id             | /api/user-groups/1/members/?ordering=id        | Ascending      |
| id             | /api/user-groups/1/members/?ordering=-id       | Descending (-) |
| username       | /api/user-groups/1/members/?ordering=username  | Ascending      |
| username       | /api/user-groups/1/members/?ordering=-username | Descending (-) |
| added\_at       | /api/user-groups/1/members/?ordering=added\_at  | Ascending      |
| added\_at       | /api/user-groups/1/members/?ordering=-added\_at | Descending (-) |

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter  | Type         |
|------------|--------------|
| id         | int          |
| username   | string       |
| membership | (exact only) |

### Errors

| Error                                 | Response code   | Message                                                                               |
|---------------------------------------|-----------------|---------------------------------------------------------------------------------------|
| Wrong ordering value                  | 400 Bad Request | "membership": \["Select a valid choice. {value} is not one of the available choices."] |
| Insufficient permissions              | 403 Forbidden   | "detail": \["You do not have permission to perform this action."]                      |
| Users Group with "id" does not exist  | 404 Not Found   | "detail": "Not found."                                                                |

## DELETE /api/user-groups/`user_group_id`/members/all/

Clears all users (members) from given users group, so after successful operation there isn’t any member assigned.

*UsersGroup.num\_of\_members*  will  be updated.
UsersGroup fields *modified\_at* and *modified\_by* will be updated.

### Permissions

Requires `authentication` and `user_groups.edit_members` permission.

### Request

* URL parameters

| Key            | Notes                          |
|----------------|--------------------------------|
| user\_group\_id  | User Group ID                  |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> DELETE /api/user-groups/1/members/all/

### Response

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| id                | int      | Automatically generated by the backend. |
| name              | string   |                                         |
| description       | string   |                                         |
| created\_at        | datetime |                                         |
| created\_by        | user     |                                         |
| modified\_at       | datetime |                                         |
| modified\_by       | user     |                                         |
| num\_of\_members    | int      |                                         |
| num\_of\_owners     | int      |                                         |
| \_meta.permissions | Object   | Object describing permissions.          |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": 1,
    "name": "test_user_group",
    "description": "",
    "created_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "num_of_members": 0,
    "num_of_owners": 0,
    "created_at": "2022-04-22T09:14:46.990000+02:00",
    "modified_at": "2022-04-22T09:14:46.990000+02:00",
    "_meta": {
        "permissions": {
            "create": true,
            "list": true,
            "view": true,
            "edit": true,
            "delete": true,
            "edit_perm_sets": true,
            "edit_members": true,
            "edit_owners": true
        }
    }
}
```

### Errors

| Cause                                       | Response code      | Message                                                             |
|---------------------------------------------|--------------------|---------------------------------------------------------------------|
| Requesting user is not authenticated        | 401 Unauthorized   | "detail": "Authentication credentials were not provided."           |
| Insufficient permissions                    | 403 Forbidden      | "detail": \["You do not have permission to perform this action."]    |

## POST /api/user-groups/`id`/owners/

Batch operation - adds single or multiple users (owners) to a given group. Duplicates are silently ignored.

*UsersGroup.num\_of\_members*  will  be updated.
*UsersGroup.num\_of\_owners*  will  be updated.
*UsersGroup fields modified\_at* and *modified\_by* will be updated.

### Permissions

Requires `authentication` and `user_groups.edit_owners`

### Request

* Headers

```
Request Method: POST
Content-Type: application/json
Location: /api/user-groups/`id`/owners/
Authorization: JWT access_token
```

* Schema

> POST /api/user-groups/1/owners/

* Body

list of user ids

```json
[
  1, 
  2, 
  3
] 
```

#### Validations

* 1 Time Completion accounts cannot be owners.
* body must be a list of user ids.
* user id must be an integer.
* user id must exist in the system.
* up to 50 users can be added at once.
* limit of 1000000 User Group Members cannot be exceeded.

### Sample request body

```json
[
  1, 
  2, 
  3
] 
```

### Response

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| id                | int      | Automatically generated by the backend. |
| name              | string   |                                         |
| description       | string   |                                         |
| created\_at        | datetime |                                         |
| created\_by        | user     |                                         |
| modified\_at       | datetime |                                         |
| modified\_by       | user     |                                         |
| num\_of\_members    | int      |                                         |
| num\_of\_owners     | int      |                                         |
| \_meta.permissions | Object   | Object describing permissions.          |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": 1,
    "name": "test_user_group",
    "description": "",
    "created_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "num_of_members": 0,
    "num_of_owners": 3,
    "created_at": "2022-04-22T09:14:46.990000+02:00",
    "modified_at": "2022-04-22T09:14:46.990000+02:00",
    "_meta": {
        "permissions": {
            "create": true,
            "list": true,
            "view": true,
            "edit": true,
            "delete": true,
            "edit_perm_sets": true,
            "edit_members": true,
            "edit_owners": true
        }
    }
}
```

### Errors

| Cause                                       | Response code    | Message                                                                                                   |
|---------------------------------------------|------------------|-----------------------------------------------------------------------------------------------------------|
| empty list                                  | 400 Bad Request  | "detail": \["This list may not be empty."]                                                                 |
| max batch limit exceeded                    | 400 Bad Request  | "detail": \["Up to 50 items allowed."]                                                                     |
| null/empty list sent instead of list of ids | 400 Bad Request  | "detail": \["This list may not be empty"]                                                                  |
| Insufficient permissions to user            | 400 Bad Request  | "detail": \["You do not have permission to add user "user\_id" as an owner of User Group "group\_id"."]  |
| wrong type send instead of list of ids      | 400 Bad Request  | "detail": \["Expected a list of items but got type "type"."]                                             |
| wrong type in a list                        | 400 Bad Request  | "detail": \["Incorrect type. Expected pk value, received "type"."]                                       |
| not existed user on list                    | 400 Bad Request  | "detail": \["Invalid pk "pk" - object does not exist."]                                                  |
| 1 Time Completion accounts cannot be owner  | 400 Bad Request  | "detail": \["1 Time Completion account "user\_1tc\_id" cannot be owner."]                                  |
| limit exceed                                | 400 Bad Request  | "detail": \["Limit of 1000000 User Group Members has been exceeded."]                                      |
| Requesting user is not authenticated        | 401 Unauthorized | "detail": "Authentication credentials were not provided."                                                 |
| Insufficient permissions                    | 403 Forbidden    | "detail": \["You do not have permission to perform this action."]                                          |

## OPTIONS /api/user-groups/`id`/owners/

### Permissions

Requires `authentication`

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> OPTIONS /api/user-groups/1/members/

### Response

* Successful status `200 OK`
* Response body:

```json
{ 
    "batch": { 
        "type": "set", 
        "required": true, 
        "autocomplete": "/api/users/autocomplete/?account_type!=one_time_completion&text__icontains=" 
    }, 
    "restrictions": { 
        "limit_items": 10, 
        "limit_items_in_batch": 10 
    } 
} 
```

## DELETE /api/user-groups/`id`/owners/

Batch operation - removes users (owners) from a given group. Duplicates are silently ignored.

*UsersGroup.num\_of\_members*  will  be updated.
*UsersGroup.num\_of\_owners*  will  be updated.
UsersGroup fields *modified\_at* and *modified\_by* will be updated.

### Permissions

Requires `authentication` and `user_groups.edit_owners` permission.

### Request

* URL parameters

| Key | Notes                          |
|-----|--------------------------------|
| id  | User Group ID                  |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> DELETE /api/user-groups/1/owners/

* Body

list of user ids

```json
[
  1, 
  2, 
  3
] 
```

### Response

| Key               | Type     | Notes                                   |
|-------------------|----------|-----------------------------------------|
| id                | int      | Automatically generated by the backend. |
| name              | string   |                                         |
| description       | string   |                                         |
| created\_at        | datetime |                                         |
| created\_by        | user     |                                         |
| modified\_at       | datetime |                                         |
| modified\_by       | user     |                                         |
| num\_of\_members    | int      |                                         |
| num\_of\_owners     | int      |                                         |
| \_meta.permissions | Object   | Object describing permissions.          |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": 1,
    "name": "test_user_group",
    "description": "",
    "created_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "modified_by": {
        "id": 11,
        "first_name": "ALX User Super Admin",
        "last_name": "Full permissions",
        "username": "api.alx.user+super_admin_new@gmail.com",
        "company_name": "",
        "is_deleted": false,
        "account_type": "super_admin"
    },
    "num_of_members": 0,
    "num_of_owners": 0,
    "created_at": "2022-04-22T09:14:46.990000+02:00",
    "modified_at": "2022-04-22T09:14:46.990000+02:00",
    "_meta": {
        "permissions": {
            "create": true,
            "list": true,
            "view": true,
            "edit": true,
            "delete": true,
            "edit_perm_sets": true,
            "edit_members": true,
            "edit_owners": true
        }
    }
}
```

### Errors

| Cause                                       | Response code      | Message                                                             |
|---------------------------------------------|--------------------|---------------------------------------------------------------------|
| empty list                                  | 400 Bad Request    | "detail": \["This list may not be empty."]                           |
| max batch limit exceeded                    | 400 Bad Request    | "detail": \["Up to 10 items allowed."]                               |
| null/empty list sent instead of list of ids | 400 Bad Request    | "detail": \["This list may not be empty"]                            |
| wrong type send instead of list of ids      | 400 Bad Request    | "detail": \["Expected a list of items but got type "type"."]       |
| wrong type on a list                        | 400 Bad Request    | "detail": \["Incorrect type. Expected pk value, received "type"."] |
| not existed user on list                    | 400 Bad Request    | "detail": \["Invalid pk "pk" - object does not exist."]            |
| Requesting user is not authenticated        | 401 Unauthorized   | "detail": \["Authentication credentials were not provided."]         |
| Insufficient permissions                    | 403 Forbidden      | "detail": \["You do not have permission to perform this action."]    |

## GET /api/user-groups/`id`/owners/

#### Response

* Status `405 Method Not Allowed`

---

---
url: /knowledgebase/administration/user-groups.md
---

# User Groups

User Groups help you organise users into teams, making it easier to manage permissions, assign work, and configure workflows.

This section explains how to create and manage User Groups, control visibility, and configure User Group Permission Sets.

## Getting started

If you're new to User Groups, begin with these articles:

* [Why do I need User Groups?](/knowledgebase/administration/user-groups/why-do-i-need-user-groups/)
* [What do I need to know about creating a User Group?](/knowledgebase/administration/user-groups/what-do-i-need-to-know-about-creating-a-user-group/)
* [User Group List](/knowledgebase/administration/user-groups/user-group-list/)

## Managing User Groups

Learn how to manage membership and ownership of existing User Groups.

* [Editing a User Group](/knowledgebase/administration/user-groups/editing-a-user-group/)
* [Users and Groups visibility](/knowledgebase/administration/user-groups/users-and-groups-visibility/)

## Managing permissions

Learn how User Group Permission Sets work and how to configure them.

* [User Group Permissions](/knowledgebase/administration/user-groups/user-group-permissions/)
* [Editing User Group Permissions](/knowledgebase/administration/user-groups/editing-user-group-permissions/)

## Related topics

You may also find these Administration guides useful:

* [All About Users](/knowledgebase/administration/all-about-users/)
* [Roles and Permissions](/knowledgebase/administration/roles-and-permissions/)

---

---
url: /api/catalyst/resources/users/user-preferences.md
---
# User Preferences

> User preferences are collection of a user frontend application layout settings.
> Under keys managed by fronted application are stored information about tables columns, sorting, filtering and other
> any user layout settings.

## POST /api/users/preferences/`key`/

Creates or override authenticated user preferences for passed `key`.

### Permissions

Requires `authentication`.

### Request

* URL parameters

| Key | Type   | Notes                                                           |
|-----|--------|-----------------------------------------------------------------|
| key | string | Any string following regexp rule `a-zA-z0-9\-\\` and length 255 |

* Body parameters

| Key         | Type   | Notes    |
|-------------|--------|----------|
| preferences | string | required |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/users/preferences/`key`/

{
  "preferences": <string>
} 
```

### Sample request body

```json
POST /api/users/preferences/key/

{
  "preferences": "{\"tables\": [1,2]}"
} 
```

### Validations

* preferences
  * Max length: 110000
* key
  * Max length: 255
  * Regexp `a-zA-Z0-9\-\\`

### Response

> Empty response body

* Successful status `201 Created`

### Errors

| Cause                                                                   | Response code    | Message                                                                         |
|-------------------------------------------------------------------------|------------------|---------------------------------------------------------------------------------|
| Max 5000000 User Preferences exceeded per user                          | 400 Bad Request  | "detail": \["Limit of 5000000 User Preferences for the User has been exceeded."] |
| Max 110000 characters in `performance` value exceeded                   | 400 Bad Request  | "preferences": \["Ensure this field has no more than 110000 characters."]        |
| `performance` value can't be null                                       | 400 Bad Request  | "preferences": \["This field may not be null."]                                  |
| `performance` is required in request data                               | 400 Bad Request  | "preferences": \["This field is required."]                                      |
| Max 255 characters in `key` exceeded                                    | 400 Bad Request  | "key": \["Ensure this field has no more than 255 characters."]                   |
| `key` value contains not allowed characters. Allowed are a-z, A-Z, -, \ | 400 Bad Request  | "key": \["Enter a valid value."]                                                 |

## GET /api/users/preferences/`key`/

Returns user preferences for passing key.

### Permissions

Requires `authentication`.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/users/preferences/`key`/
```

### Response

| Key            | Type   | Notes                                                                              |
|----------------|--------|------------------------------------------------------------------------------------|
| preferences    | string |                                                                                    |

* Successful status `200 OK`
* Response body schema

```json
{
  "preferences": <string>
}
```

### Sorting

Not supported

### Filtering

Not supported

### Errors

| Error                                                           | Response code | Message                                                        |
|-----------------------------------------------------------------|---------------|----------------------------------------------------------------|
| User Permissions with key for authenticated user does not exist | 404 Not Found | "detail": "Not found."                                         |

---

---
url: /knowledgebase/release-notes/release-notes-1.3/user-type-field.md
---

# User type field

We proudly present the long-awaited User Type Field, making its grand entrance to the Autologyx Catalyst platform.

This invaluable feature empowers **System Administrators** to level up their user management and streamline processes effortlessly.

With the User Type Field, **Administrators have complete control over field configuration**, enabling them to seamlessly select users registered in the system and make them available for selection on the record's page.

By defining minimum and maximum selections, Administrators ensure a smooth and error-free experience during record creation or editing.

![Users\_articles.gif](/knowledgebase/images/img_11639851419549_1776895694.png)

## Imagine the possibilities of the User Type Field

* **Assign responsible parties** to legal cases or projects, ensuring clear accountability and fostering efficient collaboration.
* **Streamline complex processes** by configuring approval workflows with authorised approvers, guaranteeing that critical documents and decisions follow the correct channels.
* **Facilitate team collaboration** by selecting and assigning team members to relevant records, ensuring streamlined communication and easy access to vital information.

## Get ready to use it

Dive into the intuitive interface of the User Type Field. Effortlessly select users, customise configurations, and create a tailored experience for your organization.

With just a few clicks, you'll be on your way to optimised user management and streamlined collaboration.

![Users2\_articles.gif](/knowledgebase/images/img_11639851419549_1776895695.png)

---

---
url: /api/catalyst/resources/users/users.md
---
# Users

This technical design describes implementation and API for Users.

# Users API

## POST /api/users/

Creates a new User.

### Permissions

Requires `authentication` and `users.create` permission.

### Request

* Body parameters

| Key                          | Type   | Notes                                                |
|------------------------------|--------|------------------------------------------------------|
| username                     | string | Unique email address                                 |
| account\_type                 | enum   | Please check "details.schema" in OPTIONS /api/users/ |
| first\_name                   | string |                                                      |
| last\_name                    | string |                                                      |
| job\_title                    | string |                                                      |
| company\_name                 | string |                                                      |
| phone                        | string |                                                      |
| mobile                       | string |                                                      |
| password                     | string |                                                      |
| roles                        | array  | Roles IDs                                            |
| delay\_activation             | bool   |                                                      |
| timezone                     | enum   |                                                      |
| is\_ip\_restriction\_enabled    | bool   |                                                      |
| allowed\_ip\_ranges            | list   |                                                      |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> POST /api/users/

```json
{ 
  "username": <str>, 
  "account_type": <enum>, 
  "first_name": <str>, 
  "last_name": <str>, 
  "job_title": <str>, 
  "company_name": <str>, 
  "phone": <str>, 
  "mobile": <str>, 
  "roles": [<int>],
  "delay_activation": <bool>,
  "is_ip_restriction_enabled": <bool>,
  "allowed_ip_ranges": [<str>]
} 
```

### Validations

* username
  * is valid email
  * is unique
  * is not null
  * max length is 100
* account\_type
  * is a valid choice
* first\_name
  * is string
  * is not null
  * max length is 100
  * min length is 1
* last\_name
  * is string
  * is not null
  * max length is 100
  * min length is 1
* job\_title
  * is string
  * is not null
  * max length is 100
* company\_name
  * is string
  * is not null
  * max length is 100
* phone
  * is string
  * is not null
  * max length is 20
* mobile
  * is string
  * is not null
  * max length is 20
* delay\_activation
  * is bool
  * is optional
* timezone
* is valid choice
* password
  * is string
  * is not null
  * password\_prevent\_reuse
  * password\_rotation\_interval
  * max\_repeating\_chars
  * min\_letters
  * min\_numbers
  * min\_symbols
  * min\_lower\_case
  * min\_upper\_case
  * min\_length
  * validated only for account types: `service_internal` and `service_external`
* is\_ip\_restriction\_enabled
  * is bool
  * is optional
* allowed\_ip\_ranges
  * is list of valid combination of IP address and network prefix (\[10.0.0.1/32", "2001:db8::/32"]).
  * both Pv4 and IPv6 addresses are allowed.
  * is optional
  * maximum number of items is 10

### Restrictions

* Separate limits for each user account type are enforced (defaults in table below).
* Limits are configurable per build.

| Account type      | Limit |
|-------------------|-------|
| Internal          | 1000  |
| External          | 2500  |
| Full              | 100   |
| 1 Time Completion | 5000  |
| Super Admin       | 25    |
| Service Internal  | 1     |
| Service External  | 5     |

* The `Service Internal` account type has the same permissions as `Super Admin`,
  except that it cannot change passwords.

### Response

| Key                       | Type     | Notes |
|---------------------------|----------|-------|
| id                        | int      |       |
| username                  | string   |       |
| account\_type              | string   |       |
| first\_name                | string   |       |
| last\_name                 | string   |       |
| job\_title                 | string   |       |
| company\_name              | string   |       |
| phone                     | string   |       |
| mobile                    | string   |       |
| status                    | enum     |       |
| activated\_at              | datetime |       |
| password\_set\_at           | datetime |       |
| password\_expires\_at       | datetime |       |
| roles                     | array    |       |
| created\_at                | datetime |       |
| created\_by                | user     |       |
| modified\_at               | datetime |       |
| modified\_by               | user     |       |
| link\_sent\_at              | datetime |       |
| link\_sent\_by              | user     |       |
| timezone                  | enum     |       |
| next\_actions              | array    |       |
| is\_ip\_restriction\_enabled | bool     |       |
| allowed\_ip\_ranges         | list     |       |
| \_meta                     | Object   |       |

* Successful status `201 Created`
* Response body schema

```json
{ 
  "id": <int>, 
  "username": <str>, 
  "account_type": <enum>, 
  "first_name": <str>, 
  "last_name": <str>, 
  "job_title": <str>, 
  "company_name": <str>, 
  "phone": <str>, 
  "mobile": <str>, 
  "status": <enum>, 
  "activated_at": <datetime>,
  "password_set_at": <datetime>,
  "password_expires_at": <datetime>, 
  "roles": [<int>], 
  "created_at": <datetime>, 
  "created_by": <user>, 
  "modified_at": <datetime>, 
  "modified_by": <user>,
  "link_sent_at": <datetime>, 
  "link_sent_by": <user>,
  "timezone": <enum>,
  "is_ip_restriction_enabled": <bool>,
  "allowed_ip_ranges": [<str>],
  "next_actions": [<str>],
  "_meta": { 
    "labels": { 
      "roles": [<str>] 
    }, 
    "permissions": { 
      "list": <bool>,
      "view": <bool>,
      "create": <bool>,
      "edit": <bool>,
      "delete": <bool>
    },
    "allowed_account_type_changes": [<str>]
  } 
} 
```

### Errors

Standard validation errors and additional custom errors enumerated in the table below:

| Cause                                                      | Response code     | Message                                                                                                     |
|------------------------------------------------------------|-------------------|-------------------------------------------------------------------------------------------------------------|
| "roles" provided with non config admin account             | 400 Bad Request   | "roles": \["Roles can be assigned only to config admin account."]                                          |
| Wrong delay\_activation value                               | 400 Bad Request   | "delay\_activation": \["Must be a valid boolean."]                                                          |
| delay\_activation not allowed                               | 400 Bad Request   | "delay\_activation": \[ "delay\_activation can not be set with this account type." ]                         |
| Limit of accounts has been exceeded                        | 400 Bad Request   | "detail": "Limit of {LIMIT} {account\_type} accounts has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED" |
| Timezone is not a valid choice                             | 400 Bad Request   | "timezone": \["value is not a valid choice."]                                                              |
| Timezone is null                                           | 400 Bad Request   | "timezone": \["This field may not be null."]                                                               |
| Password does not satisfy password complexity requirements | 400 Bad Request   | "password": \["Max repeating chars 2"]                                                                     |
| Invalid IP address                                         | 400 Bad Request   | "allowed\_ip\_ranges": \["Must be a valid set of IPv4 or IPv6 network addresses."]                           |
| Max number of items exceeded                               | 400 Bad Request   | "allowed\_ip\_ranges": \["Limit of 10 IP restrictions has been exceeded."]                                   |
| Wrong is\_ip\_restriction\_enabled value                      | 400 Bad Request   | "is\_ip\_restriction\_enabled": \["Must be a valid boolean."]                                                 |

## GET /api/users/

Returns list of Users.

### Permissions

Requires `authentication` and any of:

1. `users.list` permission
2. `user_groups.view` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> GET /api/users/

### Response

The response contains only users for which request user has `users.list` permission.

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

#### Response `results` array

| Key                 | Type     | Notes                                                |
|---------------------|----------|------------------------------------------------------|
| id                  | int      |                                                      |
| username            | string   |                                                      |
| roles               | array    | Roles IDs                                            |
| account\_type        | enum     | Please check "details.schema" in OPTIONS /api/users/ |
| status              | enum     |                                                      |
| full\_name           | string   |                                                      |
| last\_login          | datetime |                                                      |
| activated\_at        | datetime |                                                      |
| password\_set\_at     | datetime |                                                      |
| password\_expires\_at | datetime |                                                      |
| created\_at          | datetime |                                                      |
| created\_by          | user     |                                                      |
| modified\_at         | datetime |                                                      |
| modified\_by         | user     |                                                      |
| link\_sent\_at        | datetime |                                                      |
| link\_sent\_by        | user     |                                                      |
| next\_actions        | array    |                                                      |
| \_meta.permissions   | Object   | Object describing permissions.                       |

* Successful status `200 OK`
* Response body schema

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str | null>,
  "previous": <str | null>,
  "results": [
    {
      "id": <int>,
      "username": <str>,
      "roles": [<int>],
      "account_type": <enum>,
      "status": <enum>,
      "full_name": <str>,
      "last_login": <datetime>,
      "activated_at": <datetime>,
      "password_set_at": <datetime>,
      "password_expires_at": <datetime>,
      "created_at": <datetime>,
      "created_by": <user>,
      "modified_at": <datetime>,
      "modified_by": <user>,
      "link_sent_at": <datetime>, 
      "link_sent_by": <user>, 
      "next_actions": [<str>],
      "_meta": {
        "permissions": {
          "list": <bool>,
          "view": <bool>,
          "create": <bool>,
          "edit": <bool>,
          "delete": <bool>
        }
      }
    }
  ]
}
```

### Sorting

| Parameter       | Example                                 | Notes          |
|-----------------|-----------------------------------------|----------------|
| id              | /api/users/?ordering=id                 | Ascending      |
| id              | /api/users/?ordering=-id                | Descending (-) |
| username        | /api/users/?ordering=username           | Ascending      |
| username        | /api/users/?ordering=-username          | Descending (-) |
| last\_login      | /api/users/?ordering=last\_login         | Ascending      |
| last\_login      | /api/users/?ordering=-last\_login        | Descending (-) |
| activated\_at    | /api/users/?ordering=activated\_at       | Ascending      |
| activated\_at    | /api/users/?ordering=-activated\_at      | Descending (-) |
| password\_set\_at | /api/users/?ordering=password\_set\_at    | Ascending      |
| password\_set\_at | /api/users/?ordering=-password\_set\_at   | Descending (-) |
| created\_at      | /api/users/?ordering=created\_at         | Ascending      |
| created\_at      | /api/users/?ordering=-created\_at        | Descending (-) |
| modified\_at     | /api/users/?ordering=modified\_at        | Ascending      |
| modified\_at     | /api/users/?ordering=-modified\_at       | Descending (-) |
| link\_sent\_at    | /api/users/?ordering=link\_sent\_at        | Ascending      |
| link\_sent\_at     | /api/users/?ordering=-link\_sent\_at       | Descending (-) |

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter       | Type     |
|-----------------|----------|
| id              | int      |
| username        | email    |
| full\_name       | string   |
| account\_type    | enum     |
| status          | enum     |
| roles           | set      |
| is\_available    | bool     |
| is\_super\_admin  | bool     |
| last\_login      | datetime |
| activated\_at    | datetime |
| password\_set\_at | datetime |
| created\_at      | datetime |
| created\_by      | user     |
| modified\_at     | datetime |
| modified\_by     | user     |
| link\_sent\_at    | datetime |
| link\_sent\_by    | user     |

### Errors

| Error                            | Response code   | Message                                                                                      |
|----------------------------------|-----------------|----------------------------------------------------------------------------------------------|
| Wrong ordering value             | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."]        |
| Wrong status filter value        | 400 Bad Request | "status": \["Select a valid choice. {value} is not one of the available choices."]          |
| Wrong link\_sent\_by filter value  | 400 Bad Request | "link\_sent\_by": \["Select a valid choice. That choice is not one of the available choices."]|
| Insufficient permissions         | 403 Forbidden   | "detail": "You do not have permission to perform this action."                               |

## GET /api/users/`id`/

Returns single User by `id`.

### Permissions

Requires `authentication` and `users.view` permission.

### Request

* URL parameters

| Key          | Type | Notes       |
|--------------|------|-------------|
| id           | int  |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> GET /api/users/`id`/

### Response

| Key                         | Type     | Notes |
|-----------------------------|----------|-------|
| id                          | int      |       |
| username                    | string   |       |
| account\_type                | string   |       |
| first\_name                  | string   |       |
| last\_name                   | string   |       |
| job\_title                   | string   |       |
| company\_name                | string   |       |
| phone                       | string   |       |
| mobile                      | string   |       |
| status                      | enum     |       |
| activated\_at                | datetime |       |
| password\_set\_at             | datetime |       |
| password\_expires\_at         | datetime |       |
| roles                       | array    |       |
| created\_at                  | datetime |       |
| created\_by                  | user     |       |
| modified\_at                 | datetime |       |
| modified\_by                 | user     |       |
| link\_sent\_at                | datetime |       |
| link\_sent\_by                | user     |       |
| timezone                    | enum     |       |
| is\_ip\_restriction\_enabled   | bool     |       |
| allowed\_ip\_ranges           | list     |       |
| next\_actions                | array    |       |
| \_meta                       | Object   |       |

* Successful status `200 OK`
* Response body schema:

```json
{ 
  "id": <int>, 
  "username": <str>, 
  "account_type": <enum>, 
  "first_name": <str>, 
  "last_name": <str>, 
  "job_title": <str>, 
  "company_name": <str>, 
  "phone": <str>, 
  "mobile": <str>, 
  "status": <enum>, 
  "activated_at": <datetime>,
  "password_set_at": <datetime>,
  "password_expires_at": <datetime>, 
  "roles": [<int>], 
  "created_at": <datetime>, 
  "created_by": <user>, 
  "modified_at": <datetime>, 
  "modified_by": <user>,
  "link_sent_at": <datetime>, 
  "link_sent_by": <user>,
  "timezone": <enum>,
  "is_ip_restriction_enabled": <bool>,
  "allowed_ip_ranges": [<str>],
  "next_actions": [<str>],
  "_meta": { 
    "labels": { 
      "roles": [<str>] 
    }, 
    "permissions": { 
      "list": <bool>,
      "view": <bool>,
      "create": <bool>,
      "edit": <bool>,
      "delete": <bool>
    },
    "allowed_account_type_changes": [<str>]
  } 
} 
```

### Errors

| Error                         | Response code | Message                                                        |
|-------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions      | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| User with "id" does not exist | 404 Not Found | "detail": "Not found."                                         |

## PATCH /api/users/`id`/

Updates single User.

### Permissions

Requires `authentication` and `users.edit` permission.

For changing password, `Super Admin` account type is required.

### Request

* URL parameters

| Key          | Type | Notes       |
|--------------|------|-------------|
| id           | int  |             |

* Body parameters

| Key                        | Type      | Notes                                                     |
|----------------------------|-----------|-----------------------------------------------------------|
| username                   | string    | Unique email address                                      |
| account\_type               | enum      | Please check table below to determine allowed operations  |
| first\_name                 | string    |                                                           |
| last\_name                  | string    |                                                           |
| job\_title                  | string    |                                                           |
| company\_name               | string    |                                                           |
| phone                      | string    |                                                           |
| mobile                     | string    |                                                           |
| password                   | string    |                                                           |
| roles                      | array     | Roles can be provided only to "config admin" account type |
| delay\_activation           | bool      |                                                           |
| timezone                   | enum      |                                                           |
| is\_ip\_restriction\_enabled  | bool      |                                                           |
| allowed\_ip\_ranges          | list      |                                                           |

* Allowed "account\_type" changes

![](/api/catalyst/resources/users/media/patching-account-type.png)

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> PATCH /api/users/`id`/

```json
{ 
  "username": <str>, 
  "account_type": <enum>, 
  "first_name": <str>, 
  "last_name": <str>, 
  "job_title": <str>, 
  "company_name": <str>, 
  "phone": <str>, 
  "mobile": <str>, 
  "password": <str>,
  "roles": [<int>],
  "delay_activation": <bool>,
  "is_ip_restriction_enabled": <bool>,
  "allowed_ip_ranges": [<str>]
} 
```

### Restrictions

* Separate limits for each user account type are enforced (defaults in table below).
* Limits are configurable per build.

| Account type      | Limit |
|-------------------|-------|
| Internal          | 1000  |
| External          | 2500  |
| Full              | 100   |
| 1 Time Completion | 5000  |
| Super Admin       | 25    |
| Service Internal  | 1     |
| Service External  | 5     |

* The `Service Internal` account type has the same permissions as `Super Admin`,
  except that it cannot change passwords.
* The password can be changed for Service accounts only. Attempts to change the password
  for other account types are silently ignored.

### Response

| Key                       | Type      | Notes |
|---------------------------|-----------|-------|
| id                        | int       |       |
| username                  | string    |       |
| account\_type              | string    |       |
| first\_name                | string    |       |
| last\_name                 | string    |       |
| job\_title                 | string    |       |
| company\_name              | string    |       |
| phone                     | string    |       |
| mobile                    | string    |       |
| status                    | enum      |       |
| activated\_at              | datetime  |       |
| password\_set\_at           | datetime  |       |
| password\_expires\_at       | datetime  |       |
| roles                     | array     |       |
| created\_at                | datetime  |       |
| created\_by                | user      |       |
| modified\_at               | datetime  |       |
| modified\_by               | user      |       |
| link\_sent\_at              | datetime  |       |
| link\_sent\_by              | user      |       |
| timezone                  | enum      |       |
| is\_ip\_restriction\_enabled | bool      |       |
| allowed\_ip\_ranges         | list      |       |
| next\_actions              | array     |       |
| \_meta                     | Object    |       |

* Successful status `200 OK`
* Response body schema:

```json
{ 
  "id": <int>, 
  "username": <str>, 
  "account_type": <enum>, 
  "first_name": <str>, 
  "last_name": <str>, 
  "job_title": <str>, 
  "company_name": <str>, 
  "phone": <str>, 
  "mobile": <str>, 
  "status": <enum>, 
  "activated_at": <datetime>,
  "password_set_at": <datetime>,
  "password_expires_at": <datetime>, 
  "roles": [<int>], 
  "created_at": <datetime>, 
  "created_by": <user>, 
  "modified_at": <datetime>, 
  "modified_by": <user>, 
  "link_sent_at": <datetime>, 
  "link_sent_by": <user>,
  "timezone": <enum>,
  "is_ip_restriction_enabled": <bool>,
  "allowed_ip_ranges": [<str>],
  "_meta": { 
    "labels": { 
      "roles": [<str>] 
    }, 
    "permissions": { 
      "list": <bool>,
      "view": <bool>,
      "create": <bool>,
      "edit": <bool>,
      "delete": <bool>
    }, 
    "allowed_account_type_changes": [<str>]
  } 
} 
```

### Errors

Standard validation errors and additional custom errors enumerated in the table below:

| Cause                                                      | Response code     | Message                                                                                                     |
|------------------------------------------------------------|-------------------|-------------------------------------------------------------------------------------------------------------|
| Account type change not allowed                            | 400 Bad Request   | "account\_type": \["Account type cannot be changed from {current type} to {new type}."]                     |
| Wrong delay\_activation value                               | 400 Bad Request   | "delay\_activation": \["Must be a valid boolean."]                                                          |
| delay\_activation not allowed                               | 400 Bad Request   | "delay\_activation": \[ "delay\_activation can not be set." ]                                                |
| "roles" provided with non config admin account             | 400 Bad Request   | "roles": \["Roles can be assigned only to config admin account."]                                          |
| Limit of accounts has been exceeded                        | 400 Bad Request   | "detail": "Limit of {LIMIT} {account\_type} accounts has been exceeded.", "error\_code": "ERR\_LIMIT\_EXCEEDED" |
| Timezone is not a valid choice                             | 400 Bad Request   | "timezone": \["value is not a valid choice."]                                                              |
| Timezone is null                                           | 400 Bad Request   | "timezone": \["This field may not be null."]                                                               |
| Password does not satisfy password complexity requirements | 400 Bad Request   | "password": \["Max repeating chars 2"]                                                                     |
| Non Super Admin attempts to change password                | 403 Forbidden     | "detail": "You do not have permission to perform this action."                                              |
| Invalid IP address                                         | 400 Bad Request   | "allowed\_ip\_ranges": \["Must be a valid set of IPv4 or IPv6 network addresses."]                           |
| Max number of items exceeded                               | 400 Bad Request   | "allowed\_ip\_ranges": \["Limit of 10 IP restrictions has been exceeded."]                                   |
| Wrong is\_ip\_restriction\_enabled value                      | 400 Bad Request   | "is\_ip\_restriction\_enabled": \["Must be a valid boolean."]                                                 |
| Modifying own allowed\_ip\_ranges                            | 400 Bad Request   | "allowed\_ip\_ranges": \["You cannot modify your own IP restriction settings."]                              |
| Modifying own is\_ip\_restriction\_enabled                    | 400 Bad Request   | "is\_ip\_restriction\_enabled": \["You cannot modify your own IP restriction settings."]                      |

## DELETE /api/users/`id`/

Deletes single User.

### Permissions

Requires `authentication` and `users.delete` permission.

### Request

* URL parameters

| Key           | Type | Notes |
|---------------|------|-------|
| id            | int  |       |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> DELETE /api/users/`id`/

### Response

* Successful status `204 No Content`

### Errors

| Error                          | Response code | Message                                                        |
|--------------------------------|---------------|----------------------------------------------------------------|
| Insufficient permissions       | 403 Forbidden | "detail": "You do not have permission to perform this action." |
| User with "id" does not exist  | 404 Not Found | "detail": "Not found."                                         |

## OPTIONS /api/users/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> OPTIONS /api/users/

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "list": {
        "columns": [
            {
                "alias": "id",
                "type": "int",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "username",
                "type": "string",
                "predicates": [
                    "exact",
                    "iexact",
                    "contains",
                    "icontains",
                    "startswith",
                    "istartswith",
                    "endswith",
                    "iendswith"
                ],
                "sort_ok": true
            },
            {
                "alias": "roles",
                "type": "set",
                "predicates": [
                    "containsall",
                    "containssome",
                    "isnull"
                ],
                "sort_ok": false,
                "autocomplete": "/api/roles/autocomplete/?text__icontains="
            },
            {
                "alias": "account_type",
                "type": "enum",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "values": [
                    {
                        "value": "internal",
                        "text": "Internal"
                    },
                    {
                        "value": "external",
                        "text": "External"
                    },
                    {
                        "value": "service_internal",
                        "text": "Service Internal"
                    },
                    {
                        "value": "service_external",
                        "text": "Service External"
                    },
                    {
                        "value": "full",
                        "text": "Full"
                    },
                    {
                        "value": "one_time_completion",
                        "text": "1 Time Completion"
                    },
                    {
                        "value": "super_admin",
                        "text": "Super Admin"
                    }
                ]
            },
            {
                "alias": "status",
                "type": "enum",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "values": [
                    {
                        "value": "created",
                        "text": "Created"
                    },
                    {
                        "value": "pending",
                        "text": "Pending"
                    },
                    {
                        "value": "active",
                        "text": "Active"
                    }
                ]
            },
            {
                "alias": "full_name",
                "type": "string",
                "predicates": [
                    "exact",
                    "iexact",
                    "contains",
                    "icontains",
                    "startswith",
                    "istartswith",
                    "endswith",
                    "iendswith"
                ],
                "sort_ok": false
            },
            {
                "alias": "last_login",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range",
                    "isnull"
                ],
                "sort_ok": true
            },
            {
                "alias": "activated_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range",
                    "isnull"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "created_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "modified_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range"
                ],
                "sort_ok": true
            },
            {
                "alias": "modified_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            },
            {
                "alias": "link_sent_at",
                "type": "datetime",
                "predicates": [
                    "exact",
                    "gt",
                    "gte",
                    "lt",
                    "lte",
                    "range",
                    "isnull"
                ],
                "sort_ok": true
            },
            {
                "alias": "link_sent_by",
                "type": "user",
                "predicates": [
                    "exact",
                    "in"
                ],
                "sort_ok": false,
                "autocomplete": "/api/users/autocomplete/?text__icontains="
            }
        ]
    },
    "details": {
        "schema": [
            {
                "alias": "account_type",
                "type": "enum",
                "required": true,
                "values": [
                    {
                        "value": "internal",
                        "text": "Internal"
                    },
                    {
                        "value": "external",
                        "text": "External"
                    },
                    {
                        "value": "service_internal",
                        "text": "Service Internal"
                    },
                    {
                        "value": "service_external",
                        "text": "Service External"
                    },
                    {
                        "value": "full",
                        "text": "Full"
                    },
                    {
                        "value": "one_time_completion",
                        "text": "1 Time Completion"
                    },
                    {
                        "value": "super_admin",
                        "text": "Super Admin"
                    }
                ]
            },
            {
                "alias": "password",
                "type": "string",
                "schema": [
                    {
                        "alias": "required_for_account_types",
                        "values": [
                            "service_internal",
                            "service_external"
                        ]
                    }
                ]
            },
            {
                "alias": "username",
                "type": "email",
                "required": true,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "first_name",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 100
                    },
                    {
                        "type": "min_length",
                        "length": 1
                    }
                ]
            },
            {
                "alias": "last_name",
                "type": "string",
                "required": true,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 100
                    },
                    {
                        "type": "min_length",
                        "length": 1
                    }
                ]
            },
            {
                "alias": "job_title",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "company_name",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "phone",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "phone"
                    },
                    {
                        "type": "max_length",
                        "length": 20
                    }
                ]
            },
            {
                "alias": "mobile",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "phone"
                    },
                    {
                        "type": "max_length",
                        "length": 20
                    }
                ]
            },
            {
                "alias": "roles",
                "type": "set",
                "required": false,
                "autocomplete": "/api/roles/autocomplete/?text__icontains="
            },
            {
                "alias": "delay_activation",
                "type": "bool",
                "required": false,
                "validators": []
            },
            {
                "alias": "timezone",
                "type": "enum",
                "required": false,
                "values": [
                    { "value": "Africa/Abidjan" },
                    { "value": "America/Chicago"},
                    { "value": "Europe/Reykjavik"}
                // ... 
                ]
            }
        ]
    },
    "restrictions": {
        "limit_internal": 1000,
        "limit_external": 2500,
        "limit_full": 100,
        "limit_one_time_completion": 5000,
        "limit_super_admin": 25,
        "limit_items": 8625
    }
}
```

## POST /api/users/`id`/send-activation-email/

This API endpoint is for resend an activation email for a given user.

### Permissions

Requires `authentication` and a `users.edit` permission.

### Request

* URL parameters

| Key | Type | Notes       |
|-----|------|-------------|
| id  | id   |             |

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

### Validations

* user
  * Valid user ID with account status `created` or `pending`.

- Successful status `201 Created`

### Errors

| Cause                                                 | Response code   | Message                                                         |
|-------------------------------------------------------|-----------------|-----------------------------------------------------------------|
| User with given `id` has account already activated.   | 400 Bad Request | "detail": "The given account has already been activated."       |
| Insufficient permissions                              | 403 Forbidden   | "detail": "You do not have permission to perform this action."  |
| Invalid `id` in URL                                   | 404 Not Found   | "detail": \["Not found."]                                      |

## PATCH /api/users/`id`/add-roles/

Endpoint to add given roles to existing ones.
Batch operation - adds single or multiple roles.

### Permissions

Perm to check: `users.edit`

### URL parameters

| Key         | Notes      |
|-------------|------------|
| id          | User ID    |

### Request Schema

* Headers

```
Request Method: PATCH
Location: /api/users/{id}/add-roles/ 
Authorization: JWT access_token
```

* Body

```json
{
    "roles": [7,8]
}
```

### Request example

```json
{
    "roles": [7,8]
}
```

### Response

| Key                 | Type     | Notes |
|---------------------|----------|-------|
| id                  | int      |       |
| username            | string   |       |
| account\_type        | string   |       |
| first\_name          | string   |       |
| last\_name           | string   |       |
| job\_title           | string   |       |
| company\_name        | string   |       |
| phone               | string   |       |
| mobile              | string   |       |
| status              | enum     |       |
| activated\_at        | datetime |       |
| password\_set\_at     | datetime |       |
| password\_expires\_at | datetime |       |
| roles               | array    |       |
| created\_at          | datetime |       |
| created\_by          | user     |       |
| modified\_at         | datetime |       |
| modified\_by         | user     |       |
| \_meta               | Object   |       |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": 4,
    "username": "test@mail.test",
    "account_type": "full",
    "first_name": "User",
    "last_name": "FullPermissions",
    "job_title": "",
    "company_name": "",
    "phone": "",
    "mobile": "",
    "status": "active",
    "activated_at": "2021-11-12T10:21:02.637000+01:00",
    "password_set_at": "2021-11-12T11:11:59.270000+01:00",
    "password_expires_at": null,
    "roles": [
        7,
        8
    ],
    "created_at": "2021-11-12T10:07:41.347000+01:00",
    "created_by": null,
    "modified_at": "2022-03-15T08:53:42.447000+01:00",
    "modified_by": null,
    "_meta": {
        "labels": {
            "roles": [
                "Create permissions",
                "Edit permissions"
            ]
        },
        "permissions": {
            "list": true,
            "view": true,
            "create": true,
            "edit": true,
            "delete": true
        }
    }
}
```

### Errors

| Error                     | Response code   | Message                                                             |
|---------------------------|-----------------|---------------------------------------------------------------------|
| roles is required         | 400 Bad Request | "roles": \["This field is required." ]                             |
| roles is empty            | 400 Bad Request | "roles": \["This list may not be empty." ]                         |
| roles not a list          | 400 Bad Request | "roles": \["Expected a list of items but got type "type"."]      |
| roles not an integer list | 400 Bad Request | "roles": \["Incorrect type. Expected pk value, received "type"."]|
| roles incorrect account   | 400 Bad Request | "roles": \["Roles can be assigned only to config admin account."]  |
| Wrong/not existing `id`   | 404 Not Found   |                                                                     |
| Insufficient permissions  | 403 Forbidden   | "detail": "You do not have permission to perform this action."      |

## PATCH /api/users/`id`/unassign-roles/

Endpoint to remove given roles from existing ones.
Batch operation - removes single or multiple roles.

### Permissions

Perm to check: `users.edit`

### URL parameters

| Key         | Notes      |
|-------------|------------|
| id          | User ID    |

### Request Schema

* Headers

```
Request Method: PATCH
Location: /api/users/{id}/unassign-roles/ 
Authorization: JWT access_token
```

* Body

```json
{
    "roles": [7,8]
}
```

### Request example

```json
{
    "roles": [7,8]
}
```

### Response

| Key                 | Type     | Notes |
|---------------------|----------|-------|
| id                  | int      |       |
| username            | string   |       |
| account\_type        | string   |       |
| first\_name          | string   |       |
| last\_name           | string   |       |
| job\_title           | string   |       |
| company\_name        | string   |       |
| phone               | string   |       |
| mobile              | string   |       |
| status              | enum     |       |
| activated\_at        | datetime |       |
| password\_set\_at     | datetime |       |
| password\_expires\_at | datetime |       |
| roles               | array    |       |
| created\_at          | datetime |       |
| created\_by          | user     |       |
| modified\_at         | datetime |       |
| modified\_by         | user     |       |
| \_meta               | Object   |       |

* Successful status `200 OK`
* Response body schema:

```json
{
    "id": 4,
    "username": "test@mail.test",
    "account_type": "full",
    "first_name": "User",
    "last_name": "FullPermissions",
    "job_title": "",
    "company_name": "",
    "phone": "",
    "mobile": "",
    "status": "active",
    "activated_at": "2021-11-12T10:21:02.637000+01:00",
    "password_set_at": "2021-11-12T11:11:59.270000+01:00",
    "password_expires_at": null,
    "roles": [],
    "created_at": "2021-11-12T10:07:41.347000+01:00",
    "created_by": null,
    "modified_at": "2022-03-15T08:53:42.447000+01:00",
    "modified_by": null,
    "_meta": {
        "labels": {
            "roles": []
        },
        "permissions": {
            "list": true,
            "view": true,
            "create": true,
            "edit": true,
            "delete": true
        }
    }
}
```

### Errors

| Error                     | Response code   | Message                                                             |
|---------------------------|-----------------|---------------------------------------------------------------------|
| roles is required         | 400 Bad Request | "roles": \["This field is required." ]                             |
| roles is empty            | 400 Bad Request | "roles": \["This list may not be empty." ]                         |
| roles not a list          | 400 Bad Request | "roles": \["Expected a list of items but got type "type"."]      |
| roles not an integer list | 400 Bad Request | "roles": \["Incorrect type. Expected pk value, received "type"."]|
| roles incorrect account   | 400 Bad Request | "roles": \["Roles can be assigned only to config admin account."]  |
| Wrong/not existing `id`   | 404 Not Found   |                                                                     |
| Insufficient permissions  | 403 Forbidden   | "detail": "You do not have permission to perform this action."      |

## GET /api/users/autocomplete/

List Users based on query parameters.

### Permissions

Requires `authentication` and `users.list` permission

### Request example

* Headers

```
Request Method: GET
Location: /api/users/autocomplete/
Authorization: JWT access_token
```

### Response

The response contains only users for which request user has `users.list` permission.

| Key               | Type       | Notes                                                                            |
|-------------------|------------|----------------------------------------------------------------------------------|
| limit             | int        | 	                                                                                |
| offset            | int        | 	                                                                                |
| total\_count       | int        | Total number of items visible to the user (based on permissions).                |
| filtered\_count    | int        | Number of items visible to the user (based on permissions) with filters applied. |
| next              | URL / null | Next page URL (null if there is no next page)                                    |
| previous          | URL / null | Previous page URL (null if there is no previous page)                            |
| results           | Array      | Described in the next table.                                                     |

### Response `results` array

| Key   | Type     | Notes                                                 |
|-------|----------|-------------------------------------------------------|
| value | id       |                                                       |
| text  | string   |                                                       |

### Response example

* Status `200 OK`
* Body

```json
{
  "limit": 100,
  "offset": 0,
  "filtered_count": 2,
  "total_count": 21,
  "next": null,
  "previous": null,
  "results": [
    {
      "value": 21,
      "text": "John Doe",
    },
    {
      "value": 20,
      "text": "Sarah Connor",
    }
  ]
}
```

### Sorting

| Parameter   | Example                                                 | Notes          |
|-------------|---------------------------------------------------------|----------------|
| text        | {build}/api/users/autocomplete//?ordering=text          | Ascending      |
| text        | {build}/api/users/autocomplete/?ordering=-text | Descending (-) |

### Filtering

For the full description of standard predicates see [ALX API standards - Developers guide](/api/standards/).

| Parameter        | Type   |
|------------------|--------|
| id               | int    |
| text             | string |

| Error                                   | Response code      | Message                                                        |
|-----------------------------------------|--------------------|----------------------------------------------------------------|
| Max items in filtering by \_in exceeded  | 400 Bad request    | {'id\_\_in': "At most 50 values are allowed."}                   |
| Requesting user is not authenticated    | 401 Unauthorized   | "detail": "Authentication credentials were not provided."      |
| Unauthorized API call                   | 403 Forbidden      | "detail": "You do not have permission to perform this action." |

## POST /api/users/reset-password/

The method is intended for requesting password reset email, typically when the user forgot his password.
In response the system sends the user an email with the link to the reset password page:
`<Client URL>/ui/accounts/reset-password/<password-reset-token>/`
For now, we will use the current email template.

### Permissions

Any user.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/users/reset-password/

{
    "email": <email>
} 
```

* Successful status `200 OK`

### Errors

| Error                                                            | Response code   | Message                                                                                                                                                                                                    |
|------------------------------------------------------------------|-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Account locked                                                   | 400 Bad Request | {"detail": "Password reset is disabled while your account is locked. Please wait until the lockout ends at "datetime".", "error\_code": "ERR\_ACCOUNT\_LOCKED", "data": "lockout\_ends\_at": "datetime>" }} |
| Reset password token invalidated due to SSO-only account type  	 | 400 Bad Request | {"detail": "This user account is not allowed to log in using login and password." }                                                                                                                        |

## GET /api/users/reset-password/`token`/

The method is intended for the FE use. Before displaying the Password reset page, FE validates the token.
If the token is invalid or it is expired, FE redirects the user to the appropriate page.

### Permissions

Requires valid `token`.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/users/reset-password/<token>/
```

### Response

| Key   | Type  | Notes      |
|-------|-------|------------|
| email | email | User email |

* Successful status `200 OK`
* Response body schema

```json
{ 
    "email": "syl*****e@test.test" 
} 
```

### Errors

| Error                                                             | Response code   | Message                                                                                                                                                                                                    |
|-------------------------------------------------------------------|-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Invalid token                                                     | 403 Forbidden   | "detail": "Authentication credentials were not provided."                                                                                                                                                  |
| Token expired                                                     | 400 Bad Request | "detail": "Token expired."                                                                                                                                                                                 |
| Account locked                                                    | 400 Bad Request | {"detail": "Password reset is disabled while your account is locked. Please wait until the lockout ends at "datetime".", "error\_code": "ERR\_ACCOUNT\_LOCKED", "data": "lockout\_ends\_at": "datetime>" }} |
| Reset password token invalidated due to SSO-only account type   	 | 400 Bad Request | {"detail": "This user account is not allowed to log in using login and password." }                                                                                                                        |

## POST /api/users/reset-password/`token`/password/

The method is intended for resetting users password following password reset request.
The caller is identified by the token.

### Permissions

Requires valid `token`.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
POST /api/users/reset-password/<token>/password/

{
    "password": <string>
} 
```

### Validations

* password
  * password\_prevent\_reuse
  * password\_rotation\_interval
  * max\_repeating\_chars
  * min\_letters
  * min\_numbers
  * min\_symbols
  * min\_lower\_case
  * min\_upper\_case
  * min\_length

### Response

* Successful status `201 Created`

```json
{ 
    "refresh": "REFRESH_TOKEN", 
    "access": "ACCESS_TOKEN"
} 
```

### Errors

| Error                                                             | Response code   | Message                                                                                                                                                                                                    |
|-------------------------------------------------------------------|-----------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Invalid token                                                     | 403 Forbidden   | "detail": "Authentication credentials were not provided."                                                                                                                                                  |
| Invalid password                                                  | 400 Bad Request | "password": \["Max repeating chars 2"]                                                                                                                                                                    |
| Account locked                                                    | 400 Bad Request | {"detail": "Password reset is disabled while your account is locked. Please wait until the lockout ends at "datetime".", "error\_code": "ERR\_ACCOUNT\_LOCKED", "data": "lockout\_ends\_at": "datetime>" }} |
| Reset password token invalidated due to SSO-only account type  	  | 400 Bad Request | {"detail": "This user account is not allowed to log in using login and password." }                                                                                                                        |

## OPTIONS /api/users/reset-password/`token`/password/

### Permissions

Any user.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/users/reset-password/<token>/password/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "details": { 
    "schema": [
        {
            "alias": "password", 
            "type": "string", 
            "required": true 
            }
        ]
    } 
}
```

## PATCH /api/users/me/

Updates information about logged user.

### Permissions

Requires `authentication`.

### Allowed parameters

| Key          | Type   | Notes |
|--------------|--------|-------|
| username     | string |       |
| first\_name   | string |       |
| last\_name    | string |       |
| job\_title    | string |       |
| company\_name | string |       |
| phone        | string |       |
| mobile       | string |       |

Any parameter not listed above are silently ignored if passed.

### Request

* Headers

```
Request Method: PATCH
Content-Type: application/json
Location: /api/users/me/
Authorization: JWT access_token
```

* Sample request body

```json
{
    "username": "alx.dev@autologyx.com",
    "first_name": "John",
    "last_name": "Smith"
}
```

### Validations

* username
  * is valid email
  * is unique
  * is not null
  * max length is 100
* first\_name
  * is string
  * is not null
  * max length is 100
  * min length is 1
* last\_name
  * is string
  * is not null
  * max length is 100
  * min length is 1
* job\_title
  * is string
  * is not null
  * max length is 100
* company\_name
  * is string
  * is not null
  * max length is 100
* phone
  * is string
  * is not null
  * max length is 20
* mobile
  * is string
  * is not null
  * max length is 20

### Response

| Key                      | Type      | Notes |
|--------------------------|-----------|-------|
| id                       | int       |       |
| username                 | string    |       |
| account\_type             | string    |       |
| first\_name               | string    |       |
| last\_name                | string    |       |
| job\_title                | string    |       |
| company\_name             | string    |       |
| phone                    | string    |       |
| mobile                   | string    |       |
| status                   | enum      |       |
| activated\_at             | datetime  |       |
| password\_set\_at          | datetime  |       |
| password\_expires\_at      | datetime  |       |
| roles                    | array     |       |
| created\_at               | datetime  |       |
| created\_by               | user      |       |
| modified\_at              | datetime  |       |
| modified\_by              | user      |       |
| user\_groups\_membership   | array     |       |
| \_meta                    | Object    |       |

* Successful status `200 OK`
* Response body schema

```json
{
    "id": 2,
    "username": "alx.dev@autologyx.com",
    "account_type": "super_admin",
    "first_name": "John",
    "last_name": "Smith",
    "job_title": "",
    "company_name": "",
    "phone": "",
    "mobile": "",
    "status": "active",
    "activated_at": null,
    "password_set_at": "2021-11-05T13:57:07.228000+01:00",
    "password_expires_at": null,
    "roles": [],
    "created_at": "2021-11-05T13:56:26.726000+01:00",
    "created_by": null,
    "modified_at": "2021-11-16T15:32:53.479000+01:00",
    "modified_by": null,
    "user_groups_membership": [],
    "_meta": {
        "labels": {
            "roles": [],
            "user_groups_membership": [],
        },
        "permissions": {
            "list": true,
            "view": true,
            "create": true,
            "edit": true,
            "delete": false
        }
    }
} 
```

### Errors

Standard validation errors.

## PATCH /api/users/me/set-password/

Updates logged user password.

### Permissions

Requires `authentication`.

Service accounts are not allowed.

### Allowed parameters

| Key          | Type   | Notes |
|--------------|--------|-------|
| old\_password | string |       |
| new\_password | string |       |

Any parameter not listed above are silently ignored if passed.

### Request

* Headers

```
Request Method: PATCH
Content-Type: application/json
Location: /api/users/me/set-password/
Authorization: JWT access_token
```

* Sample request body

```json
{
    "old_password": "some_old_pass",
    "new_password": "some_old_pass"
}
```

### Validations

* old\_password
  * is valid password
  * is required
  * is not null
* new\_password
  * is string
  * meets security rules
  * is required
  * is not null

### Response

| Key     | Type     | Notes                                 |
|---------|----------|---------------------------------------|
| refresh | string   | JWT token to refresh JWT access token |
| access  | string   | JWT token to access ALX API endpoints |

* Successful status `200 OK`
* Response body schema

```json
{
    "refresh": "refresh_token",
    "access": "access_token"
}
```

### Errors

| Cause                                                                           | Response status code | Response message                                                                                  |
|---------------------------------------------------------------------------------|----------------------|---------------------------------------------------------------------------------------------------|
| old\_password is not provided                                                    | 400 Bad Request      | "old\_password": \["This field is required."]                                                     |
| old\_password is NULL                                                            | 400 Bad Request      | "old\_password": \["This field may not be null."]                                                 |
| old\_password is blank string                                                    | 400 Bad Request      | "old\_password": \["This field may not be blank."]                                                |
| old\_password is not a string                                                    | 400 Bad Request      | "old\_password": \["Not a valid string."]                                                         |
| old\_password does not match current password                                    | 400 Bad Request      | "old\_password": \["Invalid password."]                                                           |
| new\_password is not provided                                                    | 400 Bad Request      | "new\_password": \["This field is required."]                                                     |
| new\_password is NULL                                                            | 400 Bad Request      | "new\_password": \["This field may not be null."]                                                 |
| new\_password is blank\_string                                                    | 400 Bad Request      | "new\_password": \["This field may not be blank."]                                                |
| new\_password is not a string                                                    | 400 Bad Request      | "new\_password": \["Not a valid string."]                                                         |
| new\_password does not match security rule about number of repeating chars       | 400 Bad Request      | "new\_password": \["Can have only "number" repeating consecutive chars"]                        |
| new\_password does not match security rule about number of letters               | 400 Bad Request      | "new\_password": \["Must be more complex (must contain "number" or more letters)"]              |
| new\_password does not match security rule about number of digits                | 400 Bad Request      | "new\_password": \["Must be more complex (must contain "number" or more digits)"]               |
| new\_password does not match security rule about number of special characters    | 400 Bad Request      | "new\_password": \["Must be more complex (must contain "number" or more special characters)"]   |
| new\_password does not match security rule about number of uppercase characters  | 400 Bad Request      | "new\_password": \["Must be more complex (must contain "number" or more uppercase characters)"] |
| new\_password does not match security rule about number of lowercase characters  | 400 Bad Request      | "new\_password": \["Must be more complex (must contain "number" or more lowercase characters)"] |
| new\_password does not match security rule about length                          | 400 Bad Request      | "new\_password": \["Invalid Length (Must be "number" characters or more)"]                      |
| new\_password does not match security rule about re-using password from the past | 400 Bad Request      | "new\_password": \["Password used in the past"]                                                   |
| Reset password token invalidated due to SSO-only account type    	              | 400 Bad Request      | {"detail": "This user account is not allowed to log in using login and password." }               |
| Service account attempts to change password                                     | 403 Forbidden        | "detail": "You do not have permission to perform this action."                                    |

## OPTIONS /api/users/me/

### Permissions

Requires `authentication`

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
OPTIONS /api/users/me/
```

### Response

* Successful status `200 OK`
* Response body:

```json
{
    "details": {
        "schema": [
            {
                "alias": "username",
                "type": "email",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "first_name",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 100
                    },
                    {
                        "type": "min_length",
                        "length": 1
                    }
                ]
            },
            {
                "alias": "last_name",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 100
                    },
                    {
                        "type": "min_length",
                        "length": 1
                    }
                ]
            },
            {
                "alias": "job_title",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "company_name",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "max_length",
                        "length": 100
                    }
                ]
            },
            {
                "alias": "phone",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "phone"
                    },
                    {
                        "type": "max_length",
                        "length": 20
                    }
                ]
            },
            {
                "alias": "mobile",
                "type": "string",
                "required": false,
                "validators": [
                    {
                        "type": "phone"
                    },
                    {
                        "type": "max_length",
                        "length": 20
                    }
                ]
            },
            {
                "alias": "timezone",
                "type": "enum",
                "required": false,
                "values": [
                    { "value": "Africa/Abidjan" },
                    { "value": "America/Chicago"},
                    { "value": "Europe/Reykjavik"}
                // ... 
                ]
            }
        ]
    }
}
```

## GET /api/users/me/

### Permissions

Requires `authentication`

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/users/me/
```

### Response

| Key                    | Type     | Notes |
|------------------------|----------|-------|
| id                     | int      |       |
| username               | string   |       |
| account\_type           | string   |       |
| first\_name             | string   |       |
| last\_name              | string   |       |
| job\_title              | string   |       |
| company\_name           | string   |       |
| phone                  | string   |       |
| mobile                 | string   |       |
| status                 | enum     |       |
| activated\_at           | datetime |       |
| password\_set\_at        | datetime |       |
| password\_expires\_at    | datetime |       |
| roles                  | array    |       |
| created\_at             | datetime |       |
| created\_by             | user     |       |
| modified\_at            | datetime |       |
| modified\_by            | user     |       |
| user\_groups\_membership | array    |       |
| timezone               | enum     |       |
| \_meta                  | Object   |       |

* Successful status `200 OK`
* Response body schema

```json
{
    "id": 2,
    "username": "alx.dev@autologyx.com",
    "account_type": "super_admin",
    "first_name": "ALX",
    "last_name": "Developer",
    "job_title": "",
    "company_name": "",
    "phone": "",
    "mobile": "",
    "status": "active",
    "activated_at": null,
    "password_set_at": "2021-11-05T13:57:07.228000+01:00",
    "password_expires_at": null,
    "roles": [],
    "created_at": "2021-11-05T13:56:26.726000+01:00",
    "created_by": null,
    "modified_at": "2021-11-16T15:32:53.479000+01:00",
    "modified_by": null,
    "user_groups_membership": [],
    "timezone": "UTC",
    "_meta": {
        "labels": {
            "roles": [],
            "user_groups_membership": [],
        },
        "permissions": {
            "list": true,
            "view": true,
            "create": true,
            "edit": true,
            "delete": false
        }
    }
} 
```

### Errors

| Error         | Response code   | Message                                                   |
|---------------|-----------------|-----------------------------------------------------------|
| Invalid token | 403 Forbidden   | "detail": "Authentication credentials were not provided." |

## GET /api/users/stats/

### Permissions

Requires `authentication` and `users.view` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/users/stats/
```

### Response

| Key                 | Type     | Notes |
|---------------------|----------|-------|
| internal            | object   |       |
| external            | object   |       |
| full                | object   |       |
| one\_time\_completion | object   |       |
| super\_admin         | object   |       |

#### Response `account_type` object

| Key   | Type     | Notes                                                     |
|-------|----------|-----------------------------------------------------------|
| count | int      | The current number of accounts of the corresponding type. |
| limit | int      | The max number of accounts of the corresponding type.     |

* Successful status `200 OK`
* Response body schema

```json
{
  "internal": {
    "count": <int>,
    "limit": <int>
  },
  "external": {
    "count": <int>,
    "limit": <int>
  },
  "full": {
    "count": <int>,
    "limit": <int>
  },
  "one_time_completion": {
    "count": <int>,
    "limit": <int>
  },
  "super_admin": {
    "count": <int>,
    "limit": <int>
  }
}
```

### Errors

Standard validation errors.

## GET /api/users/permissions/

Returns logged-in User permissions.

### Permissions

Requires `authentication`.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> GET /api/users/permissions/

### Response

| Key                     | Type     | Notes                                                |
|-------------------------|----------|------------------------------------------------------|
| company\_details         | object   |                                                      |
| authentication\_objects  | object   |                                                      |
| custom\_components       | object   |                                                      |
| files                   | object   |                                                      |
| object\_classes          | object   |                                                      |
| object\_records          | object   |                                                      |
| object\_class\_forms      | object   |                                                      |
| object\_models           | object   |                                                      |
| roles                   | object   |                                                      |
| outbound\_mail\_setup     | object   |                                                      |
| message\_templates       | object   |                                                      |
| sequences               | object   |                                                      |
| single\_sign\_on          | object   |                                                      |
| tasks                   | object   |                                                      |
| task\_templates          | object   |                                                      |
| task\_group\_templates    | object   |                                                      |
| ui\_config               | object   |                                                      |
| users                   | object   |                                                      |
| standard\_authentication | object   |                                                      |
| user\_groups             | object   |                                                      |
| integrations            | object   |                                                      |

* Successful status `200 OK`
* Response body schema

```json
{
  "company_details": {
    "edit": <bool>,
    "view": <bool>
  },
  "authentication_objects": {
    "list": <bool>,
    "view": <bool>,
    "create": <bool>,
    "edit": <bool>,
    "delete": <bool>
  },
  "custom_components": {
    "list": <bool>,
    "view": <bool>,
    "create": <bool>,
    "edit": <bool>,
    "delete": <bool>
  },
  "files": {
    "store": <bool>,
    "list": <bool>,
    "delete": <bool>
  },
  "integrations": {
    "list": <bool>,
    "view": <bool>,
    "create": <bool>,
    "edit": <bool>,
    "delete": <bool>
  },
  "object_classes": {
    "list": <bool>,
    "create": <bool>
  },
  "object_records": {
    "create": <bool>,
    "list": <bool>
  },
  "object_class_forms": {
    "list": <bool>
  },
  "object_models": {
    "list": <bool>,
    "view": <bool>,
    "create": <bool>,
    "edit": <bool>
  },
  "roles": {
    "list": <bool>,
    "view": <bool>,
    "create": <bool>,
    "edit": <bool>,
    "delete": <bool>
  },
  "outbound_mail_setup": {
    "view": <bool>,
    "edit": <bool>
  },
  "message_templates": {
    "list": <bool>
  },
  "sequences": {
    "list": <bool>,
    "view": <bool>,
    "create": <bool>,
    "edit": <bool>,
    "delete": <bool>
  },
  "single_sign_on": {
    "list": <bool>,
    "view": <bool>,
    "create": <bool>,
    "edit": <bool>,
    "delete": <bool>
  },
  "tasks": {
    "list": <bool>
  },
  "task_templates": {
    "list": <bool>,
    "view": <bool>,
    "create": <bool>,
    "edit": <bool>,
    "delete": <bool>
  },
  "task_group_templates": {
    "list": <bool>,
    "view": <bool>,
    "create": <bool>,
    "edit": <bool>,
    "delete": <bool>
  },
  "ui_config": {
    "view": <bool>,
    "create": <bool>
  },
  "users": {
    "list": <bool>,
    "view": <bool>,
    "create": <bool>,
    "edit": <bool>,
    "delete": <bool>
  },
  "standard_authentication": {
    "view": <bool>,
    "edit": <bool>
  },
  "user_groups": {
    "create": <bool>,
    "list": <bool>
  }
}
```

### Sorting

Not available.

### Filtering

Not available.

### Errors

| Error                     | Response code   | Message                                                                             |
|---------------------------|-----------------|-------------------------------------------------------------------------------------|
| Insufficient permissions  | 403 Forbidden   | "detail": "You do not have permission to perform this action."                      |

## GET /api/users/`id`/user-groups/

Returns list of groups where a given user is a member.

### Permissions

Requires `authentication` and `users.view` permission.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> GET /api/users/`id`/user-groups/

### Response

| Key            | Type  | Notes                                                                              |
|----------------|-------|------------------------------------------------------------------------------------|
| limit          | int   |                                                                                    |
| offset         | int   |                                                                                    |
| total\_count    | int   | Total number of results visible to the user (based on permissions).                |
| filtered\_count | int   | Number of results visible to the user (based on permissions) with filters applied. |
| next           | url   | Next page URL (null if there is no next page)                                      |
| previous       | url   | Previous page URL (null if there is no previous page)                              |
| results        | Array | List of results. Described in the next table.                                      |

#### Response `results` array

| Key                   | Type      | Notes                                             |
|-----------------------|-----------|---------------------------------------------------|
| id                    | int       | User Group id                                     |
| name                  | string    | User Group name                                   |
| added\_at              | datetime  | timestamp when the user was added to a user group |
| created\_at            | datetime  | timestamp when the User Group was created         |
| created\_by            | user      | user (object) who created the User Group          |
| modified\_at           | datetime  | timestamp when the User Group was modified        |
| modified\_by           | user      | user (object) who modified the User Group         |
| num\_of\_members        | int       | number of group members                           |
| num\_of\_owners         | int       | number of group owners                            |
| \_meta.permissions     | Object    | Object describing permissions.                    |

* Successful status `200 OK`
* Response body schema

```json
{
  "limit": <int>,
  "offset": <int>,
  "filtered_count": <int>,
  "total_count": <int>,
  "next": <str | null>,
  "previous": <str | null>,
  "results": [
    {
      "id": <int>,
      "name": <str>,
      "added_at": <datetime>,
      "created_by": <user>,
      "modified_at": <datetime>,
      "modified_by": <user>,
      "num_of_members": <int>,
      "num_of_owners": <int>,
      "_meta": {
        "permissions": {
          "list": <bool>,
          "view": <bool>,
          "create": <bool>,
          "edit": <bool>,
          "delete": <bool>
          "edit_perm_sets": <bool>
          "edit_members": <bool>
          "edit_owners": <bool>
        }
      }
    }
  ]
}
```

### Sorting

| Parameter      | Example                              | Notes          |
|----------------|--------------------------------------|----------------|
| id             | /api/users/?ordering=id              | Ascending      |
| id             | /api/users/?ordering=-id             | Descending (-) |
| name           | /api/users/?ordering=name            | Ascending      |
| name           | /api/users/?ordering=-name           | Descending (-) |
| added\_at       | /api/users/?ordering=added\_at        | Ascending      |
| added\_at       | /api/users/?ordering=-added\_at       | Descending (-) |
| num\_of\_members | /api/users/?ordering=num\_of\_members  | Ascending      |
| num\_of\_members | /api/users/?ordering=-num\_of\_members | Descending (-) |
| num\_of\_owners  | /api/users/?ordering=num\_of\_owners   | Ascending      |
| num\_of\_owners  | /api/users/?ordering=-num\_of\_owners  | Descending (-) |
| created\_at     | /api/users/?ordering=created\_at      | Ascending      |
| created\_at     | /api/users/?ordering=-created\_at     | Descending (-) |
| modified\_at    | /api/users/?ordering=modified\_at     | Ascending      |
| modified\_at    | /api/users/?ordering=-modified\_at    | Descending (-) |

### Filtering

Please check [ALX API standards](/api/standards/#filtering-predicates) for predicates available per type.

| Parameter        | Type     |
|------------------|----------|
| id               | int      |
| name             | email    |
| added\_at         | datetime |
| num\_of\_members   | int      |
| num\_of\_owners    | int      |
| created\_at       | datetime |
| created\_by       | user     |
| modified\_at      | datetime |
| modified\_by      | user     |

### Errors

| Error                    | Response code   | Message                                                                              |
|--------------------------|-----------------|--------------------------------------------------------------------------------------|
| Wrong ordering value     | 400 Bad Request | "ordering": \["Select a valid choice. {value} is not one of the available choices."]|
| Insufficient permissions | 403 Forbidden   | "detail": "You do not have permission to perform this action."                       |
| Invalid `id` in URL      | 404 Not Found   | "detail": \["Not found."]                                                           |

## OPTIONS /api/users/`id`/user-groups/

### Permissions

Requires `authentication` only.

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

> OPTIONS /api/users/`id`/user-groups/

### Response

* Successful status `200 OK`
* Response body:

```json
{
  "list": {
    "columns": [
      {
        "alias": "id",
        "type": "int",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range" 
        ],
        "sort_ok": true
      },
      {
        "alias": "name",
        "type": "string",
        "predicates": [
          "exact",
          "iexact",
          "contains",
          "icontains",
          "startswith",
          "istartswith",
          "endswith",
          "iendswith" 
        ],
        "sort_ok": true
      },
      {
        "alias": "added_at",
        "type": "datetime",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range" 
        ],
        "sort_ok": true
      },
      {
        "alias": "created_by",
        "type": "user",
        "predicates": [
          "exact",
          "in" 
        ],
        "sort_ok": false,
        "autocomplete": "/api/users/autocomplete/?text__icontains=" 
      },
      {
        "alias": "modified_by",
        "type": "user",
        "predicates": [
          "exact",
          "in" 
        ],
        "sort_ok": false,
        "autocomplete": "/api/users/autocomplete/?text__icontains=" 
      },
      {
        "alias": "num_of_members",
        "type": "int",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range" 
        ],
        "sort_ok": true
      },
      {
        "alias": "num_of_owners",
        "type": "int",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range" 
        ],
        "sort_ok": true
      },
      {
        "alias": "created_at",
        "type": "datetime",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range" 
        ],
        "sort_ok": true
      },
      {
        "alias": "modified_at",
        "type": "datetime",
        "predicates": [
          "exact",
          "gt",
          "gte",
          "lt",
          "lte",
          "range" 
        ],
        "sort_ok": true
      }
    ]
  }
}
```

## GET /api/users/ws-auth/

### Permissions

Requires `authentication`

### Request

* Headers

```
Content-Type: application/json
Authorization: JWT access_token
```

* Schema

```json
GET /api/users/ws-auth/
```

### Response

| Key                    | Type     | Notes                                                                                                                                                 |
|------------------------|----------|-------------------------------------------------------------------------------------------------------------------------------------------------------|
| uuid                   | string   | The UUID is a standard unique identifier generated by the system and is valid for 5 minutes. The UUID can be used only once, it will expire when use. |

* Successful status `200 OK`
* Response body schema

```json
{
    "uuid": "f1b1b1b1-1b1b-1b1b-1b1b-1b1b1b1b1b1b",
} 
```

### Errors

| Error         | Response code    | Message                                                   |
|---------------|------------------|-----------------------------------------------------------|
| Invalid token | 401 Unauthorized | "detail": "Authentication credentials were not provided." |

---

---
url: /knowledgebase/system-configuration/merge-fields/users-and-groups.md
---

# Users and groups

User-type fields in Catalyst can contain references to both users and user groups. These fields support two different approaches for accessing data: **ID-based access** for compatibility with existing systems, and **object-based access** for enhanced functionality.

### ID-Based Access (Legacy Compatibility)

The traditional approach returns lists of IDs, maintaining compatibility with existing configurations:

```
{{ record.field_user }}
```

Returns an object containing both user IDs and user group IDs.

#### Example output

```
{ "users": [123, 456, 789], "user_groups": [10, 20] }
```

```
{{ record.field_user.user_groups }}
```

Returns an array of user group IDs only.

### Object-Based Access (Enhanced Functionality)

For accessing full user and group objects with all their properties, use the `.meta` syntax:

```
{{ record.field_user.meta.users }}
```

Returns an array of user objects only.

```
{{ record.field_user.meta.meta.user_groups }}
```

Returns an array of user group objects only.

### User Object Properties

When using `.meta.users`, each user object contains:

| Property | Type | Description |
| --- | --- | --- |
| `KEEP 0018` | integer | User ID |
| `KEEP 0019` | string | User's first name |
| `KEEP 0020` | string | User's last name |
| `KEEP 0021` | string | Email address |
| `KEEP 0022` | string | Company name |
| `KEEP 0023` | string | Phone number |
| `KEEP 0024` | string | Mobile phone number |
| `KEEP 0025` | boolean | Deletion flag - `KEEP 0026` |
| `KEEP 0027` | enum | Account type enum - `KEEP 0028` |

#### Complete user object example

```
  [
    {
      "id": 525,
      "first_name": "Bridget",
      "last_name": "Marquardt",
      "username": "bridget.marquardt826@example.com",
      "company_name": "",
      "phone": "16253372", 
      "mobile": "27363737" 
    },
    {
      "id": 591,
      "first_name": "Abelardo",
      "last_name": "Gutkowski",
      "username": "abelardo.gutkowski752@example.com",
      "company_name": "",
      "phone": "76235342", 
      "mobile": "93833722" 
    },
    {
      "id": 795,
      "first_name": "Aaron",
      "last_name": "Dalton",
      "username": "aaron@example.domain",
      "company_name": "",
      "phone": "999383833", 
      "mobile": "0002923832" 
    }
  ]
```

#### Example usage

```
{% for user in record.field_assignees.meta.users %}
  - {{ user.first_name }} {{ user.last_name }} ({{ user.username }})
{% endfor %}
```

#### Indexing users

You can access specific users by index:

```
{{ record.field_assignees.users[0] }} 
{{ record.field_assignees.users[0].username }} 
{{ record.field_assignees.users[1].first_name }}
```

#### Hidden properties

Some properties are not returned by default but can be accessed explicitly:

```
{{ record.field_assignees.users[0].is_deleted }} 
{{ record.field_assignees.users[0].account_type }}
```

### Deleted Users Handling

When a user is deleted from the system:

* Only the `id` property is returned
* All other properties are **anonymized** for privacy
* The user object will look like: `{"id": 525}`

### Iteration Examples

#### Basic user loop

```
{% for users in record.field_usertype.users %} 
    User ID: {{ users.id }}
    Account type: {{ users.account_type }}
{% endfor %}
```

#### Safe property access

```
{% for user in record.field_assignees.users %} 
    {% if user.first_name %} 
        Active User: {{ user.first_name }} {{ user.last_name }} 
    {% else %} 
        Deleted User (ID: {{ user.id }}) 
    {% endif %} 
{% endfor %}
```

### User Group Object Properties

When using `.meta.user_groups`, each group object contains:

* `id` - User ID
* `name` - Group name
* `num_of_members` - Number of group members

#### Complete user group object example

```
    [
    {
      "id": 525,
      "name": "Team ABC",
      "num_of_members": 20
    },
    {
      "id": 999,
      "name": "Lawyers united",
      "num_of_members": 400
    },
    {
      "id": 1249,
      "name": "Research team",
      "num_of_members": 6
    }
  ]
```

#### Example

```
{% for group in record.field_teams.meta.user_groups %}
  - {{ group.name }} ({{ group.num_of_members }} members)
{% endfor %}
```

#### Indexing user groups

You can access a specific user group by index:

```
{{ record.field_usertype.user_groups[0] }}
{{ record.field_usertype.user_groups[0].name }}
{{ record.field_usertype.user_groups[0].num_of_members }}
```

### Mixed Access Example

You can combine both users and groups in a single iteration:

```
{% for item in record.field_assignees.meta %}
  {% if item.username %}
    User: {{ item.first_name }} {{ item.last_name }}
  {% else %}
    Group: {{ item.name }} ({{ item.num_of_members }} members)
  {% endif %}
{% endfor %}
```

### Supported Contexts

User-type merge fields work in:

* Document templates
* Sequencer actors (API Call, Send Message, Local Variable)
* Related records merge fields
* All other contexts where merge fields are supported

### Useful info

**Empty field:** If no users are assigned, the array will be empty `[]`.

`id`
`first_name`
`last_name`
`username`
`company_name`
`phone`
`mobile`
`is_deleted`
`hidden`
`account_type`
`hidden`

---

---
url: /knowledgebase/administration/user-groups/users-and-groups-visibility.md
---

# Users and Groups visibility

From Catalyst 1.10 onwards, visibility of users and User Groups is controlled through List permissions.

List permissions determine which users and User Groups appear throughout the platform when someone needs to select people or groups.

This helps ensure that users can only see and select the users and groups they are allowed to work with.

## How visibility works

List permissions control who can see and select users and User Groups across Catalyst.

They affect areas such as:

* task assignment
* record ownership
* Object Class ownership
* Permission Sets
* user-type fields
* filters and dropdown lists

If a user does not have the relevant List permission, the user or User Group will not appear in selection fields.

## User-type field exception

There is one exception.

If a user-type field has been configured with specific users or User Groups, those configured options are available to users who can create or edit records containing that field.

This applies even if the user would not normally have permission to list those users or User Groups.

In this situation, limited details such as name and email address may be visible for the selected users.

## How List permissions are granted

Permissions for viewing and listing users and User Groups are closely connected.

When a user has permission to **view** a User Group, they can also list the members of that group.

This allows users to select the relevant users or User Groups in areas where visibility is required.

## User Group Permission Sets

Each User Group has default Permission Sets that control who can view and interact with the group.

### Owners

Owners have full permissions for the User Group:

* View
* Edit
* Delete

These permissions cannot be modified for Owners.

Owners can view the User Group, list its members, and manage the group.

### Members

The Members Permission Set applies to all members of the User Group who are not Owners.

By default, Members have **View** permission. This allows them to see the User Group and list other members in places such as task assignment, default task assignee selection, and Permission Set assignment.

### Everyone

The Everyone Permission Set applies to users who are not Owners or Members of the User Group.

By default, no permissions are granted.

This means users outside the group cannot list the group's members unless additional permissions are assigned.

### Custom Permission Sets

Custom Permission Sets can be created to provide more precise visibility.

For example:

* a legal team may need visibility of a compliance User Group
* a team leader may need visibility of a group they do not own
* a department may need access to specific users without seeing all users in the system

![User Group Permission Sets controlling visibility of users and groups](../../../images2/zendesk_4669904917535_001_da0e95ae3994.gif)

## API-based visibility for Config Admins

Config Admin users can be granted the `users.list` permission through the API by using a dedicated Role.

This permission allows them to list and view all users across the system, even if those users are not part of User Groups they own.

This is useful where trusted administrators need broader user visibility while other users remain restricted to their assigned groups.

![API configuration granting Config Admin users global users.list permission](../../../images2/zendesk_4669904917535_002_d3bf623b61c4.gif)

## Super Admin visibility

Users with a Super Admin account type have full List permissions across the platform.

They can view and list all users and User Groups, including full user account details.

## Visibility for 1-time completion users

Users with a 1-time completion account type cannot be assigned to User Groups.

However, they still need to be visible for some actions, such as:

* task assignment
* filtering
* user-type fields

Visibility of 1-time completion users is automatically available to:

* Super Admin users
* Config Admin users with the appropriate `users.list` permission granted through the API

This allows task-specific users to be assigned where required without exposing other user information more widely.

## Where List permissions matter

List permissions affect any part of Catalyst where users or User Groups can be selected.

Examples include:

* Task ownership and assignment
* Object Class ownership
* record ownership
* Object Class Permission Sets
* Record Permission Sets
* user-type fields
* default task assignees in Sequences
* User Group management
* dropdown autocompletes and filters

Users can always list themselves. This ensures that a user can select themselves when needed, such as assigning themselves to a task.

## Things to remember

1. Users can always see and select themselves.
2. Viewing a User Group also allows its members to be listed.
3. Super Admin users have unrestricted visibility across the system.
4. Config Admin users require the `users.list` permission to view all users.
5. 1-time completion users cannot belong to User Groups.
6. User-type fields may display configured users even when normal List permissions would otherwise prevent them from appearing.
7. User Group visibility is controlled through User Group Permission Sets.
8. The user who creates a User Group automatically becomes its Owner and a member of the group.
9. The maximum number of User Groups you can have in your system is 1,000.

---

---
url: >-
  /knowledgebase/release-notes/release-notes-1.10/users-and-groups-visibility-control.md
---

# Users and groups visibility control

Balancing security with operational efficiency shouldn't feel like walking a tightrope. Our latest User Group Permission Sets update transforms this challenge into a strategic advantage.

Now you can manage precise user and group visibility across your entire platform through an intelligent permission system that adapts to your organisation's needs. This update ensures that the right users have access to the right information, helping you maintain both operational efficiency and strict compliance with privacy standards.

## What are List permissions?

**List permissions** are essential for controlling who can see and select users and groups across the system. They are the foundation of user and group visibility across the platform. Without the appropriate permissions, users will not appear in selection fields, preventing unauthorised or unnecessary access to specific individuals or groups.

## How are List permissions granted?

Permissions for **viewing** and **listing** users and groups are closely connected - when you have permission to **view** users or user groups, you automatically gain **list** permissions for those users and groups as well.

Importantly, being able to view a user group also enables you to list all members within that group, allowing for seamless selection and interaction wherever user or group visibility is required in the system.

**List permissions can be granted through several mechanisms:**

### 1. User Group Permission Sets

Each user group has predefined permission sets - Owners, Members, and Everyone - that determine who can view and interact with the group.

* **Owners**: Group owners have full permissions - view, edit, and delete - over the group. Importantly, these permissions cannot be modified for group owners. Owners will have full visibility into the group and can manage it completely.
* **Members**: This permission set applies to all members of the group. By default, "view" permission is set to true, meaning group members can see the group as a whole and list its other members in contexts like task assignments, default task assignees selection, or permission sets.
* **Everyone**: This set applies to all other users in the system who are not part of the group. By default, no permissions are granted, meaning that users outside the group cannot list any of the group members. This is crucial in industries like finance, where only authorised users should have access to specific groups, such as compliance officers or risk management teams.
* **Custom Permission Sets**: Custom Permission Sets can be created to provide more granular control over which users or departments can view specific groups or users. For instance, a legal department might need visibility into compliance groups, while HR can be restricted from viewing sensitive case-related groups.

**![Group perm sets.gif](../../../images2/zendesk_4566657938591_001_da0e95ae3994.gif)**

### 2. API (for Config Admins)

Config Admins can be granted the users.list permission exclusively through the API by a dedicated role. This role enables them to list and view all users across the system, even if those users are not part of their assigned groups.

For large companies, this API-based permission ensures that trusted administrators can manage user visibility on a global scale, while regular users remain restricted to their specific groups.

![Group perm sets2.gif](../../../images2/zendesk_4566657938591_002_d3bf623b61c4.gif)

### 3. Super Admins

These types of users have full **list permissions** throughout the platform. This ensures that system-wide administrators maintain comprehensive oversight and manage users and permissions effectively.

## Visibility for One-Time Completion (1TC) Accounts

A key addition to this update is the handling of **One-Time Completion (1TC) Accounts**. Users with 1TC accounts are crucial for specific workflows but cannot be assigned to any group. However, they need to remain visible for task assignments, filtering, and user-type fields.

**Therefore, visibility of 1TC users is automatically granted to:**

* **Super Admins**: Given their global visibility.
* **Config Admins** with the appropriate users.list permission via API.

This ensures seamless management of temporary or task-specific users while maintaining strict control over visibility.

## Where do list permissions matter?

List permissions enable users to see and choose group members or groups in any part of the system where user and user group selection is available, such as:

* Task ownership and assignment
* Object Class and Record ownership
* Permission Sets (both Object Class and Record)
* User-Type Class fields
* Default task assignees in Sequences
* User Group management and Permission Sets
* Dropdown autocompletes and filters

Users will always have permission to list themselves. This ensures that every user can select themselves when needed, such as assigning themselves to a task, regardless of group or system permissions.

## Summary

This new feature offers a significant leap forward in how user visibility is managed within the platform. By tying **view** and **list permissions** together, we've made it easier to enforce security protocols while maintaining the flexibility needed for complex workflows.

With more control over who can view, list, and assign users, you can now enforce tighter security protocols while maintaining flexible workflows. Experience how this intelligent permission system can protect your sensitive data while streamlining your team's daily operations - all through an intuitive, group-based control panel.

---

---
url: /knowledgebase/administration/users-roles-and-user-groups.md
---
# Users Roles And User Groups

This section is **currently empty** or under construction.

---

---
url: >-
  /knowledgebase/administration/authentication-objects/using-an-authentication-object-in-an-api-call.md
---

# Using an Authentication object in an API call

An Authentication object allows you to securely store authentication details for supported providers and reuse them across multiple API calls.

This means credentials can be managed in one place rather than being entered separately into each API call configuration.

For more information, see [What is an Authentication object and how do I configure it?](/knowledgebase/administration/authentication-objects/what-is-an-authentication-object-and-how-do-i-configure-it/).

## Set up the API call

To use an Authentication object in an API call:

1. Right-click the API call actor and select **Configure**.

2. Choose the required **Type**, **Method**, and **Data Type**.

3. In the **Authentication** menu, select **Auth Object**.

![API call configuration showing Auth Object selected in the Authentication menu](/knowledgebase/images/img_4410153067537_1776896085.png)

4. A new field called **Auth Object** is displayed.

5. Select the required Authentication object from the list.

![API call configuration showing the Auth Object selection field](/knowledgebase/images/img_4410153067537_1776896086.png)

6. Complete the remaining API configuration.

7. Test the API call so that it becomes active.

8. Save the API call configuration.

## Things to remember

1. An Authentication object can be reused in multiple API calls.
2. Updating an Authentication object updates the credentials used by all API calls that reference it.
3. The maximum number of Authentication objects allowed in your system is 100.

---

---
url: >-
  /knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/using-conditional-logic-in-a-form.md
---

# Using conditional logic in a form

You may have seen our article about constructing a [Task template - self contained form](/knowledgebase/system-configuration/task-templates/response-configuration---task-type---complete-self-contained-form/). These can be created with one or two fields. However, very comprehensive forms can also be constructed.

They can have multiple sections, up to three columns, numerous instructions and several different data input formats.

In addition, these forms can contain conditional logic, which allows you to change the behaviour of the form based on what the user selects or enters into a field.

## Forms that support conditional logic

**Conditional logic is available in the following forms:**

* Task templates
* Object classes
  * create/edit view
  * summary view
  * standalone forms

## Example: create a Subscription and Shareholders' Agreement task template form

To demonstrate this feature, we will show you the steps to create a Subscription and Shareholders' Agreement task template form.

1. Create the task template and call it "Subscription and Shareholders' Agreement".
2. Click on "Create response form".
3. Click on "New Section 1" and call it "Subscription and Shareholders' Agreement". Give this section two columns and leave the column ratios set at 50:50.
4. **Add and configure the fields** in sections which do not require conditional logic, as shown below in preview mode:

   * Most fields are single or multi-line text.
   * Some have default values to indicate the format required, eg a numeric field is used for **Shareholding - right to receive financial information (%)** and the default is entered as 10.
   * The Description input in the field properties is used for any instructional text about that field.
   * Sections without names are used to break up the form into specific subject areas which do not require any labelling. As an alternative, you can use the option to switch off **Show this section header**. This will also reduce the size of the header.

![mceclip0.png](../../../images2/zendesk_4409196021265_001_26211681645e.png)

In the first section of the form where conditional logic is required, the user will be asked to enter the details of Founders. Subsequent sections will require them to enter details of Investors, individuals with Pre Completion Shareholdings and individuals with Post Completion Shareholdings.

**The first step** is to find out how many of each type of individual there are.

5. **Add a control field** using a Single select field labelled "Select the number of founders". Enter options 1-4, for example.

![mceclip0.png](../../../images2/zendesk_4409196021265_002_9eb35017b5da.png)

Note that the field has been made mandatory by ticking the **Required** option in the field properties. This is really important if you have subsequent sections which will only display on the basis of the value in a field like this one. However, do bear in mind that fields used to control conditional display do not have to be mandatory; it might not matter that the field is left blank, it just means that none of the sections using the logic from this field will be shown.

A dropdown list has been chosen over radio buttons. You can use **Preview** in order to check how the form will display.

![mceclip1.png](../../../images2/zendesk_4409196021265_003_abb8a6d91e2a.png)

In this example, the user can select between 1 and 4 founders. This means that you must add 4 more sections to your form which include the fields where the details of 1, 2, 3 or 4 founders can be entered.

## Set section conditional visibility

6. **Configure section visibility.** Having done that, click on to the first of these sections. The **Conditional Visibility** control is at the bottom of the **Section Properties**.

Click the + button and find the field which will be used to control the conditional visibility - in this case, select **number\_of\_founders**. Note that the display shows you the field alias, not the field label; this is because the alias is unique, whereas the label does not have to be.

Next, select the appropriate operator. **Choices are:** **is not empty**, **is equal to** and **is not equal to**.

The screenshot below shows that the section called **Details of one founder** will be displayed if the field Number of Founders = 1.

![mceclip2.png](../../../images2/zendesk_4409196021265_004_111bef91dab7.png)

You can try this out in preview mode.

![mceclip3.png](../../../images2/zendesk_4409196021265_005_76ccb0c99d87.png)

Any field which is used to control visibility of a section will contain a blue icon. Hovering over the icon will tell you that the field has relations:

![mceclip0.png](../../../images2/zendesk_4409196021265_006_a0094239e3c1.png)

Likewise, a section which is displayed via conditions will have a similar blue icon. When hovering over this, you are told that the section contains conditional visibility:

![mceclip1.png](../../../images2/zendesk_4409196021265_007_d694ff4498cf.png)

7. **Repeat the logic setup** for the following three sections.

![mceclip4.png](../../../images2/zendesk_4409196021265_008_658cbf1985f1.png)

![mceclip5.png](../../../images2/zendesk_4409196021265_009_3f58906ba9e5.png)

If the form requires it, you can use more than one condition to determine that a section should be displayed. **Remember:** these conditions are **AND** conditions. Therefore, if you use more than one condition, all of them must be met for the section to be displayed.

In the example shown below, the section called **Details of 3 founders** will only display if:

* the value in field **number\_of\_founders** = 3 AND
* the value in field **value\_of\_single\_ordinary\_share** = 100

![mceclip6.png](../../../images2/zendesk_4409196021265_010_e26030771e3f.png)

## Repeat for other groups and save

8. Repeat from point 5 for each of the other groups of people whose details must be captured - Investors, individuals with Pre Completion Shareholdings and individuals with Post Completion Shareholdings.

9. Configure the other task template tabs as required and save.

---

---
url: /knowledgebase/record-and-task-forms/using-conditional-logic-in-forms.md
---
# Using Conditional Logic in Forms

This section explains how to use conditional logic to make forms in Autologyx more dynamic and responsive.

Conditional logic allows a form to change based on the values a user enters. This can be used to show or hide fields, sections, or other form content, helping you create form experiences that are clearer, more relevant, and easier for users to complete.

Use this section to understand how conditional logic works in practice, how it can improve the user experience, and what to consider when changing forms that already rely on existing conditional rules.

## What you will find in this section

* [Using conditional logic in a form](/knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/using-conditional-logic-in-a-form/)
* [What happens if I change the properties of a field used in conditional logic](/knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-change-the-properties-of-a-field-used-in-conditional-logic/)
* [What happens if I remove a column that has a field which is used in conditional logic](/knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-remove-a-column-that-has-a-field-which-is-used-in-conditional-logic/)
* [What happens if I remove a field which controls conditional logic in a form](/knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-remove-a-field-which-controls-conditional-logic-in-a-form/)
* [What happens if I remove a section that has a field which is used in conditional logic](/knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-remove-a-section-that-has-a-field-which-is-used-in-conditional-logic/)

## Notes

::: info
This section is focused on making forms behave differently based on user input, rather than on the wider layout or structure of the form itself.
:::

::: tip
Use conditional logic to simplify the user experience by showing people only the fields and sections that are relevant to them at that point in the form.
:::

---

---
url: /knowledgebase/system-configuration/using-docusign-with-catalyst.md
---
# Using Docusign With Catalyst

**Browse the sections below:**

* [1. Introduction](/knowledgebase/system-configuration/using-docusign-with-catalyst/1.-introduction/)
* [2. Setting Up A Free Developer Docusign Account](/knowledgebase/system-configuration/using-docusign-with-catalyst/2.-setting-up-a-free-developer-docusign-account/)
* [3. Creating An Authentication Object For Use With Docusign](/knowledgebase/system-configuration/using-docusign-with-catalyst/3.-creating-an-authentication-object-for-use-with-docusign/)
* [4. Configuring An Api Call To Create An Envelope In Docusign](/knowledgebase/system-configuration/using-docusign-with-catalyst/4.-configuring-an-api-call-to-create-an-envelope-in-docusign/)
* [5. Monitoring The Status Of Your Docusign Envelope](/knowledgebase/system-configuration/using-docusign-with-catalyst/5.-monitoring-the-status-of-your-docusign-envelope/)
* [6. Monitoring The Signing Status Of Individual Recipients](/knowledgebase/system-configuration/using-docusign-with-catalyst/6.-monitoring-the-signing-status-of-individual-recipients/)
* [7. How To Retrieve The Signed Document And Store Within Catalyst](/knowledgebase/system-configuration/using-docusign-with-catalyst/7.-how-to-retrieve-the-signed-document-and-store-within-catalyst/)
* [8. System Migrations And Docusign Authentication Objects](/knowledgebase/system-configuration/using-docusign-with-catalyst/8.-system-migrations-and-docusign-authentication-objects/)

---

---
url: /knowledgebase/using-help-and-support.md
---
# Using Help and Support

## Sections

* [FAQs](/knowledgebase/using-help-and-support/faqs/)
* [We're here to help](/knowledgebase/using-help-and-support/we're-here-to-help/)

---

---
url: >-
  /knowledgebase/applied-ai/applied-ai-and-the-sequencer/public-ai-providers/openai/making-api-calls-to-openai.md
---

# Using the API Call actor with AI services

**Placeholder:** This page is a placeholder for guidance about using the Sequencer API Call actor to initiate outbound REST requests to AI services, including patterns that use Loop actors and playbook-style Object Classes for reusable prompt functions.

---

---
url: >-
  /knowledgebase/system-configuration/sequences-for-relational-records/using-the-sequence-runner-actor-for-one-object-class.md
---

# Using the Sequence Runner actor for one Object Class

Although the **Sequence Runner** actor will quite often be used together with the **Relation Lookup** actor so that an action such as assigning a task or updating a field may be carried out against the parent or child records which the Relation Lookup has identified, ([click here](/knowledgebase/system-configuration/sequences-for-relational-records/a-guide-to-using-the-relation-lookup-and-sequence-runner-actors-together/) for a guide), there are many occasions when it will be used alone.

The Sequence Runner can be used at any point in a sequence to run another sequence for a sub-process against the same object class. This allows you to keep sequences from getting overly large and therefore difficult to maintain.

There are two Sequence Runners in the below screenshot - see the pink actors!

![Screenshot\_2023-05-31\_at\_19.36.02.png](/knowledgebase/images/img_11111322757021_1776895891.png)

## When to use the Sequence Runner alone

The Sequence Runner can be triggered for all records or a subset of records in the same object class as the starting sequence; your trigger conditions would determine for which records in the case of a subset.

It could be used to activate sequences by subject matter. For example, you could have a starting sequence for intake of a number of different types of matters or claims in which would be included your KYC tasks. You could then use the Sequence Runner to commence different processes for Real Estate, Commercial, Employment and other types of case.

Alternatively, your use case may be to do with the additional legal compliance required when operating in different countries, or screening compliance for working in different sectors. This type of sub-process could be triggered from your main sequence once the common core checks have been completed.

## Example: escalation tasks for Mortgage Applications

The following example shows how you might use one sequence for all escalation tasks relating to Mortgage Applications. If these tasks are all escalated to one user or a group of users, you can make them the default task assignee(s) when creating the sequence to be activated from the main one.

The above screenshot shows the first few steps of the main sequence. You can see that once data consent has been given in the "GDPR Agreement" task, there are two further tasks:

* **Review application - intake**
* **Check affordability**

Both of these tasks require the task owner to make a decision as to whether this part of the mortgage application can be approved, or if it should be rejected or escalated.

The task template for the Affordability Check is shown below.

![Screenshot\_2023-05-31\_at\_16.06.46.png](/knowledgebase/images/img_11111322757021_1776895891.png)

### Escalate outcome

Each of the 3 outcomes has a very distinct route in the process:

|  |  |
| --- | --- |
| **The applicant meets the affordability criteria** - the Application Status is updated to "Affordability passed" and the next task called "Primary terms" is created for the record. | ![Screenshot\_2023-05-31\_at\_16.41.21.png](../../../images2/zendesk_11111322757021_003_44e8ce2e30c7.png) |
| **The applicant DOES NOT meet the affordability criteria** - when this option is chosen in the task form a new field is presented where the user can enter the reason for this decision.  This input is merged into an email to the applicant(s) informing them of their failure to meet the criteria.  The application status is updated to "Application rejected".  The process would stop at this point. | ![Screenshot\_2023-05-31\_at\_16.43.16.png](../../../images2/zendesk_11111322757021_004_69bba39ca0fe.png)  ![Screenshot\_2023-05-31\_at\_16.49.39.png](../../../images2/zendesk_11111322757021_005_1f8feba93476.png) |

**Escalate** - this is where the Sequence Runner is used.

The first screenshot shows that the application status is updated to "Escalate affordability".

![Screenshot\_2023-05-31\_at\_16.52.49.png](/knowledgebase/images/img_11111322757021_1776895892.png)

Following this, the Sequence Runner has been configured so that it is looking at "Self" records, which means records in the same object class as the current sequence is running against, in this case, Mortgage Applications.

![Screenshot\_2023-05-31\_at\_17.01.22.png](/knowledgebase/images/img_11111322757021_1776895892.png)

The sequence which the actor will run is one called "Escalations".

### Triggering the escalation sequence

The below screenshot shows the part of this sequence which relates to the escalation at the affordability check in the starting sequence.

The trigger configuration is set to **"When Sequence Activated"**. However, because this sequence is activated for more than one type of escalation, there is a supplementary condition which is looking for records where the field "Affordability check outcome" is equal to Escalate.

![Screenshot\_2023-05-31\_at\_19.15.53.png](/knowledgebase/images/img_11111322757021_1776895892.png)

If a record matches this condition, a task called "Affordability Check - escalation" will be assigned. This check has two possible outcomes:

* **Affordability failed** - the application status is updated to "Application rejected"; an email is sent to the applicant(s) to let them know of their failure to meet the criteria. The process would stop at this point.
* **Affordability approved** - the application status is updated to "Affordability passed". An email is sent to all record owners to advise them of this outcome.

### Rejoining the main sequence

Going back to the starting sequence, because the task "Affordability Check - escalation" was of the "Update object record" type, the field where the outcome was recorded can be used to rejoin the main process at the appropriate next stage.

The sequence trigger is **"When Record Updated"** with a supplementary condition using the field which was updated in the escalation task. Following this update, the "Primary terms" task is created for the record.

![Screenshot\_2023-05-31\_at\_19.40.13.png](/knowledgebase/images/img_11111322757021_1776895893.png)

The process will continue through the main sequence workflow.

---

---
url: /api/catalyst/resources/platform-information/version.md
---
# Version

This page documents endpoints that return platform version information.

## GET /api/version/

Returns the current platform versions. This is a global endpoint accessible via any tenant domain.

### Permissions

Public access

### Request example

* Headers

```
Content-Type: application/json
```

### Response

| Key             | Type     | Notes                                      |
|-----------------|----------|--------------------------------------------|
| version         | string   | version from git describe or related file. |
| version\_history | string   | version from git describe or related file. |

* Successful status `200 OK`
* Response body schema:

```json
{
    "version": <string>,
    "version_history": <string>
}
```

***

## GET /api/version/ (Admin Portal API — cluster-specific)

Returns the versions of all components installed on a specific cluster and namespace. The target cluster and namespace are identified by the domain used to make the request.

Each active Catalyst instance is deployed under a unique domain in the format:

```
<namespace>.<cluster>.<domain>
```

For example: `catalyst-vnext-be.iac-eu-west-1-0.autologyx.com`

For the list of deployed Catalyst instances, see [clientvalue.autologyx.com](https://clientvalue.autologyx.com).

### Permissions

Requires a valid Admin Portal API Key sent in the `X-API-Key` HTTP header over HTTPS.

### Request example

* Headers

```
Content-Type: application/json
X-API-Key: <key>
```

### Response

| Key             | Type   | Notes                                     |
|-----------------|--------|-------------------------------------------|
| version\_ui      | string | Version of the UI component installed.    |
| version         | string | Version of the API component installed.   |
| version\_history | string | Version of the History component installed. |

* Successful status `200 OK`
* Response body schema:

```json
{
    "version_ui": "<string>",
    "version_api": "<string>",
    "version_history": "<string>"
}
```

### Errors

| Error              | Status code       | Notes           |
|--------------------|-------------------|-----------------|
| Unauthorized       | 401 Unauthorized  | Standard message |
| Incorrect API Key  | 403 Forbidden     | Standard message |

---

---
url: /knowledgebase/release-notes/release-notes-1.9/viewer-panel.md
---

# Viewer panel

We've all been there. You're neck-deep in documents, downloading and viewing them one by one, especially when you have a stack to review. It can be a real time-consuming hassle. We're thrilled to introduce the all-new Viewer panel, designed to streamline your document workflow and make your life a whole lot easier.

## Overview

The Viewer panel opens directly when you click on a saved document in Card view, when editing records, and on Task completion pages.

**Document actions:** Our document upload/view component has been slightly modified - you can find other document-related actions, such as delete or download, in the action menu at the end of each document attached to the field.

![Viewer1\_article.gif](/knowledgebase/images/img_17929936583581_1776895645.png)

## Key features of the new panel

* **Thumbnail view:** Get a quick overview of your document without having to open it.
* **Pagination:** Easily navigate through your document, one page at a time.
* **Zoom in and out:** Get a closer look at the details or zoom out to see the big picture.
* **Search:** Find specific text within your document quickly and easily.
* **Fit to width:** View your document at a comfortable width, no matter the size of your panel.
* **Print and download:** Print your document or save it to your computer for later.

![Viewer2\_article.gif](/knowledgebase/images/img_17929936583581_1776895646.png)

## Use cases

Whether you're a legal professional handling contracts, court filings, and case files, or an insurance adjuster navigating policy claims and damage assessments, the Viewer Panel is your go-to solution. Attorneys can swiftly review documents, accelerating case preparation, and claim adjusters benefit from an efficient review of policy documents, medical records, and accident reports, expediting claims processing and elevating customer satisfaction.

**Experience the future of document management today** with the enhanced Viewer Panel - it's time to take your productivity to the next level.

---

---
url: /knowledgebase/using-help-and-support/we're-here-to-help.md
---
# We'Re Here To Help

**Browse the sections below:**

* [Creating A Support Ticket](/knowledgebase/using-help-and-support/we're-here-to-help/creating-a-support-ticket/)
* [Service Levels And Escalation](/knowledgebase/using-help-and-support/we're-here-to-help/service-levels-and-escalation/)
* [What To Expect When You Submit A Support Ticket](/knowledgebase/using-help-and-support/we're-here-to-help/what-to-expect-when-you-submit-a-support-ticket/)

---

---
url: /knowledgebase/administration/web-sockets.md
---
# Web Sockets

**Note:** This section is currently empty or under construction.

---

---
url: /knowledgebase/release-notes/release-notes-1.11/websockets.md
---

# WebSockets

Real-time access to data is essential for maintaining efficiency, improving decision-making, and enhancing user experience. With the introduction of WebSockets in Catalyst, we are taking a major step toward enabling real-time updates for Object Records. This new capability ensures that businesses can receive instant notifications about changes in their data without relying on manual refreshes or periodic polling.

## How it works

WebSockets provide a persistent connection between clients and the server, enabling immediate data updates. This means that whenever an Object Record is created, modified, or deleted, connected clients will be instantly notified, allowing them to react in real time. This is particularly valuable for businesses relying on up-to-date information to make critical decisions.

## Catalyst Elements

This implementation is particularly useful for **Catalyst Elements**, our framework for custom front-end applications that clients frequently use on landing pages. With WebSockets, these Elements can now reflect the latest data without requiring users to refresh the page manually.

## Authentication and connection

**To establish a WebSocket connection:** API users need to generate a unique authentication token. This is done by making a GET request to `/api/users/ws-auth/` endpoint, which returns a one-time use only UUID.

![Websockets1\_article.gif](/knowledgebase/images/img_4702127751327_1776895611.png)

When a WebSocket connection to the endpoint `/ws/events/object-records/` is established, the server starts streaming real-time events related to Object Records.

**These updates include:**

* **New record creation** – ensuring immediate visibility of newly added data.
* **Record deletions** – preventing outdated records from appearing in views.
* **Record updates** – keeping all modifications synchronised without delays.

Each event is broadcast only for the environment defined in the token used for the connection, ensuring secure and contextual data updates.

## Performance limits

Performance has been a top priority in this implementation. The WebSocket service efficiently manages traffic, allowing up to **100 concurrent connections** per client and processing updates within defined limits: a maximum of **1,000 events** per broadcast every **5 seconds** (or sooner if the event limit is reached).

![Websockets2\_article.gif](/knowledgebase/images/img_4702127751327_1776895612.png)

## Release impact

This release lays the groundwork for a system that provides real-time visibility into your data. By enabling WebSockets at the backend, we are paving the way for future enhancements where Catalyst’s UI will dynamically reflect changes as they happen.

This real-time capability is particularly valuable in industries where up-to-the-second information is crucial. In financial services, compliance teams can now track risk assessments in real time. For legal departments managing M\&A due diligence, document review statuses update instantly as teams move through contract assessments, eliminating the traditional drag of information lag.

With WebSockets, your data is always current, always reliable, and always ready to fuel your best decisions. With this first step, we are bringing Catalyst closer to a fully real-time experience, empowering users to make decisions with confidence and efficiency.

---

---
url: /knowledgebase/welcome-introduction-to-catalyst.md
---

# 👋 Welcome & Introduction to Catalyst

Welcome to Catalyst — the Autologyx platform for designing, running, and improving complex operational processes with structure, visibility, and control.

Catalyst is built for teams that need more than a simple workflow tool. It brings together workflow orchestration, structured data, tasks, forms, document automation, integrations, and AI-enabled capabilities in one platform so organisations can tackle demanding, high-volume, and highly regulated work with confidence.

Whether you are here to understand the platform, configure a new solution, explore what other customers have achieved, or find technical reference material, this documentation is designed to help you move quickly from orientation to action.

## What type of user are you?

Different people come to Catalyst with different goals. A good way to get value quickly is to start in the part of the documentation that best matches how you use the platform.

### I am an end user

You may be here to understand how to work with records, tasks, and day-to-day features in the platform.

**Useful starting points:**

* [In-application Help](/knowledgebase/welcome-introduction-to-catalyst/in-application-help/)
* [Workspace](/knowledgebase/workspace/)
* [Tasks](/knowledgebase/workspace/tasks/)

### I am a configuration admin or super admin

You may be responsible for setting up Object classes, Task templates, Sequences, permissions, forms, Document Templates, Authentication Objects, or other platform configuration.

**Useful starting points:**

* [System configuration](/knowledgebase/system-configuration/)
* [Administration](/knowledgebase/administration/)
* [Terminology](/knowledgebase/terminology/)
* [Capacity and System Limits](/api/catalyst/resources/limits)

### I am a developer or integrator

You may be looking for API behaviour, integration patterns, WebSockets, technical standards, or implementation detail.

**Useful starting points:**

* [Catalyst API](/api/catalyst/)
* [API Standards](/api/standards/)
* [WebSockets](/api/websockets/)
* [Event History API](/api/event-history/)
* [Terminology](/knowledgebase/terminology/)

## Why Catalyst matters

Some work is easy to describe but hard to manage well.

It may involve many stakeholders, multiple hand-offs, large numbers of Object Records or documents, changing rules, regulatory pressure, or the need to combine human decision-making with automation. In many organisations, that kind of work ends up spread across email, spreadsheets, shared drives, disconnected tools, and manual workarounds.

Catalyst is designed for exactly those kinds of problems.

It gives organisations a structured way to model their processes, connect their data, automate repeatable work, and keep people in control where judgement still matters. The result is not just faster work, but better operational visibility, stronger consistency, and a platform that can scale as demand grows.

## What Catalyst can help you do

Catalyst is used to support a wide range of use cases, especially where work is process-heavy, data-rich, and operationally important.

**Typical examples include:**

* legal intake and triage
* matter and case management
* contract self-service and contract intelligence
* remediation and repapering programmes
* portfolio and obligation management
* claims and exception handling
* task-driven reviews and operational workflows
* document-heavy processes requiring structure, automation, and auditability

In practice, that means Catalyst can support teams dealing with everything from day-to-day operational work to the kind of “gnarly” enterprise problems that involve scale, complexity, and many moving parts.

## The power of Catalyst

Catalyst is powerful because it does not force you to choose between flexibility and control.

It is designed to help organisations build solutions around their own processes and data model, while still benefiting from a consistent platform foundation.

**That includes:**

* **structured, relational data** built around Object classes and Object Records, so your processes have real context
* **workflow automation** through Sequences and Sequencer to reduce repetitive work and improve consistency
* **forms and task orchestration** through Task templates, Task Group Templates, and guided user interactions
* **document automation** using Document Templates and merge fields to turn structured data into usable outputs
* **integrations** supported by Authentication Objects and API capabilities to connect with the systems your teams already rely on
* **AI-enabled capabilities** to help extend workflow orchestration and decision support where appropriate

For many teams, the value of Catalyst is not just that it automates work. It is that it helps them design better ways of working in the first place.

## Enterprise-ready, without losing usability

Catalyst is used in environments where the work is often complex, high-value, and closely scrutinised.

It is designed to support organisations that need to manage structured processes at scale, particularly where consistency, auditability, operational visibility, and control are essential. That makes it a strong fit for legal operations, corporate services, financial services, insurance, and other settings where teams are handling large volumes of work, documents, decisions, and workflow steps.

That matters because Catalyst is not aimed only at lightweight task automation. It is built for serious operational use, where the challenge is not just to move work faster, but to manage it more intelligently, more consistently, and at enterprise scale.

## Using this documentation

This part of the [Knowledgebase](/knowledgebase/) is here to help you get oriented in Catalyst and understand what is possible.

## What else is available in the docs

As you explore further, the documentation is organised to help different audiences find the right level of detail.

### Knowledgebase

The [Knowledgebase](/knowledgebase/) is the main guide for using and configuring the platform.

**It includes content for:**

* end users
* configuration admins
* super admins
* solution builders
* workflow and form designers

**It covers topics such as:**

* administration
* Object classes and Object Records
* forms and form builder
* Task templates and Sequences
* merge fields and Document Templates
* integrations and Authentication Objects
* release notes and new features

### API documentation

The API documentation provides technical reference material for teams integrating with the platform or working with service-level interfaces.

**This includes:**

* the main [Catalyst API](/api/catalyst/)
* merge fields and technical reference pages
* [Event History API](/api/event-history/)
* [WebSockets](/api/websockets/)
* standards, limits, and other technical guidance

### Technical and reference material

Some pages are designed as implementation reference rather than end-user guidance. These pages are especially helpful for developers, integrators, and technical configuration teams working with:

* API behaviour and standards
* system limits and capacity planning
* service-level interfaces
* WebSockets and real-time updates
* integrations and advanced automation patterns

## A platform that grows with you

One of the strengths of Catalyst is that it can support both immediate operational improvements and longer-term platform thinking.

Some teams start with a single workflow or intake process. Others use Catalyst to standardise how entire categories of work are managed across departments, service lines, jurisdictions, or client portfolios. The platform is flexible enough to support both starting small and growing into something much broader over time.

That is why Catalyst is often best understood not just as a workflow tool, but as an operational foundation for structured work.

## Final thought

The goal of Catalyst is simple to state, even if the work it supports is not: help organisations handle complex work in a way that is more structured, more visible, more scalable, and easier to improve.

If you are new here, this is a good place to begin.

---

---
url: >-
  /knowledgebase/system-configuration/landing-page/welcome-and-introduction-to-catalyst.md
---

# Welcome and introduction to Catalyst

**Landing page**

## About help

Link to article about UI and navigation.

RC to complete.

---

---
url: >-
  /knowledgebase/welcome-introduction-to-catalyst/in-application-help/welcome-to-in-application-help.md
---

# Welcome to in-application help

Welcome to in-application Help for Autologyx Catalyst, our operations platform for legal & compliance.

**Get started here**

You'll find lots of information to help you get started. There is also a wider knowledgebase available via Zendesk, with more business-focused and end-user training, tips, and ideas.

Access the full **[Catalyst knowledgebase](https://ng-autologyx.zendesk.com/hc/en-us)**.

**Need more help?**

Our great customer success team are happy to help you through process design, configuration, and testing. We'd also love to hear from you about whether the articles you have access to here are useful.

**Where you are now**

You're reading this from the Landing page, which can be configured to provide your Users with feature shortcuts, reports, and handy tips.

---

---
url: >-
  /knowledgebase/administration/elements/what-are-elements-and-what-can-you-do-with-them.md
---

# What are Elements and what can you do with them?

Elements are custom web components developed specifically for your Autologyx platform. They allow your organisation to extend the standard functionality of the application with bespoke user interfaces, dashboards, visualisations, integrations, and interactive tools.

Once an Element has been developed, packaged and imported into Autologyx, it can be placed onto supported pages using the form builder without requiring further development.

## Where Elements can be used

Elements can be added to the following areas of the platform:

* the Landing page
* Object Classes
  * Create/Edit view
  * Summary view
  * Standalone forms

This allows the same Element to be reused wherever it is needed throughout your solution.

## How Elements work

Elements are hosted securely inside an **IFRAME**, which isolates them from the main Autologyx application.

This isolation improves security by preventing the Element from directly accessing or modifying the surrounding page.

Instead, Autologyx passes a controlled set of information to the Element using a secure messaging mechanism. Depending on where the Element is being used, this information can include:

* the logged-in user's authentication token
* user information
* the current Object Class ID
* the current Record ID
* any configuration parameters defined for the Element

Your Element listens for this information and uses it to render its interface or communicate with APIs.

## Why use Elements?

Elements make it possible to tailor Autologyx to your organisation's specific requirements without changing the core product.

Typical use cases include:

* displaying dashboards and charts
* embedding third-party applications
* integrating external services
* presenting information from other systems
* creating bespoke controls or user experiences
* visualising live business data

Because Elements are independently developed, they allow organisations to deliver highly specialised functionality while continuing to benefit from standard Autologyx upgrades.

## Accessing Elements

Elements are managed from:

**Administration** → **Elements**

Only users with a Super Admin account type can create, import, edit or delete Elements.

## The Elements list

By default, the Elements list displays the following columns:

![Elements list showing installed Elements and their status](/knowledgebase/images/img_13243615249437_1776896009.png)

* **ID** — the unique identifier assigned when the Element is created.
* **Name** — the Element name. This must be unique.
* **Publisher** — the organisation that developed the Element, taken from the package configuration.
* **Enabled** — indicates whether the Element is currently available for use.
* **Status** — shows the current installation state.
* **Actions** — provides options to edit or delete the Element.

### Element status values

During installation an Element can have one of three statuses:

* **Processing** — the package is currently being downloaded or installed.
* **Installed** — the package has been successfully installed and is ready to use.
* **Failed** — installation was unsuccessful. Common causes include:
  * incorrect Git repository credentials
  * missing required files
  * invalid package structure
  * configuration validation failures

## Creating Elements

For step-by-step instructions on building and importing an Element, see:

[Everything you need to create an Element](/knowledgebase/administration/elements/everything-you-need-to-create-an-element/)

## Things to remember

1. Your Autologyx instance can contain up to **100 Elements**, whether enabled or disabled.
2. Element names must be unique.
3. Consider including a version number in the Element name when importing updated versions.
4. Elements are isolated from the main application and communicate through secure message passing.
5. A single Element can be reused across multiple pages and forms.

---

---
url: /knowledgebase/system-configuration/object-classes/what-are-object-classes.md
---

# What are Object Classes?

We use Object classes to keep records of the same type in one place; they are like a database table. This allows us to create and run processes in the Sequencer against these records, ie an Object class.

It also allows us to define individual Tasks of the "Update object record" type and groups of tasks - Task group templates - for a specific Object class.

A User's Role and/or Object class permissions will determine whether they have visibility of Object classes in the System Configuration section of the main left hand navigation menu. A User with any of the Object class permissions shown below will see the Object class menu item.

![mceclip5.png](../../../images2/zendesk_4402907067281_001_261d1026c1dd.png)

It is worth noting that **additional permissions are set for each Object class**. This is done by creating Permission sets for groups of Users. Permissions will relate to the Object class itself and to Object records and Tasks associated with it. Find out more about [editing object class permissions](/knowledgebase/system-configuration/object-classes/edit-object-class---creating-class-permissions-and-addremove-assignees/).

## Object classes list

**The default column configuration** for the Object classes list is shown below.

![mceclip6.png](../../../images2/zendesk_4402907067281_002_940a69552c93.png)

**Other useful columns are:**

* **Owners** - this shows the avatar of the User who is the Class owner if there is only one, or the avatar of the oldest Owner and the number of additional Owners if there is more than one.
* **Records** - this shows the number of records in the Object class.

![mceclip7.png](../../../images2/zendesk_4402907067281_003_e5cf56145083.png)

**The unique feature in the Actions menu** for an Object class is the **View usage** option. This will show:

* How many records are associated to the Object class
* A list of Task group templates associated with the Object class
* A list of Sequences which have been created for the Object class
* Whether related to another object class

![1006a.png](../../../images2/zendesk_4402907067281_004_f35e344730ad.png)

Find out more about [list page](/knowledgebase/finding-your-way-around/ui-and-navigation/list-pages/) features.

**Visibility of the list** will depend on a User's permissions, but Users with the Super admin account type will have visibility of all Object classes in the list.

## Useful info

1. You can have up to 10,000 Object classes in your system.
2. You can define up to 2,000 fields per Object class.
3. Each Object class can have up to 500,000 records associated with it.

---

---
url: >-
  /knowledgebase/system-configuration/task-group-templates/what-are-task-group-templates.md
---

# What are task group templates?

We use Task group templates to manage multiple tasks at the same time.

For example, in a Sequence, a task group template can be used to create several tasks at once for an Object record. They can aslo be used in reporting to determine that a set of Tasks is complete.

Task group templates can be created and edited from the **Task group template list**.

## Visibility and list access

The Task group templates list will only be visible to Users who meet one of the below options:

|  |  |
| --- | --- |
| - have a Super Admin account - have a Role where the system permissions under the Task configuration tab for Task Group Templates have been enabled for create and edit or edit only | mceclip0.png |

This list has all the usual features of lists in your system. More details about those can be found **[HERE](/knowledgebase/finding-your-way-around/ui-and-navigation/list-pages/)**.

## Default columns

The default columns are as follows:

* **ID** - A unique number given to the Task group template which is automatically applied by the system on creation of the template. This is useful for aiding recognition when debugging, etc. when you have a number of templates with similar names.
* **Name** - The Name given to the Task group template on creation or when last edited.
* **# Of Task Templates** - Shows you the number of Task templates contained in the Task group template.
* **Created** - Gives the date/time stamp of when the template was created.
* **Actions** - The menu which will allow a User to Edit or Delete the template depending on their permissions.

Another column which can be added, and is particularly useful as your Task group template list becomes more comprehensive, is Object Classes. This column will show the object classes which have been selected in the template and therefore for which object classes the Task group template will be available to use in a Sequence.

![mceclip0.png](/knowledgebase/images/img_4402907144465_1776895980.png)

## Useful info

1. The maximum number of Task group templates you can have in your system is **10,000**.
2. Only Tasks with the Task creation mechanism **Automatic** can be added to a Task group template.

---

---
url: /knowledgebase/system-configuration/task-templates/what-are-task-templates.md
---

# What are Task templates?

We use Task templates to create Tasks for Object records. The Task template should be thought of as **a blueprint for the Task**. It determines:

* how the Task presents to the User responsible for completing it
* what instructions are given
* what type of response is expected
* whether it is a Task which is done only once or has an expiry and will renew

Task templates can be created and edited from the Task template list.

![mceclip0.png](/knowledgebase/images/img_6175004114077_1776895914.png)

## Task templates list

The Task templates list will only be visible to Users who meet one of the below options:

|  |  |
| --- | --- |
| - have a Super Admin account - have a Role where the system permissions under the Task configuration tab for Task Templates have been enabled for create and edit or edit only | mceclip0.png |

This list has all the usual features of lists in your system. More details about those can be found **[HERE](/knowledgebase/finding-your-way-around/ui-and-navigation/list-pages/)**.

### Default column headers

The Task templates list has the following default column headers:

**ID** - this is a unique number applied to the Task template on creation. It should not be confused with the Task ID which is given when a Task is created from a Task template for an Object record.

|  |  |
| --- | --- |
| The Task template ID number for "GDPR Agreement" is 30. | mceclip0.png |
| This Task template has been used to create Tasks for Record IDs 402 and 401. The Task IDs are 347 and 342 respectively. | mceclip1.png |

**Name** - the Name given to the Task template. Please note that for a Manual Task, although the User will find the Task template using this Name, they can give the Task a completely different Name when creating it for an Object record.

**Task creation mechanism** - shows whether the Task template can be used to create Tasks automatically from a Sequence or manually on the Object Record in the Tasks tab of the side panel.

**Task type** - there are two Task types:

* **Self contained form** - this is constructed of Fields which are unrelated to any Object class and therefore can be used to create Tasks for Records in any Object class
* **Update object record** - this is configured for a specific Object class and allows the User to select Fields from the Object class (which will update the Record when the Task is completed) and, if wanted, additional Fields which are not related to the Object class

**Description** - used to describe what the Task is for, and under what circumstances it may be created for a Record.

**Actions** - has an Edit option which allows the User to change certain elements of the Task template. Click **[HERE](/knowledgebase/system-configuration/task-templates/editing-a-task-template/)** for information.

### Other useful columns

Other useful columns which can be added via the Column configuration link are:

**# Tasks created** - shows how many Tasks have been created from the Task template.

**Last task created** - shows a date/time stamp for when the Task template was last used to create a Task.

## Useful info

1. The maximum number of Task templates you can have in your system is 10,000.

---

---
url: >-
  /knowledgebase/administration/all-about-users/what-can-i-edit-in-a-user-account.md
---

# What can I edit in a user account?

Only Users with a Super admin account can edit user accounts. This can be done by:

|  |  |
| --- | --- |
| - Clicking **Edit** in the **Action** menu for the selected User - Double clicking anywhere on the user's record from the Users list | ![mceclip0.png](../../../images2/zendesk_5900607982621_001_61d9eb2db4fd.png) |

## User Account Type

On the Edit user page, a User's account type will be highlighted with a blue outline. A User's account type can be changed if required. For instance, a User with an Internal account type could be changed to a Config admin account type, or a User with a Config admin account type can be promoted to a Super admin.

However, Internal, External, Config admin, and Super admin account types cannot be changed to 1-time completion. Note that this option is greyed out.

**1-time completion account type**

**![](../../../images2/zendesk_5900607982621_002_b048f837a0e7.png)**

Users with a 1-time completion account type can be changed to any of the other four account types. If you do this, the Save button will be enabled. When Save is clicked, the modal asking whether you would like to send the activation email will be displayed.

**Activation email options**

**![](../../../images2/zendesk_5900607982621_003_a0f2ad2c769f.png)**

If you select "Send email", the activation email will be sent and the account Status will change to Pending.

If you select "I'll do it later", the email will not be automatically sent and the account Status will change to created.

A User cannot change their own account type.

## Username

This is the email address associated with the user account. The field is required, so it cannot be left blank, and it must contain a unique value.

![](../../../images2/zendesk_5900607982621_004_01e3786820cf.png)

If the Username is updated, the user will be required to enter their new username the next time they log in. If they don't, the following error will be shown:

![mceclip1.png](../../../images2/zendesk_5900607982621_005_29ea4812f2b3.png)

Their password will not be affected.

## Password

Passwords cannot be updated on the Edit user page, but can be reset by users from the login page.

Users can update their own username and/or password by clicking their Avatar or Name in the top right of each screen and selecting *My Account*. In order to change their password in this area, they are required to provide their current password as part of the process.

## Explanation of account Status

**Created** - the user account has been created but not activated. The account activation email has not yet been sent. The Status section of the Edit user page will show that they are at stage 1. The date/time the account was created is shown.

There is a "Send activation email" button which you can use to send the activation email when/if appropriate. NB: Users who are expected to log in via single sign-on should not have an activation email sent to them.

![](../../../images2/zendesk_5900607982621_006_85dd3f39377f.png)

**Pending** - the account activation email has been sent but the User has not completed their account setup. You can see the last time the email was sent and resend it if necessary.

![](../../../images2/zendesk_5900607982621_007_a0270dc3073a.png)

**Active** - the user has activated their account and logged in. The date/time the account was successfully activated is shown.

![](../../../images2/zendesk_5900607982621_008_9133422bec04.png)

## Roles

The Roles section is present only for Users with the Config admin account type. Roles can be added or removed as required. The Role determines a user's level of access to System configuration and Administration areas. If a Role is added or removed and the account is saved, the User's permissions will be instantly updated without the need to log out of their session. [Find out more about user roles.](/knowledgebase/administration/roles-and-permissions/why-do-users-need-roles/)

If the User is in the middle of creating or editing an area of the system where they no longer have permission to do so because a Role has been removed or amended, the Save button will be disabled and when they hover over it the restricted icon will be shown.

## Personal Information

These details can be updated when required. The changes will be reflected in that User's *My Account*. Likewise, if a User edits their own Personal Information from their *My Account* page, this will update the details in the User account.

First name and Last name can be amended but not left blank, as they are mandatory fields.

![](../../../images2/zendesk_5900607982621_009_4c6b7b0896c4.png)

## Useful Info

1. The maximum number of roles that can be given to a user is 25.
2. Users with more than one Role will receive all permissions that are 'switched on' in any of the roles, regardless of whether they are not permitted by other roles. Care should be taken when setting these up.

---

---
url: >-
  /knowledgebase/system-configuration/object-classes/what-can-i-edit-in-an-object-class.md
---

# What can I edit in an Object class?

When you select **Edit** in the Actions menu of an Object class, what you can edit depends on what you have already configured.

When you create an Object class, you are only required to complete one field: the Object class Name. You may also have added a description.

**Both of these fields can be amended.** The change will take immediate effect; there is no additional save button. However, it is important to note that the Object class Name must be unique.

## What you can edit

Beyond this, the edit page has five tabs:

![1006b.png](../../../images2/zendesk_4417365702929_001_8f84c4465c23.png)

* **Fields** — here you can add, configure and amend the fields to be used for data capture on the Object records belonging to the Object class. View a detailed explanation of [field types, uses and their attributes](/knowledgebase/system-configuration/object-classes/object-class-field-types-uses-and-attributes/). View help on [editing Object class fields](/knowledgebase/system-configuration/object-classes/editing-object-class-fields/).
* **Display** — here you can [configure how Object records will be shown in the list view](/knowledgebase/system-configuration/object-classes/edit-object-class---configure-displays/) (create/edit), the card view and summary view.
* **Forms** — here you can configure forms to be used specifically for record creation. The URL for a form can be hosted elsewhere, but users will be prompted to log in and they must have the Create record permission for the Object class to be able to add records. Find out more about [creating a standalone form](/knowledgebase/system-configuration/object-classes/create-a-standalone-form/).
* **Document Templates** — here you can [create and edit document templates](/knowledgebase/system-configuration/working-with-document-templates/) from which documents can be generated for records via the sequencer or manually in the side panel of the record. View a separate section with [several articles which will explain how to create your templates and use them in the system](/knowledgebase/system-configuration/working-with-document-templates/).
* **Permissions** — here you can add [permission sets for the Object class](/knowledgebase/system-configuration/object-classes/edit-object-class---creating-class-permissions-and-addremove-assignees/) itself and for the records and tasks associated with it. Users are assigned a permission set which will determine what they can see and do.

## Who can edit an Object class

Only the following users will be able to edit an Object class:

* Those who have the Super admin account type
* Those who have the Edit permission against Object Classes in their Role (this will allow the user to edit all Object classes)

![mceclip0.png](../../../images2/zendesk_4417365702929_002_0f54e9a6348e.png)

* Owners of the Object class. **NB:** You will automatically become the owner of any Object class which you create.
* Users who have a permission set for the Object class which allows them to edit it, as shown below in the Permission set called SME

![mceclip1.png](../../../images2/zendesk_4417365702929_003_262f298405bf.png)

## Useful info

1. Rather than selecting **Edit** in the Actions menu of the Object class, double-click on its row in the list to be taken to the edit screen.
2. You can configure up to 100 stand alone forms for an Object class.

---

---
url: >-
  /knowledgebase/finding-your-way-around/my-account/what-can-i-edit-in-my-account-and-what-effect-will-this-have.md
---

# What can I edit in My account and what effect will this have?

## **Username**

When the username is edited and saved:

1. The value given in the ‘My account’ page will be written back into the user account page > Username field.
2. If Username is changed for an account that has not been activated, the system automatically sends new activation email (with a new token) to the new Username.
3. If Username is changed for an active *standard* or *super admin*, the affected user will need to use the new Username when logging in next time.

## **Row density**

Row density allows the user to set the row density for all list pages in one place.

* **Row density options** are shown as radio buttons.
* **Available options:**
  1. **Comfortable**
     * Row height: 40px
     * Header height: 43px
  2. **Default**
     * Row height: 35px
     * Header height: 38px
  3. **Compact**
     * Row height: 30px
     * Header height: 33px
* **Default option:** Default
* When a user changes the option and saves successfully, all list pages will be updated to show the new row density selected.
* When a user changes the option, a preview of the selected ‘density’ will show below the tiles.

---

---
url: >-
  /knowledgebase/system-configuration/sequences-for-relational-records/what-can-you-do-with-relational-records-in-a-sequence.md
---

# What can you do with relational records in a sequence?

There are some additional sequence features which can be used when your object class is part of a relationship. Your object class may be a parent or a child of another object class, or it may be both.

## Using Relation Lookup

The **Relation Lookup** actor allows the sequencer to check through the associated parent or child records and identify those which match the given conditions configured within it.

## Using Sequence Runner

The **Sequence Runner** actor can be used together with the Relation Lookup actor so that an action such as assigning a task or updating a field may be carried out against the parent or child records which the Relation Lookup has identified.

Alternatively, it can be used at any point in a sequence to run another sequence for a sub-process against the same object class. This allows you to keep sequences from getting overly large and therefore difficult to maintain.

View a [step by step guide on configuration and use of these actors](/knowledgebase/system-configuration/sequences-for-relational-records/a-guide-to-using-the-relation-lookup-and-sequence-runner-actors-together/).

## Useful info

1. The Relation Lookup actor can traverse records' relations to find parents or children one level up or down in the relational model. For instance, if your model has three levels like the below, the following will be true:

|  |  |
| --- | --- |
|  | In a sequence running against the root parent object class, Employee Management, the Relation Lookup can be used to find records in the Employees object class. |
| In a sequence running against the middle object class, Employees, the Relation Lookup can be used to find records in the parent object class, Employee Management or in the child object class, Employment Contracts. |
| In a sequence running against the child of Employees and the grandchild of Employee Management, Employee Contracts, the Relation Lookup can be used to find records in its parent object class, Employees. |

2. You can have multiple Relation Lookup and Sequence Runner actors working in the same sequence.

---

---
url: >-
  /knowledgebase/administration/user-groups/what-do-i-need-to-know-about-creating-a-user-group.md
---

# What do I need to know about creating a User Group?

User Groups allow you to organise users for permission management, task assignment, and collaboration.

Before you can create a User Group, you must have the appropriate permissions.

## Who can create a User Group?

You can create a User Group if one of the following is true:

* you have a Super Admin account type
* you have a Config Admin account type and a Role with the **Create** permission enabled for **User Groups** under **Administration** system permissions

![Role permissions showing the Create permission for User Groups](../../../images2/zendesk_4402900120209_001_f1c83c140c1b.png)

## Create a new User Group

Open the **User Group List** and click **+ Create**.

The **Create User Group** page opens.

When creating a User Group:

* the group must have a unique name
* you can optionally provide a description
* the **Save** button remains disabled until a name has been entered

![Create User Group page showing the Name and Description fields](../../../images2/zendesk_4402900120209_002_56de7c062ecc.png)

Click **Save** to create the User Group.

You will then be asked whether you want to add members immediately.

![Confirmation dialog asking whether to add members now](../../../images2/zendesk_4402900120209_003_a20e2a56c295.png)

## Add members immediately

If you choose **Add members**, the new User Group opens on the **Membership** tab.

The User Group contains two tabs:

* **Membership**
* **Permissions**

You are automatically added as both a Member and an Owner of the User Group.

![New User Group showing the Membership and Permissions tabs](../../../images2/zendesk_4402900120209_004_8385e4182f54.png)

## Add users to the User Group

Below the member summary, change the filter from **Members** to **Non-members**.

![Membership filter changed to Non-members](../../../images2/zendesk_4402900120209_005_4a4813527f0c.png)

The Non-members list contains every eligible user in the system except users with a 1-time completion account type.

Each user has an **Actions** menu containing:

* **Add as member**
* **Add as owner**

![Actions menu for adding a user as a Member or Owner](../../../images2/zendesk_4402900120209_006_ce145bce4a39.png)

These actions can be used to add users individually.

To add several members at the same time, select the required users using the checkboxes and click **+ Add as members**.

![Bulk adding multiple users to a User Group](../../../images2/zendesk_4402900120209_007_a10b540256c4.png)

A green success toast confirms that the users have been added.

Return the filter to **Members** to view the updated membership list.

## Managing members

Each member has an **Actions** menu.

From here you can:

* promote a member to an Owner
* remove a member from the User Group

![Actions menu for managing an existing User Group member](../../../images2/zendesk_4402900120209_008_66a61d00767f.png)

These actions are covered in more detail in the following articles:

* [Editing a User Group](/knowledgebase/administration/user-groups/editing-a-user-group/)
* [User Group Permissions](/knowledgebase/administration/user-groups/user-group-permissions/)

## Add members later

If you choose **Add members later**, the User Group is saved immediately and appears in the User Group List.

You can return to it at any time by:

* double-clicking the User Group
* selecting **Open** from the **Actions** menu

From there you can:

* add members
* promote members to Owners
* remove members
* manage User Group permissions

## Things to remember

1. User Group names must be unique.
2. The user who creates a User Group automatically becomes both its first Member and first Owner.
3. When viewing the **Non-members** list, only the first 10 users are shown by default. Increase the page size or use the search box to find additional users.
4. A maximum of 50 users can be added or removed in a single bulk action.
5. A system can contain up to 1,000 User Groups.
6. Each User Group can contain up to 1,000,000 Members.
7. A User Group can have up to 10 Owners.

---

---
url: >-
  /knowledgebase/getting-started/building-applications-analysts/what-goes-into-a-typical-application.md
---

# What goes into a typical application?

Before you start to build your first process in Catalyst, you need to consider a number of things. An application is made up of many components, but one of the most important and easiest to forget as a novice is the required outcomes.

## Required outcomes

These may be as simple as getting a document signed or providing a weekly report highlighting the number and type of matters commenced.

Whatever the required outcomes, you will be working with data. It is important to understand how the Catalyst data model is organised so that you can ensure that you have your [**Object Classes**](/knowledgebase/system-configuration/object-classes/) correctly set up. And of course the data captured here will be some of what feeds into any reporting requirements.

## Data collection and integrations

You might use our task forms to collect data via a task, so you will need to know [**how to create task templates**](/knowledgebase/system-configuration/task-templates/) and how to **[create sequences](/knowledgebase/system-configuration/sequences/)** in which the templates are used to create tasks.

In addition, some data may be collected via integration with other applications, so you will want to understand how our **API** works. In the first instance, please contact one of the Client Value team so we can help get you started.

## People and permissions

You will also need to consider the people who will be involved in your application.

Some will be internal staff who are responsible for working with the data, ensuring that the workflow is completed and outcomes achieved. Others will be subject matter experts or individuals who only get involved in certain circumstances.

You will need to give some of them **[User roles](/knowledgebase/administration/roles-and-permissions/)** and set their role permissions; most users' permissions will be determined by the [**User group**](/knowledgebase/administration/user-groups/) or groups to which they belong.

## Communication

While thinking about the people involved in your application, you will need a means of communicating with them.

You will probably want to notify users when they are assigned a task. And there will most likely be other bespoke messages needed in your workflow. In order for these emails to be successfully sent from Catalyst you will need to ensure that the [**Outbound mail setup**](/knowledgebase/administration/communication/outbound-mail-setup/) has been correctly configured.

## Documents

Another important component of any application is the documents it involves.

These may be provided by users of the system via stand alone forms or task forms, or they may be generated in a sequence via a DocAuto actor from Document templates stored in an Object class.

## Next step

Go to our **[checklist](/knowledgebase/getting-started/building-applications-analysts/checklist-of-things-to-set-up-which-are-common-across-all-applications-of-the-system/)** for things to set up once only and for each application. This guide will help you get on your way.

---

---
url: >-
  /knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-change-the-properties-of-a-field-used-in-conditional-logic.md
---

# What happens if I change the properties of a field used in conditional logic?

Numeric fields are often used in conditional logic to display subsequent sections.

In this example, the field is being used to show or hide the next section, **Dependent's Details**.

Please note that this example uses a standalone field in a Task template.

The screenshot below shows that the numeric field **Number of Dependents** was originally created without any validation.

![Numeric field used in conditional logic](/knowledgebase/images/records-and-tasks/using-cond-logic-forms-1.png)

Values 1, 2, 3, and so on are used to display sections with the appropriate number of fields to capture dependents' details.

## If validation is added

If validation is added so that a condition can no longer be met, the affected sections are highlighted in red.

![Section highlighted because a conditional logic condition can no longer be met](/knowledgebase/images/records-and-tasks/using-cond-logic-forms-2.png)

When you click on the highlighted section, an error message explains that the condition cannot be met.

![Error message explaining that the condition cannot be met](/knowledgebase/images/records-and-tasks/using-cond-logic-forms-3.png)

Clicking on the condition opens the **Edit condition** modal, where you can see why the condition can no longer be met.

In this example, the minimum allowed value in the field **Number of Dependents** has been changed to 2.

However, the condition in **Conditional Visibility** was configured as:

```text
field_number_of_dependents is equal to 1
```

Because of the revised validation, this condition can never be met.

**Note:** The **Edit condition** modal displays **Min 2**.

![Edit condition modal showing that the condition can never be met](/knowledgebase/images/records-and-tasks/using-cond-logic-forms-4.png)

To return the section to a valid state, do one of the following:

* remove or amend the field validation
* amend the condition
* remove the invalid condition

Similarly, single and multi select field types are often used to control the display of subsequent sections because the pre-defined options leave little room for data-entry errors.

In this example, the field **Gender** was originally created with six options.

Each option is used to display a further section containing gender-specific questions.

![Gender field options used in conditional logic](/knowledgebase/images/records-and-tasks/using-cond-logic-forms-5.png)

If one of these options is removed or amended, the affected section is highlighted in red.

![Section highlighted because a conditional logic option is no longer valid](/knowledgebase/images/records-and-tasks/using-cond-logic-forms-6.png)

## If an option is amended or removed

When you click on the highlighted section, an error message explains that the condition cannot be met.

![Error message explaining that the condition cannot be met](/knowledgebase/images/records-and-tasks/using-cond-logic-forms-7.png)

**Important:** An amended option is treated as if it has been removed.

![Edit condition modal showing an invalid option used in conditional logic](/knowledgebase/images/records-and-tasks/using-cond-logic-forms-8.png)

As before, you can amend the condition or remove the invalid condition.

In this example, replacing the removed option will resolve the issue. The order of the options does not matter, provided the required option exists.

## Things to remember

1. Fields used in conditional logic should normally be marked as **Required**.
2. If validation prevents a condition from being met, the affected section is highlighted in red.
3. Changing or removing select-list options can invalidate conditional logic in the same way as changing validation rules.
4. An amended option is treated as a removed option for conditional logic purposes.
5. Invalid conditions can usually be resolved by updating the validation, restoring the option, amending the condition, or removing the invalid condition.

---

---
url: >-
  /knowledgebase/administration/roles-and-permissions/what-happens-if-i-edit-a-role.md
---

# What happens if I edit a role?

Roles can be edited from the Roles list by:

* selecting **Edit** from the **Actions** menu
* double-clicking the role row

Only users with a Super Admin account type can create and edit users and roles.

![Roles list showing the Edit option in the Actions menu](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-1.png)

You can edit any part of the role page.

**Important:** Permission changes take effect immediately.

## Create permission removed

If a user's role originally included **Create** permission and this permission is removed, the **+ Create** button is removed from the relevant list page.

If the user still has **Edit** or **Delete** permission, they can still access the list page and use the remaining permitted actions.

In the example below, **Task Templates** has **Create** and **Edit** enabled.

The user can:

* view the Task Templates list
* create new Task Templates
* edit existing Task Templates

![Role permissions showing Create and Edit enabled for Task Templates](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-2.png)

![Task Templates list showing the Create button and editable rows](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-3.png)

If **Create** is disabled but **Edit** remains enabled, the user can still view and edit existing Task Templates, but the **+ Create** button is removed.

![Role permissions showing Create disabled and Edit enabled for Task Templates](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-4.png)

![Task Templates list with the Create button removed](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-5.png)

If the **Create** permission is removed while the user is creating an item, they will not be able to save it.

An onscreen error message will explain that their role permissions have been updated and the action is no longer permitted.

## Edit permission removed

If a user's role originally included **Edit** permission, but not **Create** or **Delete**, and **Edit** is then disabled, the list page is usually removed from the left-hand menu.

The user will no longer have access to that area.

The exception is Object Classes. If the user has an Object Class Permission Set that allows them to view a specific Object Class, the list remains available but shows only the Object Classes they are permitted to see.

In the example below, **Data model** > **Object Classes** has **Edit** enabled.

The user can:

* view the Object Classes list
* edit existing Object Classes
* access the Object Classes area from the menu

![Role permissions showing Edit enabled for Object Classes](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-6.png)

![Object Classes list visible when Edit permission is enabled](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-7.png)

If **Edit** is disabled, the user can see only Object Classes where they have a separate Permission Set that allows access.

![Role permissions showing Edit disabled for Object Classes](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-8.png)

![Object Classes list restricted to permitted Object Classes](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-9.png)

![Object Classes menu access limited by Object Class permissions](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-10.png)

## Delete permission removed

If a role originally included **Delete** permission but not **Create** or **Edit**, and **Delete** is then disabled, the list page is removed and the item no longer appears in the left-hand menu.

In the example below, **Sequencer** has **Delete** permission enabled.

The user can:

* view the Sequences list
* delete Sequences

They cannot create new Sequences or edit existing Sequences.

![Role permissions showing Delete enabled for Sequencer](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-11.png)

![Sequences list showing delete access without create or edit access](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-12.png)

If **Delete** is disabled, the user loses access to the Sequences list.

The Sequences option is removed from the menu. If the user attempts to access the page directly, an access denied message is displayed.

![Role permissions showing Delete disabled for Sequencer](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-13.png)

![Navigation menu with Sequences removed](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-14.png)

![Access denied message shown when attempting to open Sequences directly](/knowledgebase/images/administration/what-happens-if-i-edit-a-role-15.png)

## Things to remember

1. Role permission changes take effect immediately.
2. Removing **Create** removes the **+ Create** button from the relevant list page.
3. Removing **Edit** usually removes access to the list page unless another permission still grants access.
4. Removing **Delete** removes delete access and may remove the list page if no other permissions remain.
5. Object Classes can still appear if the user has separate Object Class permissions.
6. The maximum number of Roles your system can have is 5,000.

---

---
url: >-
  /knowledgebase/administration/authentication-objects/what-happens-if-i-edit-an-authentication-object.md
---

# What happens if I edit an Authentication object?

An Authentication object stores the credentials used to authenticate API integrations with external services.

Because the same Authentication object can be shared by multiple API Call actors, updating it allows you to change authentication details in one place instead of updating every individual API call.

**Important:** Changes are applied wherever the Authentication object is used, so you should plan updates carefully to avoid disrupting live integrations.

## Edit an Authentication object

Start from the **Authentication Objects** list and locate the Authentication object you want to update.

By default, the list is sorted by **ID** in descending order, but you can use the search and filters to quickly find the required object.

From the **Actions** menu, select **Edit**.

![Authentication Objects list showing the Edit action](../../../images2/zendesk_4410153982993_001_22c343df8275.png)

The Authentication Object configuration page opens.

Sensitive values, such as passwords or client secrets, are displayed as asterisks (`*****`) rather than their actual values. This helps prevent credentials from being exposed while still allowing authorised users to update them.

Only users with a Super Admin account type, or users whose Role includes the appropriate permissions, can edit Authentication Objects.

![Authentication Object edit page showing protected credential fields](../../../images2/zendesk_4410153982993_002_976341663973.png)

## Updating credentials

The **Provider** field is fixed once an Authentication object has been created and cannot be changed.

To update a credential, click into the appropriate field. The existing value is cleared for security reasons, allowing you to enter the replacement value.

After updating the required information, click **Save**.

The updated Authentication object is immediately available to every API Call actor that references it.

## Token refresh behaviour

For **Autologyx Internal Authentication** objects, changing the username or password may not take effect immediately.

Authentication tokens are refreshed every 24 hours. Until the current token expires, the Sequencer continues using the existing authentication token.

This means there may be a short delay before integrations begin using the updated credentials.

## Things to remember

1. Updating an Authentication object automatically updates every API Call actor that uses it.
2. The **Provider** cannot be changed after the Authentication object has been created.
3. Sensitive credential values are hidden and must be re-entered when updated.
4. Changes to Autologyx Internal Authentication credentials may not take effect until the current authentication token expires.

---

---
url: >-
  /knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-remove-a-column-that-has-a-field-which-is-used-in-conditional-logic.md
---

# What happens if I remove a column that has a field which is used in conditional logic?

In the screenshot below, the section called Personal Details has 3 columns.

The third column includes a field called "How many dependents do you have?"

This field controls the logic that shows or hides the next section, titled "Dependents".

## Removing a column

If you try to remove a column by reducing the number of columns from 3 to 2, an on-screen message will ask which column you want to remove.

You can clearly see that **column 3** has the conditional logic icon, whereas columns 1 and 2 do not.

![1806a.png](/knowledgebase/images/img_4409465009809_1776895757.png)

**To continue, click the column you wish to remove.** The display colour of the selected column will become blue.

## If the column contains a field used in conditional logic

If the selected column contains a field with conditional logic, a second on-screen message will be shown.

This message tells you that all the fields in the selected column will be deleted. It also lists the sections that are conditionally displayed because of a selection or input into a field in that column.

![Screenshot 2024-06-18 at 16.02.29.png](/knowledgebase/images/img_4409465009809_1776895758.png)

**You can then choose one of the following options:**

* Click **Cancel** to retain the column.
* Click **Remove** to delete the column and all related conditional logic.

---

---
url: >-
  /knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-remove-a-field-which-controls-conditional-logic-in-a-form.md
---

# What happens if I remove a field which controls conditional logic in a form?

If you try to remove a field which is used in conditional logic, you will be shown an on-screen warning message telling you that removing the field will result in the conditions being deleted.

![mceclip0.png](/knowledgebase/images/img_4409464999697_1776895757.png)

**The warning also lists** the sections which are conditionally displayed from a selection or an input in this field.

You can choose to retain the field by clicking **No, go back** or to delete the field and its conditional logic by confirming **Yes**.

---

---
url: >-
  /knowledgebase/record-and-task-forms/using-conditional-logic-in-forms/what-happens-if-i-remove-a-section-that-has-a-field-which-is-used-in-conditional-logic.md
---

# What happens if I remove a section that has a field which is used in conditional logic?

If you try to remove a section that contains a field used in conditional logic, you will see an on-screen warning message explaining that removing the section will result in the conditions from the field being deleted.

![1806b.png](/knowledgebase/images/img_4409465038737_1776895758.png)

**The warning also lists** the sections that are conditionally displayed from a selection or an input in the field or fields that are controlling the display of another section or sections.

**You can then choose** to retain the section by clicking **No, go back**, or to delete the section and all related conditional logic by confirming **Yes**.

---

---
url: >-
  /knowledgebase/administration/all-about-users/what-happens-when-a-user-clicks-the-forgot-your-password-link-on-the-login-page.md
---

# What happens when a user clicks the "Forgot your password?" link on the login page?

Users who normally sign in to Catalyst using a username (email address) and password can reset their password from the login page if they forget it.

The password reset process is quick and secure, requiring access to the email address associated with the user account.

> **Note:** This process is available only for standard user accounts that authenticate using a username and password. It is **not** available for Service Accounts or users who authenticate exclusively through Single Sign-on (SSO).

## Request a password reset

On the login page, click **Forgot your password?**

![Login page showing the Forgot your password link](../../../images2/zendesk_5547555661213_001_9c87dc01dc08.png)

Enter your username (email address).

![Forgot password page requesting the user's email address](../../../images2/zendesk_5547555661213_002_0a2a974d6b85.png)

Click **Reset**.

![Reset button on the Forgot password page](../../../images2/zendesk_5547555661213_003_352760fb1ea7.png)

A confirmation message is displayed to confirm that, if the email address belongs to a valid account, a password reset email will be sent.

> **Important:** The email address must belong to an active user account that supports password authentication. Password resets are not available for Internal or External Service Accounts.

## Reset your password

The password reset email contains a secure, single-use link.

Clicking the link opens the **Reset password** page.

![Password reset email containing the secure reset link](../../../images2/zendesk_5547555661213_004_159d99187a1b.png)

If your organisation has configured contact information on the Company details page, the email also includes details of the person or team to contact if you did not request the password reset.

On the **Reset password** page, enter and confirm your new password.

The page displays your organisation's password requirements, which update in real time as each requirement is satisfied.

| | |
|---|---|
| ![Reset password page showing password requirements](../../../images2/zendesk_5547555661213_005_0416c083aab5.png) | ![Password requirements successfully satisfied](../../../images2/zendesk_5547555661213_006_d5fb19ed823a.png) |

When all password requirements have been met, click **Reset password**.

A confirmation message is displayed and you are automatically signed in and taken to the Workspace.

## Things to remember

1. Password reset links remain valid for **24 hours**.
2. If **Prevent password re-use** is disabled in the **Standard authentication** configuration, users may reuse a previous password.
3. Users who authenticate exclusively through **Single Sign-on (SSO)** cannot reset their password in Catalyst and will instead be redirected to their organisation's normal sign-in process.
4. Service Accounts do not support the **Forgot your password?** feature. Their passwords can only be reset by a Super Admin.
5. Password reset emails are sent only to valid user accounts that support password authentication.

---

---
url: >-
  /knowledgebase/administration/all-about-users/what-happens-when-an-individual-uses-single-sign-on.md
---

# What happens when an individual uses Single sign-on?

If Single sign-on has been enabled, the **Log in** page displays a **Single sign-on** dropdown.

All enabled Single sign-on configurations are listed in this dropdown.

The **Email** and **Password** fields remain visible because some users may still sign in using standard authentication.

![Log in page showing the Single sign-on dropdown](../../../images2/zendesk_4409718956817_001_a16bf31695d1.png)

## When a user selects Single sign-on

If the user is already signed in to the Single sign-on provider, Catalyst checks whether their email address matches a user account.

The following outcomes are possible:

* If the user has an **active** account with a matching email address, they are taken to the Landing page.
* If the user has a **non-active** account with a matching email address, the account status is changed to **Active**, the activation date is set to the first SSO login date, and the user is taken to the Landing page.
* If the user does **not** have an account, they see an **Access denied** message.

**Note:** Different behaviour applies if **Automatically create user** is enabled in the Single sign-on configuration.

If the user is not already signed in to the Single sign-on provider, they are redirected to the provider's login page.

After successful authentication with the provider, Catalyst checks the user's account according to the scenarios above.

## Automatically create user

If **Automatically create user** is enabled in the Single sign-on configuration, Catalyst can create a new user account when someone signs in through the provider for the first time.

In the example below, Rachel Chambers does not yet have a user account in this Catalyst system.

![Users list showing that Rachel Chambers does not yet have an account](../../../images2/zendesk_4409718956817_002_321598ec185f.png)

When Rachel signs in through the Single sign-on provider, Catalyst creates a user account automatically.

The user account fields are populated as follows:

* **Email** - taken from the email address stored with the Single sign-on provider
* **Account type** - set to **Standard**
* **First name** - taken from SSO API user information
* **Last name** - taken from SSO API user information
* **Account status** - set to **Active**
* **Roles** - assigned from the **Roles to assign to created user** field in the Single sign-on settings

A maximum of 10 Roles can be assigned to a user created this way.

![Single sign-on settings showing roles assigned to automatically created users](../../../images2/zendesk_4409718956817_003_a8beefedf4ea.png)

After successful login, the user can access the parts of Catalyst allowed by the Role or Roles assigned through the Single sign-on configuration.

In the example below, Rachel Chambers has been created as a user with a Standard account type and assigned the configured Role.

![Automatically created user account after successful Single sign-on](../../../images2/zendesk_4409718956817_004_16a0ca3e7d7c.png)

## Things to remember

1. Single sign-on users are matched to Catalyst accounts using their email address.
2. A non-active account becomes Active after the user's first successful SSO login.
3. If **Automatically create user** is not enabled, users without an account see an **Access denied** message.
4. Users created automatically through SSO are given a Standard account type.
5. Roles for automatically created users are controlled by the Single sign-on configuration.
6. Email and password fields remain visible on the login page for users who do not use SSO.

---

---
url: >-
  /knowledgebase/administration/authentication-objects/what-is-an-authentication-object-and-how-do-i-configure-it.md
---

# What is an Authentication object and how do I configure it?

An Authentication object securely stores the credentials required to authenticate with external systems.

Rather than embedding usernames, passwords, API keys or client secrets into individual API Calls, you can store them in a single Authentication object and reuse it wherever those credentials are needed.

This approach improves security, simplifies administration, and makes it easy to update credentials without editing multiple integrations.

## Supported providers

Authentication Objects support the following authentication providers:

* **Autologyx Internal**
* **DocuSign**
* **API Key**
* **Adobe OAuth 2.0 (Client Credentials flow)**
* **Box OAuth 2.0 (Client Credentials flow)**
* **Generic OAuth 2.0 (Client Credentials flow)**
* [**Generic OAuth 2.0 (ROPC Grant flow)**](/knowledgebase/release-notes/release-notes-1.11/ropc-flow-authentication-objects/)
* **iManage OAuth 2.0 (Password Grant flow)**

## Create an Authentication object

To create an Authentication object, you must have the appropriate Role permissions and the authentication details for the provider you want to connect to.

Navigate to:

**Administration** → **Authentication Objects**

Click **+ Create**.

A maximum of **100 Authentication Objects** can be configured in your system. Once this limit is reached, the **+ Create** button is disabled.

![Authentication Objects list showing the Create button](../../../images2/zendesk_4410097277713_001_f079baffd2f6.png)

## Enter the object details

Provide a unique and descriptive **Name**.

This is the name you'll select later when configuring API Call actors, so choose something that clearly identifies the integration or account.

Optionally, add a **Description** to explain the Authentication Object's purpose. Descriptions can contain up to **500 characters** and are displayed in the Authentication Objects list.

### Expiry dates

If the credentials expire, enable **Set expiry date**.

You can then:

* select the expiry date
* record what the expiry relates to

Recording expiry dates makes it easier to manage credential renewals before integrations stop working.

You can also use the Sequencer to create automated reminders as expiry dates approach.

![Authentication Object expiry date configuration](../../../images2/zendesk_4410097277713_002_07afa05fec70.png)

## Select the provider

Choose the appropriate **Provider**.

After selecting a provider, additional configuration fields are displayed. These fields vary depending on the provider being configured and must all be completed before the Authentication Object can be tested.

## Validate and test

Autologyx performs validation as you enter information.

For example:

* Authentication Object names must be unique.
* URL fields must use a valid format.
* Mandatory fields must be completed before testing is allowed.

![Validation message showing an invalid configuration value](../../../images2/zendesk_4410097277713_003_0ddbb89a05fd.png)

The **Test Authentication Object** button remains disabled until all mandatory fields contain valid values.

If the authentication test fails, a toast notification explains that the connection could not be established.

![Toast notification showing a failed authentication test](../../../images2/zendesk_4410097277713_004_f52b78c9c188.png)

Once the authentication test succeeds, click **Save**.

The Authentication Object is added to the Authentication Objects list and a success notification confirms that it has been created.

## Next steps

After creating an Authentication Object, you can reference it from one or more API Call actors.

For more information, see [Using an Authentication object in an API call](/knowledgebase/administration/authentication-objects/using-an-authentication-object-in-an-api-call/).

## Things to remember

1. One Authentication Object can be reused by multiple API Call actors.
2. Storing credentials centrally makes them easier to maintain and update.
3. Expiry dates help you manage credential renewals before integrations are affected.
4. A maximum of **100 Authentication Objects** can be configured in your system.

---

---
url: >-
  /knowledgebase/system-configuration/relational-modeller/what-is-the-relational-modeller.md
---

# What is the Relational modeller?

The Relational modeller allows a user to create parent/child relationships between object classes.

It not only provides a visual display of these relationships, but is also the mechanism by which child object classes are made available to the parent object class.

This means that when a relationship has been configured and saved in the relational modeller, child object classes can be added to the create/edit view of the parent object class.

It also means that the parent record will have access to the data held in related child records, and that this data can be merged into documents and send message actors.

The screenshot below shows a relational modeller with two separate relationships.

![](/knowledgebase/images/img_10381818299293_1776895902.png)

## **Relationship 1: left-hand side**

The first relationship, on the left-hand side, consists of three object classes, each at a different level:

* **Employee Management (HR)** is at the top - we call this the root parent.
* **Employee Management (HR)** has one direct child - **Employees**. The ratio of parent record to each child record is 1:1. Note that object class **Employees** is not only a child. It is a parent to object class **Employment Contracts**.
* **Employment Contracts** is a direct child of **Employees**. The ratio of Employee to Employee Contracts is one to many, shown as 1:N. During the life-cycle of any employee, it is likely that they will have more than one contract as the company expands or their job role changes, etc.

## **Relationship 2: right-hand side**

The second relationship, on the right, has a root parent object class called **Mortgage Application**.

It has four direct child object classes, each with a 1:1 ratio with the parent. This means that a Mortgage Application record can have no more than one **Applicant 1** record, one **Applicant 2** record, one **Property**, and one **Lender**.

Find out more about [creating your relational model](/knowledgebase/system-configuration/relational-modeller/creating-the-relational-model/).

## **Useful info**

For any user creating or editing the relational model:

1. There is one relational modeller per instance of Catalyst.
2. The maximum number of root parent object classes is five.
3. An object class can only appear once in the relational model. It will be greyed out on the Object class sidebar once dropped onto the canvas.
4. The maximum number of child object classes another object class can have is five.
5. The maximum number of parent/child levels for any relationship is five. This limit is from the root parent (or top object class) down to the deepest descendent.
6. A record in a parent object class can be created without any child objects, or it may contain some, eg in the above example, a Mortgage Application may be created with an Applicant 1 record and a Property. It may be edited later to include a Lender. It does not have to ever include an Applicant 2.

---

---
url: /knowledgebase/system-configuration/sequences/what-is-the-sequencer.md
---

# What is the Sequencer?

The **Sequencer** is the workflow engine within Autologyx. It is where you build and run your automated processes.

## Access

You will be able to access the sequencer if:

* You have a super admin account type
* You have a config admin account type and a role which gives create and/or edit sequence permissions

## What the Sequencer does

You can select one of the Object classes you have already created and use the Task templates you have configured, together with the sequence actors, to ensure that the right people are involved at the right time and are presented with appropriate tasks and communications.

The Sequencer can handle thousands of processes, events, tasks and communication.

It can switch from one route or process to another, depending on the response it gets back from a User or third party system, and can be used to track expiry dates so that reminders are sent out well in advance.

## Main features

The main features of the Sequencer are:

* **Drag and drop interface**
* **Processes can be triggered to commence under various circumstances**: creation of Records, Records being updated, addition or removal of child records, and when certain points in a "main" process have been reached, other sequences can be activated
* **Ability to create “intelligent” pathways** based on changing Record data, completion of a task or response from a third party system via an API call, etc
* **Send bespoke messages** to internal and external users and third parties who never log in
* **Ability to connect to 3rd party systems via API**
* **Use of Authentication objects** to ensure optimum security when connecting to third party systems
* **Use of "Actors"** to assist in getting, managing and processing data

![](/knowledgebase/images/img_6231824652445_1776895985.png)

Please see further articles in this section to help you with navigation and configuration of sequences.

---

---
url: >-
  /knowledgebase/using-help-and-support/we're-here-to-help/what-to-expect-when-you-submit-a-support-ticket.md
---

# What to expect when you submit a support ticket

---

---
url: /knowledgebase/finding-your-way-around/my-account/what's-in-my-account.md
---

# What's in My account?

Click your name in the top right-hand corner to reveal your **"My account"** page and the **Log out** option.

![mceclip0.png](../../../images2/zendesk_5709757886749_001_0010ecc7bae1.png)

When you go into **My account**, you'll see your Avatar, your first and last name, and your username (email address) in brackets at the top of the page.

## Tabs

Below this are 3 tabs:

### My account

Here, your Username is repeated.

A section called **Personal Information** follows. The details here are populated from your User account.

If you amend these details, the changes will be saved here and written back to your User account.

![mceclip0.png](../../../images2/zendesk_5709757886749_002_17a06fbecc62.png)

Likewise, if a User with a Super Admin account type edits the information in your User account, the changes will be reflected in your **My account** tab.

### Preferences

Here you can define options for your view of the application.

#### Language and localisation

Under the **Language and localisation** tab, you can:

* set your time zone
* select the date format, decimal format and thousand separator format to be used in date and numeric fields throughout the system
* select the required language for your system

![mceclip2.png](../../../images2/zendesk_5709757886749_003_58e2dd3bd6ee.png)

#### Row settings

Under the **Row settings** tab, you can set the row density for all lists in your system.

![mceclip3.png](../../../images2/zendesk_5709757886749_004_84deba400547.png)

### Password

Here you can change your system password as often as you wish.

The password requirements are shown so that you can ensure your new password conforms to the password rules set in Standard authentication.

![mceclip1.png](../../../images2/zendesk_5709757886749_005_cb6206bba31a.png)

## Useful info

1. Only Users with a **Super admin** or Standard account type will have a **"My account"** page.
2. All **Preferences** settings are global.

---

---
url: >-
  /knowledgebase/system-configuration/relational-modeller/who-can-create-a-relational-model.md
---

# Who can create a relational model?

Users with a Super admin account type can create and edit the relational model. These users automatically have access to all areas of the system.

## Choosing the account type

The account type is chosen when creating a user, as below:

![super\_admin.png](/knowledgebase/images/img_10383469362205_1776895903.png)

As you will want to keep the super admin type of user to a minimum for security and data integrity purposes, a role permission is also available for create/edit relational model.

## Role permission for create/edit relational model

This can be found in the Data model tab of System permissions when you create or edit a Role.

![relational\_modeller\_permission.png](/knowledgebase/images/img_10383469362205_1776895903.png)

A role can be given to users with a standard account type so that they can access the relational modeller to create and edit this feature.

## Restricted menu items

You will note, however, that the menu items under System configuration are restricted:

|  |  |
| --- | --- |
| **User with super admin account type** | **User with standard account type and role allowing access to certain system areas including the relational modeller** |
|  |  |

**Please note:** A user who has a role with the create/edit relational model permission enabled will also need the edit permission enabled for Object classes under the System permissions/Data Model tab. This will allow the user to select the required object classes for the model.

---

---
url: /knowledgebase/administration/user-groups/why-do-i-need-user-groups.md
---

# Why do I need User Groups?

User Groups allow you to organise users into logical teams so they can be managed and referenced throughout the system.

Unlike Roles, which determine **what a user is allowed to do**, User Groups determine **who users belong with**.

A User Group can contain users with different Roles, or it can contain users who all perform the same job. For example, you might create User Groups for:

* Customer Services
* Compliance
* HR
* Finance
* Regional Teams
* Project Teams

Once created, a User Group can be used throughout Catalyst wherever multiple users need to be selected or managed together.

## Where User Groups can be used

User Groups can be referenced in many areas of the system.

### User-type fields

A User Group can be selected in a User-type field configured on an Object Class.

User-type fields can appear in:

* Create, Edit and Summary views
* Standalone forms
* Task Templates of the **Update object record** type
* Task Assignment actors in the Sequencer
* Record Access actors in the Sequencer

![User Group available for selection in a User-type field](../../../images2/zendesk_4402906517521_001_059e4a093c92.png)

## Permission Sets

User Groups can be assigned to Permission Sets, making it easier to grant access to many users at once.

Examples include:

* Object Class Permission Sets
* User Group Permission Sets

![Assigning a User Group to a Permission Set](../../../images2/zendesk_4402906517521_002_004fa616c811.png)

**Note:** User Groups can also be assigned to Record Permission Sets, but this is done through a Record Access actor or the API rather than directly from the Record.

## Record Access actors

User Groups can be used within Record Access actors in the Sequencer.

Depending on the configuration, the actor can:

* append users
* override existing users
* remove users

from a Record Permission Set.

![Record Access actor using a User Group](../../../images2/zendesk_4402906517521_003_c7b538b19611.png)

## Manual task creation

When manually creating a task, a User Group can be selected to assign the task to multiple users.

![Selecting a User Group during manual task creation](../../../images2/zendesk_4402906517521_004_5ee56f9dcb6f.png)

## Task reassignment

User Groups can also be selected when manually reassigning an existing task.

![Selecting a User Group when reassigning a task](../../../images2/zendesk_4402906517521_005_01bca31dacf9.png)

## Send Message actors

Within the Sequencer, a User Group can be selected in a **Send Message** actor.

Each member of the User Group will receive the same email notification.

![Selecting a User Group in a Send Message actor](../../../images2/zendesk_4402906517521_006_6aaa7605e714.png)

## Why use User Groups?

Using User Groups instead of selecting individual users offers several advantages.

You can:

* manage teams instead of individual users
* assign permissions to multiple users in one action
* simplify task assignment
* simplify workflow configuration
* make Sequence configuration easier to maintain
* reduce ongoing administration as team membership changes

## Related articles

To learn more, see:

* [User Group List](/knowledgebase/administration/user-groups/user-group-list/)
* [What do I need to know about creating a User Group?](/knowledgebase/administration/user-groups/what-do-i-need-to-know-about-creating-a-user-group/)
* [Editing a User Group](/knowledgebase/administration/user-groups/editing-a-user-group/)
* [User Group Permissions](/knowledgebase/administration/user-groups/user-group-permissions/)

## Things to remember

1. A user can belong to multiple User Groups.
2. The user who creates a User Group automatically becomes both its first Member and first Owner.
3. A User Group can have up to 10 Owners.
4. A User Group can contain up to 1,000,000 Members.
5. A system can contain up to 1,000 User Groups.
6. User Groups complement Roles—they organise users, whereas Roles determine administration permissions.
7. Using User Groups makes permission management and workflow configuration much easier as teams grow.

---

---
url: /knowledgebase/administration/roles-and-permissions/why-do-users-need-roles.md
---

# Why do Users need Roles?

Roles control which areas of **Administration** and **System Configuration** a user can access and what actions they can perform within those areas.

Roles are assigned to users with the Config Admin account type. They allow you to delegate configuration responsibilities without granting unrestricted access to the entire system.

For example, one Config Admin might be responsible for maintaining Task Templates, while another manages Sequences or configures Single sign-on. Roles make it possible to give each user only the permissions they require.

## What do Roles control?

Roles determine whether a Config Admin can create, edit or delete items within specific areas of the platform.

Examples include:

### System Configuration

Roles can grant permission to manage:

* Object Classes
* Task Templates
* Task Group Templates
* Sequences

### Administration

Roles can also control access to Administration features, including:

* Authentication Objects
* Single Sign-on settings
* Company Details
* User Groups

Roles **do not** control access to records or tasks.

Access to business data is managed separately using:

* Object Class Permission Sets
* Record Permission Sets
* User Group Permission Sets

A Config Admin will often have both a Role (to configure the system) and one or more Permission Sets (to work with records and tasks).

## The Roles list

The **Roles** list displays all configured Roles.

By default, the list shows the key information required to identify each Role.

Additional columns are available through **Column configuration**, including:

* Created
* Created by
* Last edited
* Last edited by

Your chosen column configuration is remembered the next time you sign in.

![Roles list showing additional audit columns](/knowledgebase/images/administration/why-do-users-need-roles.png)

## Managing Roles

Users with the appropriate permissions can create, edit and delete Roles from the Roles list.

For more information, see:

* [How do I create a Role?](/knowledgebase/administration/roles-and-permissions/how-do-i-create-a-role/)
* [What happens if I edit a Role?](/knowledgebase/administration/roles-and-permissions/what-happens-if-i-edit-a-role/)
* [Overview of User Permissions](/knowledgebase/administration/roles-and-permissions/overview-of-user-permissions/)

You can also find out more about the common features available on list pages:

* [List Pages](/knowledgebase/finding-your-way-around/ui-and-navigation/list-pages/)
* [List Page Filter Editor](/knowledgebase/finding-your-way-around/ui-and-navigation/list-page-filter-editor/)

## Things to remember

1. Roles apply only to users with the Config Admin account type.
2. Roles control access to Administration and System Configuration—not business records or tasks.
3. Record access is managed separately using Object Class, Record and User Group Permission Sets.
4. A user can be assigned multiple Roles. Where permissions overlap, the most permissive access is applied.
5. Your Catalyst system can contain up to **5,000 Roles**.

---

---
url: /knowledgebase/system-configuration/working-with-document-templates.md
---
# Working With Document Templates

**Browse the sections below:**

* [Automatic Generation Of Documents Via The Sequencer](/knowledgebase/system-configuration/working-with-document-templates/automatic-generation-of-documents-via-the-sequencer/)
* [Create A Document Template](/knowledgebase/system-configuration/working-with-document-templates/create-a-document-template/)
* [Document Templates List](/knowledgebase/system-configuration/working-with-document-templates/document-templates-list/)
* [Edit A Document Template](/knowledgebase/system-configuration/working-with-document-templates/edit-a-document-template/)
* [Manual Generation Of A Document From A Template](/knowledgebase/system-configuration/working-with-document-templates/manual-generation-of-a-document-from-a-template/)
* [Ms Word Add In   Configuration](/knowledgebase/system-configuration/working-with-document-templates/ms-word-add-in---configuration/)

---

---
url: /knowledgebase/workspace/working-with-relational-records.md
---

# Working with Relational Records

Relational records allow you to create and manage parent and child relationships between Object records.

These relationships help users organise information across related Object classes, such as customers and orders, employees and contracts, or matters and documents.

The articles below explain how to create, associate, and work with related records from within the Workspace.

## Creating and associating child records

### Create a child record from a parent record

Learn how to create a new child record directly from an existing parent record.

* [How to create a child record from the parent record](/knowledgebase/workspace/working-with-relational-records/how-to-create-a-child-record-from-the-parent-record/)

### Associate existing child records

Learn how to link an existing child record to a parent record.

* [How to associate child records with existing parent records](/knowledgebase/workspace/working-with-relational-records/how-to-associate-child-records-with-existing-parent-records/)

## Working with related records

### View and interact with child records

Learn how to:

* preview child record information

* open child records as fly-outs

* navigate through parent, child, and grandchild records

* [Interacting with associated child records via the parent](/knowledgebase/workspace/working-with-relational-records/interacting-with-associated-child-records-via-the-parent/)

## Things to remember

1. Parent and child relationships must be configured using the Relational Modeller before they can be used in the Workspace.
2. Child Object classes must be added to the Create and Edit View of the parent Object class.
3. Your permissions determine which related records you can view and interact with.
4. Related records can be navigated directly from parent records without leaving the Workspace.

---

---
url: /knowledgebase/workspace.md
---
# Workspace

The **Workspace** is where most day-to-day work is carried out in the Autologyx platform.

It is primarily designed for internal and external users who need to work with Records, Tasks, and related information as part of their normal operational processes. In most cases, this area is intended for users who are not working as Config Admins or Super Admins.

Within the Workspace, users can:

* **view and work with** Records
* **create and update** information
* **complete and manage** Tasks
* **work with** related records and parent / child relationships
* **access** the Task Panel to progress assigned work

## Who this section is for

This section is mainly relevant to:

* internal operational users
* external users working in a shared process
* case handlers, reviewers, and task-based users
* anyone carrying out day-to-day work in the platform

If you are looking for platform setup, configuration, or administration guidance, you will usually need the **System Configuration** or **Administration** areas of the Knowledgebase instead.

## What you will find in this section

### Records

**Learn how to work with records** in Catalyst, including viewing, editing, creating, and managing access.

* [Records](/knowledgebase/workspace/records/)

### Tasks

**Understand how tasks are presented** in the **Workspace** and how users can work with task lists.

* [Tasks](/knowledgebase/workspace/tasks/)

### Working with relational records

**Learn how to work with related records**, including parent and child records, creating related records, and interacting with associated information.

* [Working with relational records](/knowledgebase/workspace/working-with-relational-records/)

## Notes

::: info
The Workspace is focused on **doing the work** of the platform rather than configuring how the platform behaves.
:::

::: tip
If you are new to the Workspace, a good place to start is [Records](/knowledgebase/workspace/records/), and [Tasks](/knowledgebase/workspace/tasks/), as these are the areas most users interact with every day.
:::