Features
What datakumi does, how business users work with it, and how sign-in and access work.
| Area | What you get |
|---|---|
| Editing | Editable grid served a page at a time (any size of dataset), add/delete rows, dropdowns from domains, undo/redo (Ctrl+Z / Ctrl+Y, bulk edits included), fill down, bulk set / % / amount / find & replace over a selection or a filter |
| Rules | Primary key (composite OK), required columns, domains: enum, hierarchy (parent → child), reference (value must exist in another table), parent (a parent-child hierarchy inside the dataset) |
| Validation | Type coercion, per-row errors with the offending key, typo suggestions ("activ" → "active"); invalid saves write nothing |
| Versioning | One save = one Delta version (single MERGE), history with user/comment/row counts, cell-level diff, rollback (as a new version); the dataset as of any date, and each record's validity history (_valid_from, _valid_to, who changed and approved it) |
| Hierarchies | A parent field holds the key of the record above (a chart of accounts, cost centres, an org): uneven depths, no loops, an optional maximum depth, and a parent can't be deleted while it has children. Its settings (the field's panel → Allowed values) also take the hierarchy's name, its level names (Class, Group, Account), a field only bottom-level records may have (such as Postable) and the only records allowed at the top (any other record without a parent is unassigned: an issue). A dataset can have several (a management and a statutory view of the same records). In the grid: Table / Tree shows the records in the hierarchy's order, indented, with arrows to fold branches (a search keeps each match's branch); a parent field shows the parent's name as a chip that opens it; a record with others under it says how many; the parent field's header has a tree icon; the dataset's header and Details say it has a hierarchy, with its levels and anything unassigned. Hierarchy opens the tree, where it's also reorganised: drag a record onto another (or use its menu: add under it, move, rename, delete), see what the move does first (its branch, from where to where, its new level, who reads the dataset, what stops it), and it goes into your draft like any other change, so rules, approval and history apply; publish it with an effective date to date a reorganisation. The tree shows each branch's size and, optionally, the total of a number field; on a past date as it was, on a future date with the approved changes scheduled until then; and changes since a date (added, moved, renamed, removed) |
| Lists that depend on another field | A field whose choices depend on another (category → subcategory) sits right after it, both with a band in their header; its header says what it depends on, and its cells show the path (Snacks › Chips). Changing the field above clears a value that no longer fits, in the same undo step |
| Field changes | Renaming a field, changing its type or deleting it needs approval on datasets that need approval (an owner or admin other than the requester), with what it affects; published copies keep a renamed field's old name for a notice period |
| For data teams | Each dataset registered in Unity Catalog or AWS Glue under a stable name, and exported as a dbt seed (CSV, column types, tests from the rules) committed to the dbt project's git repository: Admin → Integrations |
| Concurrency | Optimistic base_version check (409 if someone saved first) + per-table write lock |
| New datasets | From an Excel, CSV or TSV file, pasted cells, an empty table, or another dataset's structure. Finds the header row under titles, picks the sheet, suggests types, the key (checked for duplicates with line numbers), required fields and value lists to review before creating; owner, folder and approval set at once |
| Uploads | Your own spreadsheets as well as the template: columns matched by name, business label or close spelling, with a mapping step for the rest that's remembered per dataset; "update and add" or "replace" (missing records deleted, through approval); values that don't fit stay in the draft marked to fix, with "use X in all N" fixes; a downloadable list of problems by line |
| CSV | Dry-run preview, import good rows / report bad ones, partial-column updates (API) |
| Sign-in | Email + password (scrypt hashes, lockout after 5 failures, temporary passwords that must be changed), single sign-on with any OpenID Connect provider, personal API tokens for scripts |
| Access | Admins vs members; members get viewer / editor / owner access on all datasets, a folder, or one dataset, plus optional record limits |
| Approvals | Workflows of several steps (named people, roles, the dataset's owners; how many approvals each step needs), a person approves at most one step, SLAs with reminders and escalation to admins; risk tiers per field with automatic approval of small low-risk changes; approve or send back several at once; send back some records and approve the rest; Approve / Send back buttons in email, Teams and Slack; delegates while you're away |
| Impact | Before publishing: records in other datasets that would point at removed or renamed values, the pipelines / reports / applications that read the dataset, the published copy, overlapping drafts |
| Duplicates | Per field: Allowed or Not allowed. Not allowed refuses a value another record already has (ignoring case and surrounding spaces); existing duplicates show under Issues |
| Notifications | In the app, by email (SMTP), and to Microsoft Teams or Slack channels; each person chooses email now, a daily digest, or off |
| Other | Read-only SQL across tables (Polars SQL; CLI query and SDK), tamper-evident audit log, derive hierarchy from existing data, optimize + vacuum, English / Danish / German |