Arveo Flex Client Documentation

The current Flex delivery target is 1.0.0; development artifacts are not a released 1.0.0 product. The following versions are declared deployment references, not independently proven minima or a complete certified production combination.

Freeze the production Workspace release and immutable delivery identities before release acceptance. No earliest compatible Workspace release has been established. The selected Download-Service support baseline is 13.1.0 for both ZIP and CSV; this is not evidence that every earlier release is incompatible. ECR 28.1.0 remains a contract-level candidate, while 28.2.0 is the exercised baseline. Complete installation and load acceptance remains required for the selected combination. See Installation and service dependencies and Flex capacity planning for deployment scope.

The integration contract defines separate version-1 filter and sorting envelopes. The v2. filter-context prefix is a preference-context format; it is neither configuration payload v4 nor an ECR product version. Link producers must support the exported configuration schema and the deployed Flex link contract explicitly. They cannot infer those capabilities from the Workspace or ECR version.

The deployed Flex version must provide authenticated configuration export and shared sorting before external applications rely on those features. No earliest released Flex version has been qualified for that combination. Saved links remain subject to current configuration, field permissions and repository state; they are not historical snapshots. Qualify login destination restoration and URL-length limits with the selected Workspace/gateway topology during installation acceptance.

The current Flex Client is not compatible without changes with the reviewed ECR 27.x releases. The assessment compared the released repository API contracts for 27.0.2, 27.1.2 and 27.2.2 with the calls required by the current client. It is a contract assessment, not an integrated runtime test on 27.x. LTS maintenance status does not guarantee that an older server provides APIs added in a later major release. Confirm the supported LTS minor and latest maintenance patch with the product supplier before planning an installation.

Supporting a customer installation on 27.x would require a separately implemented and validated compatibility path for type/system-field metadata and enumeration values, followed by testing with the exact LTS maintenance release. Presence of older CRUD or lifecycle APIs is insufficient to qualify that installation. Do not substitute empty system-field metadata or inferred permission/retention defaults to bypass the missing API. Existing production data and type definitions must remain valid under any proposed compatibility solution.

ZIP and CSV also need qualification of Download-Service 13.1.0 against the selected 27.x repository and identity setup. Successful exports against ECR 28.2.0 do not establish that cross-version service combination. Workspace and identity-provider compatibility must be checked independently of the ECR version.

On 12 November 2026, focused original-service tests passed with the following combination:

The checks exercised authenticated ZIP generation/download with exact original content comparison and CSV precheck/content/encoding/count in all three table contexts. They do not establish a lower compatible version, a complete browser save workflow or full product qualification.

Use the selected baselines until another combination has been qualified for the required features. Obtain the approved deployment artifacts and installation instructions through your delivery channel. Record the exact delivered versions and immutable artifact identities in the installation acceptance record.

For an older repository, assess mandatory metadata loading before testing individual features. Acceptance must then cover authentication and embedded navigation, repository operations and search, scenario permissions, configured lifecycle features, original/rendition access, and any enabled ZIP/CSV workflows.

Released ECR versions are listed in the public arveo documentation archive. Use the documentation for the exact installed version; an archive entry by itself is neither a Flex compatibility certification nor a current LTS support commitment.

Browsers access the public HTTPS Workspace and identity provider. Workspace needs private connectivity to Flex, Valkey and its identity dependencies. Flex needs its PostgreSQL database, ECR and identity discovery/signing keys, plus Download-Service when exports are enabled. Managed/external catalogue discovery needs the configured identity access. Download-Service needs repository access and delegated-user token exchange. ECR, conversion and workers additionally require the discovery, messaging and storage connectivity specified by their product installation guides. Do not expose private business-service listeners as alternate browser entry points.

Agree DNS, certificates and trust chains, issuer/audience, time synchronization, firewall rules and proxy streaming/body/timeout limits before deployment. Size connection pools across all replicas. Keep secret mounts and setup credentials out of application logs and published installation records.

The delivered Flex container includes its JVM. Running the executable Flex JAR outside that container requires a Java 25-compatible runtime. Other products use their own delivered runtimes; Java 25 is not a platform-wide prerequisite. Node, npm, Maven, the TypeScript SDK and development tooling are source-build requirements, not additional customer services or browser prerequisites.

Prepare storage, databases, secrets and certificates first. Bring up identity, registry, messaging and Valkey before their consumers; establish ECR and Workspace readiness, then optional export/conversion services and Flex’s managed prerequisites. Follow the installed products' readiness contracts rather than fixed delays. Flex’s optional initial type verification occurs on the first authenticated configuration read; local process startup alone does not prove that operation.

Choose the initial human administrator explicitly. After successful managed setup, retire setup login credentials and prove restart/discovery without them. Preserve the encryption key ring, including old keys needed to read stored credentials.

Agree owners, backup retention, recovery point/time objectives and restore tests for every persistent component. Back up application data and required keys, keeping keys and credentials separately protected. Restore repository metadata and content consistently. Include route/state recovery, archive cleanup alarms and certificate renewal in handover. Capacity and version qualification must cover the customer’s actual topology, not merely successful startup.

The starting assumption is 250 named users with 25 concurrently active users, including two simultaneous ZIP downloads and two CSV exports. Export size, CSV row width, search frequency and permission complexity affect Flex load. The configured CSV ceiling of 1,000,000 rows is a safety limit, not a capacity guarantee.

The recommendation adds headroom for the same workload; it does not promise a higher supported user count. Totals exclude host/operating-system overhead, replicas and failover reserve. A single instance provides no high availability. A shared physical PostgreSQL cluster must reserve the Flex allocation separately from other workloads while retaining Flex’s dedicated logical database and account.

For Flex Backend, an initial JVM heap budget near 50–60% of its container memory leaves space for native buffers, threads and metadata. Validate actual heap/native use and garbage collection; do not allocate all container memory to the heap.

Operating-system/container-image space, backups and replication are additional. Database growth depends on configuration, translations, private user preferences and export tracking, rather than the repository’s stored document bytes. Measure actual growth and apply log rotation. If logs are collected externally, size local buffers and collector retention according to the agreed operating model.

ZIP archive storage belongs to Download-Service, not Flex. Flex persists job and transfer metadata and streams archive content from that service to the browser; it does not maintain a durable archive pool. Size and operate archive storage under the Download-Service’s own requirements. Repository originals and renditions are likewise outside Flex storage sizing.

CSV streams through Flex without a persisted CSV artifact. Budget concurrent stream buffers and network capacity; a buffering proxy requires its own separate assessment. For example, transferring 10 GiB through Flex in 200 seconds requires approximately 51.2 MiB/s on both the incoming and outgoing paths per active transfer, before protocol overhead. Two such transfers require approximately 102.4 MiB/s in each direction. Browser CSV fallback may buffer a complete Blob and needs client memory proportional to the export, independently of Flex Backend memory.

Size Flex database backups separately from measured full/incremental backup sizes, WAL generation, change rate and the agreed retention policy. Do not assume compression or deduplication. Retain the matching managed-bootstrap keys in separately protected secret storage where managed discovery is used. See Backup and restore of an existing installation for backup scope and restore checks; no platform-wide backup capacity is specified here.

Monitor concurrent requests, p95 response times, CPU, heap/native memory, garbage collection, database connections, WAL/checkpoints, disk latency, free space and transfer throughput. Initial investigation triggers can be sustained CPU above 70%, memory above 80% or free space below 30%; tune them to the operating objectives. Assess database I/O with representative Flex reads/writes before selecting storage; no measured IOPS requirement has been established.

Validate representative configuration/user-state activity, repository requests through Flex and concurrent ZIP/CSV transfers. Record resource limits and results, then adjust these estimates. No load benchmark has been performed for this sizing.

Open arveo Workspace using the address supplied by your administrator and sign in with your own account. Open Flex Client from the Workspace dashboard. The application runs inside Workspace; a bookmark must use the Workspace entry point. If authentication expires and Workspace requests a new sign-in, complete it in Workspace. Ordinary access denials and loading errors do not automatically mean your session expired. 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.

The published Workspace theme and light/dark appearance also apply to Flex, including tenant branding when configured. Choose appearance in Workspace; Flex has no separate theme importer or mode selector. The theme changes application controls, text and document-viewer controls while original document and image content keeps its own colors. If the Workspace appearance cannot be loaded, Flex remains usable with its bundled appearance and shows a warning. Use Retry in that warning to try loading the Workspace appearance again. The warning disappears after a successful retry; retrying does not save or change scenario settings.

The enabled Workspace language is used when Flex Client opens and whenever you change the language in Workspace. Use the Workspace language selector to change the language for Flex Client. When the selector is hidden on a narrow screen, open More actions in the Workspace header to choose a language. Flex does not display its own language selector or branding footer. If Workspace language is unavailable or disabled in Flex, the client uses an enabled saved preference, then a matching browser language, then the configured default. 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.

The browser address follows your scenario, Records or Documents workspace, selected record, and document open in the right-side panel. You can bookmark or share that address, paste it into the browser, or reload it to reopen the same workspace. Closing the document panel removes the document from the address. Browser Back and Forward follow these destinations and reopen or close the panel. Opening a saved address still requires your current scenario and repository permissions. Old links using scenario query parameters redirect to the new paths. Unsaved editor changes must be resolved before leaving through in-app navigation or browser history.

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, and pagination 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.

Before permanent deletion, read the consequences and type the displayed item name exactly. If no recognizable name is available, type DELETE as instructed. The Delete button remains unavailable until the text matches. While deletion is running, wait for the result. If it fails, the confirmation stays open with an error so you can retry or cancel. For record deletion, also review the consequences for child documents.

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.

Open Set up filter criteria to edit filters in the drawer. Choose a comparison and a value, then select Apply to update the chips and search results. Cancel, the close button and Escape discard drawer edits. Remove an applied chip to clear that criterion, or use Clear all to reset the search. Filter changes restart the result list at its first page and continue to respect the selected record’s scope.

Applied table filters are included in the address. Copy the full address to reopen or share the same search, including comparisons, ranges, lookup selections and the permitted inclusion of trashed items. Record and document tables retain separate searches in the same link. A valid URL search takes precedence over saved search preferences, including when the linked search is empty. Filters are checked against the current configuration and permissions; incompatible criteria are discarded. Base64 is an encoding, so filter values remain readable to anyone with the link.

Sorting is shared in a separate address parameter, including the priority of multiple sort fields. If filters or sorting cannot all be applied, a warning appears and the address is corrected to the effective state. You can expand the warning for details or dismiss it. Copy the address after loading has completed. For applications that generate links, see Developer integration: links with filters and sorting.

Number and date bounds are inclusive: greater than or equal to and on or after include the selected lower bound; less than or equal to and on or before include the upper bound. Between applies both bounds together. A date equality on a timestamp matches that entire local calendar day. Is empty and is not empty check whether a stored value is absent or present and need no entered value. Enumeration selections and time ranges are also sent to the repository search. Drawer actions, comparison labels and chips follow the selected language.

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. Lookup search inputs in forms use the field label, for example Search Customer…, to identify the values being searched. 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. Selecting a value preserves the dropdown’s loaded pages while the address updates to reflect the active filters. If the lookup source is unavailable, ask an administrator to check this attribute’s lookup mapping and your scenario/repository access. Your selection is preserved; retry after the setup or access problem has been resolved. This message does not mean that a saved value has been deleted. 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 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 use the permissions of this scenario and attribute, together with your repository access to the configured source data. The source does not need its own scenario. If your access or the mapping changes, pending lookup results are discarded. Keep existing selections and ask an administrator to check the mapping and your permissions; an unavailable lookup is not proof that a saved value was deleted. Read-only fields may still show permitted saved-value labels without allowing a different value to be selected. Deleted or trashed source entries cannot become valid selections.

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. Column-header filter controls remain unavailable. CSV actions appear when configured for the current table and supported by its visible fields. ZIP actions appear when configured for the current workspace, permitted for your account and backed by an available Download-Service.

Select one or more table rows and choose Download selected as ZIP. Selection checkboxes do not open a row. After selecting all loaded rows, choose whether to include Loaded rows or All matching. When the table has finished loading the complete result set without an error, those sets are identical and preparation starts directly without this choice. Loaded rows include previously loaded scroll pages. All matching follows the current authorized search, filters and parent record, including rows not yet loaded. If that search cannot be translated safely, all matching is disabled; loaded-row export remains available.

Loading another scroll page does not select its new rows automatically. Select those rows, or use the header checkbox again, to include them. The review shows selected documents, included documents and included files separately; several original files can belong to one included document.

Record tables export the selected records' direct readable documents. Use Download entire record as ZIP from the record-context action menu to export one record independently of table selection and document-table filters. Recursive subrecords, deleted documents, historical versions, renditions and annotations are excluded. Shared documents appear separately in each selected owning record folder.

Preparation resolves original contents and exact sizes before generation. Review the counts and confirm any size warning or disclosed omissions. Hard limits cannot be overridden; unknown sizes, no surviving files or interrupted preparation prevent generation. Changing selection, search or parent context invalidates pending preparation. Generated jobs remain available while navigating between scenarios or returning to the dashboard.

DownloadManager appears at the bottom-left while you have retained preparations, jobs or pending save acknowledgements. It shows actual generation progress, failures and the archive’s expiry. Its badge counts ready archives that have not been saved or removed. A ready notification never starts downloading; opening the popover does not clear the badge.

Choose Download explicitly to select a destination where verified saving is supported. Flex streams the archive, verifies its size and waits for the file to close successfully before acknowledging the save. Canceling the picker or encountering a transfer/write failure leaves the archive available for retry. A successfully saved archive disappears from the ordinary list; if acknowledgement fails, Saved — cleanup pending is retried without forcing another download.

Browser download provides an explicit alternative when verified saving is unavailable or blocked. The browser manages that download, so Flex cannot confirm that it was saved. Keep the entry until you choose Downloaded / Remove, or let it expire. Canceling a save picker never silently switches to browser downloading.

After the first acknowledged verified save, Flex schedules deletion five minutes later. Repeated acknowledgements do not extend that delay, and service retention can expire sooner. The expiry timestamp is not extended by viewing, polling or downloading. Expired or confirmed unavailable archives disappear from the ordinary list; temporary service errors retain retry feedback. After a reload, retained jobs can reappear before every service status has been refreshed. A temporary-unavailability indication keeps the job available for retry; starting a download still checks its current availability and your permission. An already started transfer may finish after expiry, but upstream cleanup can still interrupt it. Source permissions are checked again before generating an archive; starting a generated archive download still requires its current ZIP entitlement.

Choose Download selected as CSV to export metadata from a document, record or record-document table. Record exports contain record attributes, not the contents of their documents. Record-document exports stay within the current parent record. CSV activation is independent of ZIP. Your administrator must enable CSV globally for documents or records and for the current scenario table. The document setting also applies to documents inside records.

Select individual rows, or select all loaded rows and choose Loaded rows or All matching. Loaded rows include previously loaded scroll pages. When the complete result set has finished loading, no scope choice is needed. Newly loaded rows remain unchecked until explicitly selected. All matching follows the current authorized search and filters. CSV is unavailable while Include trashed items is active; clear that filter before exporting. The export keeps the visible data columns in their current order and the table’s row sorting. Checkbox and action columns are excluded. Reference and lookup columns contain stored IDs, which can differ from their displayed labels. Unsupported column, filter, sort or formatting mappings prevent export with an explanation. In this delivery, date-only and decimal-family columns cannot be mapped faithfully for every value and prevent export while included; timestamp formatting is limited to supported locale profiles. Hide unsupported columns before starting a new export if they are not needed.

Flex checks the row count before starting a transfer. Zero rows show No data to export. Counts above the effective maximum are blocked; confirmation cannot override this limit. At the warning threshold, review the scope, count and maximum and confirm using the final save action. Below that threshold, a Save CSV action may still be necessary to let the browser open its save picker. Changing the export intent requires a fresh check.

When native saving is available, choose a destination. Only a complete transfer and successful file close count as a verified save. When the native picker is unavailable or blocked by browser policy, Flex reads the complete response into temporary browser memory and hands it to the browser’s download mechanism. Large CSV files can require substantial memory; a row limit does not establish a file-size limit. Canceling the picker never silently starts the fallback. Browser-managed saving and cancellation after handoff are outside Flex’s control; handoff does not verify a local save.

An active CSV transfer remains in DownloadManager while navigating within Flex. It has no percentage, estimated completion time, expiry, retry or reload recovery. Successful native saves and browser handoffs show CSV downloaded successfully and remove the entry. Explicit cancellations remove the entry without a success message. Failed entries remain with an error until dismissed; start a new export from the table to try again. A failed transfer never intentionally hands off a partial CSV.

CSV uses UTF-8 with a byte order mark and semicolons. Column headings use the active language; supported date and number formats follow the table and browser time zone. Filenames use the localized scenario name and a timestamp. CSV text is passed through from Download-Service: spreadsheet formula-like strings, including values starting with =, are preserved. Review untrusted text before opening CSV in software that evaluates formulas.

The export freezes selection, columns, search and sorting, not repository data. Concurrent changes can remove rows or change results between the count check and streaming. A changed count within the hard limit does not require another confirmation. An empty result after a successful check is accepted. CSV exports are direct transfers, with no stored artifact or later re-download.

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. Trashing a shared document changes that same entity in every record where it is linked; it does not remove only the current membership. Review any shared/global impact shown in confirmation. 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 requires the current record-scoped permissions and membership. It deletes the document entity; it does not merely remove a record link. For supported m:n membership removal, use Remove from this record instead; irreversible m:n deletion remains blocked. 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. A partial result is not a rollback: some items may already have changed, and an unresolved item may have changed even if its response was lost. Start a new action only after checking current state and reviewing a fresh confirmation. 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.

This section is for infrastructure and identity administrators installing a new Flex Backend alongside an existing ECR and arveo Workspace. Application configuration administrators perform the handover checks afterwards. Do not reset ECR, replace the realm or overwrite existing Workspace registrations. The current Workspace migration has automated integrated verification, but live host, restart and existing-infrastructure installation acceptance remain required. These instructions do not establish production readiness. The approved rights scope preserves shared Flex configuration and existing scenario/ECR permission checks; organization-specific configuration and repository isolation are deferred.

Sign in through arveo Workspace 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 Workspace client and use this navigation rather than bookmarking a nested administration URL.

Customer appearance is managed in Workspace, separately from Flex scenario configuration. A Workspace administrator manages the published theme and system/light/dark selection under Settings → Preferences → Appearance. Flex administration receives the same published appearance as scenario pages; configuration-administrator rights in Flex do not grant Workspace appearance-administration rights. There is no separate Branding page or theme import in Flex. If Flex displays an appearance-loading warning, Retry requests the current Workspace appearance without saving the configuration draft.

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.

Deletion dialogs require you to type the displayed item name exactly, or DELETE when instructed, before the destructive Delete action becomes available. Category subtree deletion lists every affected scenario assignment, including hidden scenarios; the scenarios themselves are not deleted. Language removal and category removal change the draft and still require Save. Scenario deletion waits for the server result. If a request fails, its dialog stays open with an error so you can retry or cancel. Duplicate opens a name editor and stays open if saving the new scenario fails.

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 an enabled language using the Workspace header and check both static UI text and scenario labels. Flex does not provide a separate runtime language selector. An enabled Workspace language takes precedence when the client opens or the host selection changes; a disabled host language does not enable that language in Flex. Additional configured catalogs remain available for administration; Workspace currently offers English and German for runtime selection. Host synchronization does not overwrite an existing saved Flex language preference.

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.

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 validate criteria in both Allow and Deny rules; unsupported criteria must be corrected before saving.

Schema v4 exports include the scenario’s action rules and field overrides, with no discovery credentials, cached catalogs or current-user grants. Supported legacy and released 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.

Groups stay listed by full path, for example Group: /Admin. Token group names match the final path segment: Admin matches /Admin, and accounts matches /finance/accounts. Existing mappings need no changes. Groups with equal names under different parents cannot be distinguished when the token supplies names only; allow and deny rules match all such paths, with deny taking precedence. A name-only membership does not imply access through ancestor groups. Tokens supplying full paths retain path-specific matching and descendant membership. Names are case-sensitive.

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, column-header filtering controls and document summary cards remain unavailable; record summary cards are supported. ZIP export is controlled independently by its global/surface settings, current grants and service availability.

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. The server rechecks current configuration, permissions and related scope before execution. Confirmation does not reserve or lock repository data. An increased affected count requires a fresh confirmation. Partial or lost responses require refreshing repository state before another action; completed steps are not rolled back. There is no resumable operation history or recovery control for these actions.

The supported repository contract for reading retained content and annotations while trashed is not yet confirmed, 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.

Release 0.1.4 uses configuration version 2. ZIP settings belong to version 3. Released version-2 imports retain scenarios, categories, presentation and permissions through an explicit upgrade; files labeled version 2 that contain version-3 ZIP settings are rejected. Stored version-2 and version-3 configurations are validated against their inherited schemas and upgraded automatically to version 4 at startup without resetting data. CSV collection settings require version 4; imports labeled version 2 or 3 that contain these settings are rejected. Authored ZIP settings and scenario permissions are preserved. New exports use version 4 and require a compatible application; importing them into a version-2-only release is unsupported. Database migration numbers are independent of configuration-file versions.

Links from permission catalog usages include the scenario and exact permission target in the address path. Bookmarking or reloading that address reopens the corresponding Permissions editor and target drawer, subject to administrator access. Older query-based links redirect to the same destination.

Obtain the deployment’s public HTTPS Workspace origin and packaged Flex mount from the operator, for example https://workspace.example/flex-client/. Keep the trailing slash. Do not construct links to internal container ports. /flex-client-dev/ is development-only. Workspace owns normal browser login and forwards the destination to Flex; the link contains no credentials or access tokens. Acceptance of destination restoration after login depends on the deployed Workspace’s normal guest routing.

Read GET https://workspace.example/flex-backend/config/export with an authenticated session or an operator-provisioned bearer token accepted by the existing gateway and backend. All authenticated users may read, including ordinary users; configuration writes remain administrator-only. Unauthenticated access is rejected. This endpoint introduces no anonymous download or new login flow.

Both user-context and autonomous-service integration are intended. Autonomous-service identity provisioning, audience and gateway access must be agreed with the operator; this feature supplies no client credentials, token endpoint or token exchange. Do not assume a browser cookie is a supported service credential. Never put a bearer token in a generated link or persist it alongside a link.

The response is the existing full configuration export JSON, not converted metadata:

The example omits scenarios only for brevity. A real response includes their complete saved configuration and any saved optional download settings. Unsaved Config UI edits are excluded. Validate schemaVersion and the export schema before consuming it; see the configuration reference. Future schema versions require explicit support in the producer. ETag is the configuration collection revision; X-Scenario-Revisions is a JSON array of revision strings aligned with scenario order. Cache privately and revalidate before generating fresh links. An HTTP conditional request can use the normal ETag mechanism. An unchanged configuration revision says nothing about changes to separately retrieved repository TypeDefs.

The endpoint shares normal configuration-read initialization and failure behavior: an authenticated read may reconcile missing packaged scenarios after backend restart. It does not replace existing settings. Authentication/gateway failures can return 401/403; unavailable pristine initialization returns 503 with the sanitized code CONFIGURATION_INITIALIZATION_UNAVAILABLE. Do not parse error text as configuration or silently use an incomplete response. Handle other non-success responses explicitly.

Choose a scenario by its exact name, not its translated title, category or TypeDef alias. Scenario names are URL identifiers. Record/document IDs must come from the producer’s authorized business integration; the export endpoint does not list records.

For a filter field, join stage.search.filters[].attribute to stage.attributes[].attribute and to that TypeDef’s attribute of the same name. Both configured entries must be available. The filter ID for a search filter is search: followed by the exact attribute name. The existing header:<attribute> form is also accepted only for an available table column with headerFilterEnabled; new integrations should normally produce search: filters. Labels do not identify fields. Effective field permissions and the current live schema are checked again when opening the link.

For sorting, the attribute must exist in the TypeDef and the available table matrix, and the column must be sortable. A configured unavailable search property can also exclude the attribute from sorting. Do not sort by display labels or generated action columns. Field visibility permissions can remove columns for the target user.

The export is authored configuration; it is not a caller-effective permissions or TypeDef response. Obtain live TypeDefs through the deployment’s existing authorized ECR integration. With the ECR SDK, the client uses getAllDefinitionByName() and getSystemFieldsByName(alias) to include system fields; raw catalog access is GET /flex-backend/ecr/api/definitions/named through Workspace. ECR uses its ASDL wire format, not a plain JavaScript attribute dictionary. Use the supported SDK or decode/validate the ASDL format before joining attributes. Enum definitions and lookup values likewise come from the existing authorized repository integration; this API does not add business-data discovery endpoints or bypass scenario search permissions.

An attribute lookup is configured in stage.attributes[].lookup: sourceType, storedValueColumn and displayColumns identify its source and stored-key mapping. The matching search-filter lookup.selectionMode is single or multi. Resolve the source TypeDef and obtain actual stored keys from authorized source records; displayed text is not a stored key. For record documents use the shared document attributes with the record-document search settings. A missing/incompatible source or unavailable mapping can invalidate a previously generated criterion.

Paths below are relative to the public client mount. Percent-encode each identifier as one path segment using UTF-8. Never concatenate unescaped IDs, encode a whole path as one segment or use form encoding (+) for path spaces.

For example, Customer files and record case 42 produce:

https://workspace.example/flex-client/scenario/Customer%20files/record/case%2042

Use the optional filter and sorting query parameters independently. Supply each at most once; duplicates are invalid. They do not select a scenario or record: the path owns selection. Recycle-bin/litigation destinations are not covered by this external ordinary-search recipe. Do not generate legacy scenario-selector queries.

Both parameters contain JSON serialized to UTF-8, then Base64url without padding: replace Base64 + with - and / with _, and remove trailing =. Add values through a URL query builder. Decode in the reverse order. Do not Base64-encode Unicode code units directly, use a locale-dependent character encoding, trim operands or normalize Unicode strings. Existing filter links also accept the legacy padded/Base64 alphabet; new producers should emit Base64url without padding. Sorting accepts the canonical unpadded Base64url alphabet. Both decoders reject values longer than 100,000 encoded characters; this is a decoder bound, not a promise that a browser or proxy will accept such long URLs. Operators must establish a lower deployment-specific end-to-end URL limit where necessary. Producers must reject oversized URLs rather than truncate them.

The filter format is unchanged, version 1. Its context key is:

"v2." + lowercaseHex(SHA-256(UTF8(JSON.stringify([scenarioName, viewName]))))

Use a compact JSON array without added whitespace or escaped non-ASCII characters. The v2. prefix versions the existing preference context, not the filter envelope. Use the exact scenario/view names from the table above. No record ID participates in the hash; record-document filters are shared by that scenario’s record-document table. Build separate entries to carry record-list and record-document searches.

Fixed context vectors for Customer files:

Fixed encoding vector: the exact JSON {"value":"Ärger 東京 😀 + / & % "} (two spaces after %) becomes eyJ2YWx1ZSI6IsOEcmdlciDmnbHkuqwg8J-YgCArIC8gJiAlICAifQ. This small vector demonstrates encoding only; actual parameters require their full envelope.

<computed context> is explanatory, not a usable key. The generator below computes it. filters is an array of [filterId, group] pairs, not a JSON object. Within a group every criterion’s filterId must match the pair key. columnName is the exact TypeDef attribute name, operator is uppercase, value and label are strings. label is presentation text and never an executable field or lookup operand. combineOperator is exactly AND or OR. Different groups combine with AND. Duplicate group IDs should not be generated. A group must contain at least one criterion; the empty search is filters: [].

includeTrashed is a mandatory boolean for each supplied table entry. Normally use false. true requires configured inclusion support and the target user’s effective trash-search permissions; otherwise it is removed with a warning. A link cannot enable litigation access or change record membership scope.

Use value: "" for null-check operators. For an inclusive range, put GREATER_EQUAL and LESS_EQUAL criteria in one AND group. For several accepted values, use equality criteria in one OR group. A partially invalid group is rejected whole, preventing a half-range or changed OR expression from broadening the search.

Configured lookups accept EQUALS in an OR group and carry an additional storedValue: { "type": "LONG", "value": "9007199254740993" } (example). The type must match the target attribute, and the lexical value must pass that type’s stored-key validation. value/label remain strings for presentation. For a single selection the group has exactly one criterion. Null checks use a single criterion without storedValue. Exact timestamp/decimal keys must retain their canonical stored representation. Do not attach storedValue to an ordinary non-lookup filter.

scenario must match the path scenario exactly. Supported table keys are documents, records and recordDocuments; they correspond to the earlier table, independently of hashed filter contexts. Fields use exact TypeDef attribute names. Direction is exactly asc or desc; array order is priority. Do not repeat a field. Empty arrays explicitly clear personal sorting. Backend-owned tie-breakers can still stabilize paging and are not user sorting entries. Unsupported fields are removed; the relative order of accepted fields is retained.

This example runs as an ES module in modern browsers or Node with Web Crypto (Node 26 is used by this project); it is also valid TypeScript after adding application types. It needs no Angular code. Supply already validated filters and sorting derived from the exported configuration and live TypeDefs. The example values require matching fields in your deployment; they are not built-in demo identifiers.

The record-document entries explicitly clear that table’s preferences. Replace them with the intended record-document filters/sorting to carry both searches. For record only, construct the path without either query parameter. For filters only, omit sorting; for sorting only, omit filter. To explicitly clear both, pass empty filter and sort arrays and retain the generated entries. To select a document, append its encoded path suffix before setting query parameters.

Complete output of the example above (adapt origin, scenario, record and fields before use):

Read configuration using the host application’s existing authenticated HTTP client:

For a browser on the same origin, the authenticated fetch can use the normal Workspace session. Cross-origin applications and server services require the operator’s supported access setup; this example neither enables CORS nor defines an authentication flow.

The following standard-library Java example generates the same single equality filter and sorting as the JavaScript example. The caller must validate scenario/attribute choices against the exported configuration and live TypeDefs before calling it. Use the application’s existing JSON parser for reading configuration. This example only serializes the small link payload; it has no HTTP authentication dependency.

An explicit table entry overrides the opening user’s personal state, even when preference persistence is disabled. Empty entries explicitly clear state. Missing parameters/tables use normal saved preferences or defaults. Therefore omit an entry only when personal/default state is intentional. Copy the full address after loading has completed to share the frontend’s effective filters and sorting.

Filters and sorting are checked against the current configuration, TypeDefs and permissions. Independent valid groups/sort fields survive; invalid groups are removed whole. Malformed or unknown-version explicit parameters clear the destination table’s state instead of silently activating saved preferences. The client replaces the URL with the state actually applied, retaining explicit empty entries when necessary. The visible warning persists through this automatic cleanup and can be dismissed; details identify filter versus sorting rejection without echoing sensitive operands or hidden field names. Zero matching rows alone do not mean a criterion is invalid.

Refresh, a new session and browser navigation restore explicit URL state using the same client path. Missing/inaccessible scenarios, records or documents show the existing safe unavailable-target behavior; links cannot bypass current access checks. The selected record/document is resolved independently of table paging and filters.

Links have no built-in expiry and do not pin historic configuration, rights or data. Keep version-1 filters when storing links; a changed/removed scenario, attribute, lookup source or record can later make a link partially or entirely unusable. Fetch current configuration/TypeDefs when generating links on demand. For stored links, revalidate before reuse when feasible and expect the same warnings/unavailable-target behavior when they are opened later. Configuration revisions can aid cache invalidation but are not embedded authorization or historical-schema snapshots.

Base64 is readable encoding. Field names, values, labels and sorting can appear in browser history, copied links, screenshots, referrers and infrastructure logs. Follow deployment policy for sensitive values; do not generate such links when URL exposure is unacceptable. Credentials and access tokens must never appear in either parameter.