Custom Field and Workflow Governance

A custom field now starts as a draft. A draft is invisible to every form, the API and the mobile app, which read active fields only, so you can build it up, name it and set its rules without anyone seeing a half-finished field. Publishing makes it live. From then on, Settings › Custom Fields › Governance shows each field’s usage, how many records hold a value, and the history of changes to its definition.

Some changes can break things: changing a field’s type, making it required or unique, retiring options that records still hold, or archiving a field that is in use. Before any of these, AWRA works out the impact and shows it, for example 1,240 vendors hold a value in this option. A workspace can switch on change approval, and then such a change is held as a request that a different person approves or rejects. Approval is off until a workspace turns it on. Permanent deletion of a field goes through the trash and its own approval.

In practice: a procurement team wants to make Tax PIN required on vendors. The impact preview shows 312 existing vendors have no value. The request is held, the head of procurement reviews it, rejects it with a note to fill the gaps first, and approves the same change two weeks later when the preview shows zero missing.

Eight field types join the existing ones. Person, department, warehouse and bin location store a link to a record in your workspace, so a field such as Site supervisor is a real person, not a typed name. URL, email, phone and barcode are text with a format checked on entry. Validation now includes a library of presets, such as a KRA PIN, a Kenyan national ID or mobile number, a vehicle registration, an IBAN or a SWIFT code, as well as cross-field rules (this date after that one) and date windows (no more than 90 days ahead). Imports of vendors, customers, assets, custodians, warehouses, locations and the chart of accounts accept custom field columns.

A field marked sensitive is masked in the trash and in the audit log, and each time someone reveals its value the view is recorded. A sensitive field can also opt in to encryption at rest. Encryption is off by default, and it has a cost you should accept knowingly: an encrypted field cannot be filtered, searched or reported on by its value, because the database only holds ciphertext.

Bulk edit sets a custom field on many records at once and records the batch: how many records, how many values, the errors per row, and the previous value of every field it changed. If the batch was wrong, roll it back and the previous values are restored. In practice: an asset manager sets Insurance policy number on 600 vehicles from a spreadsheet, realises the column was shifted by one row, and rolls the batch back in a single step before anyone relies on it.

Five industry workflow packs join the module packs: retail, distribution, manufacturing, NGO and pharmacy. Each is a set of ready workflows for that kind of organization. Before installing, the install preview shows each workflow in the pack and what it would do, so nothing goes live by surprise; installed workflows can be adjusted like any other.

A simulation suite is a set of saved test cases for a workflow, each with an expected outcome. Running the suite replays every case against the workflow as it stands now and records pass or fail on each. Nothing is executed: rules are evaluated with the engine’s own logic and branch actions report the branch they would take, so the suite cannot disagree with a live run about the path. Branch coverage shows the share of possible paths that at least one case reached, including rules matching and not matching, every named branch and each default.

In practice: a pharmacy installs the pharmacy pack and adjusts the controlled-medicine approval. The pharmacist adds three cases: a controlled item above the limit, a controlled item below it, and an ordinary item. The suite passes all three but shows 75% branch coverage, because no case reaches the out-of-hours branch. A fourth case closes the gap before the workflow is published.

No workflow goes live without a named owner and a runbook link, so whoever is called when it misfires knows who owns it and what to do. A backup owner is recommended, not required, so a one-person workspace can still publish, but if one is named it must be a different person from the owner. The same rule applies on every route to going live, including an approved change and a rollback.

The workflow observability dashboard (Workflows › Observability, also in the API and the app) shows how workflows are actually behaving over the last days: runs, successes, failures and stuck runs, throughput per day, SLA breaches, retried actions, connector failures and open dead letters, and the active workflows that have no backup owner. Suggestions the workflow AI made are kept in a review log, with what was suggested and what the person accepted, so an AI-drafted change can be traced to the person who approved it.

Workflow export and import now carry an environment map. A workflow exported from a sandbox names people, connectors and URLs that differ in production; on import, AWRA maps them to their counterparts and reports which mappings it made and which you must set by hand. In practice: an implementation partner builds an approval workflow in the sandbox, exports it, imports it into production, maps the sandbox approver to the real finance manager, and publishes it with that manager as owner and a link to the team’s runbook.