datakumi

How business users work with it

Structure. Datasets live in folders (e.g. Commercial / Product master, Reference data) and carry business metadata: display name, description, owner (data steward), kind (master, reference, mapping), tags, column labels, sections and help text. The Relationships page draws how datasets reference each other.

Editing is always a draft. Grid edits, record-form edits, pasted blocks, bulk edits, new rows, Excel uploads, issue fixes and undos all land in the user's private, autosaved draft (per dataset). Nothing is live until they press Review & publish, which shows a business summary: counts, fields changed, percent moves with unusual (>=20%) changes flagged, a breakdown per market, conflicts with other people's edits and any rule problems.

Publishing follows the dataset's approval policy (Settings tab), one of three modes:

  • none: publish immediately (still versioned and audited)
  • every change: goes to Approvals and through the dataset's steps in order (e.g. a data steward, then Finance). Each step names people, roles and/or the dataset's owners and how many must approve. Nobody approves more than one step, nor their own change (unless the owner switch below is on); one rejection sends it back. With a response time (SLA), a waiting step reminds its approvers, and at twice that the admins are told.
  • by risk: each field is low, normal or sensitive (rated in its field panel, opened from the column header; unrated fields take a default), and a change takes the highest tier it touches (deletes are sensitive, new records at least normal). Low-risk changes of up to N records (default 50) that pass every rule are approved by the policy: recorded as a decision ("policy (automatic)") in the change request and the audit log, and the owners see each one in their digest. Normal changes go through the first step; sensitive ones through every step, and with a single step two different people approve.
  • a step never waits for more approvals than there are people who can give one (two approvers asked for, but only one person besides the author can approve: that one approval is enough)
  • Owners can approve their own changes (a switch in the Settings tab › Approval, off by default) for small teams where the owner also does the editing; their change still goes through the steps and is recorded as approved by them
  • datasets set up with the older "sensitive fields and deletes" mode read as by risk with the same effect
  • the draft bar says which of these applies before anyone presses publish ("Needs approval: Steward → Finance")
  • an optional effective date schedules it; a background job publishes it on the day

Deciding quickly, still governed. Requests to approve carry Approve and Send back buttons in email, Teams and Slack; they open the change request signed in, with the decision ready to confirm (they never decide on their own, so mail scanners that follow links can't approve anything). On Approvals a reviewer can approve or send back several change requests at once, each checked and recorded on its own. Inside a change request they can send some records back to the author's draft with a comment and approve the rest. Under Settings › When you're away, a person names a delegate until a date: the delegate can approve what they could (if the delegate can edit the dataset) and gets their requests and reminders; every decision still shows who made it.

Before anything is published, the review shows its impact: records in other datasets that would point at a value the change removes or renames, the registered consumers of the dataset (Settings tab › Consumers), its published copy, and other people's drafts touching the same records. Reviewers see the changes side by side and can comment on a single cell.

Duplicates are a rule on each field: Allowed or Not allowed (the key never allows them). Values that repeat in a field that doesn't allow them show under Issues as duplicates, and each issue can be assigned to someone who can edit the record (they can edit the dataset, and the record is within their record limits).

Change sets store per-cell patches, so an approved change only overwrites the cells it changed; anything someone else changed meanwhile is shown as a conflict.

AreaWhat it does
DashboardStat cards (open issues, to approve, your changes, datasets) with the catalog's shape beside them (datasets by kind, any without an owner); one row of your recent activity, recent changes (datasets added or changed) and popular datasets; then issues: by type, and the datasets that have them
DataGrid with business labels; what you can edit shows at a glance: an editable cell outlines like a field when you point at it (pick lists show a chevron), a locked column (the key, once a record is saved) has a lock in its header and recessed cells, and people who can only view see one "View only" tag; an approval mark per record (green ✓ approved, amber clock pending or changed in your draft, red ✕ rejected; hover for who and when, click for the record with its created / reviewed details; All / Pending / Approved / Rejected chips filter by it), dropdowns from rules (hierarchy-aware), paste from Excel, saved/shared views, bulk edit (set, +/- %, +/- amount, find & replace, clear), Excel template download/upload; owners can add fields (a new version; existing records empty or filled with a value) and delete them from the field's panel: it first shows what deleting does, or what stops it (the key, another dataset's list taking its values from it, a list depending on it, record limits) and what to do instead; you type the field's name to confirm. The deletion is a new version; its rules and settings go, open drafts and saved views stop using it, and Restore field in History adds it again with its values and settings. Each field's header has a settings button that opens its panel (owners edit and save it there, others read)
Record panel⤢ on a row: the record's problems to fix, per-record history with one-click Undo, comments with @mentions, and related records in other datasets (its values are edited in the grid)
Dataset tabsData (the grid and your draft); Approvals (your draft, change requests waiting or scheduled, access requests, recently published; a change request opens and is decided here); Issues (records to fix, including duplicates where a field doesn't allow them); History (versions); Settings (overview, approval, access, published copy, consumers; owners edit, others read). A banner above the dataset shows what's waiting for your approval on it
FieldsA panel per field, opened from its column header: business name, help text, section, example; technical name and type (changing it converts every value in a new version, or lists the records that can't convert); key and required; allowed values (a list, depends on another field, or from another dataset); Duplicates: Allowed / Not allowed (not allowed: no two records may have the same value, ignoring case and spaces; new duplicates are refused when saving and existing ones show under Issues; the key never allows them); access; approval risk; included in the published copy. Saved from the panel, after warning about records the new rules would break
Change requestsLive in their dataset (Approvals tab, #/tables/<name>/approvals/<id>) from draft to live: write the note and publish or submit while it's a draft, follow the approval steps, decide, then see it live. The Approvals page is the overview across datasets and leads there; old #/changesets/<id> links (emails, Teams, Slack) open it in its dataset
ApprovalsChange requests, field changes, moves and access requests waiting for you, your own requests, scheduled changes
History(the History tab) Versions with author, approver and change request; cell diff; browse a past version; Undo a version (into your draft); restore the whole dataset (owners)
IssuesRule violations and duplicates across datasets, one-click fixes from suggestions, assign (to people who can edit the record), dismiss, health and trend per dataset
SearchCtrl+K: datasets, pages and records across all datasets
CollaborationNotifications (approvals, mentions, assignments, published changes), presence ("Anna is editing"), dataset discussion
UsersAdmins add users (temporary password or SSO only), make admins, reset passwords, deactivate, and give access; each user's effective access and why; one access editor for users, roles and a dataset's Access (Settings tab); Request access: people who can see a dataset ask for edit or owner access with a reason, its owners (admins, for owner access) approve or reject it from Approvals; field limits per field (its panel → Access): who can see a field and who can change it, everyone the dataset allows or only chosen people and roles (owners and admins always can; the key is never limited). Hidden fields are left out of everything that person reads (grid, records, exports, search, SQL, history, change requests, comments, issues); fields they can't change show a lock and are refused in every edit, paste, upload and API call
NavigationSidebar: Dashboard, Issues, Approvals, Favorites (star a dataset to pin it); Datasets (folder tree with + and folder-settings icons on hover, drag to rearrange, scrolls on its own as it grows; Relationships). At the bottom, your account (opens Settings, and Admin for admins) and Sign out on one line. Settings is yours alone and laid out like Admin, one section at a time from a menu on the left (account, appearance, notifications, when you're away, password, API tokens; #/settings/<section>); Admin has Users, Storage and published copies, notification channels and the audit log; folders are set up from the dataset tree