1 The concept: registers instead of rigid forms
A register is a freely definable table. You decide the fields — Floriti automatically builds entry forms, list views, exports, reports and interfaces from them.
The core of Floriti is deliberately not preconfigured: there are no hard-wired screens. Instead you create registers (e.g. “Processing activities”, “Assets”, “Risks”, “Customers”) and define each register's fields with type, mandatory flag, order and logic. Everything else — form, table, search, export, report — emerges automatically.
Any number of registers, any fields — extendable at any time, no programming required.
Registers reference each other (link fields, matrices, VLOOKUP formulas).
Roles, areas, approvals and the audit log keep data clean and traceable.
Even registers with several 100,000 entries stay fast — lists, import and export are built for it.
2 Creating & managing registers
Under Administration → Registers you create registers and maintain their fields in the register editor.
The register editor
- General: name, description, section (groups registers in the sidebar), display field (which value represents an entry, e.g. in link lists), default editor (user or 👥 group), and the switch “✨ Offer AI form assistant in the questionnaire”.
- Fields: per field: label, type, mandatory yes/no, order (move with arrows), explanatory text (rich text, shown as guidance under the field), placeholder, default value, visibility condition, “hide in form” (for silent formulas), “show in register list”, “N/A allowed” and primary-key marker (for import matching).
- Approval workflow: enable it and define approvers (users or groups, with a default) — details in chapter 10.
- Public form / public view: see chapter 7.
Illustration: register editor with the General box (incl. ✨ switch) and field list.
Handy management features
“Structure only” or “structure incl. content” — ideal for templates and variants.
Export registers as JSON and import them into other instances — renamable on import.
Save the entire configuration (registers, entries, rules, workflows) as a template and restore it in any instance.
Restore or permanently delete removed entries per register — incl. “empty trash”.
3 All field types at a glance
Field types are the building blocks of every register — from simple text to linked registers and calculated formulas.
| Field type | Description & specials |
|---|---|
| Text / Text area | Single/multi-line input. With placeholder, default value and explanatory text. |
| Number | Numeric input — also usable in formulas. |
| Date | Date picker; usable in formulas, e.g. for deadline calculations. |
| Input with e-mail format. | |
| Select | Dropdown with fixed options. Optional: multi-select or rendering as buttons (with adjustable width) — great for workflow triggers. |
| Checkbox | Yes/no. Often a control field for conditions (“Other partners? → extra fields appear”). |
| Formula | Calculated field: expression over other fields, with IF, arithmetic and VLOOKUP/LINKED into linked registers. Optionally “hidden in form” (silent calculation), still shown in the register list on demand. |
| Link | Reference to entries of another register — as dropdown, list or with server-side search (fast even at 400k+ entries). Optional: multi-select, “create new” right from the form, filters (offer only matching target entries, AND/OR rules) and a default entry. |
| Matrix | Embeds a matrix register as a clickable grid inside the form (see chapter 4). |
| Direct link | Jump link to a specific entry of any register. |
| Info text | Display-only block (rich text) in the form — explanations, legal notes, instructions. Not counted as a question. |
| Divider | Section heading; structures the form into chapters and feeds the chapter navigation. |
| Area visibility | Controls which areas (compounds) can see an entry. |
4 Matrix registers
A matrix combines two registers into a clickable grid: X axis from register A, Y axis from register B, assignment by clicking a cell.
Typical uses: risk matrix (likelihood × impact), data subjects × data categories (GDPR), competence matrices. Matrix registers appear as their own menu item and can additionally be embedded as a matrix field in forms — each entry then stores its own cell selection.
- Colour grading: cells automatically coloured green/yellow/red — incl. manual override of individual cells (“this risk is red regardless of its position”).
- Section: matrices can be grouped into sidebar sections like registers.
- Enlarged view: the matrix field of an entry can be opened in its own full view.
Illustration: matrix with colour grading and clicked assignments.
5 Entering & maintaining data
Four ways lead to data: direct entry, questionnaires, public forms and the AI form assistant. This chapter covers working directly in the register.
The register list (table)
- Server-side pagination: even huge registers (tested with 400,000+ entries) load in milliseconds.
- Filtering: per field with operators (equals, not equals, contains, filled/empty, greater/less) — including a filter on the entry ID (e.g. “everything above ID 400”).
- Sorting by columns or manual ordering (custom sequence by moving entries).
- Bulk actions: edit or delete filtered entries collectively — set-based, even with tens of thousands of matches.
- Status colours: approved, pending, rejected, draft are colour-coded.
The entry form
- Chapter navigation: dividers create a chapter menu listing every question — in edit and view mode; clicking jumps to the question.
- Progress bar: counts only real input fields (no dividers, info texts or formulas) and only genuinely answered values. Plus a question filter “all / unanswered / mandatory / open mandatory”.
- Full-screen mode (⛶) for focused work — the AI assistant stays available.
- Field comments (💬) and file attachments (📎) directly on a field, plus attachments on the entry.
- Drafts: save intermediate states before requesting approval — drafts are visible only to their author.
- History: every change is traceable in the entry history and the central audit log (who, when, what — incl. field authors in collaborative editing).
- Invite additional editors: let colleagues or externals work on an entry via an e-mail link (no login required, token-secured).
6 Questionnaires: the same data, asked in a tailored way
A questionnaire is an alternative view of a register: a selection of fields, rephrased as questions — without duplicating the data structure.
- Field selection: a questionnaire contains a subset of the register fields in its own order.
- Overrides: per field its own label (“Which data do you process?” instead of “Data categories”), its own explanatory text and its own mandatory setting — only for this questionnaire.
- Info blocks & dividers: additional display blocks that appear only in the questionnaire (introductions, legal texts, chapters).
- Usage: questionnaires are attached to work assignments and invitations — different audiences get different views of the same register.
Questionnaire-workflow dynamics
Questionnaires, conditions and workflows interlock:
This creates a guided process: people answer only what concerns them; as soon as e.g. “incident reported” is selected, the workflow jumps to the next step, assigns the responsible group and notifies it — details in chapter 11.
7 Public forms & public views
Registers can be opened to the outside — for capturing (form) or reading (view). Entirely without a user account.
Public form
- Its own friendly URL (freely chosen slug), shareable via link or QR code.
- Captcha protection against automated submissions.
- Optional file attachments by submitters (via a switch on the register).
- Language selection right on the form — translations come from the register translations (chapter 17).
- Conditions and default values work like in the internal form; submissions land regularly in the register (optionally through the approval process).
Public view
- Read-only list of a register under its own URL — e.g. a public directory or status overview.
- Controllable per field whether it is publicly visible (“show in public view”).
8 ✨ AI form assistant & AI analysis
The AI reads documents and fills questionnaires — as a chat assistant right inside the form, or as an analysis tool for whole documents.
The chat assistant in the questionnaire
When a questionnaire opens, the assistant (✨ button bottom right, with a friendly speech bubble) offers its help:
- Hand over documents: via the 📎 button or drag & drop — even several at once (PDF, Word, text, Markdown, CSV). Or simply describe the case in your own words.
- Automatic filling: the AI extracts values for the still-empty fields — it never overwrites an existing value and never guesses: if information is missing, the field stays empty and the assistant asks a targeted question.
- Understands the form logic: fields hidden by conditions do not exist for the AI. If an answer activates new fields (e.g. “DPA in place” → contract partner), the assistant immediately reports them as open items.
- Links included: if the AI recognises e.g. an asset name, it links the existing entry — or offers, with one click, to create the asset.
- A dialogue with memory: the chat history is preserved; questions and answers build on each other. At the end the assistant summarises: what was filled, what is open, which documents would still help — plus filling tips.
Illustration: form with progress and AI chat — documents via drag & drop, follow-up questions in dialogue.
More AI tools
Upload whole documents — the AI proposes finished register entries; you review and adopt them (optionally with a review assignment for a colleague).
The AI analyses which fields are frequently empty and recommends which documents (contracts, concepts, lists) would fill them.
AI can be enabled per instance (cost protection with a monthly quota) and switched off per register via the ✨ toggle. Your data is not used for AI training.
The AI gets to know your company
Four building blocks make the AI company-specific — without any model training and fully under your control:
Upload company documents (policies, templates, concepts) as a knowledge source — for the entire workspace or targeted per register. The AI pulls the most relevant sections into its answers and names the sources (“company knowledge used”). Indexing happens directly on the server — your knowledge base never leaves it. The test search shows which passages are found for a question.
In the register editor you store binding rules for the AI per field: expected format, scope versus other fields, desired inferences (e.g. “country outside EU/EEA ⇒ third country = Yes”). Users never see these hints — the AI treats them as a mandatory checklist that outranks everything else.
Floriti automatically records whether AI suggestions were accepted, corrected or discarded — per field, with examples (AI value → final value). Fields with a weak rate are listed first: the candidates for an AI hint, with a direct link into the register editor.
Fixed test cases (material text + expected field values — also via drag & drop from files) safeguard AI quality permanently: a test run checks all cases against the current AI and shows the hit rate plus the change versus the previous run (▲/▼).
9 Conditions & formulas
Forms that think along: fields appear only when relevant — and values calculate themselves.
Visibility conditions
- Every field can depend on one or several other fields — combined with AND or OR.
- Operators: equals not equals filled empty.
- Conditions behave identically everywhere: in the form, the questionnaire, the public form, the approver view — and in the AI form assistant.
- Cascades are possible: field C depends on B, B on A.
Formula fields
- Expressions over field values in square brackets: [Price] * [Quantity]
- Case logic: IF([Location] = "DE", "domestic", "abroad")
- Pull values from linked registers: VLOOKUP / LINKED — e.g. the risk class of the linked asset.
- Formulas calculate live in the form and are stored server-side; “recalculate formulas” refreshes existing data.
- Silent formulas: “hide in form” + optionally “show in register list” — ideal for scores and traffic lights.
10 Approval process
Four-eyes principle per register: entries only take effect once approvers have released them.
- Approver pool: per register users and/or 👥 groups as approvers, with a default preselection. For groups, “one is enough” — any member can fulfil the slot.
- Multi-approver: several approvers per entry (“all must agree”), including override and a record of who decided for a group.
- Flow: editor saves a draft → “request approval” → approvers review in their own view (with progress and all answers) → approve or reject with a reason.
- Queries: approvers ask questions directly on individual fields; the editor answers and, via the 🔔 notification (“Reply”), lands directly in edit mode at the question concerned. Questions can be closed, the thread remains.
- Entry-specific approvers: individual entries can have deviating approvers.
- Status colours in all lists: approved · pending · rejected · draft.
11 Workflows: multi-stage processes
Workflows guide entries through defined steps — with automatic assignments, notifications and custom continue buttons.
- Steps: a workflow belongs to a register and consists of ordered steps (e.g. “Report → Assessment → Measures → Closure”).
- Triggers: a step starts when a field receives a certain value (e.g. select buttons “Status = Assessment”) — or via the continue button.
- Assignment: per step an editor group — members see the entry as a task.
- Notifications: notify groups per step, with a custom message (🔔 bell + e-mail).
- Forward/backward buttons: label freely configurable per step (“Hand over to business unit” instead of “Next”); going back is possible.
- Transparency: the workflow display in the entry shows the current step; every trigger is logged with user, time and value.
Illustration: workflow display with active step, group assignment and configurable continue button.
12 Rules: automation between registers
Rules react to entries and automatically create follow-up entries in other registers — including data transfer and assignment.
- Trigger: register + event (create/change) + optional field condition (field, operator, value).
- Action: create an entry in the target register, with field mappings (source field → target field).
- Automatic assignment of the new entry: to the creator, to people from fields of the source entry, to register approvers or to the editors of the source entry.
13 Reports, scheduler & e-mail dispatch
Registers become reports — on demand or automatically on a schedule, straight to the inbox.
Report builder
- Choose a primary register and compose columns — including fields of linked registers (e.g. a ROPA report with asset details).
- View reports on demand and download them as Excel.
Scheduler & dispatch
- Schedule per report (e.g. weekly, Mondays 07:00) — Floriti generates the report automatically.
- E-mail dispatch to defined recipients, with the report attached.
Illustration: scheduled reports with schedule, recipients and status.
14 Search, import & export
Find, bring in and hand out data — fast and permission-aware.
Global search
- Full-text search across all entries — right from the top bar.
- Permission-aware: everyone finds only what they are allowed to see (areas, roles, own drafts).
Import
- Excel/CSV import per register — processed in blocks and therefore suitable for very large files (tested with 400,000 rows).
- Primary-key field: existing entries are matched on re-import instead of duplicated; imports are repeatable.
Export
- Single entry: Excel, CSV or PDF — optionally with “include linked” (linked entries come along).
- Whole register: Excel, CSV, PDF (each entry on its own page) — generated as a stream, so it works reliably even for 400k registers.
- Everything at once: “All → Excel” (one workbook, one sheet per register) and “All → CSV (ZIP)”.
- Link overview: all register links as their own Excel/CSV evaluation.
15 User management: roles, groups, areas
Three building blocks control who sees and does what: roles (function), groups (assignment) and areas (data access).
Roles
| Role | Rights |
|---|---|
| Admin | Everything: build registers, manage users, all data, direct write access. |
| Approver | Reviews and approves entries of their registers; sees all entries there; manages the trash. |
| User | Captures and edits own entries via the approval process. |
| Direct editor | Writes directly to the register without the approval loop. |
| Assignment creator | Creates empty entries and distributes them as work assignments. |
| Translator | Maintains translations of structures and contents. |
Roles are combinable — a user can be approver and translator at the same time.
User groups 👥
- Groups bundle users and can be used wherever a single user is possible: as approvers (“one is enough”), assignment recipients, default editors, workflow editors, notification recipients.
- Membership changes take effect everywhere immediately.
Areas (compounds)
- Areas bundle registers into visibility packages assigned to users — e.g. the business unit sees only “ROPA + Assets”.
- Area members see the entries of their area registers (excluding other people's drafts); without an area a user sees only their own entries.
- Per entry, visibility can additionally be controlled via an area field.
16 Open interfaces & data sovereignty
Floriti is no silo: data flows in, out and in both directions — under control.
Connect registers with tables of external databases (e.g. Microsoft SQL Server): field mapping, direction and matching configurable — for leading systems such as ERP or CMDB.
Read-only views and capture forms under their own URL — token- or captcha-secured (chapter 7).
Provide report data for external evaluations (BI, Excel links) — kept up to date automatically.
Exchange register structures as JSON between instances — renamable on import.
Full database backup plus GDPR-compliant data export — at the push of a button in the admin area.
System mails (invitations, approvals, notifications, reports) via your SMTP dispatch, with test function.
17 Multilingual
The interface speaks 10 languages — and your content can too.
- Interface: German, English, French, Spanish, Italian, Polish, Dutch, Portuguese, Czech, Turkish — selectable per user, switchable in the top bar.
- Register translations (structure): translate register names, field labels, explanatory texts and select options into any target language — into all 10 languages, regardless of which language the instance was built in.
- Content translations: even the entry values themselves (e.g. for public views) are translatable.
- Auto-translate: machine suggestions at the push of a button, with a freely selectable source language — refinable manually afterwards. Translator role included.
- Public forms offer the language selection directly to submitters.
18 Administration & operations
The admin area bundles all management functions into six clear groups — present as navigation boxes on every admin page.
| Group | Functions |
|---|---|
| ⭐ Main group | Registers · Matrix registers · Users · User groups · Areas · Reports · Rules |
| 🌐 Translation & branding | Register translations · Translate contents · App branding (logo, colours, instance name) |
| ℹ️ Information area | 📜 Audit log · Link overview |
| 🔑 Licensing | Licences · 🔓 Activation |
| 🛠️ Boundary functions | External reporting · Backup · Transfer building blocks · Test e-mail · Demo area · External data sources |
| 📤 Export | All → Excel · All → CSV (ZIP) · Links Excel/CSV |
- Audit log: complete timeline of all actions (create, change, approve, restore, permanently delete …) with user, time, IP and field snapshots.
- App branding: own logo and appearance per instance.
- Mobile: the core areas (login, lists, forms, workflows, dashboard, public forms) are optimised for smartphones; the admin editors are deliberately desktop-oriented.