1) A readable audit trail without extra fields
What: Keep a simple change log per record as JSON (who changed what, and when).
Why: Easier reviews and handoffs; no more scattering “_old/_new” fields across the table.
How: On commit, append one JSON entry to an “AuditJSON” field.
// Append one change entry (example for a Status change)
Set Variable [ $entry ;
JSONSetElement ( “{}” ;
[ “timestamp” ; Get ( CurrentTimestamp ) ; JSONString ] ;
[ “user” ; Get ( AccountName ) ; JSONString ] ;
[ “field” ; “Status” ; JSONString ] ;
[ “from” ; $$old_Status ; JSONString ] ;
[ “to” ; Status ; JSONString ]
)
]
Set Field [ Table::AuditJSON ; List ( Table::AuditJSON ; $entry ) ] // one JSON per line
2) A safe outbound “API outbox” (with retry)
What: Queue JSON payloads for external systems (ERP/CRM/shipping) with a status flag: Queued, Sent, Failed.
Why: Network hiccups happen; a queue prevents lost or duplicate updates.
How: Write payloads to an Outbox table; a server script (or Claris Connect) posts and updates status.
Set Variable [ $payload ;
JSONSetElement ( “{}” ;
[ “orderId” ; Orders::OrderID ; JSONString ] ;
[ “total” ; Orders::Total ; JSONNumber ] ;
[ “items” ; Orders::ItemsJSON ; JSONObject ] // your own items JSON
)
]
New Record/Request
Set Field [ Outbox::Endpoint ; “https://api.example.com/orders” ]
Set Field [ Outbox::Payload ; $payload ]
Set Field [ Outbox::Status ; “Queued” ]
3) Validate incoming JSON before it touches your fields
What: Confirm required keys and data types with JSON functions.
Why: Protects your schema; stops odd values at the door.
How: Use JSONListKeys and JSONGetElementType to check presence and types.
Set Variable [ $body ; $$IncomingJSON ]
If [ PatternCount ( ¶ & JSONListKeys ( $body ; “” ) & ¶ ; ¶ & “email” & ¶ ) = 0
or JSONGetElementType ( $body ; “email” ) ≠ “string” ]
Show Custom Dialog [ “Incoming JSON missing a valid email.” ]
Exit Script
End If
4) Drive picklists and rules from JSON (no schema change)
What: Store business rules (allowed statuses, thresholds) in JSON so small changes don’t require schema edits.
Why: Faster updates; fewer trips through the relationship graph.
How: Keep rules in a Settings table, load to a global on first use.
// Settings::RulesJSON example: { “StatusOptions”: [“New”,”Packed”,”Shipped”] }
Set Variable [ $$rules ; Settings::RulesJSON ]
Set Variable [ $$statuses ; JSONListValues ( $$rules ; “StatusOptions” ) ]
// Use $$statuses in a value list or custom UI
5) Hand a “view model” to a Web Viewer
What: Build a small JSON view model for a record and let HTML/JS render cards or charts.
Why: Clear separation: FileMaker gathers data; the viewer handles visuals.
How: Assemble JSON and pass it as a parameter or via a global field.
Set Variable [ $$vm ;
JSONSetElement ( “{}” ;
[ “customer” ; Customers::Name ; JSONString ] ;
[ “balance” ; Customers::AR_Balance ; JSONNumber ] ;
[ “orders” ; Customers::RecentOrdersJSON ; JSONObject ] // prebuilt JSON
)
]
// Web Viewer page reads $$vm and renders
6) A tidy JSON summary for BI (Power BI/Tableau)
What: Normalize your data once into JSON and expose it via an OData layout for BI tools.
Why: One shaping step in FileMaker keeps dashboards simple downstream.
How: Write a “staging” JSON per row in a BI_Staging table that your OData layout publishes.
Set Variable [ $row ;
JSONSetElement ( “{}” ;
[ “OrderID” ; Orders::OrderID ; JSONString ] ;
[ “ItemCount” ; ValueCount ( JSONListValues ( Orders::ItemsJSON ; “” ) ) ; JSONNumber ] ;
[ “OrderDate” ; Orders::OrderDate ; JSONString ]
)
]
Set Field [ BI_Staging::RowJSON ; $row ] // include this field on the OData layout
How to try this (quick plan)
Pick one use case above (audit trail or validation is a good start).
Build a small script in a copy of your file; test with a few records.
If it helps, add a Claris Studio form or a Claris Connect step to round out the flow.
Share a short demo with your team and note the time saved or errors avoided.
Note on sample code
The snippets below are examples. You’ll need to adapt names and context to your solution before running them. In particular, update:
Layout names (e.g., Orders_list, Customers_edapi)
Table occurrences and field names (paths used in JSON and scripts)
Portal/table occurrence names for portalData and related writes
Privileges and triggers (who can run it, when it should fire)
Error handling (Get( LastError ), logging, retries)
Publishing context for BI (place fields on your OData layout)
Web Viewer handoff method (global field, script parameter, etc.)