Client Control Surface: Airtable + Softr Build Checklist

Confirm Softr Professional+ (for Call API), an Airtable base, and a Make account. Create a dedicated Airtable service user + Personal Access Token (PAT) named “Service (Make)” and store the PAT + a shared secret (for webhook header) in a password manager.

Create base “Client Control Surface.” Table: Clients with fields: - Client (Primary, single line text) - Client_ID (Formula: RECORD_ID()) - Portal_Emails (Long text or multiple email; one per line) - Panic_Switch (Checkbox) - Notes (Long text).

Create table: Toggles with fields: - Toggle (Primary, e.g., “Send Weekly Report”) - Client (Link to Clients; enable ‘Allow linking to multiple records’ off) - Toggle_Record_ID (Formula: RECORD_ID()) - Current_State (Single select: ON, OFF) - Audit_Reason (Long text) - Last_Toggle_At (Last modified time; watch “Current_State” only) - Last_Toggle_By (Last modified by; watch “Current_State” only).

Create table: Metrics with fields: - Client (Link to Clients) - SLA_Target_Minutes (Number, 0–10,000) - Last_Run_At (Date/Time, include time, use GMT/UTC) - Run_Status (Single select: OK, Degraded, Failed) - SLA_Chip (Formula):

IF(
  {Last_Run_At},
  IF(DATETIME_DIFF(NOW(), {Last_Run_At}, 'minutes') <= {SLA_Target_Minutes},
     "🟢 SLA OK",
     "🟠 SLA Miss"),
  "⚪ No data"
)

Share the base with the “Service (Make)” user (Editor or higher). Add base-level fields where useful: - Updated_At (Last modified time, watch all) - Updated_By (Last modified by, watch all). Expect updates made via Make to show the service user in ‘Updated_By’ for clean audit chips.

In Make, add Scenario → Trigger: Custom Webhook named toggle_event. In the webhook settings, require header X-HCZ-Secret = [YOUR_SECRET]. Send a sample payload from any REST client to capture the JSON structure.

Add modules: (a) Airtable → Search records in Clients where Client_ID = {{client_id}}; (b) Router A: If Panic_Switch = true, return Webhook Response 423 Locked with {ok:false, reason:"panic_switch"}; (c) Router B: If not locked, Airtable → Update record in Toggles by Toggle_Record_ID to set Current_State = {{desired_state}} and Audit_Reason = {{reason}}; (d) Optional: update Metrics/Clients timestamps. End with Webhook Response {ok:true}.

Create a Softr app → Data → connect your Airtable base. Create User Groups: Admin and Client. Add users to groups (your email to Admin; client contacts to Client).

Add a page “Client Dashboard.” Add a List/Grid block bound to Toggles. Visibility: show to Client only. Data rules: filter to records where the linked Clients→Portal_Emails contains currentUser.email (and optionally a Client_ID URL param if you pass it). Add a card header showing Metrics→SLA_Chip and Last_Run_At for proof.

Inside the Toggles list item, add a Button block with Action: Call API (POST) to your Make webhook URL. Headers: Content-Type: application/json, X-HCZ-Secret: [YOUR_SECRET]. Body:

{
  "client_id": "{{Clients.Client_ID}}",
  "toggle_id": "{{Toggle_Record_ID}}",
  "desired_state": "{{#if (eq Current_State 'ON')}}OFF{{else}}ON{{/if}}",
  "actor_email": "{{currentUser.email}}",
  "reason": "Client toggle from portal"
}

Success message: “Updated. Check audit chips.” Error: show message from response.

Add an “Admin” page with lists for Clients, Toggles, and Metrics, plus a visible Panic Switch chip (Clients.Panic_Switch). Restrict the entire page (or sensitive blocks) to Admin only.

In Make, set maximum concurrent executions to preserve order if needed; understand Make’s webhook rate limits (bursts may 429). Use your secret header filter first in the Scenario; add simple retry (e.g., 2 attempts with short delay) on Airtable update failures.

As Admin, create one test Client + two Toggles. As a Client user, click the toggle button ON→OFF→ON, twice each. Verify in Airtable: Current_State flips correctly, Last_Toggle_At updates, and Last_Toggle_By shows the service user. Confirm Softr success/error toasts match webhook responses.

Flip Clients.Panic_Switch = checked. As the Client user, press the toggle; expect Softr error and no Airtable change. Uncheck Panic_Switch, then manually revert any wrong Current_State values (or add a one-click Admin ‘Reset’ button if desired).

Run 10–20 toggles while logging three timestamps: request_at (client click), received_at (Make: add a ‘now’ variable), and updated_at (Airtable Last_Toggle_At). Compute median and p95 round-trip; publish these on your Build page once measured.

Invite actual client users to the Client group; spot-check record filters per user; set sensible defaults in Toggles; and pin the Admin page behind group-only visibility. Document the service PAT rotation date and the secret header location for future maintenance.