# 4. Case Manager Configuration
The four **Config** pages under Case Manager hold the settings behind case work. Administrators use them to choose which alert types are merged into cases and who the cases go to, set up alert assignment, maintain the prompts and model used by Agentic Workflows, and arrange teams into hierarchies. This chapter describes each page, field by field, as it appears on screen.
For
Administrators
In the menu
Fyscal ARCX → Case Manager → Config
Reading time
About 26 min
::: checks
- [Case Creation & Assignment: Active Configuration](#s-4-1): check how alerts are currently merged into cases and who receives them.
- [Edit the case creation configuration](#s-4-2): change alert types, groups and case assignment mappings.
- [Configuration History](#s-4-3): review earlier case creation configurations.
- [Alert Assignment](#s-4-4): set up how alerts are assigned to people.
- [Agentic Workflows: Prompt Config](#s-4-5): read the prompts and their revisions.
- [Edit and publish a prompt](#s-4-6): change a prompt and publish it as a new version.
- [Agentic Workflows: Model Config](#s-4-7): check, update or restore the model configuration.
- [Team Management: the hierarchy list](#s-4-8): find, filter and open hierarchy templates.
- [Add a hierarchy](#s-4-9): create a new hierarchy template.
- [View a hierarchy's details](#s-4-10): check a hierarchy's IDs, status and dates.
- [The hierarchy builder: Template Builder tab](#s-4-11): see the roles at each level of a hierarchy.
- [The hierarchy builder: Hierarchy Builder tab](#s-4-12): see the members at each depth as a chart.
:::
Open **Fyscal ARCX** in the sidebar, then **Case Manager**, then **Config**. Config lists four pages: **Case Creation & Assignment**, **Alert Assignment**, **Agentic Workflows** and **Team Management**. The sidebar shortens long names (for example *Case Creation …*, *Team Manage…*).
::: note
The breadcrumb under each page title differs from the sidebar path. Case Creation & Assignment and Alert Assignment show **Fyscal ARCX › Config › …**, Agentic Workflows shows **Fyscal ARCX › Agentic Workflows**, and Team Management shows **Fyscal ARCX › Case Manager › Config › Team Management**.
:::
## Case Creation & Assignment: Active Configuration {#s-4-1}
::path[Fyscal ARCX → Case Manager → Config → Case Creation & Assignment]
Controls
Which alert types become cases, how they are grouped, who receives the cases
Grouping key
Customer ID, case age and status (on-screen banner)
Example
Transaction Monitoring only; Group 1; Method Sequential
Check this page to see which alert types are turned into cases, how they are grouped and who the cases are assigned to. It shows the configuration that is currently **ACTIVE** for turning alerts into cases. It has three panels: **Merge Alerts to a Case**, **Alert Type Grouping** and **Auto Assignment of Cases**. The page opens on the **Active Configuration** tab, read-only, with an **Edit** button.
::figure[Case Creation & Assignment, Active Configuration tab: the active configuration's header, Merge Alerts to a Case, Alert Type Grouping (Group 1) and Auto Assignment of Cases.]{src="case-manager-config/01-case-creation-active.png" id="fig-case-manager-config-case-creation-active"}
::: legend
1. **Active Configuration** and **Configuration History** tabs. History is described in [Configuration History](#s-4-3).
2. The configuration header: the **ACTIVE** status, **Created At** (17 Sep 2026, 16:39:16 (+05:30) in the example), **Created By** (a staff member's name), and **Config version**, a unique ID (bb8448c2-ced2-45f8-8a52-9a825d3c6eaa) with a copy icon.
3. **Edit** opens the configuration for changes (see [Edit the case creation configuration](#s-4-2)).
4. **Merge Alerts to a Case**: the helper text reads "Select alert types for case creation". Two checkboxes: **Name Screening** (tag **NS**) and **Transaction Monitoring** (tag **TM**). In the example only Transaction Monitoring is ticked.
5. **Alert Type Grouping**: the information banner reads "Alert types in the same group will merge into a case based on customer ID, case age, and status." Each group is a card headed with its name (**Group 1**) and a tag (**1 Source**).
6. **Alert Types**: the alert types in the group. Group 1 holds **Transaction Monitoring TM**.
7. **Case age**: a slider with the value in a box to its right, in **days** (30 in the example). The label has an information icon.
8. **Case Status**: the case statuses set for the group, here **Escalated** and **Under Investigation**. The label has an information icon.
9. **Auto Assignment of Cases**: maps a group to people. The heading has an information icon.
10. **Group**: the group the mapping applies to (**Group 1**), followed by an arrow (→).
11. **Person**: the people the group maps to. Three names are shown as tags and the rest are counted in a **+2** tag.
12. **Method**: the assignment method, here **Sequential**. The label has an information icon.
:::
| Field | What it shows | Options or format seen |
| --- | --- | --- |
| Status | Whether this configuration is the one in effect | **ACTIVE** on this tab; past versions show **INACTIVE** in Configuration History |
| Created At | When the configuration was saved | 17 Sep 2026, 16:39:16 (+05:30) |
| Created By | The staff member shown as creator | A staff member's name |
| Config version | Unique ID of this configuration | A 36-character ID, with a copy icon |
| Merge Alerts to a Case | The alert types selected "for case creation" | Name Screening (NS), Transaction Monitoring (TM) |
| Alert Types (per group) | The alert types in the group | Name Screening NS, Transaction Monitoring TM |
| Case age (per group) | A number of days | Slider and value box, e.g. 30 days |
| Case Status (per group) | The case statuses set for the group | Escalated, Under Investigation in the example |
| Group (Auto Assignment) | The group a mapping applies to | Group 1 |
| Person (Auto Assignment) | The people the group is mapped to | Name tags, with a +N tag when more people are selected than are shown |
| Method (Auto Assignment) | How cases are distributed among the people | Sequential in the example |
::: note
The banner states what grouping is based on: customer ID, case age and status. The information icons beside **Case age**, **Case Status**, **Auto Assignment of Cases** and **Method** hold further help text. Hover over them to read it.
:::
#### How the three panels fit together
Alert raisedIts type is ticked under Merge Alerts to a Case
GroupAlert Types, Case age, Case Status
Merged into a caseBy customer ID, case age and status
AssignedGroup → Person, by Method (Sequential)
Diagram 4.1 — From alert to assigned case, as set on this page
Read the page from top to bottom. **Merge Alerts to a Case** picks the alert types that are turned into cases. Each **Alert Type Grouping** card says which of those types are merged together. **Auto Assignment of Cases** then maps each group to one or more people, with a **Method** for sharing the cases among them.
::: note AML context
Automatic grouping and assignment decide who sees an alert and when. Institutions usually document these rules, review changes to them, and check that work is shared so that no one reviews their own decisions.
:::
## Edit the case creation configuration {#s-4-2}
::path[Fyscal ARCX → Case Manager → Config → Case Creation & Assignment → Edit]
Use edit mode when you need to change which alerts become cases, how they are grouped or who receives the cases. Edit mode shows the same three panels with editable controls. The header line (status, Created At, Created By, Config version) stays at the top, and **Cancel** and **Save** appear at the bottom of the page.
::figure[Edit mode: removable tags, the Case age slider, Add Group, Add Mapping, and Cancel and Save at the bottom.]{src="case-manager-config/02-case-creation-edit.png" id="fig-case-manager-config-case-creation-edit"}
::: legend
1. Selected values are tags with a remove (×) mark: the group's Alert Types, Case Status values, the mapping's Group and each Person.
2. **Case age**: the slider and its value box (30 **days**).
3. **Add Group**, below the last group card. It is shown greyed out in [](#fig-case-manager-config-case-creation-edit).
4. **Add Mapping**, below the last Auto Assignment mapping.
5. **Cancel** and **Save**. **Save** is greyed out when edit mode opens.
:::
::: tip
Before you change the configuration:
- copy the **Config version** of the active configuration (copy icon in the header), so you can find it later in [Configuration History](#s-4-3);
- read the help behind the information icons beside **Case age**, **Case Status**, **Auto Assignment of Cases** and **Method**;
- change one thing at a time, then check the next cases created in [Case Manager → Cases](#s-3-1).
:::
::: step Open edit mode
On the **Active Configuration** tab, click **Edit** at the top right. The controls become editable and **Cancel** and **Save** appear at the bottom of the page.
:::
::: step Choose the alert types for case creation
Under **Merge Alerts to a Case**, tick or clear **Name Screening** and **Transaction Monitoring**.
:::
::: step Set up each group
In each group card, set **Alert Types** (click × on a tag to remove it, or open the field's list with the arrow at its right), move the **Case age** slider to the number of days you need, and set **Case Status** in the same way as Alert Types.
:::
::: step Add a group if needed
Click **Add Group** below the last group card to add a group.
:::
::: step Map groups to people
Under **Auto Assignment of Cases**, choose the **Group**, the **Person** or people, and the **Method**. Click **Add Mapping** to add another mapping.
:::
::: step Save or cancel
Click **Save** to keep your changes, or **Cancel** to leave edit mode without saving.
:::
## Configuration History {#s-4-3}
::path[Fyscal ARCX → Case Manager → Config → Case Creation & Assignment → Configuration History]
Use Configuration History to look back at earlier case creation configurations and open any of them read-only. The **Configuration History** tab lists the case creation configurations, newest first: the one that is **ACTIVE** and the earlier ones, which are **INACTIVE**. The example lists 72 configurations over 4 pages.
::figure[Configuration History: version IDs, ACTIVE and INACTIVE statuses, creation times, and pagination (Showing 1-20 of 72).]{src="case-manager-config/03-case-creation-history.png" id="fig-case-manager-config-case-creation-history"}
::: legend
1. The **Configuration History** tab.
2. **Configuration**: the configuration's version ID, with a copy icon.
3. **Status**: **ACTIVE** or **INACTIVE**.
4. **Created At**: date and time, e.g. 17 Sep 2026, 16:39.
5. **Created By**: a staff member's name.
6. The row count, e.g. **Showing 1-20 of 72**.
7. The page indicator (**Page 1 of 4**) with first, previous, next and last page buttons.
:::
| Status | Meaning as shown on screen |
| --- | --- |
| **ACTIVE** | The configuration shown on the Active Configuration tab. One row has this status. |
| **INACTIVE** | Every other configuration in the list. |
::: step Open an earlier configuration
Click a row. The **Configuration Details** dialog opens with the row's status (for example **INACTIVE**), **Config Version ID**, **Created At** (with seconds and time zone offset) and **Created By**, followed by the same three panels as the Active Configuration tab, read-only. [](#fig-case-manager-config-case-creation-history-details) shows configuration a9111850-22b7-4275-af80-7b12123ebeaa: Name Screening is ticked under Merge Alerts to a Case, and Group 1 holds Name Screening NS, with a Case age of 30 days and Case Status Escalated and Under Investigation.
::figure[Configuration Details for INACTIVE configuration a9111850: the status (1), the close button (2), Name Screening ticked (3) and Group 1 holding Name Screening NS (4)]{src="case-manager-config/04-case-creation-history-details.png" id="fig-case-manager-config-case-creation-history-details"}
:::
::: step Close the dialog
Click × at the top right of the dialog.
:::
## Alert Assignment {#s-4-4}
::path[Fyscal ARCX → Case Manager → Config → Alert Assignment]
Alert Assignment holds the settings for assigning alerts to people: the alert types it applies to, and for each mapping the people who receive the alerts and the method used to share them out. It works like [Case Creation & Assignment](#s-4-1): the page opens on the **Active Configuration** tab, read-only, with an **Edit** button, and earlier versions are listed on the **Configuration History** tab.
::figure[Alert Assignment, Active Configuration tab: the tabs (1), the configuration header (2), Edit (3), the Name Screening (4) and Transaction Monitoring (5) alert types, and Mapping 1 (6) with its Alert Types (7), Person (8) and Method (9)]{src="case-manager-config/05-alert-assignment-active.png" id="fig-case-manager-config-alert-assignment-active"}
::: legend
1. **Active Configuration** and **Configuration History** tabs.
2. The configuration header: **ACTIVE**, **Created At** (07 Oct 2026, 11:32:27 (+05:30) in the example), **Created By** (a staff member's name) and **Config version** (8c7e79b2-a825-4746-a6a5-e801ddda5a02) with a copy icon.
3. **Edit** opens the configuration for changes ([](#fig-case-manager-config-alert-assignment-edit)).
4. **Alert Types** ("Select alert types for alert assignment"): **Name Screening NS**, ticked in the example.
5. **Transaction Monitoring TM**, shown greyed out.
6. **Alert Assignment** ("Assign alerts to people, distributed by method", with an information icon) holds one card per mapping, here **Mapping 1**.
7. **Alert Types**: the alert types the mapping covers (**Name Screening NS**), followed by an arrow (→).
8. **Person**: the people who receive the alerts, shown as name tags (three in the example; names hidden in the figure).
9. **Method**: how alerts are shared among the people, here **Load Balance**. The label has an information icon.
:::
| Field | What it shows | Options or state seen |
| --- | --- | --- |
| Alert Types | The alert types the assignment applies to | Name Screening (NS); Transaction Monitoring (TM), greyed out |
| Alert Types (per mapping) | The alert types a mapping covers | Name Screening NS in the example |
| Person (per mapping) | The people who receive the alerts | Name tags |
| Method (per mapping) | How alerts are shared among the people | Load Balance in the example (Case Creation & Assignment shows Sequential) |
The **Configuration History** tab has the same columns as in [Configuration History](#s-4-3) ([](#fig-case-manager-config-case-creation-history)): **Configuration**, **Status**, **Created At** and **Created By**. The example lists 8 configurations: one **ACTIVE** and seven **INACTIVE**.
::figure[Alert Assignment in edit mode: the Name Screening checkbox (1), Transaction Monitoring greyed out (2), a removable tag (3), Add Mapping (4), and Cancel and Save (5)]{src="case-manager-config/06-alert-assignment-edit.png" id="fig-case-manager-config-alert-assignment-edit"}
::: legend
1. **Name Screening NS** can be ticked or cleared.
2. **Transaction Monitoring TM** stays greyed out in edit mode.
3. Selected values are tags with a remove (×) mark: the mapping's Alert Types and each Person.
4. **Add Mapping**, below the last mapping. It is shown greyed out in [](#fig-case-manager-config-alert-assignment-edit).
5. **Cancel** and **Save**. **Save** is greyed out when edit mode opens.
:::
::: step Open edit mode
On the **Active Configuration** tab, click **Edit**. The controls become editable and **Cancel** and **Save** appear at the bottom of the page.
:::
::: step Select the alert types
Under **Alert Types**, tick the alert types the assignment is for.
:::
::: step Set up each mapping
In each mapping card, set **Alert Types**, the **Person** or people (click × on a tag to remove it, or open the field's list with the arrow at its right) and the **Method**.
:::
::: step Save or cancel
Click **Save** to keep your changes, or **Cancel** to leave edit mode without saving.
:::
## Agentic Workflows: Prompt Config {#s-4-5}
::path[Fyscal ARCX → Case Manager → Config → Agentic Workflows → Prompt Config]
Prompts
Case Copilot, Name Screening Alert Summary, Transaction Monitoring Alert Summary
Use Prompt Config to read the prompts behind Case Copilot and the alert summaries, and to compare their revisions. Agentic Workflows has two tabs: **Prompt Config**, which holds the prompts, and **Model Config**, which holds the model configuration (see [Agentic Workflows: Model Config](#s-4-7)). Prompt Config shows one card per prompt.
::figure[Prompt Config: cards for Case Copilot, Name Screening Alert Summary and Transaction Monitoring Alert Summary.]{src="case-manager-config/07-agentic-prompt-config.png" id="fig-case-manager-config-agentic-prompt-config"}
::: legend
1. **Prompt Config** and **Model Config** tabs.
2. The prompt name.
3. The status (**Active**), the current version (e.g. **v2**), when it was published and how many revisions it has.
4. The prompt's description.
5. The arrow that opens the prompt.
:::
| Prompt | Status | Version | Published | Description shown on the card | Where its output appears |
| --- | --- | --- | --- | --- | --- |
| Case Copilot | Active | v2 | 22 Sept, 06:12 PM · 2 revisions | "Case Copilot: the shared persona, formatting rules and analysis rules for every copilot intent." | The **Case Copilot** panel on Case Details ([Case Copilot](#s-3-8)) |
| Name Screening Alert Summary | Active | v2 | 17 Aug, 07:39 PM · 2 revisions | "Summarises a name screening alert by comparing the customer against each watchlist match and judging whether they are the same identity." | The **AI Summary** card on a Name Screening alert ([Alert Details: Name Screening](#s-3-24)) |
| Transaction Monitoring Alert Summary | Active | v3 | 18 Aug, 02:16 PM · 3 revisions | "Summarises a transaction monitoring alert using the AMLC investigation framework, mapping activity to Suspicious Circumstance and Predicate Crime codes." | The **AI Summary** card on a Transaction Monitoring alert ([Alert Details: Transaction Monitoring](#s-3-25)); its footer reads *Prompt v3 · Model openai/gpt-oss-120b* |
::: step Open a prompt
Click a card. A panel opens on the right with the prompt's name, **Edit**, a close button (×), the revision navigator and the prompt sections. [](#fig-case-manager-config-agentic-prompt-panel) shows **Name Screening Alert Summary**.
::figure[The Name Screening Alert Summary panel: Edit, the revision navigator at v2 Active, Description, Task, and the collapsed Role and Expected Response (7 fields).]{src="case-manager-config/08-agentic-prompt-panel.png" id="fig-case-manager-config-agentic-prompt-panel"}
::: legend
1. **Edit** opens the prompt for editing (see [Edit and publish a prompt](#s-4-6)).
2. Previous revision.
3. The revision shown: version (**v2**), status (**Active**) and publish time (17 Aug, 07:39 PM). Click it to open the revision picker.
4. Next revision.
5. **DESCRIPTION**: what the prompt is for.
6. **TASK**: "Analyze this name screening alert and provide a structured summary."
7. **ROLE**, collapsed. Click to expand.
8. **EXPECTED RESPONSE (7 FIELDS)**, collapsed. Click to expand.
:::
:::
::: step Pick a revision
Click the revision in the navigator. A list opens with a search box (1) (*Find a version, e.g. 7*) and one row per version: **v2** (2) (marked **Active**, 17 Aug, 07:39 PM) and **v1** (3) (13 Aug, 03:02 PM). The footer (4) reads **7 of 7 loaded**. The arrows either side of the navigator are labelled **Previous revision** and **Next revision**.
::figure[The revision picker: the Find a version search (1), v2 Active (2), v1 (3) and the 7 of 7 loaded footer (4)]{src="case-manager-config/09-agentic-revision-picker.png" id="fig-case-manager-config-agentic-revision-picker"}
:::
::: step Read the Role
Click **ROLE** (1). For Name Screening Alert Summary v2, the Role opens with "You are a expert AML compliance analyst assistant." and then two lists. **INVESTIGATION RULES** (2) has eleven rules, starting with the tie-breaker priority "Name > Date of Birth > Nationality > Government ID > Place of Birth > Gender > Address". **DATA INTEGRITY RULES** (3) has two rules: "Use only supplied data. Never invent identifiers, allegations, or sources. If unknown, say "Unknown"" and "Every substantive claim must cite its source (watchlist record or customer data); output \[source: <field\_name>\] tags".
::figure[ROLE expanded (1) for Name Screening Alert Summary v2: Investigation Rules (2) and Data Integrity Rules (3)]{src="case-manager-config/10-agentic-prompt-role.png" id="fig-case-manager-config-agentic-prompt-role"}
:::
::: step Read the Expected Response
Click **EXPECTED RESPONSE (7 FIELDS)**, below the Role. It lists the fields of the response, with a **list** label on list fields, the allowed values where there are any, and a short description. For Name Screening Alert Summary v2 the fields are:
| Field | Type shown | Values or description shown |
| --- | --- | --- |
| verdict | (none shown) | likely\_true\_match, likely\_false\_match, inconclusive, insufficient\_data |
| one\_line\_summary | (none shown) | "max 10 words, very short verdict reason" |
| rationale | (none shown) | "2-3 sentence justification suitable for audit trail" |
| key\_findings | list | "3-5 bullet points of the most important findings across all matches" |
| identity\_comparison | list | "bullet points comparing key attributes: name, DOB, nationality, gender, address, ID — state customer vs watchlist values" |
| risks\_and\_gaps | list | "bullet points combining active risk flags (PEP, sanctions, adverse categories) AND missing data that limits analysis — keep concise" |
| recommended\_action | (none shown) | "specific recommended next step for the analyst" |
:::
::: step Close the panel
Click × at the top right of the panel.
:::
::: note AML context
Prompts and models shape what the AI features tell analysts. Treat a prompt or model change like any other change to a control: record why it was made, keep the earlier versions, and check the output on a few alerts before relying on it. The analyst still records the disposition.
:::
## Edit and publish a prompt {#s-4-6}
::path[Fyscal ARCX → Case Manager → Config → Agentic Workflows → Prompt Config → (prompt) → Edit]
Edit a prompt when you need to change its Description, Task or Role; publishing creates a new version. Clicking **Edit** in a prompt panel switches the panel to an edit form. A banner states which version you are editing from and which version publishing creates, for example "Editing from v2 · publishing creates v3".
::figure[Editing Name Screening Alert Summary: the version banner, Description (136/500), Task and Role, with Cancel and Publish v3.]{src="case-manager-config/11-agentic-prompt-edit.png" id="fig-case-manager-config-agentic-prompt-edit"}
::: legend
1. The version banner: "Editing from v2 · publishing creates v3".
2. **Description** with its character counter at the right (136/500).
3. **Task**.
4. **Role**.
5. **Cancel** and **Publish v3**.
:::
| Field | Helper text on screen | Required | Format |
| --- | --- | --- | --- |
| Description | what the purpose is for | Yes (\*) | Text, with a counter out of 500 characters |
| Task | one instruction | Yes (\*) | Text |
| Role | persona and rules | Yes (\*) | Multi-line text; the rules are written as lines starting with "-" |
::: step Open the prompt for editing
Open the prompt's card on **Prompt Config**, then click **Edit**.
:::
::: step Change the text
Edit **Description**, **Task** and **Role**. Watch the Description counter, which shows the length against 500.
:::
::: step Publish or cancel
Click **Publish v3** (the button names the version that will be created), or **Cancel** to leave the form without publishing.
:::
::: note
The edit form holds Description, Task and Role only. The Expected Response fields are not part of the form.
:::
## Agentic Workflows: Model Config {#s-4-7}
::path[Fyscal ARCX → Case Manager → Config → Agentic Workflows → Model Config]
Use Model Config to see which model configuration is active, to update it, or to restore an earlier one. The **Model Config** tab shows the active model configuration at the top and the earlier ones under **Previous configurations**.
::figure[Model Config: the Active configuration openai/gpt-oss-120b v3, Edit model, and Previous configurations with Restore.]{src="case-manager-config/12-agentic-model-config.png" id="fig-case-manager-config-agentic-model-config"}
::: legend
1. **Prompt Config** and **Model Config** tabs.
2. The active configuration: **Active**, the model name (**openai/gpt-oss-120b**), **API key** (masked on screen), **Version** (v3), **Temperature** (1) and **Published At** (18 Aug, 10:52 AM).
3. **Edit model** opens the **Update model** dialog.
4. **Previous configurations**: a table of earlier configurations.
5. **Restore**, one per row.
6. **Rows per page** (20), the page indicator and page buttons. The count reads **Showing 1-3 of 3**.
:::
| Column | What it shows | Example |
| --- | --- | --- |
| Model | The model name | openai/gpt-oss-120b |
| Version | The configuration's version label | v2, v1 |
| Status | The configuration's status | Inactive |
| Temperature | The temperature value | 0.2 |
| Published On | When the configuration was published | Aug 13, 2026 03:26 PM |
| Actions | Row action | Restore |
| Status | Where it appears |
| --- | --- |
| **Active** | The configuration at the top of the tab |
| **Inactive** | The rows under Previous configurations |
::: step Open Update model
Click **Edit model**. The **Update model** dialog opens with the text "Saving publishes a new configuration and retires the current one. The API key cannot be read back, so enter it again." **Model**, **Version** and **Temperature** show the current values (openai/gpt-oss-120b, v3, 1 (Creative)). **Agent Key** is empty.
::figure[Update model: Model (1), Version (2), Temperature (3), Agent Key (4), and Cancel and Update (5)]{src="case-manager-config/13-agentic-update-model.png" id="fig-case-manager-config-agentic-update-model"}
| Field | Helper text on screen | Required | Options or format |
| --- | --- | --- | --- |
| Model (1) | "Give your model a readable, unique name, like openai/gpt-oss-120b. This is how it will display for configuration." | Yes (\*) | Text |
| Version (2) | "Your own label for this configuration. Free text." | Yes (\*) | Text |
| Temperature (3) | (none) | No | 0.2 (Server default), 0.5 (Slightly varied wording), 0.7 (Varied), 1 (Creative) |
| Agent Key (4) | "Stored encrypted. It is never displayed again after saving." | Yes (\*) | Secret text; placeholder "Secret key used to call the agent"; an eye icon at the right of the field |
:::
::: step Complete the fields
Check or change **Model** and **Version**, choose a **Temperature**, and enter the **Agent Key**. The dialog states that the key cannot be read back, so it must be entered each time.
:::
::: step Update or cancel
Click **Update** (5). As the dialog states, saving publishes a new configuration and retires the current one. Click **Cancel** or × to close the dialog without saving.
:::
::: note
The active configuration labels the secret **API key** and the Update model dialog labels it **Agent Key**.
:::
The new configuration becomes the **Active** one at the top of the tab, and the one it replaces is listed under **Previous configurations** with the status **Inactive**.
## Team Management: the hierarchy list {#s-4-8}
::path[Fyscal ARCX → Case Manager → Config → Team Management]
Team Management lists the hierarchy templates. From here you add a hierarchy, view its details, and open the builder where its roles and members are arranged. A warning sits at the top of the page: "Changing these values may impact system stability. Proceed only if you understand the configuration."
::figure[Team Management: + Add Hierarchy (1), the warning (2), the search box (3), Show Filters (4) and the list columns, ending with Actions (5)]{src="case-manager-config/14-team-management-list.png" id="fig-case-manager-config-team-management-list"}
::: legend
1. **+ Add Hierarchy** opens the **Add New Hierarchy Template** dialog (see [Add a hierarchy](#s-4-9)).
2. The **Warning** banner.
3. The search box: *Search by template ID or name*.
4. **Show Filters** shows the Status filter. The button then reads **Hide Filters**.
5. The columns, ending with **Actions**, where each row has a ⋮ menu.
:::
| Column | What it shows | Example |
| --- | --- | --- |
| ID | The hierarchy's numeric ID | 4 |
| Name | The hierarchy's name | AML Hierarchy |
| Created By | The staff member who created it | A staff member's name |
| Status | The hierarchy's status | Active, Inactive or Removed |
| Created At | When it was created | Mar 31, 2026 01:59 PM |
| Updated At | When it was last updated | Mar 31, 2026 01:59 PM |
| Actions | A ⋮ menu | Edit, View, Hierarchy Builder |
Below the list: the row count (for example **Showing 1-20 of 89**), **Rows per page** (20), the page indicator (**Page 1 of 5**) and first, previous, next and last page buttons. The list is ordered by ID, highest first, so the example **AML Hierarchy** (ID 4) is on the last page.
| Status | Meaning as shown on screen |
| --- | --- |
| **Active** | Shown in green. Also the default Status for a new hierarchy. |
| **Inactive** | Shown in red. Can be chosen when adding a hierarchy. |
| **Removed** | Shown in blue. Available as a filter value. |
::: step Find a hierarchy
Type a template ID or name into **Search by template ID or name**.
:::
::: step Filter by status
Click **Show Filters**; the button now reads **Hide Filters** (1). A **Status** filter appears above the list. Open **Select Status** (2) and choose **Active**, **Inactive** or **Removed** (3). Click **Hide Filters** to hide the filter again.
::figure[Filters shown: Hide Filters (1), the Status filter (2) and its list, Active, Inactive and Removed (3)]{src="case-manager-config/15-team-management-status-filter.png" id="fig-case-manager-config-team-management-status-filter"}
:::
::: step Open a row's actions
Click ⋮ (1) in the **Actions** column. The **Actions** menu lists **Edit** (2), **View** (3) and **Hierarchy Builder** (4).
::figure[A row's ⋮ button (1) and its Actions menu: Edit (2), View (3) and Hierarchy Builder (4)]{src="case-manager-config/16-team-management-row-actions.png" id="fig-case-manager-config-team-management-row-actions"}
:::
## Add a hierarchy {#s-4-9}
::path[Fyscal ARCX → Case Manager → Config → Team Management → + Add Hierarchy]
Use this dialog when you need a new hierarchy template. **+ Add Hierarchy** opens the **Add New Hierarchy Template** dialog: "Create a new hierarchy template to define organizational structures."
::figure[Add New Hierarchy Template: Name (1), Status (2), Description (3), and Cancel and Add (4)]{src="case-manager-config/17-team-management-add-hierarchy.png" id="fig-case-manager-config-team-management-add-hierarchy"}
| # | Field | What it expects | Required | Options or format |
| --- | --- | --- | --- | --- |
| 1 | Name | The hierarchy's name | Yes (\*) | Text; placeholder "e.g. Sales Regional Hierarchy" |
| 2 | Status | The hierarchy's status | No | Active (default), Inactive |
| 3 | Description | A description of the hierarchy | No | Multi-line text; placeholder "e.g. Standard template for multi-level sales team reporting" |
| 4 | Cancel / Add | Close without saving, or add the hierarchy | – | **Add** is greyed out when the dialog opens empty |
::: step Open the dialog
Click **+ Add Hierarchy** at the top right of Team Management.
:::
::: step Complete the form
Enter a **Name**, leave **Status** at **Active** or choose **Inactive**, and add a **Description** if you need one.
:::
::: step Add or cancel
Click **Add**, or **Cancel** or × to close the dialog without adding.
:::
## View a hierarchy's details {#s-4-10}
::path[Fyscal ARCX → Case Manager → Config → Team Management → ⋮ → View]
Open a hierarchy's details to check its IDs, description, status and dates without changing anything. Choose **View** from a row's Actions menu. A details dialog opens, titled **View API Key** (1), with a two-column table (**Name**, **Value**) and a **Close** button. [](#fig-case-manager-config-team-management-view) shows the details of **AML Hierarchy**, ID 4.
::figure[Details of AML Hierarchy (ID 4): the dialog title (1), the template ID in the row labelled User ID (2), Created By shown as a number (3) and Close (4)]{src="case-manager-config/18-team-management-view.png" id="fig-case-manager-config-team-management-view"}
| Row label | What it shows | Example (AML Hierarchy) |
| --- | --- | --- |
| ID | The numeric ID from the list | 4 |
| User ID (2) | The hierarchy's template ID | tmpl\_d75oblt740mc7129kdf0 |
| Name | The hierarchy's name | AML Hierarchy |
| Description | The description entered for it | Hierarchy that drives the AML team |
| Created By (3) | A number (the list shows a name in this column) | 8 |
| Status | The hierarchy's status | Active |
| Created At | When it was created | Mar 31, 2026 01:59 PM |
| Updated At | When it was last updated | Mar 31, 2026 01:59 PM |
Click **Close** (4) or × to close the dialog.
## The hierarchy builder: Template Builder tab {#s-4-11}
::path[Fyscal ARCX → Case Manager → Config → Team Management → ⋮ → Hierarchy Builder → Template Builder]
Use the Template Builder tab to see which roles a hierarchy has and the level each role sits at. Choosing **Hierarchy Builder** from a row's Actions menu opens the builder for that hierarchy. The builder has two tabs, **Template Builder** and **Hierarchy Builder**. The Template Builder tab is headed **Hierarchy Template Builder**: "Create a template, assign roles, and arrange their hierarchy levels."
::figure[Template Builder for AML Hierarchy: the tabs (1), Template Configuration (2), Available Roles with its search (3), and Hierarchy Levels marked Persisted Hierarchy (Read-only) with L0 AML Admin to L3 AML Analyst (4); the level list scrolls, so L3 is partly hidden]{src="case-manager-config/19-team-management-template-builder.png" id="fig-case-manager-config-team-management-template-builder"}
::: legend
1. The **Template Builder** and **Hierarchy Builder** tabs.
2. **Template Configuration**: **TEMPLATE NAME**, here **AML Hierarchy**.
3. **Available Roles** ("Click a role to assign it"): a *Search roles...* box and the role list. For AML Hierarchy the list shows *No matching roles found.*
4. **Hierarchy Levels**, tagged **Persisted Hierarchy (Read-only)** with the text "Structure is locked and cannot be changed". Each level is a row with a drag handle, the level (L0 to L3), the role, and a greyed-out × at the right.
:::
| Level | Role (Template Builder) | Depth card (Hierarchy Builder) |
| --- | --- | --- |
| L0 | AML Admin | Depth 0, AML ADMIN, 4 Members |
| L1 | AML Team Lead | Depth 1, AML TEAM LEAD, 7 Members |
| L2 | AML Supervisor | Depth 2, AML SUPERVISOR, 6 Members |
| L3 | AML Analyst | Depth 3, AML ANALYST, 2 Members |
## The hierarchy builder: Hierarchy Builder tab {#s-4-12}
::path[Fyscal ARCX → Case Manager → Config → Team Management → ⋮ → Hierarchy Builder → Hierarchy Builder]
Use the Hierarchy Builder tab to see who belongs to each depth of the hierarchy and how the members are connected. The **Hierarchy Builder** tab shows the hierarchy as a chart on a canvas. Each person is a card labelled with their role (for example AML ADMIN, AML TEAM LEAD) and their name, and lines connect each card to the cards at the next depth below it. On this tab the sidebar is shown as a narrow icon rail.
::figure[Hierarchy Builder for AML Hierarchy: the tabs (1), the depth panel (2), the person-and-plus button (3), Save (4) and the zoom controls at 50% (5); member names hidden]{src="case-manager-config/20-team-management-hierarchy-builder.png" id="fig-case-manager-config-team-management-hierarchy-builder"}
::: legend
1. The **Template Builder** and **Hierarchy Builder** tabs.
2. The depth panel: one card per depth (**Depth 0** AML ADMIN, **Depth 1** AML TEAM LEAD, **Depth 2** AML SUPERVISOR, **Depth 3** AML ANALYST), each with its member count and member initials.
3. A button with a person-and-plus icon on the Depth 0 card.
4. **Save**, at the top right. It is shown greyed out in [](#fig-case-manager-config-team-management-hierarchy-builder).
5. Zoom out, the zoom level (**50%** when the tab opens) and zoom in.
:::