Multi-Site Alarm and Access-Control Service: Connect a Supabase Asset Register With Salesforce

What this looks like in fire, life-safety and security integrators

An integrator services several office buildings for a facilities group. A field app needs device identifiers and service history, while Salesforce needs customer-facing status. Some users cover the whole portfolio and others only one building. A replaced reader should retain its predecessor history without exposing restricted system details to every account contact. The register needs an accurate business model and tested access boundaries, not merely a copied Salesforce asset table.

Records, ownership, and update rules

Work through the process

1. 01
   Separate position and device

   Create distinct references for a door, panel location or other functional position and the equipment installed there. A replacement changes the device relationship while the position remains. This prevents service history from becoming ambiguous when equipment labels are reused.
2. 02
   Choose the CRM context to share

   Select the asset and service fields Salesforce users need for customer conversations. Keep restricted configuration, credentials and other sensitive operational details outside that broad summary. A successful sync should not expose every field simply because it exists in the source register.
3. 03
   Define permitted field edits

   Allow field personnel to submit verified identifier corrections or service evidence through the application's reviewed process. Decide which edits can become approved changes and which need asset-administrator review. Preserve the original value and evidence when resolving a disputed device identity.
4. 04
   Implement access independently

   Use Supabase grants and row policies for the actual user-to-site relationships. Keep the integration connection separate from client credentials and test cross-customer access explicitly. Authentication alone does not establish that a person may view every site associated with the same CRM company.
5. 05
   Reconcile replacements and delayed events

   Test a device replacement, an offline service submission and a reassigned customer relationship. Confirm that late evidence attaches to the device active at the time of the visit, not automatically to the current replacement. Verify the selected Salesforce object's supported change-detection and write behavior.
6. 06
   Review exported documents as well as database rows

   An asset register may link to service reports or supporting files that contain information beyond the summary fields. Apply the same project and role boundaries to those resources and test their direct access paths. Hiding a document link in the application does not establish authorization. The product owner should know which evidence may be shared with a customer and which remains restricted to authorized service or administrative personnel.

Handle the exceptions explicitly

Service note arrives after device replacement

Attach it to the correct historical device and visit rather than the latest asset automatically.

User moves to another property group

Update explicit memberships and verify the access change under the application's session policy.

Two assets share a handwritten label

Use reviewed identifiers and location evidence to resolve the ambiguity.

What to verify before expanding

• Current equipment and previous devices remain distinct.
• A customer user cannot read unrelated sites.
• Restricted operational fields stay out of the sales summary.
• Late service evidence attaches to the correct historical device.

Technical references

• Stacksync Supabase connection setup
• Supabase row level security
• Stacksync Salesforce connector requirements