Arveo Flex Client Documentation

Open Arveo Shell using the address supplied by your administrator and sign in with your own account. Open Flex Client from the Shell dashboard. The application runs inside Shell; a bookmark must use the Shell entry point. If authentication expires, sign in again through Shell. Before repeating a failed save, reload and check whether the change was already persisted.

A normal user sees only visible scenarios with an explicit scenario-access grant. Direct links require the same grant. Access alone does not permit reading records, documents or content: actions have independent grants and must also be enabled in configuration. Administrators can configure all scenarios but receive no automatic scenario grants. Repository authorization still applies independently. Ask your administrator when access is denied; do not repeatedly submit an action.

Columns, details and create/update fields may have independent visibility and editability rules. Hidden fields do not appear; visible restricted fields are read-only. A form cannot submit if a required restricted field cannot be satisfied. Navigation refreshes permissions. If permissions change, protected views disappear and further unauthorized submissions are blocked; unsaved input is retained only in memory. An ECR denial preserves input and does not remove the Flex grant.

Select English or Deutsch with the dashboard language selector. Scenario names, descriptions, category labels and field labels use the configured translations, falling back to the default text when a translation is missing. Open a scenario from a card or list row. To read a long description in full, hover over a scenario card or list row for one second. Keyboard focus on the scenario title opens the same enlarged preview. Move into the preview to scroll or select its text; press Escape to close it. Use the breadcrumb to return to the dashboard or to the parent record. Hidden scenarios are not available through ordinary navigation.

Use the dashboard search and card/list view controls to find scenarios, and mark favorites for quick access. When your administrator uses tree presentation, choose a category in the sidebar to narrow navigation. Flat presentation does not use that category hierarchy. Scroll within the scenario card or list area to reach more scenarios. The dashboard heading, search, view controls, pagination and language footer remain visible. Favorites and long category trees have their own scroll areas. Optional scenario icons and categories help navigation; neither changes document membership or grants repository access.

Scenario icons are chosen by the administrator. When no supported icon is configured, the dashboard shows the scenario’s initial instead.

If dashboard preferences cannot be restored, use Retry loading preferences. Changes remain pending until restoration succeeds, so they do not replace preferences that could not be loaded. If saving fails, use Retry saving dashboard preferences. A warning means the latest choices are not confirmed as saved; it does not prevent opening a scenario.

A one-stage scenario opens a document list. A two-stage scenario first opens a record list; selecting a record opens its documents. The selected record scopes child searches and creation. Confirm the parent before modifying documents.

A Simple Document scenario opens one list directly. There is no parent-selection step. The list contains the permitted items of the configured type; its displayed title and fields are chosen by your administrator.

Example: to inspect an invoice, search for its number, select the matching row, check Details, then open Viewer. If a filter hides the saved item, clear that filter before assuming the save failed.

The sidebar shows Documents in a Simple Document scenario. When your administrator enables Recycle Bin and grants access, Recycle Bin opens trashed documents directly. Record scenarios also provide Records and nested Records/Documents destinations in Recycle Bin. Breadcrumbs above the workspace show the scenario and current destination and let you return to an ancestor. Table headings distinguish Documents, Records, Trashed Documents and Trashed Records; these labels follow the selected language. When a search includes trashed items, a muted row tint and a narrow status column identify them. The header reserves the same space as each row, so business values stay aligned whether an item is active or trashed.

A Record scenario first opens the record list. Selecting a record then opens a different list containing its related documents. Search and sorting apply to the stage currently on screen.

In an m:n scenario, the same document can appear under several records with the same identity. The selected record’s document filters, counts and pages are evaluated within its membership; the separate flat document view is not evidence that a document belongs to a particular record. Records without links display an empty list. See Share documents between records (m:n) for sharing, creation and removal instructions. Sharing does not copy the document.

Record labels show only currently permitted metadata, falling back to the record ID. Recent-record history uses record IDs so saved descriptive labels cannot reveal fields that are now hidden.

Parent record actions and child document actions are separate. The record summary card’s three-dot menu offers Edit, Delete and Trash for active records, or Restore and permanent Delete for trashed records, according to scenario settings and permissions. It uses the same confirmation workflows as the record list. Use the record list’s actions to create, edit, inspect history or delete a parent where offered. Use child actions for an individual document. Creating a record does not automatically create its documents. Changing parent metadata does not edit all children.

For a 1:n with foreign key scenario, before the deletion confirmation opens, the client counts the related documents using record-scoped document read permission. Cascade deletion requires record-scoped document delete permission; unlinking requires record-scoped document edit permission and permission to update the relationship field. All-document workspace grants do not substitute for these permissions. Check the count and whether those documents will be deleted or unlinked. If the count cannot be determined, the client reports an error and does not open the confirmation; retry after resolving the loading or access problem. Record deletion is blocked for m:n scenarios, regardless of the cascade setting.

Use the search fields offered by the scenario, choose a supported operator and enter a value of the displayed type. For example, search for a known document name, then clear the search to return to the complete permitted list. Sort using the available table headings; use paging to move through results. Configuration determines available columns, order and searchable fields.

When a field uses an administrator-configured lookup, select a permitted repository value from its dropdown instead of entering arbitrary text. Labels can combine several columns with ` — `; the filter uses the stored key, never the displayed label. Depending on its settings, the dropdown allows one or several selections and optional case-insensitive search. Multiple stored keys match with OR within that field; other active fields still narrow the query. When search is enabled, start typing and continue in the same input as the dropdown opens; opening it does not move focus to Retry. Typing searches the options without applying a document filter until a value is selected. Empty lookup search filters show the field name inside the input, matching the other search fields, rather than as a separate label above it. Multiple-selection dropdowns show checkboxes beside the matches and stay open when a value is selected or deselected. Click a row or use the arrow keys and Enter to toggle a value; press Escape or click outside to close the dropdown. While a selected key is being validated, the dropdown stays open and further checkbox changes are temporarily unavailable; continue selecting once validation finishes. Checkboxes reflect confirmed selections only. Changing visible matches preserves selections on other pages. Scroll through the matches to browse more records. Single- and multiple-selection dropdowns automatically load the next page when you reach the final 10% of the scroll range, without a Load more records button. If loading fails, use Retry to continue. Active lookup filters show the latest selected match in that input without extra search captions, repeated labels or selection-removal buttons. The green filter chips use the same configured display columns as the dropdown, including for restored selections; unresolved values fall back to their stored key. Use a chip’s × button to remove only that selected key: other selections and active fields remain applied, and the dropdown reflects the remaining selections. Removing the last key clears that lookup filter; Clear all removes all filters. Filtering still uses exact stored keys, not chip labels, even when several selections have the same label.

Select lookup values individually, including across pages; lookup-filter Select all is deferred to AFC-134 and is not available. Press Escape to close the dropdown and cancel its search. The search text clears, and reopening starts with unfiltered values. Committed selections and active filter chips remain. Replace the input text to start another query, or erase it to browse unfiltered values; editing the search text alone does not remove active filter chips.

Restored lookup selections resolve separately from dropdown search and paging. A value outside the visible page is not cleared. Unavailable or ambiguous saved selections and retry actions remain visible beside the lookup input when the dropdown is closed; the stored keys remain in the active chips. If the administrator changes a mapping or disables its filter, incompatible saved filter preferences are discarded before querying. If its source type disappears or is no longer a supported document/container type, the lookup control is omitted until the configuration can be repaired.

Lookup browsing and saved-value resolution also require access to a configured source scenario and permission to read its records or documents. All configured label, stored-value and dropdown search columns must be visible in that source’s Details and permitted for you. If access changes or a required column is hidden, the lookup cannot use another scenario to bypass that restriction in the matching active source. Keep existing selections and ask an administrator to check the source scenario and field visibility; an unavailable lookup is not proof that a saved value was deleted.

Select a row to open the document workspace. Choose Details to inspect metadata. Read-only fields cannot be changed and retain their stored values when other fields are saved. Dates, enumerations and references use their corresponding controls rather than arbitrary text. Not every configured field has a control in every view. There are no column-header filter controls or table CSV/ZIP export actions in this version.

To edit, open the existing item and use its edit action. Change writable fields and save. Metadata-only edits leave unchanged content intact. When replacing original content, check filename and MIME information before saving. A failed save is not proof that nothing was stored: reload the item before retrying.

Configured metadata lookups show a single-selection dropdown. Choose the displayed item; its stored key, not its label, is saved. A saved value outside the current page or dropdown search is resolved independently. Optional editable fields offer Clear selection; required fields still need a value, and read-only or permission-restricted fields cannot be changed through the dropdown.

Wait while selections load. Empty results do not mean that an existing value should be erased. If loading fails, keep the draft and use Retry. A confirmed unavailable selection remains visible: depending on the administrator’s policy, it is preserved or an editable field requires replacement before saving. An ambiguous/invalid selection is not resolved by choosing the first matching row. A temporary service failure is shown separately and does not silently clear data or turn into a removal.

In a strict one-to-many scenario, an administrator may enable choosing another parent. Creation starts with the selected record’s referenced key, which need not be its ID. If the parent field is editable and you have the required grant, select another parent and save. After a successful move, the original record’s document list refreshes and the moved document disappears from that list. Creation under another parent likewise does not add a row to the original parent’s list. A failed save retains your draft parent selection for retry; it does not change the persisted relationship. When the setting is disabled or the field is read-only, keep the existing parent. Many-to-many scenarios continue using their separate membership controls. Moving a held document also requires any additional permission configured for editing under litigation; enabling parent selection does not bypass that protection.

Trash and permanent deletion are different actions. Where the scenario enables the recycle bin, use Trash to retain an item for restoration. Selected documents can be trashed or restored together. For a record action, confirmation shows related items and, when configured, asks whether to include children. Restoring included children restores all trashed children, even those trashed earlier. Restoring a single document may first require restoring its parent; declining that parent restoration cancels the document action. Native repository cascades are automatic. A success notification confirms completed trash and restore actions. Partial or unconfirmed operations do not show a success notification; review the results and refresh the list before retrying.

Permanent deletion still requires its own confirmation and cannot be undone. For the existing active-record deletion workflow, one-to-many cascade deletion removes children; disabling it unlinks children, and mandatory foreign keys require cascade behavior. In m:n scenarios, use Remove from this record for membership removal. The recycle-bin feature remains in development; see the administration chapter’s development notice before relying on it. Cancel if scope is unclear.

Deleting an active record follows the same cascade/unlink policy with Recycle Bin on or off. The count includes all linked documents. If any child is trashed, restore it before choosing an unlink policy. Deleting children permanently needs the corresponding active-delete or trash-purge permissions. Individual document deletion from a record also works with Recycle Bin on or off and remains limited to that record. If an item changes between active and trashed during permanent deletion, execution stops; refresh and confirm the current state before trying again.

Permanently deleting a trashed record always deletes its trashed children first; active linked children must be moved to the recycle bin beforehand. Restore, Delete and Trash are separate actions. Restoring a parent through a native cascade can restore other trashed siblings too, including documents trashed independently. Read the total impact before confirming.

For bin deletion, enter the displayed name exactly, or DELETE for bulk/unnamed items. Restore needs no deletion phrase. Cancelling makes no changes. A failed or interrupted action may have completed some steps: refresh the list and inspect the items before starting again. Repository retention restrictions still apply.

Open Viewer in the document workspace. The client chooses the viewer from the selected content’s format, not from the scenario name. The same scenario can contain PDFs, images and text documents.

An original is a stored content element of the document. A rendition is another representation associated with an original, for example a PDF generated from another format. Renditions may be unavailable until repository processing finishes. They are not additional documents or historical versions.

When several configured elements are available, use the content selector above the viewer. Entries are grouped under their originals. The default element is chosen by the administrator and can be an original or a rendition. If only one element is available, there may be no selector. Check the selected entry before viewing or downloading.

There is no dedicated native Office, audio or video viewer in this client. A supported rendition may make such content viewable, for example a PDF rendition. HTML identified as text is shown as text rather than as an interactive webpage. Viewer display controls do not change stored content.

When history is enabled, open History. Select a historical version to inspect that version rather than the current document. Return to the current version before editing. Comments appear only where enabled and permitted; cancel an unfinished comment to discard it, or submit it and reopen history to check the saved result.

Historical selection is an inspection action; it does not restore or overwrite the current version. Record and document history are independently configured.

Recent records and saved views depend on scenario context and repository access. For removed or inaccessible records, return to the scenario and search again.

When a configuration administrator has no accessible visible scenarios, the dashboard explains that scenario access requires an explicit mapping and offers a configuration shortcut. Administration remains available. Your administrator can browse the permission catalog and configure access; no permissions are granted automatically.

In Record scenarios, Documents lists all scenario documents and a selected record lists only its linked documents. Administrators can configure these workspaces independently, so their columns, filters, details and permitted actions may differ. Each workspace remembers its own enabled table and search preferences. Content and version capabilities share the scenario’s document-type settings.

Sign in through Arveo Shell with a configuration-administrator account. Open Flex Client, then Open settings. Normal users cannot manage configuration. Repository access and configuration-administrator permissions are distinct; enabled scenario capabilities never override repository authorization.

Use the administration navigation to switch between Scenario configuration, Permission catalog, Categories and Localization. Scenario settings, category hierarchy/assignments and dashboard presentation share one configuration draft. Moving between these workspaces retains unsaved changes; it does not save them. Enter through the Shell client and use this navigation rather than bookmarking a nested administration URL.

Each administration page starts with a short explanation. Configuration cards describe their purpose and provide a direct action. Shared type settings distinguish global attribute availability from view-specific visibility; permission pages distinguish configuration defaults from individual rules. Expand How are these rules applied? for the rule explanation. The global Permission catalog shows discovery status separately from identity search and usage inspection.

Choose Scenario Configuration in the navigation to open the scenario list. Search by scenario name, title or type, filter by stage kind, or use Create, Import and Export all. Select a scenario to open its overview, which shows its description, identity, structure, types and visibility, plus Export, Duplicate and Delete. Use the Configuration and Permissions navigation cards or sidebar children to open the corresponding editor. The breadcrumb shows Dashboard, Scenario Configuration, the scenario title and the current section; ancestor links navigate back. Clicking the Scenario Configuration row opens the list and toggles its submenu. Clicking a scenario row opens its overview and toggles its children, closing other scenario branches. The chevron is part of the row. Clicking anywhere on a scenario card opens its overview. Cancelling an unsaved-change prompt preserves the current page and menu expansion. The Configuration sidebar contains General and View Configuration. Each grouping opens a landing page with links to its children. General contains Overview (naming, icon, dashboard and record management) and TypeDefinitions (record and document attributes, versions and content). One-stage scenarios omit record settings. View Configuration follows runtime navigation: Records contains Record search and Documents within a record; Documents configures direct document search. Select a screen area using its button or the example image to open its settings without deeper navigation. Breadcrumb ancestors return to their landing pages. The JSON preview is read-only; edit using structured controls or validated import. Export a backup before significant changes. Unsaved edits are retained between a scenario’s overview, Configuration and Permissions pages. Moving to another scenario or the scenario list asks you to save, revert or cancel when the current scenario is dirty. Import returns to the list, where Save all persists the shared draft; successful duplication opens the copy’s overview, and deleting the open scenario returns to the list.

The separate Categories workspace manages the category tree, scenario assignments and dashboard presentation. In scenario General settings, choose an optional semantic icon; it changes presentation only, not repository data or permissions.

A scenario is a configured entry point into repository data. Choose its structure before configuring its labels and views. The document and record types must already exist in the repository; this wizard does not create types or relationships.

For a Record scenario, the wizard offers 1:n with foreign key or m:n with shared documents. The latter uses a dedicated container-to-document relation, not a copied document or a document foreign key. Only compatible current-version-only relations with a unique endpoint-pair index and no required writable custom relationship attributes are selectable. If no compatible type is offered, ask the repository administrator to check those definitions.

The wizard identifies these choices as One-stage and Two-stage. This guide calls them Simple Document and Record scenarios. A record is the parent organizing the documents, not another content rendition.

After a new scenario is successfully saved, leaving administration requires no further save unless other configuration or localization edits remain unsaved.

Select the new scenario in the sidebar and work through its document settings. Start with a small set of useful fields, save, then test it as a normal user before making it visible to the wider audience.

Example: for invoices, expose invoice number and date in the list, add corresponding search fields, and organize writable metadata in a meaningful form section. Keep repository-maintained fields read-only. Enable download only for the content elements users need.

Configuration navigation stops at four editor pages: General → Overview for naming, icon and dashboard visibility; General → TypeDefinitions for document and record attributes, attribute lookups, content and versions; and View Configuration → Records and View Configuration → Documents for grouped view settings.

A Record scenario has shared record/document type settings and three independently configured runtime workspaces: Record Search View, Record Documents View, and Documents (all documents). View Configuration groups the record workspaces on the Records page and the all-document workspace on the Documents page. Documents inside a selected record can have different table columns, search filters, detail fields, action permissions and saved preferences from all documents.

Example: put case number and case title in the Record table and summary, and document name and document date in Document views. A case title label does not rename a child document field. Explain deletion policy to users before allowing parent deletion.

Overview settings are always expanded. Use General → Overview to set the localized title, description and dashboard visibility. Use General → TypeDefinitions to edit shared settings. The Record card appears first with Attributes, Versions and Attribute lookups; the Document card contains Attributes, Content, Versions and Attribute lookups. One-stage scenarios show only Document. Visibility controls navigation, not security. Each document workspace and the record search workspace have their own creation and editing switches in their Details editor. Disable these actions when they should not be exposed; repository authorization still applies. Deletion availability also depends on permissions, and the stored record-management policy determines the treatment of children. It does not override the m:n deletion safeguard. Existing cascade-deletion and parent-selection settings are retained when editing and saving other settings, but their toggles are not exposed in the configuration editor.

Choose a scenario icon from the icon picker in General → Overview. The icon is used in dashboard cards, favorites and list rows. Choose the default option to restore the scenario initial. Imported icon identifiers that are valid but unavailable in this client are retained and also display the initial; do not supply SVG markup or an image URL as an icon identifier.

The attribute matrix displays type information and mandatory, primary-key, read-only and unique metadata. These badges describe the repository contract. Enable available fields and preserve required writable fields when creation or editing is enabled. Do not try to make a repository read-only attribute editable.

After adding an attribute to a repository type definition, restart the client to load the updated definition. Existing configurations discover the field in their matrices while preserving authored settings. If you have unsaved administration edits, save or discard them before schema reconciliation completes. Review the new field’s availability and view settings, then save the scenario to publish it to runtime views. Discovery alone does not change the published configuration.

Localized text includes a default value and optional values per language. Use the localization drawer to supply translations. A field/view label override applies only where enabled; otherwise the normal configured label applies. Preview each supported language after saving.

Open General → TypeDefinitions and expand the Document Content or Versions section. Configure original and rendition labels, availability and independent download switches. Choose an available default content element or rendition. Annotation settings belong to the original and are shared by its renditions; default visibility must be disabled when annotations are disabled.

Optional filename and MIME attributes must reference writable string fields. If omitted, repository content metadata supplies the values. The primary upload populates configured filename/MIME fields; other content elements retain their own metadata. Editing the filename before submission also changes the primary content’s system name.

Enable version history and comments separately for document and record stages. These options control the client surfaces, not underlying permission grants.

For 1:n with foreign key scenarios, review the stored recordManagement.cascadeDeleteEnabled policy in a configuration export. With cascade enabled, deleting a parent deletes its documents first. Without it, the foreign key is cleared on the children; their metadata and stored content are retained. A mandatory foreign key forces cascade deletion. The deletion confirmation shows the related-document count and the configured delete or unlink consequence. If the count cannot be loaded, confirmation is blocked. Test the configured policy with a disposable record and explain this consequence to users before exposing record deletion.

For m:n with shared documents, the cascade setting is stored policy only: record deletion and global document deletion are unavailable. Membership removal preserves the document, even when its final membership is removed. This behavior is independent of the stored cascade setting.

Open View Configuration and choose Records or Documents. In Records, choose Record search or Documents within a record. Select Results table, Search filters, Details or the record-owned Record summary using the labelled buttons or highlighted screenshot areas. The selected settings open immediately; these selections do not add deeper navigation. Configure globally available attributes first, then their supported use in search, table, detail and create/edit views. Adjust order and labels with the provided controls. Only actual runtime consumers are customer features: a configuration field alone does not establish an available UI action.

The example screen stays visible beside the settings on wide screens and above them on smaller screens. Where your changes appear explains the runtime location, and the settings guidance explains availability, initial visibility, order and label overrides. Record summary settings belong to the record even though the summary appears beside its documents. Example screenshots are fixed English demo images; they do not reflect unsaved changes. Documents examples match the scenario layout: one-stage examples have no scenario side navigation, while two-stage examples retain it. Documents within a record use their own examples and settings. Use the area buttons if an image cannot load. Switching areas retains your draft; the footer reports unsaved changes until you choose Save.

Open Categories. Categories organize dashboard navigation; they do not create repository folders, move documents or grant permissions. Each category has a stable ID and a required default label, with optional translations. Renaming or translating a label does not change the ID or its assignments.

Deleting a category requires confirmation and removes its entire subtree from the draft. Scenarios assigned anywhere in that subtree become unassigned; the scenarios and repository data are not deleted. Save all to persist the removal. Back up the full configuration when assignments must be recoverable; a category-only export does not contain them.

Open Categories from the settings sidebar. Create root or child categories, configure their localized labels, and arrange their navigation order. Stable category identities are distinct from repository record identities; moving or assigning a scenario does not link documents to records.

Category and scenario translation keys use canonical language tags, matching language settings. Examples include de, de-DE, zh-Hans, en-001 and sr-Latn-RS. Incorrect casing, underscores and malformed or repeated subtags are rejected by configuration validation.

Assign scenarios to categories and choose Tree or Flat presentation. Tree presentation uses the authored category hierarchy; flat presentation keeps scenario navigation without that hierarchy. Save changes explicitly and check the dashboard as a normal user. Category and scenario changes share the configuration draft: preserve unsaved edits when switching workspaces, and resolve stale-save errors before retrying.

On first system startup, English and German UI catalogs are installed automatically from the packaged application; no translation-provider setup or manual import is required. The shipped scenario and category labels also include both languages. Later startups add newly shipped UI keys and update untouched shipped defaults while preserving administrator overrides and saved scenario/category configuration. Customer-authored text requires its own translations.

Open Localization from the administration navigation. Choose a catalog language, search by translation key or text, edit the translation and save. Enable a language for users only when it is suitable for your audience. Select the language on the dashboard and check both static UI text and scenario labels.

Editing a label’s default-language text also updates an inherited translation for that same language. Translations in other languages remain unchanged.

Missing text uses the default language. Scenario-owned labels and global UI translations are separate. An unsaved translated draft is not persisted by changing the runtime language. Translation generation, when offered, needs a configured available provider; review generated text before accepting overrides. This guide does not assume that a generation provider is installed.

Category labels belong to the shared configuration, not the global UI catalog. In Localization, edit the required raw default label separately from explicit translations for each language. Changing the catalog’s default language does not move or overwrite a category’s stored translation. Empty or whitespace-only category defaults block saving and must be corrected at the field. Label edits do not change IDs, hierarchy or scenario assignments.

Localization saves only resources with pending edits. If the shared configuration and catalog both have changes, configuration is saved first, followed by the catalog. A partial-success message means configuration was saved but catalog changes remain unsaved; correct the error and retry the remaining work. Saving configuration may include scenario, category or presentation edits retained from the other administration workspaces.

Reload is unavailable during a save. When shared configuration edits exist, its confirmation covers both localization and configuration: confirming discards retained scenario, category and presentation edits as well as localization changes. Cancel to keep those drafts.

Invalid references, duplicate scenario names or category IDs, blank category defaults, dangling category assignments, unavailable default content, inconsistent annotation switches, missing required fields and unsupported relationships prevent a save. Correct the indicated setting rather than removing validation.

A stale save is rejected when another administrator has changed the scenario or shared configuration being saved. Your draft is retained. Preserve a copy of the intended edits, explicitly reload the saved configuration and reapply necessary changes. Remember that a shared reload can discard edits from other administration workspaces. This version does not provide a conflict-specific merge interface. For authorization or session errors, sign in again through Shell and check current state before repeating writes.

Select a scenario and use the Configuration and Permissions navigation destinations. Both edit the same scenario draft. Permission drawers stage their changes separately until you choose Save; the page Save/Save all then persists the scenario draft. The Permissions overview groups scenario access, actions and field controls. Search by feature, attribute or criterion; filter explicit rules, configuration defaults, entries without grants or disabled targets. Grouped tables show Name, Allowed and Denied with the complete configured identity labels and a three-dot menu at the end of each row. Empty sections are hidden. These lists describe configuration, not a user’s effective access.

Edit permissions only in the scenario’s Permissions section. Configuration feature switches and view matrices contain no permission controls. Each permission row’s three-dot menu contains only Edit Permission, which opens the shared right-hand drawer. Browse one catalog, initially filtered to All, and select an identity; its dialog offers green Allow, red Deny, and Cancel. The wide drawer keeps the Allow and Deny lists prominent above the catalog, with a Remove button for every entry in either list. Any allow criterion may grant; any matching deny wins. Client roles retain their client identity, groups retain full paths, and claim values retain their type. Disabled features retain editable rules.

Configure the scenario-wide Configuration defaults rule above the permission tables. Edit its Allowed and Denied criteria using the same staged drawer. Configuration status is read-only text in the table. Choose No grants, Configuration defaults, or Explicit permission rule inside the editor. Rows using defaults show their resolved criteria, labelled as inherited, and follow changes to the shared rule. No grants always denies. Explicit rules remain independent. New scenarios start with every row using defaults and a shared Allowed criterion for realm role flex-admin, with no Denied criteria. Administrators can edit this initial rule; existing scenarios retain their saved settings. Previously omitted field rules show Existing configuration behavior; explicitly choose Configuration defaults to opt them into the shared rule. Without a default rule, inherited actions grant nothing and inherited fields retain their configuration behavior. An explicitly empty default rule denies.

For fields, table visibility, detail visibility, create visibility/editability and update visibility/editability are independent. Rules can only restrict existing schema/configuration availability and writability. Removing the final criterion from an explicit rule leaves an empty denying rule.

At the bottom of Permissions, Reset to factory defaults asks for confirmation, restores the shared Allowed criterion for realm role flex-admin, clears Denied criteria and all explicit row rules, and sets every row to Configuration defaults. Other scenario settings are preserved. Reset remains an unsaved draft change until page Save/Save all.

Select multiple rows across sections to add identities to all selected Allowed or Denied lists. Section selection affects only its visible rows; selected rows remain selected when filtering. Clear the selection explicitly or switch scenarios. Bulk additions merge into existing rules without duplicates or removals. Save in the drawer applies additions to the scenario draft; Cancel discards them.

Choose Validate Permissions for advisory checks of the current draft. Hints identify missing catalog identities, duplicates, identities present in both lists, obsolete field references, unavailable grants and missing access/viewing prerequisites. For example, annotation grants cannot enable content whose availability is disabled. Findings refresh after draft changes and link to the affected configuration. Checks do not simulate user memberships, block saving or automatically change rules.

A stale catalog warning retains existing selections. Deployment operators provision read-only discovery credentials and register selectable audiences and typed claim values. Administrators do not select criteria based only on their own identity. Imports reject unsupported new criteria, including deny rules; correct the complete mapping before saving.

Schema v2 exports include the scenario’s action rules and field overrides, with no discovery credentials, cached catalogs or current-user grants. Supported v2, v2 and v2 imports upgrade without generating grants. Existing scenarios without mappings deny access after migration: configure initial access and action mappings before rollout. Configuration administration does not automatically grant business access.

Open Permission catalog in administration navigation to browse all discovered realm roles, client roles and groups, independently of your own memberships. Search by role, client identifier or full group path and filter by category. Audiences and custom claims are registered by operators and are marked separately from Keycloak entries.

The page shows the last successful discovery and warns when its snapshot is stale. Reload catalog reloads the server snapshot; discovery retries occur at most every five minutes. If discovery has never succeeded, ask your operator to configure the dedicated read-only Keycloak discovery account. Existing choices and scenario mappings survive an outage. The inventory itself remains read-only. Each entry shows its number of configured occurrences, including unsaved changes and hidden scenarios. Identities referenced by scenarios but absent from the catalog are also shown as Missing from catalog. Absence from an unavailable or stale snapshot is unconfirmed.

Sort the catalogue by Source, Identity, Usage count or Status using the column headers. Open Usage details from an entry’s trailing three-dot menu to see each scenario, action or field/control and its Allowed/Denied disposition. Remove an individual occurrence to update the shared administration draft. Removing the final identity preserves the explicit empty rule; it does not restore field inheritance. Choose Save to persist the shared draft, or Discard changes to discard all unsaved administration changes, including changes made on other configuration pages. Navigation to a usage retains the draft. Validate Permissions checks all scenarios on this page.

To grant or deny access, open the scenario’s Permissions page and select catalog entries in the target’s drawer. Configure SCENARIO_ACCESS and the required action rules, then save the scenario. Configuration administration alone grants no scenario access. You can use administration even when the dashboard shows no scenarios. Navigation to the catalog retains unsaved configuration drafts.

The drawer header and Save/Cancel footer stay visible while the body scrolls. Save applies only its working copy to the scenario draft. Cancel, Escape and drawer dismissal discard drawer-only changes. Canceling the identity-choice dialog leaves the drawer draft intact. Save the scenario page to persist applied edits.

Select a permission name to open Affected UI. Choose a location to see its effect and, where useful, a highlighted screenshot. Use Zoom in for a larger, readable image. One rule can apply to several locations; changing the selected location does not create or edit a rule. Edit Permission opens the existing editor. The preview is independent of bulk-selection checkboxes and remains open when filtering the list. On smaller screens it appears above the tables. Close preview closes only the explanation.

The screenshots are static English examples. They do not show your exact configured fields, unsaved changes or a user’s effective access. Each field is identified by its actual target label; the image highlights a representative region. Read the conditions for related permissions and configuration requirements. Historical content shares content-view/download rules, while historical annotations cannot be edited. Unimplemented actions and effects without a useful screenshot are explained in text.

Select the Configuration defaults heading to inspect targets explicitly using the shared rule. An omitted field rule retains existing configuration behavior and is not an explicit defaults selection.

The Permissions tables contain independent targets for table visibility, detail visibility, create visibility/editability and update visibility/editability. Select targets across sections and choose bulk Allow or Deny to collect additions in the drawer. Save merges criteria, skips duplicates and retains unrelated controls. Bulk operations add only; remove existing criteria or return to defaults by editing an individual permission.

The scenario permission overview shows Configuration status. Search applies together with the selected filter. Configuration defaults includes explicit defaults selections and field controls retaining inherited configuration behavior; the visual defaults explanation lists only explicit consumers of the shared rule. Explicit empty rules deny access.

Choose Use configuration defaults inside a permission editor to stage an explicit selection of the shared scenario rule. Save applies that choice to the scenario draft; Cancel retains the previous rule. Visibility and editability remain independent. An omitted field rule retains existing configuration behavior, while an omitted action grants nothing.

The catalogue also discovers explicitly configured access-token audiences and hardcoded string, boolean or number claims from Keycloak clients and client scopes. Operator-registered criteria remain available. Dynamic claim mappers do not provide selectable values, and an empty group category can mean the realm has no groups. The catalogue does not show user memberships or automatically grant permissions.

The permission catalog scrolls continuously without pagination. Permission Identity precedes Source. Click a column heading to sort; the arrow shows its direction. Row three-dot menus open usage details.

Creation and update forms follow the selected workspace’s detail field order, section headings, labels and read-only settings. In two-stage scenarios, record-scoped documents and the all-documents view retain their independent table, search, detail and permission settings. Disabling a shared attribute removes it from both document workspaces. Stored column preferences cannot restore fields that the current permissions hide.

A permission change also applies when a drawer or confirmation was already open: a revoked action cannot be submitted. Configuration administration alone does not grant business actions. Restoring historical versions, CSV/ZIP export, column-header filtering controls and document summary cards remain unavailable; record summary cards are supported.

General Overview includes scenario-wide trash, trash-bin visibility and deletion-only-for-trashed settings. Search settings control whether each workspace offers Include trashed items in its table filter bar. The filter also requires the workspace’s Trash, View trashed items and Include trashed items in search permissions. Clearing it returns to active items only.

Recycle bin appears below Documents and above History in scenario navigation. Its Records and Documents entries open separate lists with their configured columns; the Documents list also includes trashed documents whose record is active. One-stage bins show Documents only. The breadcrumb returns to the scenario. Trashed items are read-only. Editors offer Move to recycle bin and permanent Delete only when the current state, permissions and deletion policy allow them. The record summary card uses a three-dot menu for the same state-sensitive Edit, Delete, Trash and Restore actions; Restore has a recovery icon. A narrow status column keeps trash markers aligned separately from business values. Permanent deletion from the bin requires typing the displayed item name, or DELETE for bulk operations and items without a display name. Record scenarios provide independent automatic/ask modes for trashing children, restoring children and restoring a document’s parent. Native repository cascades are identified as repository-managed and cannot be overridden. Existing disabled trash cascading preserves record-only behavior.

Confirmation shows affected counts and shared/global impact. When children are included in record restoration, all trashed children are restored, even those trashed earlier independently. Declining children applies the action to the record only; declining a required parent restoration cancels document restoration. Relationships are preserved. Each action still requires its scenario permissions. Bulk operations replace the journal; partial failures refresh repository state and can be acted on again using fresh confirmation, without progress/recovery controls.

The ECR CoreTeam decision on reading retained content and annotations while trashed is pending, for both current and historical versions. Retention alone does not guarantee read access. The original delivered ECR 28.1.0 returns Not found for these reads while trashed; the same reads succeed after restoration. Do not promise preview or download access while trashed until the supported contract is decided and verified against an original delivered ECR artifact. For now, use the authorized Restore workflow and verify access after restoration, as described in Downloads, unavailable content and historical viewing; scenario settings cannot override this repository limitation.

Repository retention and deletion restrictions are administered in the repository, not through scenario switches. No retention timeout does not mean trash is disabled. The effective inherited FK definition determines native CASCADE; type inheritance alone does not create a cascade. Native downward trash/restore cannot be overridden by a scenario or end-user decline. Restoring a document’s trashed parent may also restore its trashed siblings through that native cascade; review the complete count.

An imported legacy restore-cascade false becomes Ask; true or omitted becomes Automatic. Explicit modes take precedence. Saving or editing another mode preserves that choice; disabling trash cascading does not disable child restoration.

For active strict records, the delete/unlink confirmation covers every linked child, including trash. A cascade needs child Delete permissions for active items and Permanent delete plus View trashed items for trash. Unlink needs record-scoped Edit and an editable relationship field. Restore trashed children before unlinking. If trash is disabled, use an authorized enabled-bin scenario to resolve linked trash; disabling a feature does not grant purge access.

For a trashed record, permanent deletion always removes its linked trashed children first, regardless of the active-record cascade toggle. Active linked children block purge: trash them first. m:n record and global document irreversible deletion remain unavailable. This safeguard also applies when another scenario exposes the same shared type or attempts to cascade-delete it. Optional strict-FK unlink can still preserve those shared documents. Configuration deletion removes a scenario, not its repository data.

Deletion removes metadata irreversibly. Repository document purge additionally attempts immediate content cleanup; ordinary deletion can queue content cleanup. Retention, repository permissions or integrity rules may reject either operation. Separate child/parent mutations are not atomic. After partial failure, a lost response or changed scope, refresh and review actual state before confirming again.

Recycle Bin reuses the scenario’s existing view settings. Trashed records use the Records configuration. Trashed documents use the standalone Documents configuration, including in a Record scenario; they do not use Documents within a record. Changes to those views also apply in Recycle Bin. The configuration editor explains this inheritance beside the relevant settings. Recycle Bin retains separate permissions, trash-only searches and saved view preferences. There are no separate view configuration fields for trashed items.

General / Type definitions shows read-only repository feature badges beside each selected record or document type. These describe repository capabilities, not grants. The feature summary and its explanations are inside the collapsible Type-definition features section. Other help appears beneath the corresponding Attributes, Content or Versions table, keeping collapsed sections compact. Available in the shared attribute list makes a field eligible for scenario configuration; each view and permission rule can restrict it further. Use view-specific label changes only the label on that surface, leaving the repository attribute and other views unchanged. Separate Content help explains the default original/rendition, optional MIME/file-name mappings, availability, downloads and annotation permissions.

The overall Recycle Bin switch also preserves saved navigation, search and lifecycle options while disabling dependent editing. Its saved permissions remain intact. QA scenarios document their configuration and seed ownership in their descriptions. On the dashboard, hover over a scenario card or list row for one second, or focus its title with the keyboard, to read the full description in a scrollable enlarged card. Escape closes the preview.