Glossary

This glossary defines terms specific to the Amphora document management system.

Amphora Modules

Documents

English: Documents | Eesti: Dokumendid Module: Documents | Audience: admin, end user

The primary module covering the entire lifecycle of documents: creation, formatting, confirmation, registration, processing, sharing, storage, archiving, and secure destruction. The Documents module supports electronic document registry management and uses a classification scheme for easy storage and retrieval. As of version 12.7, correspondence (letter) functionality has been merged into this module.

Comments: In older documentation and environments, letters may still appear under the legacy Correspondence module. The Documents module now handles both documents and letters via the unified "Letter" form.

Correspondence

English: Correspondence | Eesti: Kirjavahetus Module: Correspondence | Audience: admin, end user

A legacy module that was originally used for registering and managing incoming and outgoing letters. Since Amphora version 12.7, letter functionality has been developed into the Documents module, making Correspondence a deprecated module. Existing environments may still contain data in this module.

Comments: The terms "Correspondence", "Letters", and "Messages" overlap in older docs. New implementations should use the Documents module with the "Letter" form instead. Some counter configuration guides still reference "correspondence counters" and "correspondence general counters" because these counter types remain functional.

Case View

English: Case View | Eesti: Asjavaade Module: Case View | Audience: admin, end user

A module that allows documents to be grouped according to topics or cases. For example, you can bring together an initial letter and response letters on the same topic, or collect documentation related to a single legal act. Cases use a dedicated case counter that numbers documents by case sequence in the format case-number/sequence-number (e.g., 5-1/1-1).

Comments: "Case View", "Case", and "Document Package" are related but distinct concepts. A Case is the grouping itself; Case View is the module/interface for working with cases. In some docs, "files" (as in "cases/files") is used interchangeably with "cases" -- this reflects the Estonian "toimik" (file/dossier) concept.

DHX

English: DHX | Eesti: DHX Module: Documents | Audience: admin

The DHX module within Amphora enables sending and receiving documents through Estonia's DHX document exchange protocol. When sending a document via DHX, the document type must be specified; the "Letter" form has this selected by default, but other forms require manual selection or the "Document_form_id" Amp. field name to be configured.

Comments: DHX appears both as a module feature and as an integration protocol. See the Estonian Integrations section for the protocol definition.

Invoices

English: Invoices | Eesti: Arved Module: Invoices | Audience: admin, end user

A module for managing invoices within Amphora. Invoices are stored in catalogs and follow the same rights hierarchy as other modules. The Invoices module appears in folder selection alongside Documents, Correspondence, and Cases.

Comments: E-invoice (e-arve) integration is a separate concept from the Invoices module itself. See External Communication section for e-invoice details.

Calendar

English: Calendar | Eesti: Kalender Module: Calendar | Audience: end user

A module that displays calendar events for the user. Calendar events appear on the homepage alongside tasks, reports, and other user-relevant information.

Comments: No known terminology inconsistencies.

Projects

English: Projects | Eesti: Projektid Module: Projects | Audience: admin, end user

A module for organizing and tracking project-related activities and documents within Amphora.

Comments: No known terminology inconsistencies.

Discussions

English: Discussions | Eesti: Arutelud Module: Discussions | Audience: end user

A module that provides a space for internal discussions and collaborative communication among Amphora users within an organization.

Comments: No known terminology inconsistencies.

E-mails

English: E-mails | Eesti: E-kirjad Module: E-mails | Audience: admin, end user

A module for managing email integration within Amphora. Allows registration of emails as documents and sending email notifications from the system. File size limits depend on the mail server, but files should preferably stay below 10 MB and must not exceed 25 MB.

Comments: Do not confuse with the external email service Mailgun (see External Communication). The "send files as link" option can be used to work around size limitations.

Public View

English: Public View | Eesti: Avalik vaade Module: Documents | Audience: admin, end user

The public-facing document registry that displays document metadata and optionally files to the general public. For a document to appear in the Public View, the "Metadata public" option must be enabled on the document, and the catalog must be marked as a public catalog. Form configuration determines which metadata fields are visible in the public view via the "Visible in public view" setting.

Comments: "Public View" and "Public register" refer to the same feature. Some docs use "public directory" when referring to the catalog-level setting that enables public visibility.

Estonian Integrations & Acronyms

DHX (Document Exchange Protocol)

English: DHX | Eesti: DHX Module: Documents | Audience: admin

Estonia's decentralized document exchange protocol used by public sector organizations to send and receive official documents electronically. In Amphora, DHX is used as the transport layer for sending letters and receiving documents from other government systems such as KOVMEN and SPOKU. When configuring registration profiles, DHX is selected as the default delivery method for KOVMEN-type profiles.

Comments: DHX replaced the older DVK (Document Exchange Centre) protocol. It is both a protocol and a feature within Amphora's Documents module.

KOVMEN

English: KOVMEN | Eesti: KOVMEN Module: Documents | Audience: admin

An X-Road-based form integration system used by Estonian local governments to receive structured XML documents (e.g., permits, applications) from citizens via the X-Road infrastructure. In Amphora, KOVMEN documents are registered automatically using registration profiles that map XML data fields to Amphora form fields. The profile name must match the "title" field in the KOVMEN XML file exactly.

Comments: KOVMEN registration profiles use the KOVMEN registration type, which automatically selects DHX as the delivery method. "Form Settings" and "Form Configuration" are used interchangeably in the KOVMEN guide when referring to Admin -> Form Configuration.

SPOKU

English: SPOKU | Eesti: SPOKU Module: Documents | Audience: admin

An electronic petition and application system that integrates with Amphora for automatic document registration. When a document is sent from SPOKU to Amphora for the first time, the system automatically generates a new form, an associated registration profile, an automatic process, a folder called "Incoming documents for registration", and a "Chancellery" role. SPOKU forms use the KOVMEN form structure and are managed exclusively in the SPOKU environment -- changes made in Amphora are not transferred back to SPOKU.

Comments: SPOKU registration profiles must not be deleted. Form versioning is automatic: when SPOKU updates a form, Amphora automatically updates both the form and the registration profile fields.

X-Road / X-tee

English: X-Road | Eesti: X-tee Module: N/A (infrastructure) | Audience: admin

Estonia's national data exchange framework that enables secure data exchange between government information systems, private sector organizations, and citizens. Amphora uses X-Road indirectly through integrations like KOVMEN and DHX. X-Road provides the transport layer for structured document exchange.

Comments: English documentation uses "X-Road"; Estonian documentation uses "X-tee". Both refer to the same system.

GovSSO

English: GovSSO | Eesti: GovSSO Module: Authentication | Audience: admin

The Government Single Sign-On service provided by RIA (Information System Authority) for Estonian public sector organizations. In Amphora, GovSSO appears as an authentication option on the login page. The GovSSO button is visible only if the organization has joined the GovSSO service and the corresponding settings have been configured in Amphora.

Comments: GovSSO is distinct from Entra ID (Microsoft SSO). GovSSO is specifically for public sector; Entra ID is a general Microsoft service.

VOLIS

English: VOLIS | Eesti: VOLIS Module: Documents | Audience: admin

A legal act management system used by Estonian local governments for managing drafts of regulations, decisions, and other legal acts. In Amphora, if integration with VOLIS is enabled, a toolbar icon allows sending drafts directly to VOLIS from the document view.

Comments: No known terminology inconsistencies.

MTA

English: MTA (Tax and Customs Board) | Eesti: MTA (Maksu- ja Tolliamet) Module: N/A (external system) | Audience: admin

The Estonian Tax and Customs Board, an external government agency. Amphora may exchange documents with MTA through DHX or other integration channels. MTA is relevant in the context of e-invoicing and tax-related document exchange.

Comments: No known terminology inconsistencies.

RIA

English: RIA (Information System Authority) | Eesti: RIA (Riigi Infosuststeemi Amet) Module: N/A (external authority) | Audience: admin

The Estonian Information System Authority responsible for the development and administration of the state's information systems, including X-Road, GovSSO, and the SiGa signing service. RIA provides the government authentication service that Amphora supports as a login option.

Comments: RIA is referenced in the login guide as the provider of the "Government authentication service."

SiGa

English: SiGa (Signing Gateway) | Eesti: SiGa Module: N/A (infrastructure) | Audience: admin

RIA's central signing service (Signing Gateway) that provides digital signature creation capabilities for government information systems. Amphora can use SiGa as a backend service for document signing operations, particularly for ID-card and Mobile-ID based signatures.

Comments: SiGa is a backend service and is not directly visible to end users. It may be referenced in technical configuration documentation.

Authentication & Identity

ID-card

English: ID-card | Eesti: ID-kaart Module: Authentication | Audience: end user

The Estonian national identity card with an embedded chip, used in Amphora for both login authentication and digital document signing. The chip must be inserted into a card reader before opening the web browser. When logging in with ID-card, no username or password is required -- the system identifies the user by their certificate. The user's Amphora account must have the correct personal identification code. Mass-signing functionality requires an ID-card.

Comments: Users must select the correct valid certificate when prompted. Pressing "Cancel" in the certificate selection window prevents ID-card and Mobile-ID login for the entire browser session. The Token signing extension must be enabled in Chrome and Firefox for signing to work.

Mobile-ID

English: Mobile-ID | Eesti: Mobiil-ID Module: Authentication | Audience: end user

A mobile-phone-based authentication and digital signing method used in Estonia. In Amphora, Mobile-ID requires the user to enter their username and confirm login on their mobile device. The user's Amphora account must have both a personal identification code and a mobile phone number (in the GSM field). The Mobile-ID service must be activated beforehand.

Comments: Unlike ID-card login, Mobile-ID requires entering a username. The phone number must be in the GSM field specifically, not just any phone field.

Smart-ID

English: Smart-ID | Eesti: Smart-ID Module: Authentication | Audience: end user

A smartphone-app-based authentication and digital signing method. In Amphora, Smart-ID requires the user to enter their username and confirm login in the Smart-ID application. The user's Amphora account must have the correct personal identification code. Smart-ID can be used as a fallback when ID-card login fails due to a cancelled certificate selection.

Comments: Unlike ID-card login, Smart-ID requires entering a username. Smart-ID is the only eID method that works after cancelling the certificate selection window.

Entra ID

English: Entra ID | Eesti: Entra ID Module: Authentication | Audience: admin

Microsoft's cloud-based identity and access management service (formerly Azure Active Directory) that allows organizations to securely manage user access to applications through single sign-on. In Amphora, Entra ID appears as a login button that opens the Microsoft account login window.

Comments: Entra ID is distinct from GovSSO. Entra ID is a Microsoft service available to any organization; GovSSO is specifically for Estonian public sector.

Personal Identification Code

English: Personal identification code | Eesti: Isikukood Module: Admin / Authentication | Audience: admin, end user

The Estonian national personal identification number, a unique numeric code assigned to every Estonian citizen and resident. In Amphora, the personal identification code is stored on the user account and is required for ID-card, Mobile-ID, and Smart-ID authentication as well as document signing. A confirmed personal code means the user has logged in at least once with ID-card, Mobile-ID, or Smart-ID. Only one active user per personal identification code is allowed in the system.

Comments: If two users share the same personal identification code, ID-card login will fail. When a user changes organizations, the personal code should be removed from the old (passive) account.

Document Management

Catalog

English: Catalog | Eesti: Kataloog Module: Admin | Audience: admin

A hierarchical organizational container in Amphora's classification scheme used to structure and store documents. Catalogs are arranged in a tree structure and can contain subcatalogs. Each catalog can have counters, access restrictions, public visibility settings, module-specific configurations, and retention schedules. Catalogs can be searched by name using the filter in the catalog tree. A catalog cannot be deleted if it contains objects or if related objects exist in trash, correspondence, or case modules.

Comments: This is one of the most inconsistently named concepts in the documentation. The terms "Catalog" (Kataloog), "Directory", "Folder", and "Kaust" are all used to refer to the same concept. The admin guide uses "Catalogs" in headings but "directory" and "folder" in body text. The FAQ section references "directory" (e.g., "Why can't I delete a directory?") while the admin interface labels it "Catalogs." Standardize on "Catalog" for new documentation.

Unit

English: Unit | Eesti: Uksus Module: Admin | Audience: admin

A special top-level catalog type that represents an organization or structural sub-organization within Amphora. Units are denoted by a house icon in the catalog tree. Each user belongs to a unit, and the unit determines the user's main work area. Units have their own settings for public visibility, default restrictions, and correspondence general counters. The "Public directory" option on a unit controls whether the organization appears in the public view's organization selection.

Comments: A Unit is technically a special type of Catalog, but it functions as an organizational boundary. "Unit" and "structural unit" are used interchangeably. Do not confuse with user groups or departments.

Form

English: Form | Eesti: Vorm Module: Admin | Audience: admin

A configurable data entry template that defines the metadata fields, panels, and behavior for a specific document type in Amphora. Forms are created in Admin -> Form Configuration and determine which fields appear when a user creates or uploads a document. Each form has a loading method (uploaded or written document category), can be linked to templates, and can have visibility restricted by unit or user group. Forms cannot be deleted if documents have been created with them.

Comments: "Form Configuration" and "Form Settings" are used interchangeably in the documentation, particularly in the KOVMEN guide. Both refer to Admin -> Form Configuration.

Counter

English: Counter | Eesti: Loendur Module: Admin | Audience: admin

A tool configured at the catalog level that assigns automatic sequential registration numbers to documents. Counters ensure each new document gets a unique number according to specified settings including prefix, value, suffix, and validity period. Amphora supports four counter types: document counter, case counter, correspondence counter, and correspondence general counter. The counter does not update automatically after document deletion -- it must be manually "rolled back."

Comments: Counter rollback is a common admin task. The correspondence general counter (under the unit with house icon) provides continuous numbering across different series. For correspondence counters, the value field in subcatalogs must remain empty.

Registration

English: Registration | Eesti: Registreerimine Module: Documents | Audience: admin, end user

The act of officially recording a document in Amphora's registry, which assigns it a sequential number from the catalog's counter. Registration differs from simply saving a document: when drafts are allowed, the "Save" button stores the draft without a number, while the "Register" button assigns the counter value. A document must have the correct form selected in the counter composition to receive a number upon registration.

Comments: "Registration" in Amphora specifically means assigning an official registry number. Do not confuse with user registration or account creation.

Main File

English: Main file | Eesti: Peafail Module: Documents | Audience: end user

The primary file attached to a document in Amphora. Each document can have one main file, which appears prominently in the document view. For the main file to be visible in the public view, the "File public" option must be enabled during registration, and the user's group must have the corresponding policy enabled. Main files can be edited in-place using the WebDAV "Edit" link.

Comments: No known terminology inconsistencies.

Additional Files

English: Additional files | Eesti: Lisafailid Module: Documents | Audience: end user

Supplementary files attached to a document in addition to the main file. Each additional file has its own "Public" option in the Additional Files panel that controls visibility in the public view. The Additional Files panel must be enabled on the form and set to public for additional files to appear in the public registry.

Comments: No known terminology inconsistencies.

Version

English: Version | Eesti: Versioon Module: Documents | Audience: end user

A revision snapshot of a document in Amphora. Each document version has a unique identifier (ID). The Versions panel on a document shows all versions with their dates. You can navigate between versions by clicking on the version date. The document ID visible in the URL corresponds to the specific version, not the document as a whole.

Comments: No known terminology inconsistencies.

Access Restriction

English: Access restriction | Eesti: Piirang Module: Documents / Admin | Audience: admin, end user

A mechanism to restrict access to a document based on legal grounds. Access restrictions include a basis (selected from a configurable dropdown), a start date, an end date, and a data controller. Default restrictions can be configured at the catalog level and applied automatically when documents are saved. New access restriction basis options are added through Admin -> Organization settings -> Option field content.

Comments: The SPOKU integration supports conditional access restriction logic via the registration profile's "Actions" panel, where restrictions can be activated or deactivated based on XML field values.

Loading Method

English: Loading method | Eesti: Laadimisviis Module: Admin | Audience: admin

The category that determines how documents are created using a particular form. There are two types: "Uploaded document category" (a main file upload field appears on the form, used under "Load new") and "Written document category" (a text editor appears instead of a file upload field, used under "Write new"). The loading method is set when creating a new form in Admin -> Form Configuration.

Comments: No known terminology inconsistencies.

Info Presentation

English: Info Presentation | Eesti: Infoesitlus Module: Admin | Audience: admin

A catalog-level configuration that determines how document information is presented and displayed within a specific catalog. Info Presentation settings control the layout and visibility of document metadata in registry views.

Comments: Referenced in the Estonian admin_folders documentation but not fully translated in the English version. The English admin_folders.md is missing the opening sections that cover Info Presentation setup.

Registration Profile

English: Registration Profile | Eesti: Registreerimisprofiil Module: Admin | Audience: admin

A configuration that maps external document data fields (from XML files via KOVMEN or SPOKU) to Amphora form fields for automatic document registration. Registration profiles are managed in Admin -> Profiles. Each profile has a name (which must match the source document title exactly), a registration type (e.g., KOVMEN), and a linked form. Profiles can also configure automatic processes, responsible persons, conditional task assignment, case composition, and access restriction rules.

Comments: SPOKU registration profiles are auto-generated and must not be deleted. The profile "Name" field must not be manually entered for KOVMEN -- it comes from the XML file content.

Workflows & Processes

Procedure / Process

English: Procedure / Process | Eesti: Menetlus Module: Documents | Audience: admin, end user

A workflow mechanism in Amphora where a document is sent through a series of tasks to one or more users. The user can add process participants, assign task types (for coordination, completion, information, or signing), set deadlines, and add explanations. Processes can be sequential (one step after another) or parallel (multiple tasks at the same step). Completed processes are visible on the homepage "Forwards" panel for 90 days.

Comments: "Procedure" and "Process" are used interchangeably throughout the English documentation. The document history panel uses "procedure/delegation" while the FAQ and workflow guides use "process." Standardize on "Process" for new documentation. "Forwarding" in the UI (the "Forwards" panel) refers to active and completed processes.

Delegation

English: Delegation | Eesti: Delegeerimine Module: Documents | Audience: end user

A workflow action where a user assigns the same task type to all selected persons simultaneously. Unlike a process (procedure), which allows different task types per person, delegation applies a uniform task to everyone in the group. Delegation appears as an option alongside processing in the document toolbar.

Comments: "Delegation" vs "Forwarding" vs "Routing" -- these terms overlap. Delegation specifically means assigning the same task to multiple people. Forwarding/routing refers more broadly to sending a process to the next step or user. The document history panel logs both "procedure" and "delegation" as separate event types.

See also: Self-Service Portal guide

Forwarding

English: Forwarding | Eesti: Edastamine / Suunamine Module: Documents | Audience: end user

The act of directing a document or process task to another user for action. In Amphora, forwarding appears in the "Forwards" panel on the homepage. When forwarding a process, users from the same unit and units where the user has administration rights appear by default. The "Show users/user groups from all units" option reveals users across all organizational units.

Comments: "Forwarding", "Routing", and "Delegation" have overlapping meanings. "Edastamine" and "Suunamine" are both used in Estonian for this concept. "Forwarding" in the UI context specifically refers to the homepage panel showing active process tasks. "Routing" is sometimes used in workflow configuration contexts.

Coordination

English: Coordination | Eesti: Kooskolastamine Module: Documents | Audience: end user

A task type within a process where a document is sent to one or more users for approval or review. Coordination tasks allow the recipient to respond with "yes", "no", or "neutral" and add a comment explaining their decision. Coordination is one of the four standard task types in Amphora processes.

Comments: Also referred to as "approval" in some contexts. The Self-Service Portal guide uses "approval task" to describe coordination tasks sent to external persons.

See also: Self-Service Portal guide

Automated Process

English: Automated process | Eesti: Automaatne menetlus Module: Admin | Audience: admin

A pre-configured process template located under Admin -> Automated Processes that automatically initiates a workflow when a document is registered. Automated processes define sequential or parallel steps, each assigned to specific users or roles with designated task types and deadlines. Multiple automated processes can be assigned to a catalog, and person groups can be used to determine which process applies based on the document registrar.

Comments: No known terminology inconsistencies.

Task Types

English: Task types | Eesti: Ulesandetyyp Module: Documents | Audience: end user

The classification of work assigned to a user within a process. Amphora supports four standard task types: For coordination (approval/review), For completion (action required), For information (acknowledgment only), and For signing (digital signature required). Each task type determines the available response options for the recipient.

Comments: In the Self-Service Portal, only "for signing" and "for information" task types can be sent to external persons.

See also: Self-Service Portal guide

Conditional Task

English: Conditional task | Eesti: Tingimuslik ulesanne Module: Documents | Audience: admin

A task that is automatically created based on a condition, such as a date field value on a document form. For example, a conditional task can be configured so that X days before a specific date field value arrives, Amphora creates a task for the responsible person. Configuration is done through the Registries module using "Form panel settings" with the keywords "PropertyNameToAlert" (for the date field) and "DaysToAlert" (for the number of days).

Comments: The Registries module must be activated in the user group for conditional task configuration to be accessible.

Deadline

English: Deadline | Eesti: Tahtaeg Module: Documents | Audience: admin, end user

The date by which a process task must be completed. Deadlines are mandatory when creating process steps and can be set as a specific date or as a number of days. Once a process is created, changing the deadline is not possible for a regular user -- the process must be deleted and recreated with the correct deadline. In automated processes and registration profiles, deadlines can be specified in days for both task completion and response.

Comments: Always verify the deadline before creating a process, as modification after creation is restricted.

Responsible Person

English: Responsible person | Eesti: Vastutaja Module: Admin / Documents | Audience: admin, end user

The user's direct superior to whom reports are made, for example if the user exceeds task completion deadlines. A responsible person is assigned in the Users module under "Roles, substitutes and responsible person." In registration profiles (SPOKU/KOVMEN), a responsible person can be automatically assigned to incoming documents, optionally with an associated work task and deadline.

Comments: No known terminology inconsistencies.

Substitute

English: Substitute | Eesti: Asendaja Module: Admin | Audience: admin

A user designated to replace another user, for example during vacation or absence. Substitutes are configured in the Users module under "Roles, substitutes and responsible person." If a user has multiple substitutes, they can be ordered by priority. Substitute assignment follows the same process as role assignment.

Comments: No known terminology inconsistencies.

User Management & Rights

User Group

English: User group | Eesti: Kasutajagrupp Module: Admin | Audience: admin

A collection of users that share the same access rights and policies in Amphora. User groups determine folder/unit access levels and system policies for their members. A user can belong to multiple user groups, and group-derived rights are visible in the "Group rights" panel of the user edit view. User groups are managed in Admin -> User Groups.

Comments: No known terminology inconsistencies.

Policy

English: Policy | Eesti: Poliitika Module: Admin | Audience: admin

A permission setting within a user group that controls specific system capabilities, such as document metadata modification, document signing, registration rights, process creation, template usage, role creation, and more. Policies are enabled or disabled at the user group level. Key policies include "Log in as another user," "Show person groups selection in automatic processes," and "Document publication."

Comments: Policies are distinct from folder access rights. Rights control what catalogs a user can see and modify; policies control what actions a user can perform system-wide.

Role

English: Role | Eesti: Roll Module: Admin | Audience: admin

A descriptor of a user's work tasks, main activities, or job title within the organization. Roles are assigned to users in the Users module and can be used in automated processes to designate task recipients instead of specific users. Roles can be created by users with the "Role creation" policy enabled. The SPOKU integration automatically creates a "Chancellery" role for incoming document handling.

Comments: Do not confuse with user groups. Roles describe what a person does; user groups define system access permissions.

Superuser

English: Superuser | Eesti: Superkasutaja Module: Admin | Audience: admin

An elevated access mode that provides default access to all organization folders and documents and allows deleting processes and delegations created by other users. Superuser mode must be activated by Amphora client support and requires the user to have a confirmed personal code. The mode is toggled using a king/queen icon in the top-right corner, which turns red when active. A notification "You are using Amphora in superuser mode" is displayed on screen while active.

Comments: Superuser is not a permanent role but a togglable mode. The icon appearance (king or queen) depends on the user's personal code. To assign superusers, an application form must be signed by the organization's legally authorized person.

Main User

English: Main user | Eesti: Peakasutaja Module: Admin | Audience: admin

A designated administrator within an organization's Amphora environment who assists regular users with access issues, password resets, and basic system configuration. Main users typically have administration-level rights and can manage user accounts, groups, and folder permissions.

Comments: The FAQ and other guides reference "main user" as a support contact alongside "system administrator" and "super user." The exact distinction between main user and system administrator is not formally defined in the current documentation.

End User

English: End user | Eesti: Loppkasutaja Module: N/A | Audience: end user

A regular Amphora user who performs day-to-day document management tasks such as creating, registering, searching, and processing documents. End users interact with the system through the Documents, Case View, Calendar, and other front-end modules. Their capabilities are determined by their user group's policies and folder access rights.

Comments: No known terminology inconsistencies.

Rights Hierarchy

English: Rights hierarchy | Eesti: Oiguste hierarhia Module: Admin | Audience: admin

The ordered set of access levels in Amphora, from weakest to strongest: Hidden (folder not visible, can be overridden), Add (see own objects only), Limited read (see others' metadata only, no file download), Read (see others' objects, download files), Add+Read (add own and read others'), Modify (modify others' objects but not delete), Administration (full CRUD on all objects), and Forbidden (folder not visible, cannot be overridden). Rights set directly on a user are generally "stronger" than group-derived rights, except that Forbidden from a group cannot be overridden.

Comments: The "Hidden" and "Forbidden" rights appear similar but behave differently: Hidden can be overridden by a stronger right at the same level; Forbidden cannot.

Passive User

English: Passive user | Eesti: Passiivne kasutaja Module: Admin | Audience: admin

A user account that has been deactivated and can no longer log into Amphora. Passive users cannot be selected in the system for tasks or message sending. Activities performed by the user before being made passive (document loading, message sending, etc.) remain in the system. Marking a user as passive is the recommended approach for handling employees who have left the organization, rather than deleting their account.

Comments: A passive user differs from a locked user. A locked user is temporarily unable to log in (e.g., after 5 wrong password attempts) but can still be selected for tasks and exists in the calendar. A passive user is permanently deactivated until reactivated.

Form Field Types

TextBox

English: TextBox | Eesti: Tekstivali Module: Admin (Form Configuration) | Audience: admin

A single-line or multi-line text input field on an Amphora form. When the XML data field type is text, TextBox should be selected as the field type. The corresponding Amp. field name data type is "Text." TextBox supports configurable width, height, mandatory field setting, title length, and descriptive text.

Comments: No known terminology inconsistencies.

CheckBox

English: CheckBox | Eesti: Markevali Module: Admin (Form Configuration) | Audience: admin

A yes/no toggle field on an Amphora form, rendered as a checkbox. When the XML data field type is a boolean checkbox, CheckBox should be selected. The corresponding Amp. field name data type is "Yes/No." A CheckBox list variant (CheckBoxList) allows multiple selectable options.

Comments: No known terminology inconsistencies.

See also: Form configuration guide

English: Dropdown | Eesti: Rippmenuu Module: Admin (Form Configuration) | Audience: admin

A selection field (DropDownList) on an Amphora form that presents a list of predefined options in a dropdown menu. Options can be added, edited, made inactive, or deleted. The corresponding Amp. field name data type is "Number." A multi-select variant (DropDownListMulti) allows selecting multiple values. Default values can be set.

Comments: Also referred to as "dropdown menu" in documentation. The DropDownList field type is for single selection; DropDownListMulti and EditableDropdown are related variants.

See also: Form configuration guide

Classificator

English: Classificator | Eesti: Klassifikaator Module: Admin (Form Configuration) | Audience: admin

A specialized selection field type designed for large option lists with 50 or more items. Selected as "Classificator(>50)" in form configuration. Classificators support multiple selection, related fields (2-5 linked selections), and sequential selection. The corresponding Amp. field name data type is "Array." A ClassificatorList variant allows multiple classificator selections.

Comments: The "(>50)" in the field type name indicates this is intended for lists with more than 50 options. For smaller lists, use DropDownList or CheckBoxList instead.

See also: Form configuration guide

RadioButtonList

English: RadioButtonList | Eesti: Raadionupuloend Module: Admin (Form Configuration) | Audience: admin

A form field that presents mutually exclusive options as radio buttons, allowing the user to select exactly one option. The corresponding Amp. field name data type is "Number." Options can be added, edited, made inactive, and reordered. Default values can be set.

Comments: No known terminology inconsistencies.

See also: Form configuration guide

PersonChooser

English: PersonChooser | Eesti: Isikuvalija Module: Admin (Form Configuration) | Audience: admin

A form field that allows selecting a single person from the system. When added to a form, it creates a panel with three dropdowns: Organization, Department, and Name. The corresponding Amp. field name data type is "Number."

Comments: No known terminology inconsistencies.

See also: Form configuration guide

PersonChooserList

English: PersonChooserList | Eesti: Isikuvalija loend Module: Admin (Form Configuration) | Audience: admin

A form field that allows selecting multiple persons from the system. Unlike PersonChooser (single selection), PersonChooserList supports configurable height and character count limits. The corresponding Amp. field name data type is "Array."

Comments: No known terminology inconsistencies.

See also: Form configuration guide

HtmlEditor

English: HtmlEditor | Eesti: HTML redaktor Module: Admin (Form Configuration) | Audience: admin

A rich-text editor field on an Amphora form that allows formatted text input including fonts, styles, tables, and embedded content. The corresponding Amp. field name data type is "Number." HtmlEditor is used when document writing forms need an in-form text composition area.

Comments: The HtmlEditor data type is "Number" which may seem counterintuitive -- this is an Amphora-specific mapping, not a reflection of the field content.

Templates & Output

DOCX Template

English: DOCX template | Eesti: DOCX mall Module: Admin (Templates) | Audience: admin

A Microsoft Word (.docx) document template that uses template elements (placeholders) to automatically populate document content from Amphora form field values. DOCX templates support two types of template elements: colon-style elements (::FIELDNAME::) and Word Quick Parts. Templates are uploaded to Amphora under Admin -> Templates and linked to specific forms. They can be set as default templates.

Comments: DOCX templates created for SPOKU forms follow the same process as regular forms. Template file size over 200 KB triggers a warning; critical size starts at 8-9 MB.

HTML Template

English: HTML template | Eesti: HTML mall Module: Admin (Templates) | Audience: admin

A template displayed in the text editor when writing a new document using a writing form. HTML templates use ::FIELDNAME:: placeholders that are replaced with form field values when the user clicks "Add to template." They support static template elements (e.g., ::CURDATE::, ::CURUSER::), locked text (prevents user editing), and images in base64 format. The "Locked text" option is exclusive to HTML templates.

Comments: HTML templates only work with document writing forms (Written document category). The meta element within HTML templates must use the charset=utf-8 format for correct conversion.

Template Element

English: Template element | Eesti: Mallielement Module: Admin (Templates) | Audience: admin

A placeholder token in a template that gets replaced with actual data from a document's form fields when the template is rendered. Template elements are written in the format ::ID_IN_TEMPLATE:: where the ID corresponds to the "ID in template" value configured on each form field. The ID must not use accented letters or special symbols (except numbers and underscores). Capital letters are recommended.

Comments: Each form field must have an "ID in template" configured before it can be used in templates. Template elements can be added manually or via the Field dropdown menu in the template editor.

Static Template Element

English: Static template element | Eesti: Staatiline mallielement Module: Admin (Templates) | Audience: admin

A predefined template placeholder that is not linked to a specific form field but instead pulls system-level data. Available static elements include: ::CREATEDATE:: (document creation date), ::CURDATE:: (current date), ::CURDATETIME:: (current date and time), ::CURTIME:: (current time), ::CURUSER:: (logged-in user name), ::CURUSERPHONE:: (phone), ::CURUSEREMAIL:: (email), ::CURUSERORG:: (organization), ::CURUSERJOB:: (job title), ::ACLCAUSE:: (access restriction basis), ::ACLSTART::, ::ACLEND::, and ::ACLOWNER::. The ::SOURCE.EDITOR:: element is used in response document templates.

Comments: ACL-related static template elements were added in version 13.4.3.

Quick Parts

English: Quick Parts | Eesti: Quick Parts Module: Admin (Templates) | Audience: admin

A Microsoft Word feature used in Amphora DOCX templates as an alternative method for inserting template elements. Word Quick Parts are document properties or custom fields that Amphora replaces with form field values when generating a document. They provide a more Word-native approach compared to colon-style (::FIELDNAME::) template elements.

Comments: Quick Parts and colon-style template elements achieve the same result using different mechanisms. Quick Parts may be preferred when template authors are more comfortable with Word's built-in features.

External Communication

Letter

English: Letter | Eesti: Kiri Module: Documents | Audience: admin, end user

A document type used for official incoming and outgoing correspondence in Amphora. Since version 12.7, letters are registered in the Documents module using the "Letter" form. There is one unified Letter form that should be used for all letter registration. Letters use correspondence counters for numbering and can be sent via DHX, email, or the Self-Service Portal. The Letter form has the DHX document type selected by default.

Comments: "Letter", "Correspondence", and "Message" overlap in historical documentation. The legacy Correspondence module used separate forms for different letter types. The current Documents module uses a single "Letter" form. Old guides may reference "correspondence directories" and "message counters" which still function but belong to the deprecated module.

Incoming Letter

English: Incoming letter | Eesti: Sissetulev kiri Module: Documents | Audience: end user

A letter received from an external party and registered in Amphora. Incoming letters can arrive via DHX, email, or manual registration. Documents received through KOVMEN and SPOKU integrations are typically registered as incoming letters with associated automatic processes and responsible person assignments.

Comments: In the legacy Correspondence module, incoming letters had a distinct form. In the Documents module, the unified "Letter" form is used with metadata indicating the direction.

Outgoing Letter

English: Outgoing letter | Eesti: Valjaminev kiri Module: Documents | Audience: end user

A letter sent from the organization to an external recipient. Outgoing letters can be delivered via email, DHX, or the Self-Service Portal. When sending to multiple addressees, the system by default sends a separate letter to each addressee (blind copy behavior). To make addressees visible to each other, remove the "Separate letter to each addressee" option and use the Recipient or Cc fields.

Comments: Response letters get specially marked numbers (registration number + suffix) when the "Count response letters" option is enabled on the counter.

E-invoice

English: E-invoice | Eesti: E-arve Module: Invoices | Audience: admin

An electronic invoice in standardized format that can be exchanged between Amphora and external financial systems. E-invoices follow Estonian e-invoicing standards and can be processed through the Invoices module.

Comments: Do not confuse with regular invoices managed in the Invoices module. E-invoice specifically refers to the standardized electronic format for automated processing.

Self-Service Portal

English: Self-Service Portal | Eesti: Iseteenindusportaal Module: Self-Service | Audience: admin, end user

An external-facing environment accessible to individuals who are not Amphora users, located at the organization's Amphora URL with "/externalparty.aspx" appended. Person identification uses ID-card, Mobile-ID, or Smart-ID, and the person must exist in Amphora's Persons module. The portal supports three functions: reviewing documents sent for information (electronic delivery), signing documents, and submitting applications using Amphora forms. Application submission is a paid service (240 EUR + VAT one-time connection fee).

Comments: Amphora internal users can also access the Self-Service Portal via the "Self-service" link in the left menu. Process tasks sent to external persons are limited to "for signing" and "for information" types.

See also: Self-Service Portal guide

Mailgun

English: Mailgun | Eesti: Mailgun Module: E-mails | Audience: admin

An external email delivery service that can be integrated with Amphora for sending email notifications and letters. Mailgun handles the actual email transport when Amphora needs to deliver notifications about tasks, process updates, or Self-Service Portal access links to users and external persons.

Comments: Do not confuse with Amphora's internal E-mails module. Mailgun is a third-party service for email delivery infrastructure.

WebDAV

English: WebDAV | Eesti: WebDAV Module: Documents | Audience: end user

A protocol that enables in-place editing of document main files directly from Amphora without downloading and re-uploading. The "Edit" link next to a document's main file opens the file in a local application (e.g., Microsoft Word) through a WebDAV connection. Requires the IT Hit Edit Doc Opener 5 extension to be installed and enabled in the browser.

Comments: If clicking "Edit" prompts a message about protocol installation, the WebDAV program or extension needs to be installed. The extension name is "IT Hit Edit Doc Opener 5."

Glossary

Amphora Modules

Documents

Correspondence

Case View

DHX

Invoices

Calendar

Projects

Discussions

Archive

E-mails

Public View

Estonian Integrations & Acronyms

DHX (Document Exchange Protocol)

KOVMEN

SPOKU

X-Road / X-tee

GovSSO

VOLIS

MTA

RIA

SiGa

Authentication & Identity

ID-card

Mobile-ID

Smart-ID

Entra ID

Personal Identification Code

Document Management

Catalog

Unit

Form

Counter

Registration

Main File

Additional Files

Version

Access Restriction

Loading Method

Info Presentation

Registration Profile

Workflows & Processes

Procedure / Process

Delegation

Forwarding

Coordination

Automated Process

Task Types

Conditional Task

Deadline

Responsible Person

Substitute

User Management & Rights

User Group

Policy

Role

Superuser

Main User

End User

Rights Hierarchy

Passive User

Form Field Types

TextBox

CheckBox

Dropdown

Classificator

RadioButtonList

PersonChooser

PersonChooserList

HtmlEditor

Templates & Output

DOCX Template

HTML Template

Template Element

Static Template Element

Quick Parts

External Communication

Letter

Incoming Letter