Approval Workflows
Two entirely different approval systems share the word "approval" — one gates schema changes, the other gates entry data. This page covers both.
Part 1 — Schema/Revision Approval
When a non-admin edits a SmartTable's schema, the change is versioned but held back from users until an admin approves it.
Why It Exists
Every SharePoint refresh or settings change creates a new smarttable version (see Refreshing a SmartTable). If a SmartTable Admin (rather than a System Admin) makes that change, it doesn't go live immediately — it's held as a pending revision until someone with approval rights reviews it. This prevents an unreviewed schema change from silently altering a smarttable everyone else is actively using.
The versioning underneath
Each refresh creates a new entry-version row carrying its own full field schema and an approved flag, rather than overwriting the previous one in place. Every existing entry stays permanently linked to the specific version it was created under, so an unapproved (or even a later-rejected) revision can never retroactively change how an already-submitted entry's data is interpreted — only newly created entries pick up whichever version is currently approved. This is also why a rejected revision doesn't need any cleanup step: the smarttable simply keeps pointing at the last approved version, and the rejected one is just an unused row.
A brand-new smarttable (created for the first time from a SharePoint URL, not a refresh of an existing one) goes through the same approval gate at the smarttable level itself, not just at the version level — until approved, it exists but isn't live for anyone but its creator and approvers.
Status Icons
A small icon next to each smarttable name in the sidebar shows its approval state:
| Icon | Meaning |
|---|---|
| ✅ Green check | SmartTable is approved and live |
| 🟠 Orange, clickable | A new revision is pending approval (visible to approvers) |
| 🟡 Yellow, not clickable | SmartTable is not yet approved (visible to non-approvers, informational only) |
Approving a Revision
- Click the orange pending-revision icon next to the smarttable name
- The Approve Revision modal opens
- Optionally add a comment
- Choose Approve or Reject
Part 2 — Entry-Level Approval Workflow
A full multi-step sign-off chain for an entry's data, configured per SmartTable in Settings → Approval.
Turned on via Enable Multi-Step Approval in SmartTable Settings's Approval tab. Once enabled, a submitted entry doesn't count as finally approved until it's cleared every configured step, in order.
Step 0 — the submitter-chosen approver
An optional first gate, separate from the numbered steps below: before submitting, the user filling in the entry must pick who should approve it first. That person approves, and only then do the configured Approval Steps begin. A separate toggle, Notify step 0 approver(s) when subsequent steps are approved, controls whether that person keeps getting notified as the entry moves through the rest of the chain or is only involved at the start.
Approval Steps
Add as many numbered steps as needed with + Add Step. Each step independently configures:
| Setting | Description |
|---|---|
| Approvers | Which users can act on this step |
| Any one approves vs. All must approve | Whether a single approver's decision clears the step, or every listed approver must individually approve before the step is considered done |
| Notify these approvers when later steps are approved | Same idea as step 0's notify toggle — keep this step's approvers in the loop as the entry moves further down the chain, or not |
Steps run in order — step 2's approvers can't act until step 1 is fully cleared.
Interleaved Mode
A separate toggle: Interleaved Mode — Each data entry step requires approval before the next step unlocks. This only matters for a SmartTable where data entry itself happens in stages (multiple observations, or a multi-part form filled in over time) — with Interleaved Mode on, each data-collection stage must clear its own approval before the next stage of data entry even becomes accessible, rather than all data being entered first and the whole thing approved at the end as one lump. This is what a "step" being tied to a specific entry_step rather than the generic post-submission approval means under the hood.
entry_step here.
Acting on an Approval
Approvers act the same way described on the Notifications page — via a notification with Approve/Reject action buttons, optionally with a comment and/or a signature attached to that specific decision.