# Knowledge Base Source: https://knowledge.goautonomous.io/index In-depth guides, tutorials, and documentation for getting the most from Go Autonomous.
# Knowledge Base

In-depth guides, tutorials, and documentation for getting the most from Go Autonomous.

Flow

Review, confirm, and process orders with smart automation and vendor management.

Workstation

Manage incoming requests, track statuses, and upload new requests in one place.

Axon

Build and manage intent trees, create custom intents, and train your AI assistant.

Administrator Set Up

Configure your platform settings, manage users, and customize your workspace.
# Permission levels by product Source: https://knowledge.goautonomous.io/knowledge-base/administration/access-control/permission-levels What each product access level means in the platform — the user experience users get for Flow, Workstation, Pulse, and Axon at every level. ## Overview When you enable a product in a [user group's](/knowledge-base/administration/access-control/user-groups) Products tab, the access level you choose determines what members can do in that product. This page is the full reference for what each level means in practice. ## Flow Flow access is split into two scopes: requests **inside** the user's assigned area / intent / inbox, and requests **outside** of it. ### Inside area, intent, or inbox | Permission | User experience | | - | - | | **Viewer** | Same view as a secondary viewer on a request — can see everything, leave comments, but not confirm. A "view only" banner is shown. | | **Editor** | Full access — review, edit, and confirm requests. | ### Outside area or intent | Permission | User experience | | - | - | | **No access** | A 404 page appears if the user reaches the URL of a mail outside their area. | | **Viewer** | View-only access to mails outside the assigned area or intent. | ## Workstation Workstation visibility is filtered by area, intent, or inbox depending on how the user's group is scoped on the Spaces tab. | Permission | User experience | | - | - | | **In-scope mails only** | Only mails within the user's assigned area, intent, or inbox are visible. Sidebar filters also hide options unique to scopes the user can't access (e.g. a domain unique to another area). | | **All mails** | Standard experience — every mail across the organisation is visible. | | **No access** | The Workstation entry is removed from the navigation, and the URL returns a 404. | ## Pulse | Permission | User experience | | - | - | | **Viewer** | Can browse and inspect anything in Pulse, but cannot edit. | | **Editor** | Full edit access. | | **No access** | Pulse is hidden from the navigation. | ## Axon | Permission | User experience | | - | - | | **Viewer** | Can browse and inspect anything in Axon, but cannot edit. | | **Editor** | Full edit access. | | **No access** | Axon is hidden from the navigation. | ## Access Control (administration pages) The Access Control section supports per-page levels. Set them on the [Administration access](/knowledge-base/administration/access-control/user-groups#administration-access) tab of a user group. ### Users page | Permission | User experience | | - | - | | **Viewer** | Can open the Users page, view profiles, and see each user's effective permissions. Cannot invite, edit, delete, or reassign users. | | **Editor** | Full access — invite users, edit profiles, delete users, and change group memberships. | | **No access** | The Users page is hidden from the navigation; the URL returns a 404. | ### User Groups page | Permission | User experience | | - | - | | **Viewer** | Can browse the User Groups page and open the details sheet on any group. Cannot create, edit, copy, or delete groups. | | **Editor** | Full access — create, edit, copy, and delete groups, and manage their memberships. | | **No access** | The User Groups page is hidden from the navigation; the URL returns a 404. | ## What's next * [User Groups](/knowledge-base/administration/access-control/user-groups) — configure these levels on a group. * [User Management](/knowledge-base/administration/access-control/user-management) — see each user's effective permissions. # Overview Source: https://knowledge.goautonomous.io/knowledge-base/administration/access-control/user-groups Create user groups to define what your team members can access — products, areas, inboxes, intents, and admin pages. ## Overview User groups are how you control access in Go Autonomous. A group bundles together a set of permissions — which products users can use, which areas they can see, which inboxes and intents they can work with, and which administrative pages they can reach. You then assign users to groups, and they inherit everything that group allows. Find groups under **Administration → Access Control → User Groups**. ## The Access Control Manager group Every Go Autonomous environment includes one protected system group: **Access Control Manager**. Members of this group have full access to manage the Access Control area itself — adding and removing users, creating and editing user groups, and configuring SCIM. The group cannot be deleted, and its permissions cannot be edited (a shield icon marks it on the User Groups page). You can still add and remove members from it. This is the only system-protected group in the long-term setup. All other groups in your environment are fully editable. ## Create a user group The Create New User Group dialog opens. Templates pre-fill permissions across every tab, so you only need to adjust what's different. | Template | Pre-configured access | | - | - | | Everyday User | Full Flow and Workstation access in the default area | | Platform Administrator | Full access to all products and user management in the default area | | IT Administrator | Edit access to integration pages only (Connectors, Authenticators) | | Super User | Everyday user access plus user management capabilities | | Custom | No pre-configured permissions — start from a blank slate | Templates are only available when creating a new group, not when editing or copying. Work through the tabs to define what this group can do. Each tab is described below. Click **Create Group**. The group appears as a new card on the User Groups page. ## The group configuration tabs ### Basic Info The group's name (required and unique) and an optional description. **Auto-assign new users** — toggle this on to automatically add every newly created user to this group on their first login. Use it for the baseline access you want every team member to have (for example, default Flow viewer rights). The flag has no effect on users provisioned through SCIM — those memberships are still controlled by your identity provider. You can mark more than one group as auto-assign — a new user will be added to all of them. ### Members Pick the users that belong to this group. Open the **Members** combobox to search by name or email and select one or more users. The count next to the field reflects the current selection. System users are filtered out automatically. You can leave this step empty and add members later from the [User Management](/knowledge-base/administration/access-control/user-management) page. ### SCIM/SSO External Group ID mapping and sync settings. Use this tab when you want this group's membership to sync automatically from your identity provider. ### Spaces Define the access scope for this group: * **Mode** — choose between **Area** (filter mails by geographic area) or **Inbox** (filter by inbox assignment). * **Areas** — select specific areas, or use **Default (All Areas)** for full access. * **Inboxes** — select specific inboxes; with no selection, the group has access to all inboxes. Public and private inboxes are distinguished with icons. * **Intents** — choose allowed intents from the hierarchical Category → Subcategory → Intent tree. When Inbox mode is selected, available intents may be limited based on inbox restrictions. ### Products Toggle each product on or off and configure access levels: | Product | Configuration | | - | - | | Flow | Master toggle + In-area access (Viewer / Editor) + Out-of-area access (No Access / Viewer) | | Workstation | Master toggle + Visibility (Assigned Only / All Mails) | | Pulse | Master toggle + Access Level (Viewer / Editor) | | Axon | Master toggle + Access Level (Viewer / Editor) | If Pulse or Axon is enabled without a level selected, you'll see a validation error before you can save. ### Administration access Administration permissions are now more granular in two ways: you can control **view vs. edit** access independently per section, and — for sections that support it — restrict **which areas** a group can act on. | Area | Access levels | | - | - | | Access Control | Section toggle + per-page level (No Access / Viewer / Editor) for **Users** and **User Groups** | | Company Settings | No Access, Editor | | Audit Trail | No Access, Editor | #### Access Control — per-page levels Toggle **Access Control** on to open the per-page controls. For each page, pick the level members should get: | Page | Level | User experience | | - | - | - | | **Users** | No Access | The section is locked from the navigation; the URL returns a 404. | | | Viewer | Can open the Users page and inspect every user's profile and effective permissions, but cannot invite, edit, or delete users. | | | Editor | Full access — invite users, edit profiles, assign group memberships, delete users. | | **User Groups** | No Access | The section is locked from the navigation; the URL returns a 404. | | | Viewer | Can browse groups and open the details sheet, but cannot create, edit, copy, or delete groups. | | | Editor | Full access — create, edit, copy, and delete groups, and manage their memberships. | Toggling Access Control off resets both pages to **No Access**. Toggling it on defaults both pages to **Editor** — narrow them down as needed before saving. **Viewer** is the key addition here: it lets someone see exactly how access is structured — who's in which group, what a group can do, who owns which account — without being able to change any of it. Use it for auditors, team leads, or anyone who needs visibility into your access setup but shouldn't be able to modify it. Use **Viewer** on the User Groups page when you want auditors or team leads to see how permissions are structured without giving them the ability to change them. Use **Viewer** on the Users page when someone needs to check a colleague's group membership or effective permissions without being able to edit their account. #### Area-scoped Editor access For **Configurations** (Field Manager, product catalogs, reference data) and **Reference Data**, Editor access is scoped to the group's assigned areas — the same scoping used for Flow and Workstation on the Spaces tab. For example, if a group's Spaces tab is scoped to **Area A** only, an Editor in that group can update field settings and catalog data for Area A, but cannot touch the configuration or catalogs for Area B — even though both areas share the same Configurations section. This lets you delegate configuration work to regional admins without granting them broader access than intended. Area-scoped access doesn't yet extend to **Pulse** or the rest of **Company Settings** — those remain global for now (an Editor can act on any area). Area-scoped access for these is on the roadmap. See [Relaunching of User Groups](/knowledge-base/administration/access-control/user-permissions) for the full rollout status. ## Group card stats Each group card on the User Groups page shows a quick summary of how much access the group has — members, inboxes, areas, and intents. The wording reflects how the group is scoped: * **`X inboxes`, `X areas`, `X intents`** — the group is scoped to a specific set. * **`Any inbox`, `Any area`, `Any intent`** — the group is unrestricted for that dimension (no specific selection — full access). * **`No inboxes`, `No areas`, `No intents`** — the group has no access to that dimension. Use these counts to spot misconfigured groups at a glance — for example, an "Editor" group that unexpectedly shows **No areas**. ## Copy a group Use copy to quickly create a variant of an existing group. Click the **Copy** icon on any group card. The dialog opens pre-populated with the source group's settings: * The name is auto-suffixed with **(Copy)** and must be changed to something unique. * SCIM/SSO settings are reset — the External Group ID is cleared and sync is disabled. * No members are copied — the new group starts empty. ## Edit a group Click any group card to open the details sheet, then click **Edit** to make changes. Members of [protected groups](#protected-groups) can be managed but the group's settings cannot be changed. ## Delete a group To delete a group, open the group's menu and select **Delete**. To confirm, you must type the group name exactly. If the group has members, you'll be prompted to migrate them to another group before the deletion completes — this prevents users from being orphaned without permissions. If the group is synced via SCIM/SSO, you'll see a warning that you'll need to remove or reassign the group mapping in your identity provider configuration after deletion. ## Protected groups The **Access Control Manager** group is protected. Members of this group are granted full access to everything in the Access Control area — they can add and remove users, create and edit other user groups, and configure SCIM. The group itself can't be edited or deleted, though members can still be added to and removed from it. A shield icon marks protected groups on the card and the details sheet. For the full breakdown of what each access level means in each product, see [Permission levels by product](/knowledge-base/administration/access-control/permission-levels). ## Group details sheet Clicking a group card opens a details sheet with everything about the group: * Name, description, and Copy/Edit buttons * SCIM/SAML sync badge if applicable * Created date, created by, last synced timestamp, and external ID * Up to 4 member avatars with names; if there are more, a "View all X members" link opens the Users page filtered to that group * Space access (either Inbox Assignments or Area Access) * Intent access list * Product access summary * User access privileges (categorised by level) * Page access (categorised as Full Access, Area Only Editing, or View Access) ## What's next * [User Management](/knowledge-base/administration/access-control/user-management) for adding users to your groups. # User Management Source: https://knowledge.goautonomous.io/knowledge-base/administration/access-control/user-management Add users, manage their group memberships, and view their effective permissions across the platform. ## Overview The Users page is where you add new users to Go Autonomous, control who they are, and see exactly what each user has access to. Permissions are inherited from the user groups a user belongs to — there are no per-user permission overrides. Every change you make here flows through to the rest of the platform automatically. Find it under **Administration → Access Control → Users**. If SCIM is set up for your organisation, users are provisioned automatically from your identity provider — they appear in the Users table without anyone having to add them manually. You can still add users manually for cases where SCIM doesn't reach. ## Multiple group memberships Users can belong to more than one group. When a user's groups have different permission levels for the same space, product, or administration area, the user inherits the **broader** of the available permissions for each dimension. For example: if Group A grants Pulse Viewer access and Group B grants Pulse Editor access, a user in both groups will have Pulse Editor access. ## The Users page The Users page lists everyone with access to your Go Autonomous environment. Each row shows: | Column | What it shows | | - | - | | Name | The user's avatar (initials), full name, and an SSO indicator if they're synced from your identity provider | | Email | The address they use to sign in | | Groups | Up to two group names; if a user belongs to more, a `(+X)` count appears | | Last Sign In | A relative timestamp (e.g. "2 days ago") or "Never" | | Created | When the user was first added to Go Autonomous | Use the **search bar** above the table to filter by name or email. The result count is shown beneath the search input. ## Add a user The Add User dialog opens. Provide the **Full Name** and **Email Address**. Both are required. Pick a group from the **Assign to Group** dropdown. Every user must belong to at least one group — that's how their permissions are determined. Click **Add User**. The new user appears in the table and immediately inherits all permissions from their assigned group. ## Edit a user Click any row in the table to open the user details sheet on the right. Once a user has been assigned to a group, the details sheet shows exactly what they can access through that group — area access, intent access, page access, and product permissions. From the same sheet you can: * Update the user's **first name** and **last name**. * Change their **group memberships**. * Trigger a **password reset**. The user's email address cannot be changed after creation. ## Delete users You can delete users individually using the action on each row, or in bulk by selecting multiple rows and choosing **Delete Selected**. Deleted users immediately lose access to the platform. ## View a user's effective permissions Click any user to open their details sheet. The **Effective Permissions** section shows the merged result of every group they're a member of: * **Role badges** — global administrator, IT administrator, or area administrator labels, where applicable. * **Area access** — every area the user can reach, with the access level (Edit or View) for each. * **Intent access** — the first six allowed intents, with a `(+X more)` overflow if the user has access to more. * **Page access** — the first eight pages, with overflow handling the same way. This view is the easiest way to answer "what can this user actually do?" without opening every group they belong to. # Agentic Fields Center Source: https://knowledge.goautonomous.io/knowledge-base/administration/agentic-fields-center Author capturing rules in plain English for standard and custom fields — and see the learnings the platform has collected on each one. This is in **Beta** and is in a phased rollout. See [Rollout plan and what's next](/knowledge-base/administration/agentic-fields-center/rollout-plan) for what's available today. ## Overview The **Agentic Fields Center** gives you control to create your own fields with capturing logic, see the **real-time learnings** the system has collected on each field, and adjust them — all from your administration settings, without needing to loop in your Engagement Manager. The Agentic Fields Center is available to every organization. Find it under **Administration > Company Settings > Agentic Fields Center**. To make it easy to reason about, we've categorised every field into four types. When more than one rule could apply to the same field, the most specific one takes precedence: a **sender email** rule beats a **sender domain** rule, which beats an **Area / Source** rule, which beats the **Global Default**. See [Rule hierarchy](#rule-hierarchy) for the full breakdown. ## The four types of fields We're improving how each type is labelled in the Field Manager so it's obvious at a glance which fields use standard capturing, which are calculated, and which you can override in the Agentic Fields Center. | Type | What it is | Adjustable in Agentic Fields Center? | | - | - | :-: | | **Standard capturing** | A built-in field extracted using our standard model (e.g. product number, quantity). | Yes | | **Standard, calculated logic** | A built-in field derived from a calculation, or driven by special deterministic logic (e.g. total price = quantity × unit price). | No — the logic is fixed | | **Non-standard, no capturing** | A custom field you've defined that isn't being captured automatically. | Yes | | **Non-standard, enhanced capturing** | A custom field with capturing logic you've authored in the Agentic Fields Center. | Yes | ## Setting up a field The Agentic Fields Center sets up **extractions only**. A prompt tells the agent what value to pull out of the source document or email — it can't perform calculations, apply transformations, or look up values in other fields to derive an answer. For logic like that, you still need a **calculated field**, which is fixed, deterministic logic built into the platform rather than something you can prompt for. If you need an additional calculated field, reach out to the integration team to set it up. Everything starts in the [Field Manager](/knowledge-base/administration/fields-manager). From there, the path depends on what kind of field you're working with and whether you want AI to capture it. Add a field from the pre-written **standard** list, or create a **custom field**. Standard fields already have either standard capturing or calculated logic built in; custom fields start out with no capturing at all. * **Standard field, and you don't want AI to capture it** — toggle **Ignore AI Capture** on the field in Field Manager. That's the whole setup; no need to visit the Agentic Fields Center. * **Custom field you want captured, or a standard field whose capturing you want to refine** — head to the **Agentic Fields Center** to write a prompt. This is also where you go if you want to override or narrow down what a standard field captures by default. In Field Manager, toggle **Self-Learning** on for the field if you'd rather the agent build its own capturing rules over time from confirmed requests, instead of (or alongside) a rule you write yourself. See [Self-learning](#self-learning) below for where the rules it learns show up. Open the field in the **Agentic Fields Center** and write a prompt describing what to capture and when — see [Creating a new rule](#creating-a-new-rule) below. Save it, then open a live request to watch the learnings flow in. Today, field definitions are scoped **per intent** — a field's capturing rules apply to the intent you've configured them under. In a future release, a single field definition will be able to span multiple intents so you can maintain one source of truth for the same field across similar request types. ## Using the Agentic Fields Center ### The landing page Navigate to **Administration > Company Settings > Configurations > Agentic Fields Center**. The page opens on a searchable table of every agentic field across your organisation. At the top, you can: * **Search** fields by name. * **Filter by area** — show only fields included in one or more specific areas. * **Filter by intent** — show only fields configured for one or more specific intents. If no fields have been configured yet, the page shows an empty state pointing you to the Field Manager — agentic fields are created through field configurations there, not directly in the Agentic Fields Center. ### Table columns | Column | What it shows | | - | - | | **Field Name** | The field's display name, plus any status badges: an area-access warning if you can't fully access the field, **Auto-calculated** for calculated fields, or **Capture off** for fields with AI capture disabled in Field Manager. | | **Included In Area(s)** | One badge per area the field is configured for. A field with no area override shows a single **Default** badge. | | **Intent** | The intent (or intents) this field is configured under. | | **Prompting Rules Count** | How many prompting rules currently exist for this field, including a [standard Global Default](#standard-global-default) when one is shown. | Rows for **Auto-calculated** and **Capture off** fields are pushed to the bottom of the table and shown dimmed — they're not adjustable here, so clicking them does nothing. ### Opening a field Click any interactive row to open its configuration page. When you click the back button on a field's configuration page, you return to the landing page with your search and filters still applied. This shows: * A header with the field's name, description (if set), and the intent and areas it's configured for. * An **Agent Capture Instructions** section listing every rule for this field, with a count badge. * A **priority note** reminding you how rules are ranked: *Customer Specific > Area + Source > Area / Source > Global Default* (see [Rule hierarchy](#rule-hierarchy) below). * A **search box** and a **filter** (All / Area / Source / Customer) to narrow down the rule list. If no rules exist yet, you'll see an empty state instead — its message differs depending on whether the field already has built-in default extraction (in which case it invites you to add a rule to *refine* capturing) or has no capturing at all yet. Each rule card shows a **Self-Learned** badge when the rule was learned automatically, so you can see at a glance which rules are self-learned and which were written manually. Click any rule card to expand it. From there you can edit the **prompt** and its **examples**, then **Save Prompt**. Cards for **Self-Learned** rules are shown as a read-only overlay first — click **Override with Manual Prompt** to unlock editing. See [Deleting a rule](#deleting-a-rule) below to remove one. ### Standard Global Default Standard capturing fields come with a built-in description that the agent already uses to capture the value. When your organization hasn't written its own Global Default rule for one of these fields, the rule list shows that built-in description as a **Global Default** card with a **Standard** badge. This lets you see the baseline prompt the agent follows before you add more specific rules. The standard card only appears on the **All** filter. It also matches the search box against the description text. To customize the baseline prompt: Click the **Global Default** card marked **Standard** to see its prompt. Change the prompt text and add any **Examples**. A **Draft** badge appears on the card while you have unsaved changes. Click **Save Prompt**. The Agentic Fields Center saves your edit as your organization's own **Global Default (P0)** rule, with the area set to **Default**, the source set to **Any**, and **All Customers**. Your rule then replaces the standard card. Click **Cancel** to discard the draft. If you aren't allowed to create default rules, for example because of your area access, the card shows the reason and **Save Prompt** stays disabled. ### Self-learning Instead of (or alongside) writing a rule yourself, you can let the agent learn a field's capturing rules on its own from confirmed requests. * **Turn it on.** In Field Manager, open the field and toggle **Self-Learning** on. * **Where it shows up.** Rules the agent learns appear back in the Agentic Fields Center like any other rule, but with a **Self-Learned** badge on the card. They're shown as a read-only overlay first — click **Override with Manual Prompt** if you want to take control and edit one yourself. See [Opening a field](#opening-a-field) above for more on reading rule cards. Writing a manual prompt at a sender domain or sender email level stops self-learning for that field **at that level** — your manual prompt takes over there, even if self-learning is still on elsewhere for the field. See [Rule hierarchy](#rule-hierarchy). ### Creating a new rule From a field's configuration page, click **Add rule** to open the rule dialog. Choose which **Area** the rule applies to (or **Default** for every area), and which **Source** the agent should look in — **Any**, **Email**, or **Attachment**. Use Any when the value could appear in either. Leave it as **All Customers** for a broad rule, or narrow it to **By Sender Domain** or **By Sender Email** to target a specific customer. Enter the **Prompt rule** — describe what to capture, where to find it, and how to format it. Add 3–5 **Examples** of realistic values the field should contain. Open **Tips for writing prompts & examples** for guidance and a worked example. A badge in the dialog shows which priority tier the rule will land in as you fill out the form (e.g. **Global Default (P0)**). Click **Add rule** to save it. ### Best practices for writing prompts Be as descriptive as possible — the more context you give the agent, the more reliably it finds the right value. A strong prompt tells the agent **what to look for**, **where to find it**, and **how to format the output**, and your examples show it real values to recognise. For example, to capture a **port**: * **Prompt:** "Identify the port of loading or discharge. Ports are normally listed near the delivery address, or in a dedicated field labelled 'Port', 'POL', or 'POD'. Capture just the port name and country, without the full address." * **Examples:** `Rotterdam, NL`, `POL: Shanghai`, `Hamburg`, `Port of Long Beach` Open **Tips for writing prompts & examples** in the Add rule dialog for more guidance, including a full worked example. ### Deleting a rule On the field's configuration page, find the rule you want to remove. Click the trash icon on the rule card. Confirm in the dialog that appears. Deleting a rule is permanent and can't be undone. ### Rule hierarchy When more than one rule could apply to the same field, the most specific rule wins. Rules are ranked, from highest to lowest priority: | Tier | Priority | What sets it | | - | :-: | - | | **Customer Specific — Sender Email** | P4 | A specific sender email is set on the rule. | | **Customer Specific — Sender Domain** | P3 | A sender domain (not a specific email) is set on the rule. | | **Area / Source** | P1 | An area, a source, or both are set (with no customer identifier). | | **Global Default** | P0 | No area, source, or customer identifier is set — applies everywhere as a fallback. | The Add rule dialog and priority note distinguish rules scoped to **both** an area and a source from rules scoped to only one, but both currently rank at the same **Area / Source (P1)** priority — the difference is in how specifically the rule targets a request, not in which one wins. If you manually write a prompt at a sender domain or sender email level for a field, self-learning stops for that field **at that domain or sender level** — your manual prompt takes over and the system won't keep learning on top of it there, even if self-learning is still on elsewhere for the field. ## FAQ Not today. Prompts can only tell the agent what value to extract — they can't perform math, transformations, or reference other fields to derive a result. This is in **Beta**, and we'll be expanding what you can do here over time — see [Rollout plan and what's next](/knowledge-base/administration/agentic-fields-center/rollout-plan). ## What's next * [Rollout plan and what's next](/knowledge-base/administration/agentic-fields-center/rollout-plan) — how the Agentic Fields Center is being released, phase by phase, and what's coming after. * [Field Manager](/knowledge-base/administration/fields-manager) — configure which fields appear in each configuration. * [Areas](/knowledge-base/administration/areas) — scope Agentic Fields rules to specific areas. # API keys and service accounts Source: https://knowledge.goautonomous.io/knowledge-base/administration/api-keys Create and manage API keys for programmatic access to Go Autonomous. ## Overview API keys let external systems and scripts authenticate with Go Autonomous programmatically. Each API key is tied to a service account — a non-human identity that can call Go Autonomous APIs on behalf of your organization. Use API keys when you need to: * Integrate third-party systems that push or pull data from Go Autonomous. * Automate workflows that interact with the platform API. * Connect custom applications to your Go Autonomous environment. ## The API Keys page Navigate to **Administration > Company Settings > API Keys** to manage your service accounts. The page is split into two tabs: * **Active Keys** — keys that are currently valid and can be used to authenticate. * **Revoked Keys** — keys that have been disabled and can no longer be used. Kept for reference and auditing. Each tab shows a counter next to the label so you can see at a glance how many keys are in each state. For every key, the table shows: * **Name** — the descriptive label you gave the service account. * **Key** — a masked preview of the key value. * **Created by** — the name of the user who created the key. If the user has since been deleted, this displays "Deleted user". * **Creation date** — when the key was created. ## Audit trail Click the **Audit trail** button in the top-right of the page to open a drawer with the full history of API key activity — keys created, revoked, and other changes — along with who performed each action and when. Use the audit trail to: * Audit who created or revoked a key. * Investigate when a key was last changed. * Confirm that a revocation took effect. The audit trail mirrors entries shown in the broader [Audit Trail](/knowledge-base/administration/audit-trail), but scoped to API key events only. ## Create an API key Click the add button to create a new service account and API key. Enter a descriptive name that identifies the integration or system that will use this key (e.g., "ERP Sync Service" or "Reporting Dashboard"). After creation, the API key is displayed. Copy it immediately — for security reasons, the full key is only shown once. Store API keys securely. Treat them like passwords — never commit them to source control or share them in plain text. If a key is compromised, revoke it immediately and create a new one. ## Revoke an API key If an API key is no longer needed or has been compromised, revoke it to immediately disable access: 1. On the **Active Keys** tab, find the service account in the list. 2. Click the **Revoke** icon on the corresponding row. 3. Confirm the revocation. The key moves to the **Revoked Keys** tab and the action is recorded in the audit trail. Revoking a key is permanent. Any system using the revoked key will immediately lose access and will need to be updated with a new key. ## Best practices * **Use one key per integration** — this makes it easy to revoke access for a single system without affecting others. * **Rotate keys regularly** — create new keys and update your systems periodically as a security measure. * **Name keys descriptively** — use names that make it obvious which system uses each key, so you can manage them confidently. * **Track key ownership** — the API Keys page shows who created each key, making it easier to follow up if a key needs to be rotated or investigated. ## What's next * [Set up connectors](/knowledge-base/administration/connectors) to connect Go Autonomous to external systems. * [Configure authenticators](/knowledge-base/administration/authenticators) for credential management. # Areas Source: https://knowledge.goautonomous.io/knowledge-base/administration/areas Segment your organization into areas to route requests, apply different settings, and manage workflows by team or region. ## Overview Areas let you segment your Go Autonomous environment into logical divisions — by team, region, business unit, or any grouping that makes sense for your organisation. Each area has its own field configurations, product catalogs, reference data, and autonomous mode settings. Every organisation starts with an **Unassigned** area (the system default) that holds all requests not assigned to a specific area. ## The Areas page Navigate to **Administration > Company Settings > Areas** to manage your areas. Accessing Company Settings Company Settings Areas
Areas are displayed as a grid of cards. Each card shows: * **Emoji** — a customisable emoji you choose when creating the area.\\ * **Area name** — the display name of the area.\\ * **Subtitle** — an optional short description.\\ * **Inbox count** — the number of inboxes and intents connected to the area (e.g. "3 inboxes (5 intents)").\\ * **Status badge** — shows **Autonomous** if the area has Autonomous Mode enabled, **System Default** if it is the **Unassigned** area, or no badge if it is a standard area without autonomous processing. Company Settings Areas Zoomed ### The blue indicator A coloured bar runs along the top of each area card. When the bar is **blue**, the area has Autonomous Mode enabled — meaning Go Autonomous will automatically process and confirm matching requests without manual review. When the bar is dark, the area is in standard (manual review) mode. ### The Unassigned area The **Unassigned** area appears first in the grid and cannot be deleted or renamed. It acts as a catch-all — any request that doesn't match a specific area is automatically assigned here. This includes requests from inboxes that have no area explicitly assigned. It always shows a **System Default** badge instead of an Autonomous badge. This is also the area label you'll see anywhere the system refers to "no specific area" — for example, in the [Agentic Fields Center](/knowledge-base/administration/fields-manager) when creating a rule that isn't scoped to any particular area, the area selector shows **Unassigned** rather than a generic "default" label.\\ Screenshot 2026 05 18 At 13 19 12 ### Filtering and sorting Use the toolbar to search by area name, filter by connected inbox, or sort alphabetically. ### Bulk actions on selected areas Select one or more area cards to reveal the **selection action bar** at the top of the page. The bar shows a live **N selected** count and gives you quick access to bulk actions: * **Export areas** — download the selected areas to a file (see [Import and export areas](#import-and-export-areas)). * **Delete** — permanently delete the selected areas via the guided deletion flow. * **Clear** — deselect all areas and dismiss the bar. The **Import areas** and **Add area** buttons stay in the toolbar at all times, separate from the selection bar. What you see in the selection bar depends on your permissions: * Users with **area restrictions** see **Export areas** only. * Users **without area restrictions** see both **Export areas** and **Delete**, subject to the Company Settings → Configurations permission. ## Create a new area Click the **Add area** button in the top-right corner. Select an emoji to represent the area. Click the emoji button to open the emoji picker — you can search by name or browse by category. The emoji appears on the area card and helps your team quickly identify areas at a glance. Enter a name for the area. Names must be unique and cannot use reserved names ("default", "default area", or "unassigned"). Optionally add a subtitle to describe what the area covers. Click **Save** to create the area. It will appear in the grid and is immediately available to connect to inboxes and field configurations. ## Area details Click any area card to open the **details drawer** on the right. This gives you a full picture of what's connected to the area: * **Autonomous Mode** — whether autonomous processing is on or off for this area, and a link to configure it. * **Connected Inboxes** — all inboxes routing mail into this area, with their associated intents. Click **View connectors** to manage these connections. * **Field Configurations** — all field configurations scoped to this area. Click **View configurations** to manage them. * **Product Catalog** — whether this area uses the organisation's default product catalog or an area-specific one. * **Customer Product Catalog** — same as above, for customer product catalogs. * **Reference Data** — all reference data entries scoped to this area, searchable by name. To edit an area's name, emoji, or subtitle, hover over the card and click the **pencil icon**. ## Delete an area To delete a single area, open its menu and select **Delete**. To delete several areas at once, select them in the grid and choose **Delete** in the [selection action bar](#bulk-actions-on-selected-areas) — you'll get a short confirmation, then be taken into the same guided deletion flow. **You can't delete an area that's still in use.** If the area is connected to an inbox, a field configuration, or has area-specific reference data, a product catalog, or a customer product catalog attached, the delete is blocked and a pop-up lists what's still connected. To delete it, first detach everything from the area: * **Inboxes** — unassign the area from the inbox in the connector configuration. * **Field configurations** — unassign the area from the configuration in the Field Manager. * **Reference data** — remove or reassign the area-specific reference data entries. * **Product catalog** — remove the area-specific product catalog so the area falls back to the default. * **Customer product catalog** — same as above, for customer product catalogs. Once nothing is attached, the area can be deleted. This is a safeguard so an area still doing real work can't be removed by accident. ## Connecting areas to inboxes Inboxes are connected to areas through the **Connectors** page, not directly from the Areas page. When setting up or editing an inbox in the Microsoft connector, you assign one or more areas to it. **You can connect multiple areas to the same inbox.** This is useful when a single email address receives requests that should be handled by different teams — for example, a shared order inbox where some orders go to a UK area and others to a US area. [Set up connectors →](/knowledge-base/administration/connectors/ms-connector) ## Using multiple areas on the same inbox When two or more areas are connected to the same inbox, Go Autonomous needs to determine which area a given request belongs to. If your integration has logic to resolve this automatically, no further setup is needed. If it doesn't, you need to configure an **Area field** in each field configuration. ### Setting up the Area field For every field configuration linked to areas that share an inbox: 1. Add an **Area** field to the configuration. 2. Mark it as **required** — this prevents a request from being confirmed until the area is explicitly set. 3. Make it the **first field** in the configuration so it's the first thing a user sees when reviewing a request in Flow. ### What happens in Flow When a request comes in on a shared inbox and the area can't be determined automatically: 1. Go Autonomous **randomly assigns** one of the connected areas as a starting point. 2. The **Agent view** immediately prompts the user to confirm or correct the area selection. 3. Once the user selects the correct area, any **field settings that depend on the area** (such as dependent field options or area-specific defaults) are automatically reset to match the selected area's configuration. This ensures the user is always working with the right field configuration for their area, even when routing couldn't be resolved automatically. ## Area-specific configurations Once an area is set up, you can scope the following to it: * **Field configurations** — in the Field Manager, assign a configuration to a specific intent + area combination. This means different areas can show completely different fields for the same type of request. * **Autonomous Mode** — enable and configure autonomous processing independently per area. * **Product catalogs and reference data** — use area-specific catalogs instead of the organisation default, so each area sees only the products and data relevant to them. * **Pulse workflows** — scope workflows to specific areas so they only trigger for matching requests. ## Import and export areas **Export** — select the areas you want in the grid, then click **Export areas** in the [selection action bar](#bulk-actions-on-selected-areas) to download them as a file. This is useful for: * Backing up area configurations. * Transferring areas between environments (e.g. Sandbox to Production). **Import** — click **Import areas** in the toolbar to upload a previously exported file. ## What's next * [Set up the Microsoft connector](/knowledge-base/administration/connectors/ms-connector) — connect inboxes and assign them to areas * [Field Manager](/knowledge-base/administration/fields-manager) — create area-specific field configurations * [Autonomous Mode](/knowledge-base/administration/automation) — enable autonomous processing per area * [Pulse workflows](/knowledge-base/pulse/overview) — scope workflows to specific areas # Audit Trail Source: https://knowledge.goautonomous.io/knowledge-base/administration/audit-trail Track and review all actions taken in your organization. ## Overview The Audit Trail provides a detailed record of every significant action taken in your Go Autonomous environment. They help you answer questions like "who changed this setting?" or "when was this user added?" — useful for troubleshooting, compliance, and keeping track of configuration changes. Accessing Audit Trail ## The Audit Trail page Navigate to **Administration > Company Settings > Audit Trail** to access the log viewer. The page shows a paginated list of events with: * **Timestamp** — when the action occurred. * **User** — who performed the action. * **Action** — what was done (e.g., created, updated, deleted). * **Summary** — what was affected (e.g., a user, connector, or area). ## Filter the Audit Trail Use the filter controls at the top of the page to narrow down the events you see. Available filters include: * **Date range** — view events from a specific time period. * **Space** — filter by the space the action was performed in (e.g., Reference Data, API Keys, Connectors, User Groups, Areas). * **Action type** — show only specific types of actions. Filters can be combined to find exactly what you need. ## Jump in from a specific page Several Company Settings pages have their own **audit trail shortcut** so you don't have to navigate to the Audit Trail and filter manually. Look for a **⋮** menu (or an **Audit trail** button) in the page's toolbar — clicking it opens the same drawer experience pre-filtered to that page's space. * [**Reference Data**](/knowledge-base/administration/reference-data#audit-trail) — track uploads, edits, and deletions across your reference data files. * [**API keys**](/knowledge-base/administration/api-keys#audit-trail) — track key creation and revocation. These shortcuts show the same underlying data as this page, just scoped and pre-filtered for convenience. ## View event details Click any event row to open a detail view with the full context of what happened, including before and after values for changes. ## Export the Audit Trail Click the **Export** button to download your Audit Trail data as a CSV file. The export respects any active filters, so you can export exactly the subset of events you need. ## What's next * [Configure authenticators](/knowledge-base/administration/authenticators) to secure integrations. # Configure authenticators Source: https://knowledge.goautonomous.io/knowledge-base/administration/authenticators Create and manage authentication credentials for third-party integrations. ## Overview Authenticators store the credentials Go Autonomous needs to connect to your external systems. Before setting up a [connector](/knowledge-base/administration/connectors), you typically need to create an authenticator with the right credentials — API keys, login information, or OAuth tokens. ## Create an authenticator Navigate to **Administration > Company Settings > Authenticators**. If this is your first authenticator, click **Get started**. Otherwise, click the add button to create a new one. Select the type of authentication your external system requires — API key, basic authentication (username/password), or OAuth. Fill in the required fields. This varies by authentication type: * **API key** — enter the key and any associated identifiers. * **Basic auth** — enter the username and password. * **OAuth** — configure the OAuth flow with client ID, secret, and token endpoints. Give the authenticator a clear name (e.g., "SAP Production API Key" or "Salesforce OAuth") and save. Authenticator credentials are sensitive. Only administrators should have access to create and manage them. Make sure credentials have the minimum required permissions for the integration. ## Managing authenticators From the Authenticators page, you can: * View all configured authenticators. * Edit credentials when they change (e.g., rotating API keys). * Delete authenticators that are no longer in use. If you delete an authenticator that's in use by an active connector, that connector will stop functioning until a new authenticator is assigned. ## What's next * [Set up connectors](/knowledge-base/administration/connectors) * [Manage organization settings](/knowledge-base/administration/settings) # Autonomous Mode Source: https://knowledge.goautonomous.io/knowledge-base/administration/automation Control which requests are processed and confirmed automatically vs. queued for manual review. ## Overview Autonomous Mode is the execution layer that makes your revenue flow faster by eliminating manual bottlenecks. After monitoring your analytics, you can configure autonomous rules to capture commercial intent from any channel, understand it, and turn it into a structured, revenue-generating transaction in real-time — without human intervention. ## What is Autonomous Mode? When Autonomous Mode is enabled for a request type, Go Autonomous doesn't just extract data — it also confirms and sends the request to your connected systems without waiting for a human to review it. The request flows from inbox to ERP (or CRM, or other integration) without manual intervention. When it is disabled, requests are processed as usual (classified, data extracted) but stop at the **Ready for review** stage in Workstation, waiting for a team member to open them in Flow and manually confirm. ## Automation levels Every request requires manual review. The AI extracts data and classifies the intent, but nothing is sent to external systems until a team member confirms in Flow. This is the default for new setups and the safest option while you're building confidence in the platform's accuracy. Requests that meet your confidence thresholds are confirmed automatically. Only exceptions — requests with low confidence scores, flagged issues, or unusual patterns — are queued for manual review. Your team focuses on the edge cases instead of reviewing every request. ## How it works When a request arrives, Go Autonomous evaluates it against your automation rules: 1. The AI classifies the intent and extracts data as usual. 2. The platform checks whether the request meets your automation criteria — confidence score, data completeness, and any custom rules. 3. If all criteria are met, the request is confirmed automatically and sent to your connected system. It appears in Workstation with a **Confirmed** status and an indicator that it was processed autonomously. 4. If any criteria aren't met, the request is held for manual review in the **Ready for review** state. ## When to enable Autonomous Mode Autonomous Mode works best when: * Your product catalog is well-maintained and complete. * Your intent classifications in [Axon](/knowledge-base/axon/overview) are accurate and well-trained. * You've processed enough requests manually to build confidence in the extraction quality. * You've configured your field settings thoroughly in the [Fields Manager](/knowledge-base/administration/fields-manager). Start with Autonomous Mode disabled and only enable it after your team is confident in the platform's accuracy. Review autonomously processed requests regularly, especially in the early stages. ## Setting up Autonomous Mode Navigate to **Administration > Company Settings > Autonomous Mode** to configure rules for your organisation. For a full walkthrough of the configuration options — including modes, conditions, senders, and certainty thresholds — see the [Autonomous Mode guide](/knowledge-base/administration/automation/using-autonomous-mode). # Using Autonomous Mode Source: https://knowledge.goautonomous.io/knowledge-base/administration/automation/using-autonomous-mode A full walkthrough of the Autonomous Mode page — creating, configuring, and duplicating automation rules. ## The Autonomous Mode page Navigate to **Administration > Company Settings > Autonomous Mode** to reach the Autonomous Mode landing page. The page displays all existing automation configurations in a table showing the **Name**, **Intent**, **Mode**, **Source**, **Source Value**, **Trigger**, and **Certainty** for each rule. * To **create a new rule**, press **"Add automation"**. * To **edit an existing rule**, click anywhere on the relevant row to open the configuration pane. ## Configuring an automation When creating or editing a configuration, you'll see the following fields: ### Name Enter a unique name for your automation configuration. ### Intent Select the intent you want to automate. You can only automate intents that have been configured with fields in your Company Settings. ### Mode Choose how the automation is applied to requests. Automates the entire request on an "all or nothing" basis. **All fields** in both the summary and the product cart must be validated for the order to be automated. **Example:** If an order has 50 products and just one is missing a quantity, the entire order is flagged for manual review. Automates only the specific lines within an order that meet your criteria, leaving the rest for manual review (all Summary fields must still be validated). **Example:** If an order has 50 products and one is missing a quantity, the 49 validated products are automated while only the single incomplete line requires human review. ### Source and Source Value Select the inboxes or areas you want to automate. To avoid conflicts: you cannot select a specific inbox if its area is already used in another rule, and you cannot select an area if an inbox within it is already part of another rule. ### Senders Create a sender list to include or exclude specific emails, domains, or accounts from this automation. | Field | Description | | - | - | | **Mode** | Choose **Include** to only automate requests from senders on your list, or **Exclude** to automate everyone except those on the list. | | **Source** | Specify whether your list contains **emails** or **accounts**. | | **Upload** | Provide your list as a CSV file with all entries in a single column. For email lists, you can mix full addresses and entire domains (formatted as `@example.com`). | ### Certainty Set the minimum confidence score (0–100%) the AI must have in the identified intent for a request to be automated. We recommend starting with a threshold of **90%**. ### Automation Prevention Decide whether errors or warnings on a request should block it from being automated. This feature may not be available for all customers. Contact your Customer Success representative to enable it. ### Conditions Set specific conditions based on product cart fields to determine whether a request is eligible for automation. For example, you could require that an order total is below \$100,000. The available conditions change depending on the **Mode** you selected — see the section below. *** ## A deep dive into conditions Conditions let you define precise rules for automation eligibility. Their behaviour differs depending on whether you're using Complete Cart or Line Item mode. ### Complete Cart mode You can set **one condition** that applies to the order as a whole. * **Logic:** The condition is based on the sum of a numerical field in the product cart. Available operators: `=`, `>`, `<`, `!=`. * **Example:** Only automate orders where the sum of the unit price is less than €2,000. ### Line Item mode You can set **up to two conditions** that apply to each individual line. * **Logic:** Conditions apply to specific fields of each line item and can be joined by an **AND/OR** operator. * For non-numeric fields (e.g. product colour): `=` or `!=` * For numeric fields (e.g. quantity): `=`, `>`, `<`, `!=` * **Example:** Only automate lines where the product colour is blue. *** ## Duplicating configurations To save time when setting up a new rule that's similar to an existing one: Tick the checkbox next to the configuration you want to duplicate. Click the **Duplicate** button in the toolbar next to the search bar. The configuration pane will open with the duplicated values. Update any fields as needed. Press **Save** to create the new configuration. # Set up connectors Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors Connect Go Autonomous to your ERP, CRM, and other business systems using pre-built or custom connectors. ## Overview Connectors are the bridge between Go Autonomous and your external systems. When a request is confirmed in Flow, the connector sends the data to the right destination — whether that's your ERP for order processing, your CRM for customer updates, or a custom API for specialized workflows. ## Available connector types Go Autonomous offers pre-built connectors across several categories: * **Dynamics Customer Service** — integrate with Microsoft Dynamics 365 Customer Service. * **Salesforce** — integrate with Salesforce CRM. * **Zendesk** — integrate with Zendesk for customer service workflows. * **Infor M3** — integrate with Infor M3 ERP. * **SAP C4C** — integrate with SAP Cloud for Customer. * **API** — custom API integration for any system with a REST API. * **GoAutonomous** — Go Autonomous connector with API key for platform-to-platform communication. * **Third-Party** — integrate with a third-party system using webhooks and data contracts. * **SFTP** — secure file transfer integration for systems that exchange data via files. * **SAML** — single sign-on (SSO) integration with any SAML 2.0–compliant identity provider, like Microsoft Entra or Okta. * Additional productivity integrations for team tools and communication platforms. ## Set up a connector Navigate to **Administration > Company Settings > Connectors**. Scroll through the **Available Connectors** section or use the search bar and category tabs to find the connector you need. Click on the connector card to start the setup process. A configuration panel opens. Provide the required configuration — this varies by connector type but typically includes endpoint URLs, authentication credentials, and data mapping settings. You may need an [authenticator](/knowledge-base/administration/authenticators) set up first. Use the test function to verify that Go Autonomous can communicate with your system before going live. Once configured and tested, activate the connector. It appears in the **Active Connectors** section at the top of the page. ## API connector category Go Autonomous distinguishes two ideas: * **Integration type** — which connector product you use (for example **Salesforce**, **Microsoft**, or **API**). This is fixed by how you add the connection. * **Category** — how the platform classifies a connector instance (**CRM**, **ERP**, **File Transfer**, **Productivity**, **Custom**, and others in the backend). Category drives behaviour such as [CRM connector routing](/knowledge-base/administration/connectors/connector-routing). When you create an **API** connector, the form shows a field labelled **Connector type**. That field sets the connector's **category** (the UI label is easy to confuse with integration type). Options: * **CRM** * **ERP** * **File Transfer** * **Productivity** * **Custom** (the default) Choose **Custom** for a general-purpose API integration. Choose **CRM** when this API integration should behave as a CRM connector — it can then appear in CRM routing dropdowns and be set as your primary CRM (**Set as default CRM connector**). **ERP**, **File Transfer**, and **Productivity** classify the connector for your organisation; **per-inbox ERP routing is not available in the current release**, so those values do not add ERP inbox routing like CRM does today. This category choice is made when you create the API connector and can't be changed afterwards. If you picked the wrong value, create a new connector with the right one. Pre-built connectors (Salesforce, SAP C4C, Dynamics Customer Service, and so on) get their category from the integration type automatically — for example Salesforce is a **CRM** connector. The category picker appears only when you create an **API** connector. ## CRM connector routing **CRM connector routing** decides which CRM connector receives updates when requests from a sourced inbox are confirmed in Flow. You set the organisation's primary CRM on each CRM integration (**Set as default CRM connector**), and you can set a **per-inbox CRM route** or **No CRM Routing** on the [Microsoft connector](/knowledge-base/administration/connectors/ms-connector) inbox page. See [CRM connector routing](/knowledge-base/administration/connectors/connector-routing) for where each control appears, bulk assign, runtime resolution, and troubleshooting. ## Third-party connectors Third-party connectors allow external partners to integrate with Go Autonomous using webhooks. This is useful when a third party needs to receive data from your platform or send data back. Key concepts for third-party connectors: * **Webhooks** — define endpoints that receive data when events occur in Go Autonomous. * **Data contracts** — specify the data structure that's sent to and received from the third party. * **Logging** — third-party events are logged alongside internal events for unified troubleshooting. Third-party connector setup requires coordination between your team and the third party. Data contracts define what information flows in each direction. ## Managing active connectors Once a connector is active, it appears in the **Active Connectors** section. From there you can: * View the connector's status and configuration. * Edit connection settings. * Deactivate the connector if it's no longer needed. * View logs to troubleshoot issues. ## Connector guides Step-by-step setup guides for each available connector: Connect Go Autonomous to Salesforce CRM for order and quote processing. Connect Go Autonomous to Microsoft Outlook to process incoming emails. Integrate with SAP Cloud for Customer for order and quote workflows. Integrate with Microsoft Dynamics 365 Customer Service for order and quote workflows. Configure single sign-on (SSO) for your tenant against any SAML 2.0 identity provider. Connect Go Autonomous to your Zendesk instance for customer service workflows. ## What's next * [Configure authenticators](/knowledge-base/administration/authenticators) * [Manage organization settings](/knowledge-base/administration/settings) # API connector Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/api-connector Connect Go Autonomous to any external system using a generic REST API integration. ## Overview The API connector is a flexible, generic integration type that lets Go Autonomous communicate with any external system that exposes a REST API. Use it when there isn't a dedicated connector for your system (like there is for Salesforce or SAP). ## Set up an API connector Navigate to **Administration > Company Settings > Connectors**. Click the add button and select **API connector** from the connector type list. Provide the API connection details: * **Base URL** — the root URL of the external API. * **Authentication** — select an existing [authenticator](/knowledge-base/administration/authenticators) or configure credentials directly (API key, OAuth, or basic auth). * **Headers** — any custom HTTP headers the API requires. Define how Go Autonomous should map its data model to the external API's expected format, including field mappings and transformation rules. Save the connector to activate the integration. ## When to use the API connector The API connector is best when: * Your system isn't covered by a dedicated connector (Salesforce, Microsoft, SAP C4C, etc.). * You need a lightweight integration that sends or receives data via REST endpoints. * You want to connect to an internal or custom-built system. For systems with dedicated connectors, prefer those instead — they include pre-built mappings and business logic specific to each platform. ## Category (Connector type field) and CRM routing The create form includes **Connector type** — that sets the connector's **category**, not whether the integration is API vs Salesforce. Set it to **CRM** if this API integration should participate in [CRM connector routing](/knowledge-base/administration/connectors/connector-routing) and **Set as default CRM connector**. Other values (**ERP**, **File Transfer**, **Productivity**, **Custom**) classify the connector; they do not enable ERP inbox routing in the current release. The choice is fixed at creation. See [API connector category](/knowledge-base/administration/connectors#api-connector-category) on the connectors overview. ## What's next * [Set up connectors overview](/knowledge-base/administration/connectors) for other integrations and the API category picker. * [CRM connector routing](/knowledge-base/administration/connectors/connector-routing) for primary CRM and per-inbox routes. * [Configure authenticators](/knowledge-base/administration/authenticators) to manage API credentials. # CRM connector routing Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/connector-routing Control which CRM connector receives confirmed request data from each Microsoft inbox, including your organisation's primary CRM and optional per-inbox routes. ## Overview When a request is confirmed in Flow, Go Autonomous can send updates to your CRM. **CRM connector routing** makes that destination explicit and configurable: * An organisation-wide **primary CRM connector** (the default when an inbox has no override). * Optional **per-inbox CRM routes** on the [Microsoft connector](/knowledge-base/administration/connectors/ms-connector) inbox page. * Optional **No CRM Routing** for mailboxes that must not write to CRM at all. Routing applies to **CRM connectors only** in this release. ERP per-inbox routing and a separate “Connector routing” tab from early designs are **not** included; configuration lives on the Microsoft inbox page and in each CRM connector’s settings. Pre-built CRM connectors (Salesforce, Dynamics, and similar) participate automatically. You can also use an [API connector with category CRM](/knowledge-base/administration/connectors#api-connector-category) (the create form’s **Connector type** field) when you do not have a dedicated CRM connector. This capability is rolled out per organisation. If you do not see primary CRM controls or inbox CRM options, contact your Go Autonomous Customer Success Manager — the feature may not be enabled for your tenant yet. *** ## Where each control appears Use this map to find the right screen. All of the following require CRM connector routing to be enabled for your organisation. | What you configure | Where | | - | - | | **Primary CRM connector** (`Set as default CRM connector` on the connector) | Edit view of a Salesforce, Dynamics, or CRM-type API connector | | **CRM connector** when **Add inbox** | Add inbox dialog on the Microsoft connector page (shown when you have at least one CRM connector; pre-filled with the primary CRM) | | **CRM connector** column, row checkboxes, **Bulk assign**, and **No CRM Routing** in the inbox table | Microsoft connector inbox page — when you have **two or more** CRM connectors | With **one** CRM connector, it is the primary CRM automatically and the inbox table does not show the CRM column. You can still set or confirm CRM routing when adding inboxes. With **two or more** CRM connectors, use the CRM column or bulk assign to send different mailboxes to different CRMs or to opt out with **No CRM Routing**. *** ## Permissions Changing the primary CRM connector or inbox CRM routes requires **Editor** access to **Company Settings → Integrations**. Users with **Viewer** access can open connector settings but cannot change routing. *** ## Primary CRM connector Each organisation can designate exactly **one primary CRM connector**. That connector is the fallback for any inbox that does not have its own CRM route (and is not opted out with No CRM Routing). In the product UI the control is labelled **Set as default CRM connector**; in lists the current primary is marked **(Primary)**. ### Set or change the primary Go to **Administration → Company Settings → Connectors** and open the Salesforce, Dynamics, or API connector you want as the primary. In the connector’s edit view, enable **Set as default CRM connector**. Only one connector can hold that role at a time. If another CRM connector is already primary, you must confirm the change. The previous primary is demoted automatically. When your organisation has only **one** CRM connector, it is always the primary CRM and the control is locked on. For API connectors, set the create form’s **Connector type** field to **CRM** so the connector’s category is CRM and it appears in CRM routing. See [API connector category](/knowledge-base/administration/connectors#api-connector-category) on the connectors overview. *** ## Per-inbox CRM routing (Microsoft connector) Per-inbox routes are configured where inboxes are sourced — not on a separate routing tab. CRM column on the Microsoft connector inbox page Navigate to **Administration → Company Settings → Connectors** and select your active **Microsoft** connector. When your organisation has **two or more** CRM connectors, the inbox table includes a **CRM** column and row selection for bulk assign. If you only have one CRM connector, this column is hidden — use **Add inbox** or change routing later when you add a second CRM. For each inbox, open the CRM dropdown and select: * A specific CRM connector (the current primary is labelled **(Primary)** in the list), or * **No CRM Routing** (see below). Changes save when you confirm the selection. Inboxes that show the primary connector without a separate stored route are using the **org primary** — you do not need to set every inbox explicitly. ### Bulk assign When the CRM column is visible, select multiple inboxes with the row checkboxes and click **Bulk assign** to apply the same CRM connector (or **No CRM Routing**) to all selected inboxes at once. ### Add inbox When you **Add inbox** and at least one CRM connector is active, the dialog includes a **CRM connector** field pre-filled with your primary CRM. The choice applies to all inboxes you subscribe in that action. If you have **two or more** CRM connectors, you can choose a different CRM or **No CRM Routing** before you confirm. **No CRM Routing** is applied after subscription completes. If you only have one CRM connector, the field shows that connector and cannot be changed. *** ## No CRM Routing **No CRM Routing** is for inboxes that should **not** send confirmed request data to any CRM connector — for example mailboxes used only for testing, or flows that should stop before CRM write-back. Selecting **No CRM Routing** for an inbox: * Clears any explicit CRM connector assignment for that inbox. * Tells the platform to skip CRM connector selection for that inbox at processing time (no CRM destination is chosen for that path). This option appears in the CRM dropdown on the Microsoft inbox page (when the CRM column is shown), in bulk assign, and in **Add inbox** when you have **two or more** CRM connectors. It is separate from leaving an inbox on the primary CRM: the primary still routes CRM updates; **No CRM Routing** opts out entirely. Use **No CRM Routing** only when you intentionally want no CRM updates for that inbox. Orders and cases will not be created or updated in CRM for mail processed from that mailbox. *** ## How the platform picks a CRM connector When mail from an inbox is processed, the platform resolves the CRM connector in this order: 1. **No CRM Routing** — if enabled for that inbox, no CRM connector is used for CRM routing. 2. **Inbox-specific route** — if the inbox is assigned to a CRM connector, that connector is used when it matches the integration type being resolved (for example Salesforce-to-Salesforce). 3. **Primary CRM connector** — the organisation’s primary CRM for that integration type. 4. **Legacy inbox lists** — if none of the above applies, older include/exclude inbox lists on connector configuration may still apply as a fallback. New inboxes typically receive an explicit stored route pointing at the primary CRM when they are subscribed, so routing stays deterministic as you add mailboxes. *** ## Audit Trail and troubleshooting ### What appears in Audit Trail Promoting or demoting the **primary CRM connector** (and other connector configuration changes such as category) is recorded in [Audit Trail](/knowledge-base/administration/audit-trail). Open **Administration → Company Settings → Audit Trail**, filter by space **Connectors**, and open an event to see field-level details — including **Is primary** when the primary CRM role changed. Per-inbox CRM route changes on the Microsoft connector page are **not** written to Audit Trail today. ### Common issues * **Wrong CRM instance** — open the Microsoft connector, check the inbox’s CRM column when visible (or bulk-assign the correct connector), and confirm which connector is marked **(Primary)** in the dropdown. * **CRM column missing** — you have only one CRM connector, or CRM connector routing is not enabled for your organisation yet. * **Include/exclude lists on Salesforce** — may still affect behaviour when no CRM routing decision applies. Prefer explicit per-inbox routes or the primary CRM for multi-instance setups; discuss retiring legacy lists with your Customer Success Manager once routing is fully configured. *** ## What’s not included in v1 * **ERP routing** — choosing per-inbox ERP destinations is not available in this release. * **Dedicated Connector routing tab** — configuration is on the Microsoft inbox page and in connector edit views instead. * **Intent- or area-based routing rules** — Intent and Area on the inbox table remain sourcing configuration only; they do not change CRM destination. * **File Transfer, Productivity, or non-CRM Custom connectors** — not selectable as CRM routing targets. *** ## What's next * [Microsoft connector guide](/knowledge-base/administration/connectors/ms-connector) — sourcing inboxes and general Microsoft setup. * [Set up connectors](/knowledge-base/administration/connectors) — integration types, API connector category picker, and overview. * [Salesforce connector guide](/knowledge-base/administration/connectors/salesforce/salesforce-connector-guide) — Salesforce-specific setup. # Dynamics 365 Customer Service Connector Guide Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/dynamics-365-customer-service Connect Go Autonomous to your Dynamics 365 Customer Service environment. ## Part A — Install the package Navigate to the [Go Autonomous package on AppSource](https://appsource.microsoft.com) and click **Get it now**. Select the environment you want to install the package into and confirm. *** ## Part B — Grant consent to the Go Autonomous app Navigate to [my.goautonomous.io](https://my.goautonomous.io). If not already logged in, press **Login with Microsoft** and enter your organisation's Microsoft credentials. You will need administrative permissions in Go Autonomous — if you don't have them, reach out to your Engagement Manager. Navigate to **Company Settings > Connectors**. Under **Add connection**, select the **Customer Service** connector. Enter a name for the connected Dynamics environment (e.g., Sandbox, QA, Production) and the URL of the relevant environment. Press **Configure**. A Microsoft admin consent page will open in a new tab. In the new tab, you will be prompted to grant access to the Go Autonomous Dynamics Customer Service app using your Microsoft account. Select **Accept**. You will be redirected to a **Consent granted!** confirmation screen, and the new connector will appear in the **Active** list on the Connectors page shortly after. *** ## Part C — Assign S2S profile to the Go Autonomous app Navigate to [admin.powerplatform.microsoft.com/manage/environments](https://admin.powerplatform.microsoft.com/manage/environments). If you land on the home page, select **Manage** in the left sidebar and then **All environments**. Select the environment you connected to Go Autonomous in Part B. In the right pane, select **See all** under **S2S apps**. In the top bar, press **New app user**, then click **Add an app**. Search by **Application ID** and select the Go Autonomous app. See [Application ID](/knowledge-base/administration/connectors/dynamics-365-customer-service/application-id) for the ID to use. Searching by app name will not work — you must search by the Application ID. Select a business unit, then click the **Edit** button beside **Security roles**. Locate and select the **Go Autonomous API** security role. Verify the S2S app user details: * **App:** Go Autonomous Dynamics Customer Service Connector * **Business unit:** your environment (e.g., org8dc4f998) * **Security roles:** Go Autonomous API Click **Create** to finish. ## What's next * [Configure authenticators](/knowledge-base/administration/authenticators) * [Connectors overview](/knowledge-base/administration/connectors) # Microsoft Connector Guide Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/ms-connector Connect Go Autonomous to Microsoft to source emails from your organisation's inboxes. ## Before you start * The connector is a Microsoft-validated integration from Go Autonomous, a Microsoft Partner. It sources emails in the background — it won't disrupt end-user workflows. * Microsoft authentication requires an IT representative with **Azure Active Directory admin rights**. * Setup typically takes around three minutes. After permissions are granted, allow up to ten minutes for the connector to appear on the Go Autonomous platform. * Once available, inbox selection can be completed without further IT involvement. *** ## Set up security groups Requires Microsoft Azure AD admin rights. Your organisation may restrict application access to mailboxes before the connector is activated. Use Microsoft's application permission controls to limit which mailboxes Go Autonomous can access. * [Official Microsoft guide: limit application permissions to specific Exchange Online mailboxes](https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access) * [Microsoft Admin Center — set up security groups](https://admin.microsoft.com/Adminportal/Home) **Go Autonomous application IDs by environment:** see [Application IDs](/knowledge-base/administration/connectors/ms-connector/application-ids) for the IDs to use when restricting mailbox access. *** ## Enable the Microsoft connector Requires Microsoft Azure AD admin rights and Go Autonomous admin rights. Navigate to [my.goautonomous.io](https://my.goautonomous.io) and enter the credentials provided by your Go Autonomous Success Manager. Click the menu button in the upper right corner of the screen and open **Company Settings**. Navigate to **Connectors** and click the **Microsoft** connector under **Add connection**. A standard Microsoft authentication prompt will appear. Enter your Microsoft admin credentials. Microsoft handles all credential processing — Go Autonomous does not have visibility into them. Click **Accept** to authorise the connector. You will see a **Success!** confirmation screen. Navigate back to **Connectors**. The Microsoft connector should now appear under your active connections. Allow up to 10 minutes after granting permissions for it to appear. *** ## Set up inbox sourcing Requires the Microsoft connector to be activated (Part B) and Go Autonomous admin rights. Navigate to **Administration > Company Settings > Connectors** and click the established Microsoft connector. Select the inboxes you want to source emails from. Only new incoming emails will be sourced — emails already present in the inbox at the time of connection will not be processed. When CRM connector routing is enabled and you have at least one CRM connector, **Add inbox** includes a **CRM connector** field pre-filled with your organisation’s **primary CRM connector**. Unless you change that selection before you confirm **Add**, new inboxes route to the primary CRM. With only one active CRM connector, that connector is selected automatically and the field cannot be changed. After inboxes are listed, you can update routing when the Microsoft inbox page shows CRM controls — for example the **CRM connector** column and **Bulk assign** when you have two or more CRM connectors. You can assign a **CRM connector** or **No CRM Routing** where those options are available. See [CRM connector routing](/knowledge-base/administration/connectors/connector-routing) for the primary CRM setting, bulk assign, and how the platform picks a connector at runtime. *** ## Troubleshooting Check that the following requirements are met: * The inbox is part of a security group created in Part A. * The inbox name is spelled exactly as it appears in Azure Active Directory (including upper and lower case). * If the inbox has aliases, try searching for those as well. Check whether incoming emails are being automatically moved by Outlook to a subfolder of the inbox. Go Autonomous sources from the root inbox only. ## SSO and user access Setting up the Microsoft connector also establishes the **SSO connection** between Go Autonomous and your Azure tenant. From this point, users sign in to Go Autonomous with their Microsoft credentials. Once SSO is in place, you control **who can access Go Autonomous** directly from Azure — by managing access to the Go Autonomous Enterprise Application in your Azure user groups. Anyone you assign to the application can sign in; anyone you remove loses access. ### Sync user groups to control in-platform privileges You can take this one step further and sync Azure user groups into Go Autonomous so that **what users can do** inside the platform is also driven from Azure. When a user signs in for the first time, their group membership in Azure determines the user groups (and therefore the permissions) they inherit on the platform — no manual provisioning needed. * [User Groups](/knowledge-base/administration/access-control/user-groups) — how user groups work in Go Autonomous and what each group controls. * [Setting up SCIM](/knowledge-base/administration/access-control/scim) — sync user groups from Azure (Microsoft Entra) into Go Autonomous via SCIM. * [User Management](/knowledge-base/administration/access-control/user-management) — see synced users and their effective permissions. ## What's next * [CRM connector routing](/knowledge-base/administration/connectors/connector-routing) * [Application IDs](/knowledge-base/administration/connectors/ms-connector/application-ids) * [Set up mirror inboxes](/knowledge-base/administration/connectors/ms-connector/mirror-inboxes) * [Install the Outlook plug-in](/knowledge-base/administration/connectors/ms-connector/outlook-plug-in) * [User Groups](/knowledge-base/administration/access-control/user-groups) # Set up mirror inboxes Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/ms-connector/mirror-inboxes Create a mirrored inbox so Go Autonomous can develop against live mail without connecting to your production inbox. ## Overview A mirrored inbox is a shared mailbox that receives a forwarded copy of every email that arrives in one of your real inboxes. Connecting a mirror inbox to Go Autonomous — rather than your live inbox — means you can: * **Develop against real mail traffic** without any risk to your production environment. * **Evaluate extraction performance** on actual customer emails before go-live. * **Run UATs** in a realistic, live-data environment before switching on for real. You will need to set up separate mirror inboxes for QA and Sandbox. Do not use the same mirrored inbox for both environments. *** ## Create a shared mailbox The mirror inbox is a shared mailbox in Microsoft 365. Your Microsoft administrator needs to create one for each environment. Navigate to the [Microsoft Outlook admin page](https://admin.microsoft.com) and sign in with your Microsoft administrator account. In the left navigation pane, go to **Teams & groups** → **Shared mailboxes**. Click **Add a shared mailbox**. Fill in a name and email address for the shared mailbox. Use something descriptive that makes it easy to identify later — for example: * `orders-mirror-qa@yourdomain.com` * `orders-mirror-sandbox@yourdomain.com` Click **Save changes** to create the mailbox. *** ## Enable forwarding (mirroring) Once the shared mailbox exists, set up forwarding from the inbox you want to mirror so that all incoming mail is copied across. In the Microsoft 365 admin centre, find the user inbox or shared mailbox that you intend to eventually connect to Go Autonomous in production. Click into the mailbox and find the **Email forwarding** section. Click **Edit**. Enter the email address of the shared mailbox you created above. Save the changes. Mirroring is now enabled — from this point on, every email that arrives in the source inbox will also be delivered to the shared mirror mailbox. Forwarding copies emails — it does not move or delete them. Your original inbox continues to work exactly as before. *** ## What's next Once your mirror inboxes are created, connect them to Go Autonomous via the [Microsoft connector](/knowledge-base/administration/connectors/ms-connector). # Install the Outlook plug-in Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/ms-connector/outlook-plug-in Connect your Outlook inbox to Go Autonomous Flow and process requests directly from your email. ## Overview The Go Autonomous Outlook plug-in lets you automate order and quote processing straight from your inbox. It identifies the intent of incoming requests and extracts relevant information from emails and attachments — so you can move faster without switching between tools. Once installed, a **Navigate to Flow** button appears in your Outlook ribbon. Click it on any email to send that request directly into Flow for processing. ## Before you start This add-in requires an enterprise subscription with individual setup by your Microsoft Azure AD Admin. Users in your organization can then sign in with their Microsoft account. Pricing is individual. If your business hasn't been registered yet, [get in touch with Go Autonomous](https://goautonomous.io) to get set up. ## Install from the Microsoft Store Navigate to the [Microsoft Applications Webstore](https://appsource.microsoft.com) and search for **Go Autonomous**. Click **Get it now** and follow the prompts to add the Go Autonomous plug-in to your Outlook account. ## Add the plug-in to your Outlook ribbon If you see the **Navigate to Flow** button in your Outlook ribbon after installing, you're all set — skip this section. If the button doesn't appear, follow these steps to add it manually. In Outlook, go to **File** > **Options** to open the Outlook Options dialog. In the left sidebar of the Options dialog, click **Customize Ribbon**. In the **Choose commands from** dropdown on the left, select **All Commands**. Scroll through the list on the left to find the **Navigate to Flow** command. In the right column, select a **Commands Group** where you want the button to appear on your ribbon (for example, under **Home (Mail)**). Click the **Add >>** button to move the command to your ribbon. Click **OK** to save your changes. Restart Outlook if needed. For more details on customizing the Outlook ribbon, see [Microsoft's official guide](https://support.microsoft.com/en-us/office/customize-the-ribbon-in-office-00f24ca7-6021-48d3-9514-a31a460ecb31). ## You're all set You should now see the **Navigate to Flow** button in your Outlook ribbon. Open any email and click it to send the request directly into Flow for processing. ## FAQ This usually means Go Autonomous doesn't know about the email yet because of where it lives in your mailbox. 1. **Check the email's location.** If it isn't in the main inbox, it's probably sitting in a subfolder. 2. **Confirm the inbox itself is connected.** Go to **Administration > Company Settings > Connectors** and check that the Microsoft connector lists this inbox — see [Set up inbox sourcing](/knowledge-base/administration/connectors/ms-connector#set-up-inbox-sourcing). You'll need **administrative rights to the Connectors page** to view and change this; ask your admin if it's greyed out or not visible. 3. **Subscribe the subfolder.** If the email is in a subfolder, open the inbox in the connector settings and click **Subscribe** next to that subfolder so Go Autonomous also sources emails from it, not just the root inbox. The list of subfolders can take a second to load — give it a moment before assuming a subfolder is missing. # Salesforce Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/salesforce Connect Go Autonomous to Salesforce for seamless order and quote processing. ## Overview The Go Autonomous Salesforce connector integrates your Salesforce instance with the Go Autonomous platform, enabling seamless order and quote processing directly from Salesforce cases. The setup consists of three parts: * **Part A** — Install the Go Autonomous app in Salesforce * **Part B** — Set up the layout of the Salesforce page * **Part C** — Configure the connected app via the Go Autonomous platform ## Before you start You will need Salesforce administrator rights and Go Autonomous admin rights to complete this setup. If you have any questions or need assistance, contact your Success Manager. # Salesforce Connector Guide Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/salesforce/salesforce-connector-guide Step-by-step guide to connecting Go Autonomous with your Salesforce instance. ## Install from Salesforce AppExchange The Salesforce environment admin installs the application. Navigate to [the Go Autonomous listing on Salesforce AppExchange](https://appexchange.salesforce.com/appxListingDetail?listingId=a0N4V00000G21jxUAB\&tab=d) and find Go Autonomous. Image After pressing **Get it Now**, Salesforce will redirect you to a new tab where you select which environment to install into. If you are unsure, reach out to your Go Autonomous Customer Success Manager. After confirming the environment and agreeing to the terms and conditions, you will be navigated to the **Install Go Autonomous** page. Select **Install for Specific Profiles**. Image Scroll through the profile list and set the following profiles to **Go Autonomous API Only**: 1. Standard User 2. Sales API Only System Integrations Image Scroll back to the top and press **Install** under the **Install for Specific Profiles** button. Wait for the package to finish installing. Once complete, a success notification appears. Press **Done** to return to Salesforce. Image *** ## Create a profile and configure the user In Salesforce Setup, use the left navigation pane to find **Administration > Users > Profiles**. Find **Standard User** in the profile list. Image Inside the Standard User Profile, press **Clone**. Image Enter **Go Autonomous API** as the profile name, then press **Save**. Image Click **Edit** on the new profile and set the following permissions: **Administrative permissions:** * Access Libraries * Apex REST Services * API Enabled * API Only User * Edit Read Only Fields * Select Files from Salesforce **General user permissions:** * Assign Topics * Create Topics * Edit Tasks * Edit Topics **Standard object permissions:** | Object | Read | Create | Edit | View All | | - | - | - | - | - | | Accounts | ✓ | | | ✓ | | Cases | ✓ | ✓ | ✓ | ✓ | | Contacts | ✓ | | | ✓ | | Customers | ✓ | | | ✓ | | Documents | ✓ | ✓ | ✓ | ✓ | Save the profile once all permissions are configured. After clicking **Edit** on the Profiles page, enable **Go Autonomous** and **Go Autonomous Flow** in the **Connected App Access** section. From the Profiles page, navigate to **Users > Users** in the left pane and press **New User**. Image Set **User License** to **Salesforce** and **Profile** to **Go Autonomous API**. Fill in the required fields: Last Name, Alias, Email, Username, and Nickname. Set the Locale and Language fields to match your primary location, then save. Image Navigate to **Platform Tools > Apps > App Manager**. Find the Go Autonomous application, click the down arrow at the far right of the row, and press **Manage**. Image Press **Edit Policies**. Under the **Client Credentials Flow** section, click the magnify glass beside the **Run As** field, select **Go Autonomous API** from the pop-up, then press **Save**. *** ## Set up the Salesforce page layout Log in to Salesforce and navigate to the **page layout settings** for Cases. Click **Edit** to open the layout editor. In the left sidebar, search for **Go Autonomous**. You'll see **Go Autonomous – Flow** and **Go Autonomous – Case Management** listed under **Custom – Managed**. Drag **Go Autonomous – Flow** to the left side of the case layout. Drag **Go Autonomous – Case Management** to the right side of the layout. Click **Save**. Close the window when you see the **Changes saved** confirmation. *** ## Configure the connector in Go Autonomous Log in to the Go Autonomous platform and navigate to **Administration > Company Settings > Connectors**. Find the **Salesforce** connector in the **Available Connectors** section. Give your connection a clear name (e.g., "Main Salesforce Org"), select either **Case Creation** or **Case Enrichment** depending on your desired functionality, and enter the custom domain URL for your Salesforce organisation. Once saved, your Salesforce connection will appear under **Active Connections**. You're now ready to use the integration. # Salesforce Integration Schema Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/salesforce/salesforce-integration-schema Overview of how Go Autonomous integrates with Salesforce via case management and the Flow iframe.
Activate the **Enrich Case** and/or **Create Case** API calls by installing the Salesforce connector as outlined in the [Salesforce Connector Guide](/knowledge-base/administration/connectors/salesforce/salesforce-connector-guide). Set up the iframe canvas to embed the Go Autonomous interface inside Salesforce, also covered in the [Salesforce Connector Guide](/knowledge-base/administration/connectors/salesforce/salesforce-connector-guide).
Salesforce integration schema diagram
# SAML connector Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/saml-connector Set up single sign-on (SSO) for Go Autonomous by configuring a SAML connector against your identity provider. ## Overview The SAML connector lets your team sign in to Go Autonomous through your existing identity provider (IdP) — for example, Microsoft Entra, Okta, or any other SAML 2.0–compliant provider. Once configured, users authenticate against the IdP instead of managing a separate Go Autonomous password. Use the SAML connector when you want to: * Centralise authentication for Go Autonomous through your IdP. * Enforce your organisation's existing sign-in policies (MFA, conditional access, session lifetimes). * Pair SSO with [SCIM](/knowledge-base/administration/access-control/scim) to fully automate user provisioning and access. SAML controls **how users sign in**. To also sync users and group membership automatically, set up [SCIM](/knowledge-base/administration/access-control/scim) alongside the SAML connector. ## Before you start You'll need the following from your identity provider: * The **federation metadata XML** for the Go Autonomous application — or, individually, the **x509 signing certificate** and the **single sign-out endpoint URL**. * The list of **authorized request origin URLs** that the IdP will redirect to (typically your Go Autonomous tenant URL). ## Configure a SAML connector Navigate to **Administration > Company Settings > Connectors**. Find **SAML** in the available connectors list and click it. The configuration dialog opens. Give the connector a clear name (e.g., "Entra SSO" or "Okta Production"). The name is used internally to identify this configuration. Use the **Federation Metadata** tab to configure the connector. You have two options: * **Upload the federation metadata XML** — drop the metadata file your IdP generated for the Go Autonomous application. The x509 certificate and single sign-out endpoint URL are filled in automatically. * **Enter values manually** — paste the **x509 certificate** and the **single sign-out endpoint URL** into the fields directly. Add the origin URLs your IdP is allowed to redirect to after authentication. Use **Add another URL** to add more than one entry (for example, if you use multiple Go Autonomous environments). Switch to the **Lambda Handler** tab if you need to customise how the SAML response is processed — for example, to map custom claims onto Go Autonomous user attributes. A default handler is provided and works for most setups. Click **Configure** to save the connector. The connector appears in the **Active Connectors** section and is ready to be used for sign-in. ## Manage an existing SAML connector From the **Active Connectors** section you can: * **View** the current configuration (certificate, endpoint, origin URLs, lambda). * **Edit** the connector when your IdP rotates its signing certificate or you change the sign-out endpoint. Re-upload the metadata XML to refresh the certificate and endpoint in one step. * **Delete** the connector to remove SSO for this tenant. Editing the SAML connector immediately affects sign-in for everyone in the tenant. Coordinate with your IT team before rotating certificates or changing origin URLs. ## What's next * [Set up SCIM provisioning](/knowledge-base/administration/access-control/scim) to sync users and groups from your IdP. * [Configure authenticators](/knowledge-base/administration/authenticators) for other integrations that need credentials. * [Connectors overview](/knowledge-base/administration/connectors). # SAP C4C Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/sap-c4c-connector Connect Go Autonomous to SAP Cloud for Customer for order and quote workflows. ## Overview The Go Autonomous SAP C4C connector integrates your SAP Cloud for Customer environment with the Go Autonomous platform, enabling automated order and quote processing from SAP cases. The setup involves connecting your SAP C4C instance through the Go Autonomous platform and configuring the necessary permissions and field mappings. ## Before you start You will need SAP C4C administrator rights and Go Autonomous admin rights to complete this setup. If you have any questions or need assistance, contact your Success Manager. # SAP C4C Connector Guide Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/sap-c4c-connector/sap-c4c-connector-guide Connect Go Autonomous to your SAP Cloud for Customer (C4C) environment. ## Set up the SAP C4C connector Log in to the Go Autonomous platform and navigate to **Administration > Company Settings > Connectors**. Under **Available Connectors**, find and click **SAP C4C**. Fill in the required fields, including your SAP C4C Tenant ID. Follow the instructions on the [SAP Analytics Cloud Help website](https://help.sap.com/docs/SAP_ANALYTICS_CLOUD/00f68c2e08b941f081002fd3691d86a7/dfdde513f6984dc7b2771ec03ea0c136.html) to locate your Tenant ID. Save the connector. It will appear under **Active Connections** once the configuration is complete. ## What's next * [SAP C4C Integration Schema](/knowledge-base/administration/connectors/sap-c4c-connector/sap-c4c-integration-schema) * [Configure authenticators](/knowledge-base/administration/authenticators) # SAP C4C Integration Schema Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/sap-c4c-connector/sap-c4c-integration-schema Overview of how Go Autonomous integrates with SAP Cloud for Customer via ticket management and the iframe component.
Activate the **Service Request** and **Enrich Ticket** API calls by enabling the C4C connector as outlined in the [SAP C4C Connector Guide](/knowledge-base/administration/connectors/sap-c4c-connector/sap-c4c-connector-guide). Set up the iframe component to embed the Go Autonomous interface inside SAP C4C. Follow the [SAP mashup configuration guide](https://help.sap.com/docs/search?q=mashups\&locale=en-US\&format=standard,html,pdf,others) for instructions.
SAP C4C integration schema diagram
# SFTP connector Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/sftp-connector Connect Go Autonomous to an SFTP server for automated file-based data exchange. ## Overview The SFTP connector lets Go Autonomous connect to an SFTP (Secure File Transfer Protocol) server to exchange data files. This is commonly used for automated product catalog uploads, order exports, and other batch file transfers with systems that support SFTP. ## Set up an SFTP connector Navigate to **Administration > Company Settings > Connectors**. Click the add button and select **SFTP** from the connector type list. Enter the SFTP server details: * **Host** — the server hostname or IP address. * **Port** — the SFTP port (typically 22). * **Username** — the account to authenticate with. * **Password or key** — the credentials for the SFTP account. * **Remote path** — the directory on the server to read from or write to. Save the connector. Go Autonomous will use these settings to connect to your SFTP server. ## Common use cases * **Product catalog sync** — automatically import updated product data from your ERP system. * **Order file export** — push confirmed orders to a shared SFTP folder for downstream processing. * **Reference data updates** — pull reference data files on a schedule. ## What's next * [Set up connectors overview](/knowledge-base/administration/connectors) for other connector types. * [Configure authenticators](/knowledge-base/administration/authenticators) to manage credentials. # Third-party connector Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/third-party-connector Connect Go Autonomous to any external system by configuring outbound webhooks that fire at specific points in the request lifecycle. ## Overview The third-party connector lets you send data from Go Autonomous to any external system at defined points during request processing. You configure one or more **webhook actions** — each pairing a lifecycle event (such as "On Confirmation") with a target URL — so Go Autonomous calls your system automatically as requests move through the pipeline. Multiple third-party connectors can be created, one for each external system you need to connect to. You must have at least one [Authenticator](/knowledge-base/administration/authenticators) configured before you can create a third-party connector. The connector uses the authenticator to handle credentials for all its outbound calls. *** ## Configuration fields | Field | Description | | - | - | | **Name** | A label for the connector — used to identify it in the connectors list. | | **Authenticator** | The authenticator that provides credentials for all webhook calls made by this connector. Required. | | **Webhook base URL** | The base URL (e.g. `https://your-base-url.com`) that's prepended to any webhook endpoints entered as a relative path. Required when at least one webhook uses a relative endpoint; otherwise optional. | | **Webhook configurations** | One or more webhook actions defining when and where Go Autonomous sends data (see below). At least one is required. | *** ## Webhook actions Each webhook configuration pairs a **lifecycle event** (the **event trigger**) with a **target URL**. When the event occurs on a request, Go Autonomous posts data to that URL. ### Webhook URLs: absolute vs. relative Webhook URLs can be entered in either format: * **Absolute URL** — e.g. `https://your-system.com/hooks/confirmation`. Used as-is. * **Relative path** — e.g. `/hooks/confirmation`. Appended to the connector's **Webhook base URL** at delivery time. Using a base URL plus relative paths is the recommended setup when all webhooks target the same host — it keeps endpoints concise and lets you update the host in one place. If any row uses a relative path, the **Webhook base URL** field becomes required. ### Available event triggers | Event | When it fires | | - | - | | **Can Classify** | When a new email arrives, before classification. Your system decides whether Go Autonomous processes the email (see below). | | **On Classification** | After Go Autonomous classifies the intent of an incoming request. | | **Can Extract** | After classification, before extraction. The request includes the classified intent, and your system decides whether Go Autonomous continues processing (see below). | | **On Extraction** | After AI extraction has run and fields have been populated. | | **On Account Resolution** | After the customer account has been resolved against your data. | | **On Transformation** | After any transformation steps have been applied to the request data. | | **On Confirmation** | When a request is confirmed in Flow. | | **On Field Update** | When a specific field value is updated on a request (see below). | Each event trigger (except On Field Update) can only be used once per connector. If an event is already configured in one row, it will not be available to select in another row of the same connector. ### Can Classify and Can Extract **Can Classify** and **Can Extract** are decision hooks. Instead of only receiving data, your system replies to tell Go Autonomous whether to continue processing the email. Use them to ignore emails from specific senders, skip intents your system doesn't handle, or hold an email until an external resource is ready. Your endpoint responds with one of three values: | Value | Result | | - | - | | `yes` | Go Autonomous continues processing the email. | | `not_now` | Go Autonomous retries the call later using a Fibonacci-based delay. | | `never` | Go Autonomous stops processing and deletes all traces of the email. | For example, a **Can Extract** endpoint that rejects a return request responds with: ```json theme={null} { "can_extract": "never" } ``` Use **Can Extract** when your decision depends on the classified intent. Otherwise, use **Can Classify**. Configuring both is usually redundant. If neither is configured, Go Autonomous processes every email. ### On Field Update The **On Field Update** event fires whenever a specific field is changed. When you select this event trigger, an additional **Field** picker appears — choose the exact field (from your configured field settings) that should trigger the webhook. You can add multiple **On Field Update** rows, each watching a different field. Each field can only be used once per connector. *** ## Set up a third-party connector Navigate to **Administration > Company Settings > Connectors**. Click the add button and select **Third-party** from the connector type list. Give the connector a descriptive name so you can identify it in the list. Choose the authenticator that holds the credentials for your target system. If none exist yet, you'll be prompted to create one first. If your webhooks share a host, enter it under **Webhook base URL** (e.g. `https://your-system.com`). You can then enter each webhook below as a relative path. Leave this blank if you'll enter full absolute URLs for every webhook. Add one or more webhook rows. For each row: * Select the **event trigger** that should fire the call. * Enter the **webhook URL** — either a full absolute URL or a relative path (e.g. `/hooks/confirmation`) that will be appended to the base URL. * If using **On Field Update**, also select the **field** to watch. Save the connector to activate it. Go Autonomous will begin firing webhooks immediately for matching events. *** ## Managing webhook rows * **Add a row** — click the add button below the webhook list to add another event/URL pair. * **Delete a row** — click the delete icon on any row. You cannot delete the last remaining row; at least one webhook configuration must always be present. *** ## Integration events After the connector is active, use the **Integration Events** feed to monitor its health. It shows a log of recent outbound calls, including: * Successful deliveries. * Errors and failed calls. * Timestamps and payload details for troubleshooting. *** ## What's next * [Configure authenticators](/knowledge-base/administration/authenticators) to manage the credentials used by your connectors. * [Connectors overview](/knowledge-base/administration/connectors) for other available connector types. # Zendesk connector Source: https://knowledge.goautonomous.io/knowledge-base/administration/connectors/zendesk-connector Connect Go Autonomous to your Zendesk instance for customer service workflows. ## Overview The Zendesk connector lets Go Autonomous communicate with your Zendesk instance. Use it when your customer service team works in Zendesk and you want Go Autonomous to exchange data with it. ## Prerequisites * An [authenticator](/knowledge-base/administration/authenticators) with your Zendesk credentials. * Edit access to **Company Settings > Integrations**. Users with viewer access can see the configuration but can't change it. ## Set up a Zendesk connector Navigate to **Administration > Company Settings > Connectors**. Find **Zendesk** in the **Available Connectors** section and click the card. The configuration dialog opens. Fill in the required fields: * **Name** — a clear name for the connector (e.g., "Zendesk Production"). * **Base URL** — your Zendesk instance URL, e.g. `https://your-company.zendesk.com`. * **Authenticator** — select the authenticator that holds your Zendesk credentials. Save the connector. It appears in the **Active Connectors** section. ## Test the connection When you open an active Zendesk connector to view or edit it, a **Test connection** button appears next to the authenticator field. 1. Enter or update the **Base URL** and **Authenticator**. 2. Click **Test connection**. Go Autonomous attempts to reach your Zendesk instance with the selected credentials. 3. The result shows next to the button: **Connection successful** or **Connection failed**. If the test fails, verify that the base URL points to your Zendesk instance and that the authenticator credentials are valid. The **Save** button is disabled while a test is running. If you change the base URL or authenticator after a test, the result resets and you should test again. ## Edit a Zendesk connector 1. Open the connector from the **Active Connectors** section. 2. Update the name, base URL, or authenticator. 3. Test the connection to confirm the new settings work. 4. Save your changes. ## What's next * [Set up connectors overview](/knowledge-base/administration/connectors) for other connector types. * [Configure authenticators](/knowledge-base/administration/authenticators) to manage credentials. # Customer product numbers Source: https://knowledge.goautonomous.io/knowledge-base/administration/customer-product-numbers Upload and manage customer-specific product number mappings for accurate product matching. ## Overview Customer product numbers (CPNs) let you map the product identifiers your customers use to your internal product catalog numbers. When a customer sends an order using their own product codes, Go Autonomous uses these mappings to automatically match them to the correct products in your catalog. ## Why use customer product numbers Customers often use their own numbering systems for your products. Without CPN mappings, your team would need to manually look up each customer product number during order processing. CPN mappings automate this step, improving accuracy and speed. ## Catalogs and areas Customer product number catalogs can be uploaded per [area](/knowledge-base/administration/areas). This allows different teams or regions to maintain their own customer-specific mappings. When Go Autonomous processes a request, it uses the CPN catalog assigned to the request's area. If no catalog exists for that area, it falls back to the **Default** catalog automatically. Always maintain a Default catalog as a fallback. Any area without its own CPN catalog will use it. ## The Customer Product Catalog page Navigate to **Administration > Company Settings > Customer Product Catalog** to manage your CPN data. The page shows one **card per catalog** in a grid layout. Each card displays: * The **area name** the catalog belongs to. The fallback catalog is labelled **Default**. * An **emoji or icon** — the area's emoji when set, otherwise a generic package icon. * A **column-mapping count** — how many columns of the uploaded file are mapped to platform fields (e.g., `3 / 4 columns mapped`). Click the info icon next to the count to open a **column mappings popover** that lists every mapped source column from your file and the CPN field it maps to (e.g., `cust_sku → Customer Product Number`). Use this to verify a catalog's mapping without opening the edit drawer. * A **delta badge** when the catalog has a unique field configured for delta uploads. Hover the badge to see which unique field is used. Click any card to open the edit drawer for that catalog. Cards for areas you don't have access to are shown in a muted state and can't be opened. ### Find a catalog Use the toolbar at the top of the page to narrow down what you see: * **Search** — type in the search field to filter cards by catalog name. * **Sort** — click the sort icon to switch between **Name A—Z** and **Name Z—A**. The **Default** catalog always sorts to the top of the grid regardless of the active sort direction, so the fallback is easy to find. ### Select and bulk-manage catalogs Hover a card to reveal a checkbox in its top-right corner. Tick the checkbox on any card you have access to — you can select as many as you need across the grid. As soon as at least one card is selected, the toolbar shows a **selection action bar** with: * **Download** — export each selected catalog as a CSV file. Each area is downloaded as a separate file. * **Delete** — permanently delete the selected catalogs. Deletion is confirmed via a dialog and cannot be undone. Viewers don't see this action. * **Clear** — deselect everything and hide the action bar. Bulk delete permanently removes the selected customer product catalogs. There is no undo — re-uploading the file is the only way to restore them. ## Upload a catalog Click the **Upload catalog** button in the top toolbar. Choose which area this catalog applies to, or select **Default** to upload a catalog used as the fallback across all areas. Select a CSV file containing your customer product number mappings. Configure the delimiter and encoding if needed. Map the columns in your CSV to the CPN fields: Customer Product Number, Customer ID, and Product Number. Finalize the upload. The mappings are immediately available for product matching. ## Review and edit catalog entries Click any catalog card to open a review drawer showing all entries. From here you can: * **Search** entries to find specific mappings. * **Add** new entries manually. * **Edit** existing entries to correct mappings. * **Delete** entries that are no longer needed. Edits and deletions apply to the table immediately, so you don't have to wait for the catalog to reload. If a save fails, the row reverts to its previous value and an error toast appears — check the values and try again. ## What's next * [Review and confirm orders in Flow](/knowledge-base/flow/review-and-confirm) to see how product matching works during processing. # Send emails Source: https://knowledge.goautonomous.io/knowledge-base/administration/email-sending Send emails directly from the Go Autonomous platform as part of your order processing workflow. ## Overview Go Autonomous allows you to send emails directly from the platform as part of your workflow. This is used in features like [vendor quotation requests](/knowledge-base/flow/vendor-quotation), where you need to send a request for quote to a supplier, or when communicating with customers about their orders. ## How email sending works When you use a feature that sends an email (such as sending a vendor quote request), Go Autonomous: 1. Uses a pre-configured email template appropriate for the context. 2. Populates the template with relevant data from the current request (order details, product information, etc.). 3. Sends the email through your connected email system. ## Where email sending is used * **Vendor quotation** — send requests for quotes to suppliers directly from Flow. See [Send vendor requests for quotes](/knowledge-base/flow/vendor-quotation) for details. * **Collaboration notifications** — when you @mention someone in a collaboration thread, they may receive an email notification. * **Password resets** — administrators can trigger password reset emails from the [user management](/knowledge-base/administration/user-management) page. ## Prerequisites Email sending requires a configured [Microsoft connector](/knowledge-base/administration/connectors/ms-connector) with appropriate permissions to send emails through your organization's email system. ## What's next * [Send vendor requests for quotes](/knowledge-base/flow/vendor-quotation) for the vendor quotation workflow. * [Set up connectors](/knowledge-base/administration/connectors) to configure your email integration. # Field Manager Source: https://knowledge.goautonomous.io/knowledge-base/administration/fields-manager Create and manage field configurations that control what your team sees and captures in Flow. ## Overview The Field Manager is where you define what information appears in Flow when your team processes a request. Each **field configuration** is a set of fields linked to specific intents and areas — so the product cart and summary panel can look different depending on the type of request being processed and which team is handling it. ## The configurations list Navigate to **Administration > Company Settings > Field Manager** to see all your configurations. Each row shows: * **Name** — the configuration name. * **Intent** — the intents this configuration applies to. Up to three are shown inline; hover the **(+N)** badge to see the rest. * **Area** — the areas this configuration applies to. Displays "Default" if no area is assigned. * **Fields** — the total field count across all tabs. Click any row to open and edit that configuration. *** ## Search and filter Use the **search bar** to find configurations by name. Click **Filter** to narrow results by area or intent. Active filters are indicated by a blue dot on the button. Click **Filter** again and select **Clear** to reset. *** ## Create a configuration Click **Add configuration** (+ icon) in the top toolbar. A new blank configuration opens immediately — name it, assign intents and areas, then build out your fields. [Setting up a configuration →](/knowledge-base/administration/fields-manager/field-configuration) *** ## Duplicate a configuration Select exactly one configuration using its checkbox, then click the **Duplicate** icon in the toolbar. A copy is created named `{original name} (copy)` with the intents and areas cleared so you can assign new ones without conflict. You are taken directly to the duplicate to continue editing. *** ## Import and export configurations Configurations can be exported as `.json` files and re-imported into any environment — useful for moving configurations from a sandbox to production, or backing up your setup. **To export:** Select one or more configurations using their checkboxes, then click **Export configurations**. **To import:** With nothing selected, click **Import configurations**. Drag and drop one or more `.json` files into the upload zone and click **Upload**. If any file would overwrite an existing configuration, a confirmation step lists the affected configurations before proceeding. *** ## Delete configurations **Single delete:** Hover a configuration row and click the trash icon, then confirm. **Bulk delete:** Select multiple configurations using their checkboxes, then click **Delete selected** in the toolbar and confirm. Deleted configurations cannot be recovered. *** ## What's next * [Setting up a configuration](/knowledge-base/administration/fields-manager/field-configuration) * [Summary, Line Items, and Stocklines tabs](/knowledge-base/administration/fields-manager/tabs) * [Adding and configuring fields](/knowledge-base/administration/fields-manager/adding-fields) # Adding and configuring fields Source: https://knowledge.goautonomous.io/knowledge-base/administration/fields-manager/adding-fields How to add a field to a configuration and configure its name, type, reference data, defaults, and behaviour. ## Overview Fields are added from within any of the three tabs (Summary, Line Items, or Stocklines) in a configuration. Click **+ Add field** within a group or section to open the **Field editor** dialog. The same dialog is used when editing an existing field — click any field row to open it. The field editor has three tabs: **Details**, **Configuration**, and **Reference Data**. *** ## Details tab ### Field name The display name shown to your team in Flow. If you change it from the system default, a **Reset to default field name** link appears below the input. ### System name The internal identifier for the field (`field_id`). This is read-only and is used in integrations and API mappings. ### Description Optional free-text description. When set, an info icon appears on the field row — hovering it shows the description text. Useful for documenting what the field captures for your team. *** ### Attributes #### Type The data type controls how the field value is displayed, edited, and validated in Flow. | Type | Description | | - | - | | **Text** | Free-form string input. | | **Number** | Numeric value only. Uses a dot as the decimal separator. | | **Date** | Date value, rendered with a date picker. | | **Toggle** | Boolean true/false switch. | | **Email** | Email address input. | | **Link** | A read-only clickable URL. Link fields are automatically set to read-only and cannot be mandatory. | Type can only be changed if the field has no reference data attached and the original data type was text. Type restrictions: * **Toggle** cannot be used on fields marked as mandatory. * **Toggle** and **Email** cannot have reference data attached. * **Date** and **Link** cannot have reference data attached. Email fields can be marked as mandatory. When set, the user must enter at least one valid email address before the request can be confirmed. #### Visible Controls whether the field appears in Flow. Invisible fields are useful when you need to include information that is mandatory to create or simulate an order, but don't want it visible to the user — for example, a system reference code that must be present but has no meaning to the reviewer. * Turning **on** sets the field to optional. * Turning **off** marks the field as not applicable. The AI will still extract a value and it will still be passed to integrations. #### Mandatory When enabled, the field must have a value before a request can be confirmed. Flow will block confirmation and highlight the field if it is empty. Mandatory cannot be enabled when: * The field type is Toggle (tooltip: *"Field cannot be mandatory when configured as toggle type"*) * The field has Read only behaviour enabled Marking a field as mandatory on a live configuration will immediately block confirmation on any open requests that don't have a value for that field — including requests already in progress. *** ### Field span Control how much space a **product cart field** takes up in Flow by adjusting its **width** and **height** from the Details tab. Field span is only available on **Line Items** (product cart) fields — Summary fields and Stocklines fields aren't resizable from here. * **Width** — how wide the field is. Wider settings work well for longer values (e.g. a description or full delivery address); narrower settings suit short values (e.g. a quantity or a unit). Width also controls the column width in the product cart. * **Height** — how tall the field is. Taller settings let users see multi-line content (e.g. notes or addresses) without scrolling inside the cell. **Height can only be expanded on the lower-level fields in the product cart** — fields in the top row (such as Product Number, Product Name, Quantity, Unit Price) are limited to single-line height. Move a field into the lower section if you need it taller. Field spans are saved per field configuration, so different areas can use different sizing for the same field. *** ## Reference Data tab Attach a reference data set to make the field a searchable dropdown in Flow. Users (and the AI) can then select from a list of valid values rather than typing freeform. Click **Add** to open the reference data assignment dialog: 1. Select a reference data source from the left panel. 2. Choose the **Value** column — the internal value stored when an option is selected. 3. Choose the **Display Value** column — what the user sees in the dropdown. 4. Click **Apply**. Once attached, two additional options appear directly in the Reference Data tab: **Hidden columns** — choose which columns from the reference data set to hide from the dropdown options shown in Flow. Hidden columns are also excluded from search when users look up reference data in Flow. **Dependent fields** — link this field's available options to the value selected in another field. For example: selecting a product category in one field narrows the options available in a subcategory field. To set up a dependency: 1. Under *"When the following field has a value"*, select the parent field. 2. Under *"Then only show options for this field where the following columns match"*, select the matching column in the parent's reference data and the corresponding column in this field's reference data. A **Preview** button appears once all three dropdowns are filled, showing a plain-language summary of exactly how the dependency will behave — for example: *"When you pick \[parent field] with value X, then only show options in \[this field] where the matching column also equals X."* The Save button is disabled if the dependency configuration is partially complete. Either finish it or click **Clear dependency** to start over. Dependent fields are not available on Stocklines fields. *** ## Configuration tab ### Default value Set a fallback value that is pre-populated when the AI finds no value for the field. The input type matches the field's data type: | Field type | Default value input | | - | - | | Text / Number | Text input | | Date | Preset options: Today, Tomorrow, In 3 days, In 1 week, In 2 weeks, In 1 month — or a custom "In \_\_ days" offset. An **Include weekends** checkbox is shown once a value is selected. | | Toggle | On/off switch | | Email | Multi-email input. Type an address and press Enter to add it as a chip, or paste a list separated by commas, semicolons, or whitespace to add several at once. Invalid or duplicate addresses are rejected inline. | | Reference data | Searchable dropdown from the linked reference data | Default values are visible and editable by users in Flow — they are not locked in. **Area overrides:** When a configuration has two or more areas, you can set different default values per area. Click **Add area override**, select the area, and enter the default value for that area. This lets different teams or regions get a different pre-populated value for the same field. *** ### Behaviour Behaviour options add additional rules to how the field works. Available options depend on the field's location (Summary, Line Items, or Stocklines) and data type. | Option | Description | | - | - | | **Read only** | The field is visible but cannot be edited in Flow. Cannot be combined with Mandatory, Select only, or Simulate on update. | | **Select only** | The user can only select a value from the reference data dropdown — they cannot type a freeform value. Requires reference data to be attached. | | **Simulate on update** | Changing this field's value triggers a re-simulation automatically. Cannot be combined with Read only. | | **Include in vendor quote** | The field is included in vendor quotation requests. Maximum 5 fields allowed (product name and number are excluded from the count). | | **Show in stockline** | *(Stocklines fields only)* Displays the field in the inline stockline row within the product cart. | | **Show in tableview** | *(Stocklines fields only)* Displays the field in the expanded stockline table dialog. | *** ## Reordering fields Drag and drop fields within a tab to change their order. In the Summary tab, you can also drag entire groups to reorder them. In the Line Items tab, reordering fields changes the left-to-right column order in the product cart — use the preview strip at the top to see the result as you drag. *** ## Deleting a field Hover a field row and click the trash icon. A confirmation dialog appears. If the field is part of a **sum definition** or a **one-time delivery configuration**, the dialog will warn you that removing the field will also remove those definitions. *** ## Effect on requests * **New requests** — the field is active immediately for all new requests matching the configuration. * **Existing open requests** — the field column will appear but with an empty value. Default values are not backfilled onto existing requests. If the field is mandatory, users on existing requests will need to fill it in before confirming. *** ## What's next * [Summary, Line Items, and Stocklines tabs](/knowledge-base/administration/fields-manager/tabs) * [Stock lines setup](/knowledge-base/administration/fields-manager/stock-lines) * [Configure areas](/knowledge-base/administration/areas) # Configurations Source: https://knowledge.goautonomous.io/knowledge-base/administration/fields-manager/field-configuration Name a configuration, assign intents and areas, and understand how the three field tabs work together. ## Overview Each field configuration defines the fields that appear in Flow for a specific combination of intent and area. When a request arrives, Go Autonomous matches it to the right configuration and uses those fields for extraction, display, and confirmation. *** ## Configuration name Enter a name that reflects the use case — for example, "Order", "Quote", or "Delivery Notice". Validation rules: * Name is required before saving. * Names must be unique. If a name already exists, you'll see: *"This name already exists. Please enter a unique name."* Click the pencil icon next to the name at any time to rename it. *** ## Selecting intents Use the **Intents** picker to choose which request types this configuration applies to. At least one intent is required. **Conflict rule:** If an intent is already assigned to another configuration for the same area, it will appear greyed out with a tooltip naming the conflicting area. You cannot assign the same intent + area combination to two configurations. *** ## Selecting areas Use the **Areas** picker to choose which areas this configuration applies to. Areas are optional — leaving this blank makes the configuration the **default**, which applies to any area not covered by a more specific configuration. **Conflict rule:** If an area is already paired with the selected intents in another configuration, it will appear greyed out with a tooltip listing the conflicting intents. If you remove an area from an existing configuration, any area-specific default values that were set for fields in that configuration are automatically cleared. Once an area is linked to a configuration, you can see which configurations are attached to it directly from the [Areas](/knowledge-base/administration/areas) page. *** ## The three tabs Once a configuration is named and intents are set, three tabs let you define fields across different parts of the Flow interface: | Tab | What it controls | | - | - | | **Summary** | Request-level fields shown in the Summary panel — header details, delivery address, account information, and other order-level data. | | **Line Items** | Fields shown per product row in the product cart — the columns your team uses to review and edit extracted line items. | | **Stocklines** | Fields shown within the stockline (subproduct) viewer — additional detail about each product variant or sub-item. | Each tab is independent. You can have different fields, different visibility settings, and a different layout on each. [Learn more about configuring each tab →](/knowledge-base/administration/fields-manager/tabs) *** ## Unsaved changes If you navigate away from a configuration with unsaved changes, a dialog appears: > *"This will discard all unsaved changes. In order to not lose your changes, save your configuration first."* Click **Save configuration** in the top toolbar to commit your changes before leaving. *** ## What's next * [Summary, Line Items, and Stocklines tabs](/knowledge-base/administration/fields-manager/tabs) * [Adding and configuring fields](/knowledge-base/administration/fields-manager/adding-fields) # Stocklines (subproducts) Source: https://knowledge.goautonomous.io/knowledge-base/administration/fields-manager/stock-lines Configure the fields that appear within stocklines — the sub-product viewer built into the Flow product cart. ## Overview Stocklines (called **subproducts** in the platform) are a sub-product viewer built into each product line in the Flow cart. They let you attach a structured list of related items or data directly beneath a parent product, which users can view — and optionally select from — without leaving Flow. ## Use cases Stocklines are flexible enough to cover several different scenarios: **Stock split by characteristic** — when a single product exists across multiple stock entries that differ by warehouse, batch, expiry date, or similar attributes. Instead of showing one undifferentiated line, stocklines surface each stock entry separately so users can see availability and choose where to fulfil from. **Bill of materials** — when a product is made up of component parts (e.g. a table composed of four legs, bolts, and a tabletop). Each component is a stockline under the parent product, giving users full visibility of what makes up the order line. **Pricing variants** — when processing quotes, stocklines can display a list of similar products or pricing options for a product, letting the user compare and select the most appropriate one. In all cases, stocklines act as a structured sub-product viewer attached to a parent line — the underlying concept is the same regardless of what data you're showing. ## Selectable vs read-only stocklines Stocklines can be configured in two modes: **Selectable** — users can check and uncheck individual stocklines in the dialog. A **Select** button applies their selection back to the parent product line. Use this when the user needs to actively choose which sub-items to include (e.g. selecting a warehouse, choosing a component, picking a pricing tier). **Read-only** — all stocklines are display-only. No checkboxes appear and users can only view the data. The dialog shows a **Close** button instead of a **Select** button. Use this when the sub-product data is informational only (e.g. showing bill-of-materials components that are always included, or displaying pricing history for reference). The selectable/read-only behaviour is controlled by the `status` field on each subproduct returned from your integration — `selected`, `not_selected`, or `readonly`. ## Configuring stockline fields Stockline fields are configured separately from the main product cart fields. Navigate to **Administration > Company Settings > Field Manager**, open a configuration, and find the **Stocklines** section. Each field you add to the Stocklines section has two visibility toggles in addition to the standard field properties: * **Show in stockline view** — controls whether the field appears in the inline numbered view (visible when the parent product row is expanded in the cart). * **Show in table view** — controls whether the field appears as a column in the full stocklines dialog (opened via the layers icon on the product row). You can add any number of fields and drag them to reorder. Up to 6 fields display per row in the inline view. ### Field properties | Property | Description | | - | - | | **Read only** | Field is display-only. Users cannot edit the value. | | **Select only** | For reference data fields — users can only pick from predefined options, not enter free text. | | **Show in stockline view** | Field is visible in the inline expanded row. | | **Show in table view** | Field is visible as a column in the stocklines dialog. | ### Supported field types Stockline fields support the same data types as regular cart fields: * **Text** — free-form string. * **Number** — numeric value with formatting. * **Date** — date value with a date picker in Flow. * **Boolean** — rendered as a toggle switch. * **Email** — comma-separated list of email addresses. * **Reference data** — autocomplete lookup against a reference data set. * **Link** — clickable URL rendered as a hyperlink. ## What's next * [Stock line selection in Flow](/knowledge-base/flow/stock-lines) — how users view and interact with stocklines when processing requests * [Back to Field Manager](/knowledge-base/administration/fields-manager) * [Dependent fields](/knowledge-base/administration/fields-manager/dependent-fields) # Summary, Line Items, and Stocklines Source: https://knowledge.goautonomous.io/knowledge-base/administration/fields-manager/tabs How to configure fields across the three tabs of a field configuration. ## Overview Every field configuration has three tabs — **Summary**, **Line Items**, and **Stocklines** — each controlling a different part of the Flow interface. Fields added to one tab are completely independent of the others. *** ## Summary tab The Summary tab defines request-level fields: the data that appears in the Summary panel in Flow — things like delivery address, account, purchaser name, and order-level references. ### Groups Summary fields are organised into collapsible **groups**. Each group appears as a section in the Flow Summary panel. * **Rename a group** — click the group name to edit it inline. Group names are required and must not be blank. * **Add a group** — click **+ Add group** at the bottom. This is disabled if any group currently has a blank name or if a field in any group has an incomplete setup. * **Reorder groups** — drag and drop groups to change the order they appear in the Summary panel. * **Delete a group** — hover the group header and click the trash icon. Deleting a group removes all fields within it. ### Adding fields to a group Click the **+ Add field** button within a group to add a field to that section. Fields within a group can be reordered via drag and drop. ### One-time delivery configuration When a delivery address field is added to a Summary group, a **Configure One-Time Delivery** button appears within that group. This button lets you define how a one-time (ad-hoc) delivery address is structured when a user enters one in Flow. The Configure One-Time Delivery button only appears after a delivery address field has been added to the group. It will not be visible until that field is present. Clicking the button opens a dialog where you can: * Set a **configuration name** (required; max 25 characters). * Enable **Create in ERP** if the one-time address should be pushed to your ERP. This only works if your integration has been configured to support it — confirm with your Engagement Manager before enabling. * For each delivery address field in the group, configure: * **Include** — whether this field appears in the one-time delivery form. * **Required** — whether the user must fill it in (only available if the field is included). * **Field description** — an AI prompt describing what the field should contain and how it should be formatted (required when the field is included). For example: *"Find the delivery country and return its 2-letter ISO code."* Save is disabled until at least one field is included. For the user-facing impact of one-time delivery — including how it appears in the Agent view tile and how the AI parses addresses — see [Tips and tricks on delivery addresses](/knowledge-base/flow/delivery-addresses). *** ## Line Items tab The Line Items tab defines the columns in the Flow **product cart** — the fields your team sees and edits for each extracted product line. ### Preview A **preview strip** at the top of the tab shows a live visual mock of how the product cart will look based on your current field configuration. As you add, remove, reorder, or change field visibility, the preview updates in real time. Use it to check column layout and spacing before saving. Fields are split into two visual rows in the preview: * **Upper level fields** — the main product row (always visible per line). * **Lower level fields** — a secondary row shown when a line is expanded. ### Stacking fields The first two fields in the product cart can be placed side by side in the same column ("stacked") by dragging one onto the other. Stacking only applies to those first two fields — fields further down the list cannot be stacked. This is useful for pairing short-value fields like quantity and unit of measure. ### Spacers Click **Add spacer** to insert a blank spacer column in the cart layout. Spacers are purely cosmetic and help with visual alignment. ### Sum definition Click **Define sum** to configure how the total at the bottom of the product cart is calculated. This requires at least two visible number-type fields. The sum dialog lets you define a formula: **Field 1 \[operator] Field 2**, where the operator can be +, −, ×, or ÷. The result is summed across all line items and shown as a total at the bottom of the cart. If you remove or hide a field that is part of a sum definition, the sum definition is automatically removed. You'll be warned before confirming. *** ## Stocklines tab The Stocklines tab defines the fields shown inside the **stockline (subproduct) viewer** — the additional detail layer displayed for products that have sub-variants or stock entries. ### Preview Like the Line Items tab, a **preview strip** at the top shows how the stockline fields will render in the viewer. The preview includes both the product cart context above and the subproduct fields below, so you can see how they sit together. ### Differences from other tabs * There is no Visible toggle per field — all fields added to the Stocklines tab are always displayed. * Fields cannot be marked as Mandatory. * There are no spacers or sum definitions. * The `show_in_stockline` and `show_in_tableview` behaviour options on each field (configured in the field editor) control whether a field appears in the inline stockline view vs. the expanded table view. For more on how stocklines work from a user perspective, see [Stock lines in Flow](/knowledge-base/flow/stock-lines). For admin setup, see [Stock lines setup](/knowledge-base/administration/fields-manager/stock-lines). *** ## What's next * [Adding and configuring fields](/knowledge-base/administration/fields-manager/adding-fields) * [Tips and tricks on delivery addresses](/knowledge-base/flow/delivery-addresses) * [Stock lines setup](/knowledge-base/administration/fields-manager/stock-lines) # Manage inboxes Source: https://knowledge.goautonomous.io/knowledge-base/administration/inbox-management Configure email inboxes to control how incoming requests are received and routed in Go Autonomous. ## Overview Inboxes define which email accounts Go Autonomous monitors for incoming requests. Each inbox connects to an email account (via your Microsoft connector) and can be configured with folders, areas, and intent mappings to control how requests are processed. ## The inbox setup Inbox configuration is primarily managed through your [Microsoft connector](/knowledge-base/administration/connectors/ms-connector) settings. When you add a Microsoft connector, you can select which mailboxes to monitor and configure how emails are processed. ## Key inbox settings ### Folder selection Choose which email folders Go Autonomous should monitor within each inbox. By default, the inbox monitors the primary folder, but you can configure it to watch specific subfolders for different workflows. ### Area routing Map inboxes to specific [areas](/knowledge-base/administration/areas) to automatically route incoming requests to the right team: * Each inbox can be assigned to one or more areas. * Requests from mapped inboxes inherit the area assignment automatically. * This works in combination with user groups to control visibility. ### CRM routing Each sourced inbox can send confirmed request data to a **CRM connector**, or opt out with **No CRM Routing**. Configure this on the [Microsoft connector](/knowledge-base/administration/connectors/ms-connector) inbox page (and when you add inboxes). Inboxes without their own route use your organisation's **primary CRM connector**. See [CRM connector routing](/knowledge-base/administration/connectors/connector-routing) for the primary CRM setting, when the CRM column and bulk assign appear, and how routing is resolved at runtime. ### Intent mapping Define which intents are associated with each inbox. This helps Go Autonomous: * Apply the correct AI extraction model based on the type of requests an inbox typically receives. * Route requests to the appropriate workflow in [Pulse](/knowledge-base/pulse/overview). * Pre-configure field settings for the expected request types. ### Shared vs. personal inboxes Each inbox has a **Shared inbox** checkbox that controls whether Go Autonomous retains every incoming email or only the ones matching a selected intent. * **Shared inbox (checkbox checked):** Go Autonomous stores every email that arrives in the inbox, whether or not it classifies to a selected intent. Use this for team mailboxes where you want a complete record of incoming mail. * **Personal or individual inbox (checkbox unchecked):** Go Autonomous only retains emails that classify to a selected intent. Anything else is discarded and not stored. ### Status tagging Configure how Go Autonomous tags the status of emails in your inbox. When enabled, Go Autonomous can update the email status (e.g., read/unread, categories) in your email system to reflect processing state. ### Reply tracking Enable reply tracking to let Go Autonomous monitor when customers respond to emails that have already been processed. This creates a link between the original request and any follow-up communication. ## Subscribe to inbox updates Go Autonomous can subscribe to real-time notifications from your email provider so that new emails are processed as soon as they arrive, rather than waiting for periodic polling. ## Managing inbox folders Organize your inbox by creating folders that map to different types of requests or processing stages. Folders can be used to: * Separate different request types within a single inbox. * Create staging areas for requests at different processing stages. * Archive processed requests. ## What's next * [Set up connectors](/knowledge-base/administration/connectors) to connect your email systems. * [Configure areas](/knowledge-base/administration/areas) to define routing rules. * [Manage users](/knowledge-base/administration/user-management) to control who sees which inbox. # Notifications Source: https://knowledge.goautonomous.io/knowledge-base/administration/notifications Stay informed about assignments, mentions, and collaboration updates with in-app notifications. ## Overview Go Autonomous sends notifications when events happen that need your attention — like being assigned a request, mentioned in a collaboration thread, or receiving a reply to a comment. Notifications appear via the bell icon in the top navigation bar. ## View notifications Click the **notification bell** in the navigation bar to open the notifications drawer. New unread notifications are indicated by a visual marker on the bell icon. The notification list shows each event with: * **Icon** — indicating the notification type (assignment, mention, reply, etc.). * **Description** — a summary of what happened and who triggered it. * **Timestamp** — when the event occurred. ## Notification types | Type | Triggered when... | | - | - | | **Mail assigned** | A request is assigned to you in Workstation. | | **Tagged in conversation** | Someone @mentions you in a collaboration thread. | | **Reply to conversation** | Someone replies to a collaboration thread you're part of. | ## Navigate to the source Click any notification to navigate directly to the relevant request in Flow. If the notification is about a [collaboration](/knowledge-base/flow/collaborations), it opens the specific thread and comment so you can respond immediately. Clicking a notification also marks it as read automatically. ## Mark all as read Click the **Mark all as read** control at the top of the notifications drawer to clear all unread indicators at once. ## What's next * [Collaborations in Flow](/knowledge-base/flow/collaborations) for working with threads and comments. * [Manage requests in Workstation](/knowledge-base/workstation/manage-requests) for handling assigned work. # Administration overview Source: https://knowledge.goautonomous.io/knowledge-base/administration/overview Configure integrations, manage settings, and control how Go Autonomous works for your organization.

Administration

Configure integrations, manage settings, and control how Go Autonomous works for your organisation.

## Overview The Administration section is where you configure and manage everything behind the scenes — integrations with external systems, field configurations, product catalogs, areas, automation rules, and organization-wide settings. Administration is accessible via **Company Settings** at the top of the page. How To Get To Company Settings ## Company Settings Company Settings contains everything related to how Go Autonomous processes and connects your data. It's organized into three sections: ### Integrations Set up connections to external systems and manage authentication. Create and manage authentication credentials for third-party integrations. Connect Go Autonomous to your ERP, CRM, and other business systems. In-app notifications for assignments, mentions, and updates. Configure outbound email sending for order confirmations and communications. Configure email inboxes, folders, and routing rules. ### Configurations Define how the platform processes and organizes data. Segment your organization into areas for different teams, regions, or business units. Control which requests are processed automatically vs. queued for manual review. Configure which fields appear in Flow and how data is extracted and displayed. Create and manage API keys for programmatic access. Track and review all actions taken in your organization. ### Data Manage the reference data and product catalogs that power extraction and matching. Upload and maintain your product catalog to power extraction and auto-matching in Flow. Map customer-specific product codes to your internal catalog. Upload and manage reference data sets for extraction and matching. ## What's next Pick the area that matches what you need to set up or configure. If you're just getting started, begin with [Connectors](/knowledge-base/administration/connectors) to link your external systems, then move to [Fields Manager](/knowledge-base/administration/fields-manager) to configure how data is displayed in Flow. # Product Catalog Source: https://knowledge.goautonomous.io/knowledge-base/administration/product-catalogs Upload and maintain your product catalog to improve extraction accuracy and automate product matching in Flow. ## Overview Your product catalog is the master list of all products your organisation sells or distributes. It is the primary source of truth for product matching during extraction — when Go Autonomous processes a request, it looks up extracted product numbers against your catalog to auto-populate names, prices, units of measure, and other details. The better your catalog is maintained, the more accurate and complete your extractions will be. ## How the product catalog improves extraction A well-maintained catalog enables several powerful features in Flow: * **Auto-completion** — when editing a product number, the system suggests matches from your catalog as you type. * **Validation** — extracted values are checked against the catalog. Mismatches are flagged for review. * **Enrichment** — once a product number matches, related fields (name, price, unit of measure) are auto-populated automatically. Outdated catalog data can cause incorrect auto-completions and missed validations. Schedule regular catalog updates to keep your data current. ## Catalogs and areas Product catalogs can be uploaded per [area](/knowledge-base/administration/areas). This lets different teams or regions work with their own product data — for example, different price lists or product ranges per business unit. When Go Autonomous processes a request, it uses the catalog assigned to the request's area. If no catalog has been uploaded for that area, it falls back to the **Default** catalog automatically. Always maintain a Default catalog as a fallback. Any area without its own catalog will use the Default. ## The Product Catalog page Navigate to **Administration > Company Settings > Product Catalog** to manage your catalogs. The page shows one **card per catalog** in a grid layout. Each card displays: * The **area name** the catalog belongs to. The fallback catalog is labelled **Default**. * An **emoji or icon** — the area's emoji when set, otherwise a generic package icon. * A **column-mapping count** — how many columns of the uploaded file are mapped to platform fields (e.g., `12 / 20 columns mapped`). Click the info icon next to the count to open a **column mappings popover** that lists every mapped source column from your file and the platform field it maps to (e.g., `sku → Product Number`). Use this to verify a catalog's mapping without opening the edit drawer. * A **delta badge** when the catalog has a unique field configured for delta uploads. Hover the badge to see which unique field is used. See [Setting up delta loads](/knowledge-base/administration/product-catalogs/delta-loads). Click any card to open the edit drawer for that catalog. Cards for areas you don't have access to are shown in a muted state and can't be opened. ### Find a catalog Use the toolbar at the top of the page to narrow down what you see: * **Search** — type in the search field to filter cards by catalog name. * **Sort** — click the sort icon to switch between **Name A—Z** and **Name Z—A**. The **Default** catalog always sorts to the top of the grid regardless of the active sort direction, so the fallback is easy to find. ### Select and bulk-manage catalogs Hover a card to reveal a checkbox in its top-right corner. Tick the checkbox on any card you have access to — you can select as many as you need across the grid. As soon as at least one card is selected, the toolbar shows a **selection action bar** with: * **Download** — export each selected catalog as a CSV file. Each area is downloaded as a separate `product-catalog-.csv` file. * **Delete** — permanently delete the selected catalogs. Deletion is confirmed via a dialog and cannot be undone. Viewers don't see this action. * **Clear** — deselect everything and hide the action bar. Bulk delete permanently removes the selected product catalogs. There is no undo — re-uploading the file is the only way to restore them. ## Upload a catalog Navigate to **Administration > Company Settings > Product Catalog** in the left sidebar under Data. Format your catalog as a CSV or Excel file with defined column headers. The catalog typically includes: product numbers (SKUs/part numbers), product names, descriptions, pricing, units of measure, and categories. Choose which area this catalog applies to, or select **Default** to upload a catalog used as the fallback across all areas. Click the upload button and select your file. The platform validates the data format and reports any errors before importing. The platform auto-maps columns whose headers match a field in your configured field settings — these are marked with a ✨ sparkle indicator. Hover the indicator to see which fields a column will map to (and under which configuration). Review the mappings and adjust any column the platform couldn't match automatically. Review the uploaded data for accuracy. New entries are added and existing entries are updated based on matching product numbers. ## Auto-mapping of columns When you upload a catalog, the platform inspects each column header and tries to match it to a field defined in your [field settings](/knowledge-base/administration/fields-manager). Matches are normalised — case, spaces, and separators are ignored — so headers like `Product Name`, `product_name`, and `productName` all resolve to the same field. Auto-mapped columns are marked with a sparkle icon (✨) in the column mapping step. Hover the icon to see: * **Which field** the column maps to (its display name). * **Which configuration** the field belongs to — useful when the same field ID is reused across multiple field configurations for different areas. You can override an auto-mapping by selecting a different field from the dropdown, or leave it as-is to accept the suggestion. Columns that don't match anything in your field settings stay unmapped until you map them manually. Standardise your CSV/Excel headers to match the field IDs in your field settings. The closer your headers are to the canonical names, the more columns are auto-mapped — leaving you with fewer manual mappings to review on every upload. ## What's next * [Configure field settings](/knowledge-base/administration/fields-manager) * [Send vendor requests for quotes](/knowledge-base/flow/vendor-quotation) # Reference data Source: https://knowledge.goautonomous.io/knowledge-base/administration/reference-data Upload and manage reference data sets that enhance extraction accuracy and product matching. ## Overview Reference data is supplementary information that Go Autonomous uses during processing to improve extraction accuracy and automate data lookups. It covers any structured dataset your organisation needs — delivery addresses, vendor details (name and inbox address for vendor quotations), customer lists, account mappings, pricing tables, carrier codes, and more. ## Reference data and areas Reference data can be uploaded per [area](/knowledge-base/administration/areas), allowing different teams or regions to use different data sets. When Go Autonomous processes a request, it uses the reference data assigned to the request's area. If no reference data exists for that area, it falls back to the **Default** area's data automatically. ### Default area requirement Every reference data grouping (e.g., "Delivery Addresses") **must have a Default area file**. This file acts as the fallback for any area that doesn't have its own upload. If there is no Default file for a grouping, requests processed against areas without their own data will have nothing to fall back on. ### Column structure must match across areas All files uploaded for the same reference data grouping — across all areas — must have **identical column structures**. The column names, order, and count must be a 1:1 match between the Default file and any area-specific file. If they differ, the functionality will break and lookups may fail or return incorrect results. Before uploading an area-specific file, always verify that its columns exactly match the Default file for that grouping. Mismatched column structures will cause lookup failures. ## The Reference Data page Navigate to **Administration > Company Settings > Reference Data** to manage your reference data sets. The page shows one **card per reference data type** in a grid layout. Each card displays: * The **reference data name** (e.g., "Delivery Addresses"). * An **assignment count** — how many areas have a file uploaded for that type. * **Area badges** — one badge per area that has a file, showing the area emoji and name. The Default file is shown as a **Default** badge. * A **delta badge** when at least one file for that type is configured as a delta upload. Hover the badge to see which areas have delta uploads enabled and the **unique field** each one matches on. ### Find a reference data type Use the toolbar at the top of the page to narrow down what you see: * **Search** — type in the search field to filter cards by reference name. * **Sort** — click the sort icon to switch between **Name A—Z** and **Name Z—A**. ### View more area assignments Cards show up to **8 area badges** at once. When a type has more assignments, a **+N more** badge appears in place of the rest. Hover your mouse over the card to expand it in place and reveal the full list of areas — no need to leave the page. ### Area access Badges for areas you don't have access to are shown in a muted state and can't be opened or selected. You can still see them so it's clear where a reference data file exists, but only areas you're assigned to are actionable. ### Select individual badges Each area badge has two parts: the **emoji/icon** on the left and the **area name** on the right. Click the emoji side of a badge to select or unselect just that one badge — it shows a checkmark while selected. Click the area name to open that file instead (see [Open and edit a file](#open-and-edit-a-file)). Selecting even a single badge activates the selection action bar in the toolbar, with **Download**, **Delete**, and **Clear** — see [Select and download](#select-and-download). ### Select all areas on a card Clicking anywhere on a card — outside of a specific area badge — automatically selects every badge on that card you have access to. Click the card again to deselect them all. This is a shortcut for selecting every area at once instead of toggling each badge individually. ## Create a new reference data upload Click the **New reference** button in the top-right of the toolbar to open the upload dialog. Select an existing reference data name from the combobox to add another area file to that grouping, or type a new name to create a new reference data type. Reusing an existing name keeps files under one card on the page. Set the upload parameters: * **File** — select a CSV file containing your reference data. * **Encoding** — choose the character encoding (e.g., UTF-8). * **Delimiter** — select the column separator (comma, semicolon, tab, etc.). * **Area** — choose which area this reference data applies to. Pick **Default** to create the fallback file. Continue to the review step to preview the parsed rows and confirm the columns look correct. If the file should update existing entries instead of replacing them, configure the **delta** section and pick a **unique field** — the column that identifies each row across uploads. Confirm the upload. The new file appears as a badge on the matching card. ## Open and edit a file Click any area badge on a card to open that file in the editable drawer. In the drawer you can: * **Search** for specific values across all columns. * **Add** new rows manually. * **Edit** existing values inline. * **Delete** rows that are no longer needed. ### Preview reference data (read-only) If your user group has **Viewer** access to Company Settings data, or you don't have access to the file's area, the drawer opens in **read-only preview** mode instead. You can still search and browse every row, but **Add row**, inline editing, and row deletion are unavailable. This is useful for giving auditors or team leads visibility into your reference data without letting them change it. ## Select and download Select badges individually (see [Select individual badges](#select-individual-badges)) or all at once by clicking the card (see [Select all areas on a card](#select-all-areas-on-a-card)). When you have one or more badges selected, a selection action bar appears in the toolbar with: * **Download** — export the selected files as CSVs. Each file is named by reference type and area. * **Delete** — remove the selected files. Not available if your access is read-only. * **Clear** — deselect everything. ## Delete reference data Select one or more files and click **Delete** in the selection action bar. A confirmation prompt is shown; this cannot be undone. Deleting reference data may affect extraction accuracy for requests that rely on those lookups. New requests will no longer have access to the deleted data for matching. ## Audit trail Click the **⋮** menu in the top-right of the page and select **View audit trail** to open a drawer with the history of changes made to reference data — uploads, edits, and deletions, along with who made each change and when. Use the drawer's controls to: * **Filter** by date range or action type. * **Expand a row** to see the full detail of what changed. * **Export CSV** to download the filtered results — the export only includes entries matching your current filters. ## Hiding columns from users Once a reference data set is linked to a field in Field Manager, users see it as a searchable dropdown in Flow — but not every column in your file is necessarily useful to show them. Use **Hidden columns**, in the **Reference Data** tab of the field editor, to pick which columns to hide from the dropdown options in Flow. Hidden columns are also excluded from search when users look up reference data in Flow. Hide anything that's only there to support lookups or matching in the background (like an internal ID) and isn't helpful for a user picking a value. Hiding a column only affects the field's dropdown in Flow. The column is still part of the file itself — when you [open the file](#open-and-edit-a-file) from the Reference Data page, search covers every column, hidden ones included. See [Reference data](/knowledge-base/administration/fields-manager/adding-fields#reference-data-tab) in the Field Manager guide for how to link reference data to a field and configure hidden columns. ## What's next * [Configure fields](/knowledge-base/administration/fields-manager) to control how reference data is used during extraction. # Two-factor authentication Source: https://knowledge.goautonomous.io/knowledge-base/administration/two-factor-authentication Add a second layer of security to your Go Autonomous account using an authenticator app. Two-factor authentication (2FA) protects your Go Autonomous account by requiring a 6-digit code from an authenticator app in addition to your password each time you sign in. When your organisation enables 2FA, every user is prompted to set up an authenticator app the next time they sign in. After enrollment, you'll be asked for a code from your app on every subsequent sign-in. Two-factor authentication only applies to users who sign in with email and password. If your organisation signs in through SSO, sign-in security is handled by your identity provider. ## What you need * An authenticator app installed on your phone or computer. Any TOTP-compatible app works, including: * Google Authenticator * Microsoft Authenticator * 1Password * Authy * A safe place to store your recovery codes (e.g. a password manager). ## Set up two-factor authentication The first time you sign in after your organisation enables 2FA, you'll be taken through a three-step enrollment flow. You cannot use Go Autonomous until enrollment is complete. Open your authenticator app and scan the QR code shown on screen. If you can't scan the code, copy the **authenticator key** displayed below the QR code and paste it into your app manually. Click **Continue** once your authenticator app shows a 6-digit code for Go Autonomous. Enter the current code from your authenticator app and click **Verify**. This proves that your app is set up correctly. If the code is rejected, double-check that you scanned the right QR code and that your device's clock is accurate — TOTP codes are time-based and will fail if your phone is more than a minute or two out of sync. Go Autonomous generates a set of one-time **recovery codes**. Save them somewhere safe — a password manager is ideal. You'll need a recovery code if you ever lose access to your authenticator app. Tick **I have saved these recovery codes in a safe place**, then click **Continue** to finish enrollment and enter the platform. Recovery codes are only shown once. If you lose them and lose access to your authenticator app, an administrator will need to reset your 2FA. ## Sign in with two-factor authentication Once you're enrolled, every sign-in includes one extra step: 1. Enter your email and password as usual. 2. On the **Two-factor authentication** screen, enter the 6-digit code from your authenticator app. 3. Click **Continue**. If you don't have access to your authenticator app, enter one of your **recovery codes** in the same field instead. Each recovery code can only be used once. ## Sign-in error messages If something goes wrong during sign-in, Go Autonomous shows the reason inline on the same screen you're on — no page reload, no separate error page. You'll see this on the standard login screen, the SSO login screen, and the two-factor code screen. Common examples: * **Wrong code or recovery code** on the two-factor screen — re-enter the current code from your authenticator app, or try another recovery code. * **Expired or reused code** — TOTP codes only work for about 30 seconds. Wait for your authenticator app to generate the next code and try again. * **SSO error after returning from the identity provider** — the message from the IdP (or a Go Autonomous-friendly rewrite of it, such as "your organization doesn't have a default user group set up yet") appears at the top of the login screen so you know exactly what to fix or who to ask. The banner stays visible until you correct the input and submit successfully. ## Lost your authenticator app If you've lost access to your authenticator app: 1. Try a **recovery code** at the two-factor sign-in step. Each code works once. 2. If you have no recovery codes left, contact your administrator for help regaining access. # User Settings Source: https://knowledge.goautonomous.io/knowledge-base/administration/user-settings Update your profile, change your password, and configure personal preferences from the User Settings menu. User Settings lets each user manage their own profile and personal preferences. It is individual to each user — changes here do not affect other members of your organisation. To open User Settings, click your name or avatar in the top-right corner of the navigation bar and select **User settings**. The dialog has two tabs: **Profile** and **Preferences**. *** ## Profile The Profile tab lets you update your personal details and change your password. **Name** — update your first and last name. Click **Save** to apply changes. The Save button is disabled until a change is made. **Email** — your email address is displayed here but cannot be edited directly. Contact your administrator if your email address needs to change. ### Change password Click the **Change password** link to expand the password change form. Enter your current password, then your new password twice to confirm. ### Two-factor authentication If your organisation requires two-factor authentication, you'll be prompted to enroll the next time you sign in. See [Two-factor authentication](/knowledge-base/administration/two-factor-authentication) for setup steps, sign-in instructions, and recovery options. *** ## Preferences The Preferences tab contains personal settings that control how the platform behaves for you. ### Email notifications Toggle **Product updates** on to receive email notifications about new Go Autonomous features and product releases. Toggle it off to unsubscribe. ### Date format Choose how dates are displayed across the platform. Options: | Option | Example | | - | - | | Default browser format | Uses your browser's regional setting | | MM/DD/YYYY | 04/20/2026 | | DD/MM/YYYY | 20/04/2026 | | YYYY/MM/DD | 2026/04/20 | Your selection applies immediately and persists across sessions. # Create and train custom intents Source: https://knowledge.goautonomous.io/knowledge-base/axon/create-custom-intents Build new intents with training descriptions and real email examples to handle classifications unique to your business. ## Overview Go Autonomous comes with a library of standard intents that cover common request types. But every business is different — you may receive request types that don't map neatly to the defaults. Custom intents let you create new classifications and train the AI to recognize them using descriptions and real email examples. ## Creating a custom intent In Axon, hover between items in the intent tree to reveal the **+ Add intent** line. Click it at the position where you want the new intent to appear. The category and subcategory are pre-populated based on where you clicked. Give your intent a clear, descriptive user-facing name — this is what your team sees in Workstation and Flow. For example: "Urgent Reorder" or "Sample Request." Enter a training prompt that describes what this intent looks like. This description acts as a guide for the AI model. Be specific about what makes this type of request different from others. Attach real email examples from Workstation as training data. The more representative examples you provide, the better the AI gets at recognizing this intent. Click **Save**. The new intent appears in the tree with editor mode active. Save again to persist the metadata (creator name, creation date). Good training descriptions are specific. Instead of "orders that are urgent," try "requests where the customer explicitly mentions a deadline, rush shipping, or uses words like 'urgent,' 'ASAP,' or 'expedite.'" ## Training with email examples Linking real emails to your custom intent is one of the most effective ways to improve classification accuracy. When you link an email: * The platform uses it as a positive example during classification. * Duplicate emails are automatically detected and prevented. * You can link emails from any request in Workstation — search by subject, sender, or content. ### How many examples do you need? There's no hard minimum, but more examples generally improve accuracy. Start with 5–10 representative emails that clearly match the intent. Over time, add more examples — especially edge cases that the AI initially misclassifies. ## Editing an existing intent To edit a custom or standard intent: In the intent tree, click on the intent name (not the checkbox). This opens the train/rename modal. Update the user-facing name or the training prompt as needed. Link additional email examples or remove ones that are no longer representative. Click **Save**. The "Last edited" metadata updates to reflect your changes. If you modify a standard intent's training data and later deactivate it, the custom training data is lost. The standard intent reverts to its original configuration if reactivated. ## What's next * [Deactivate and reactivate intents](/knowledge-base/axon/deactivate-intents) * [Navigate the intent tree](/knowledge-base/axon/intent-tree) # Deactivate and reactivate intents Source: https://knowledge.goautonomous.io/knowledge-base/axon/deactivate-intents Turn off intents you don't need and bring them back when things change. ## Overview Not every standard intent is relevant to your business. If certain intents are cluttering your workspace or causing misclassifications, you can deactivate them. Deactivated intents stop appearing in the classification dropdown for new emails, but historical data is preserved. ## Deactivating intents In the active intent tree, use the checkboxes to select the intents you want to turn off. When you select a category or subcategory, all nested items are automatically selected. Click the **Deactivate** button that appears. A confirmation dialog explains what will happen. Read the confirmation message carefully — it explains that deactivated intents won't be used for new emails but will remain on historical ones. Click **Confirm** to proceed. ## What happens when you deactivate an intent * **New emails** — the deactivated intent no longer appears in the classification dropdown. The AI won't classify new emails under this intent. * **Historical emails** — emails previously classified under this intent retain their labels. You can still view and search by these classifications. * **Custom intents** — if you deactivate a custom intent, it persists on historical emails but disappears from the dropdown for new ones. * **Standard intents** — if you modify a standard intent's training data before deactivating, that training data is lost. The intent reverts to defaults if reactivated. Deactivating an intent does not delete it. Historical data is always preserved. However, custom training data for standard intents is not recoverable after deactivation. ## Viewing deactivated intents Switch to the **Deactivated intents** tab to see all intents you've turned off. The list shows: * **Intent name** — the name of the deactivated intent. * **Original location** — the category and subcategory where it was positioned. * **Deactivation date** — when the intent was turned off. ## Reactivating intents Click the **Deactivated intents** tab at the top of Axon. Locate the intent in the list. Use search if you have many deactivated intents. Click the **Reactivate** button next to the intent. A modal opens asking you to select the category and subcategory where it should be placed. Select the target category and subcategory. The intent doesn't have to go back to its original location — you can place it wherever it fits best. Click **Confirm**. The intent is removed from the deactivated list and appears in the active tree at the selected position. Start by deactivating intents that consistently cause misclassifications. Reducing noise in the intent tree helps the AI focus on the classifications that matter to your business. ## What's next * [Create and train custom intents](/knowledge-base/axon/create-custom-intents) * [Navigate the intent tree](/knowledge-base/axon/intent-tree) # Import and export intents Source: https://knowledge.goautonomous.io/knowledge-base/axon/import-export-intents Move intents between organizations or back up your intent configuration by exporting to JSON and importing from JSON. ## Overview Axon lets you export your intent configuration to a JSON file and import intents from a JSON file. Use import and export to move intents between environments (for example from a sandbox to production), share a curated intent set across organizations, or keep a backup of your custom intents. ## Export intents You can export all of your active intents or a selected subset. Go to the **Active intent tree** tab. Tick the checkbox next to any intents you want to export. Leave everything unselected to export the full active tree. Use the export action in the toolbar. Axon downloads a file named `intents-export-.json`. The exported file is human-readable JSON. Each entry contains the intent id, its user-facing name, category placement, sort order, and deprecation state. ## Import intents Import replays a JSON file into your Axon configuration. Each intent in the file is compared against your current tree and gets one of three statuses: **new**, **overwrite**, or **skipped**. In Axon, open the import dialog from the toolbar on the **Active intent tree** tab. Drop a `.json` file into the dropzone, or click to browse. Only JSON files are accepted, and only one file per import. Click **Next**. Axon validates the file and shows a summary grouped by status: * **New** — the intent id does not exist yet and will be created. * **Overwrite** — an intent with the same id already exists and will be replaced. * **Skipped** — the entry could not be imported (for example, missing `intent_id` or invalid values). The reason is shown next to the row. If every row is skipped, the dialog offers a **Go back** button so you can fix the file and try again. Click **Import** to apply the changes. New intents appear in the tree, and overwritten intents pick up the values from the file. Overwrite replaces the existing intent's fields with the values from the file. Double-check the review step before confirming, especially when importing into production. ## File format The file must be a JSON array of intent objects. `intent_id` is mandatory — every other field is optional but recommended. ```json theme={null} [ { "intent_id": "request_simple_order", "frontend_name": "Simple order", "base_model_intent": "request_simple_order", "deprecation_status": false, "deprecation_date": "2099-12-31", "intent_type": "standard", "sort_order": 111101, "custom_first_level": "Request", "custom_second_level": "Order", "custom_third_level": "Order" } ] ``` Field reference: * **intent\_id** — unique identifier used to match against existing intents. Required. * **frontend\_name** — the user-facing name shown in Workstation and Flow. * **base\_model\_intent** — the underlying model intent this entry maps to. * **deprecation\_status** / **deprecation\_date** — whether the intent is deprecated and, if so, from when. * **intent\_type** — `standard` or `custom`. * **sort\_order** — position within the tree. * **custom\_first\_level** / **custom\_second\_level** / **custom\_third\_level** — category, subcategory, and intent labels used to place the intent in your tree. Export your current configuration first, then edit the JSON. That gives you a valid template with your own ids and category structure to work from. ## What's next * [Create and train custom intents](/knowledge-base/axon/create-custom-intents) for building intents from scratch inside Axon. * [Navigate the intent tree](/knowledge-base/axon/intent-tree) for organizing what you import. # Navigate and organize the intent tree Source: https://knowledge.goautonomous.io/knowledge-base/axon/intent-tree Understand the intent hierarchy and rearrange categories, subcategories, and intents with drag and drop. ## Overview The intent tree is the backbone of how Go Autonomous classifies incoming emails. It organizes your intents into a visual hierarchy of categories, subcategories, and individual intents. You can rearrange this hierarchy using drag and drop, create new categories and subcategories, and expand or collapse sections to focus on what matters. ## Understanding the hierarchy The tree has three levels: * **Categories** (Level 1) — broad groupings like Document, Request, Provision, Other. Each category shows the number of subcategories and intents it contains. * **Subcategories** (Level 2) — groupings within a category. For example, "Request" might contain subcategories like "Orders," "Quotes," and "Adjustments." * **Intents** (Level 3) — the specific classifications that the AI applies to incoming emails. These are the values you see in the **Identified type** column in Workstation. ## Expanding and collapsing Click the arrow next to any category or subcategory to expand or collapse it. This lets you drill into specific areas of the tree without being overwhelmed by the full list. Each collapsed category shows a summary count — for example, "Request — 9 subcategories · 56 intents" — so you can quickly see the scope of each area. ## Rearranging with drag and drop You can reorder categories, subcategories, and intents using drag and drop: Click and hold the drag handle (the dots icon on the left side of any row). Move the item to its new position. Collapsed categories and subcategories expand automatically when you hover over them during a drag. Release to place the item. Intents can only be dropped at the subcategory level — the platform shows an error toast if you try to drop at an invalid level. Changes enter editor mode automatically. Click **Save** to persist the new order, or **Discard** to undo. You can select multiple items using their checkboxes and drag them together. When you select a category or subcategory, all nested items are automatically included. ## Creating categories and subcategories Hover between any two items in the tree to reveal an **+ Create category** or **+ Create subcategory** button. Click it to open a modal where you enter the name. The new item appears at the insertion point with editor mode active. ## Editor mode When you make structural changes to the tree — rearranging, creating, or modifying — Axon enters editor mode. This is indicated by a visual change in the interface. In editor mode: * Changes are held in a draft state until you save. * Click **Save** to persist all changes. * Click **Discard** to throw away all unsaved changes and revert to the previous state. * Each item shows metadata: who last edited it and when. If you navigate away from Axon with unsaved changes, you'll be prompted to save or discard. Unsaved changes are lost if discarded. ## What's next * [Create and train custom intents](/knowledge-base/axon/create-custom-intents) * [Deactivate and reactivate intents](/knowledge-base/axon/deactivate-intents) # Axon overview Source: https://knowledge.goautonomous.io/knowledge-base/axon/overview Axon identifies, classifies, and tags every customer request — routing it to exactly the right place, instantly.

Axon

Identify, classify, and route every customer request to exactly the right place — instantly.

## What is Axon? In biology, an axon is the part of a nerve cell that transmits signals to exactly where they need to go. We named our engine after it for the same reason: Axon identifies, classifies, and tags every customer request to help you route it to the right place, instantly. ## Axon's vision Our vision for Axon is a triage layer for B2B growth. It understands and classifies your incoming emails and CRM cases, enabling you to fire each request to the right expert — and flags what's important, whether that's a high-margin quote, a VIP customer, or a churn risk. ## Capabilities **Real-time learning** — Axon introduces real-time learning capabilities that ensure your intent model continuously improves based on your guided interactions, so classification accuracy gets better over time at supercharged speeds. **Flexibility** — Make your intent structure suit your business. Create and train custom intents, giving you flexibility beyond our standard intent list. Organise intents into categories and subcategories that match how your business actually works. Drag, drop, and train intents to rearrange and rename to fit your terminology. **Empowering your team** — Administrators can configure intent logic directly, without waiting on our team for adjustments. ## The intent tree Axon organizes intents into a three-level hierarchy: 1. **Categories** — the top level (e.g., Document, Request, Provision, Other). 2. **Subcategories** — groups within a category (e.g., under Request: Orders, Quotes, Adjustments). 3. **Intents** — the specific classifications (e.g., Simple Order, Product Quote, Order Adjustment). The **Active intent tree** tab shows all your currently active intents with their hierarchy, along with counts for subcategories and intents at each level. ## Searching and filtering Use the search bar at the top of Axon to find any category, subcategory, or intent by name. The filter button next to the search bar lets you narrow the view further. ## Active vs. deactivated intents Axon has two tabs: * **Active intent tree** — all currently active intents, organized in their hierarchy. This is what the platform uses for classification. * **Deactivated intents** — intents that have been turned off. They no longer appear in the classification dropdown for new requests, but historical requests classified under these intents retain their labels. ## Included vs. Axon Premium | Functionality | Included | Premium | | - | :-: | :-: | | Rename intents to match your business terminology | ✓ | ✓ | | Add, edit, and delete categories and subcategories | ✓ | ✓ | | Move intents between categories and subcategories via drag and drop | ✓ | ✓ | | Deactivate and reactivate intents | ✓ | ✓ | | Standard model improvements via normal upgrade cycle | ✓ | ✓ | | [Tag requests with deterministic rules](/knowledge-base/axon/tags) | ✓ | ✓ | | Real-time customer-specific learning from every intent interaction in Flow | | ✓ | | Create custom intents specific to your business | | ✓ | | Edit and refine standard intent instruction prompts | | ✓ | | Link training data from Workstation to Axon to train intents | | ✓ | Axon's standard capabilities follow our normal model upgrade cycle — your experience improves automatically with each update. With Premium, you take ownership of your classification strategy, enabling real-time learning and intent instruction optimisation so first-time-right accuracy improves with every email your team processes. Interested in Axon Premium? Reach out to your Engagement Manager to learn more. ## What's happening with Intent Tags As part of this rollout, the **Intent Tags** functionality in the Tags page is being retired. Going forward, intent naming and organisation will live exclusively within Axon. ## What's next * [Navigate and organize the intent tree](/knowledge-base/axon/intent-tree) * [Create and train custom intents](/knowledge-base/axon/create-custom-intents) * [Deactivate and reactivate intents](/knowledge-base/axon/deactivate-intents) * [Tag emails with deterministic rules](/knowledge-base/axon/tags) # Tag requests with deterministic rules Source: https://knowledge.goautonomous.io/knowledge-base/axon/tags Create tag groups with custom rules that classify and route incoming requests based on mail content and captured field values. ## Overview The **Tags** page in Axon lets you classify incoming requests with deterministic, rule-based tags. Unlike intent classification, which uses AI, tags apply predictable rules that you define yourself. When a request matches a rule, Axon applies the tag. This gives you an exact, repeatable way to flag and route requests, for example marking those from a specific customer list or orders above a quantity threshold. Tags are organized into **tag groups**. A tag group defines where the tags apply (scope), which tags belong together, and how Axon picks a winner when several tags match. The Tags page is being rolled out gradually and may not be visible in your Axon side menu yet. Reach out to your Engagement Manager if you'd like access.