Data Builder for Perfex CRM By Head Random • 2026-05-09 5:58 AM

Mastering Per-Table CRUD Permissions in Perfex CRM

The Danger of the Global "Write Access" Toggle

When connecting external applications—like Zapier, mobile apps, or custom portals—to your CRM, the most common security risk is over-provisioning. Many REST APIs offer a simple binary choice for API tokens: Read-Only or Read/Write.

If you need an automation tool to create new Leads, you are forced to give it global write access. But what happens if that tool gets compromised or misconfigured? Suddenly, it has the power to overwrite Invoices, delete Clients, or modify Staff records.

This violates the Principle of Least Privilege.

Granular Per-Table Permissions in Data Builder

To solve this, Data Builder for Perfex CRM replaces the risky global "allow write" toggle with a strict, granular Per-Table CRUD Permission Matrix.

Every API Token in Data Builder now has its own permission set mapped directly to the database tables. You can precisely control whether a token can perform:

  • READ (GET)
  • CREATE (POST)
  • UPDATE (PUT)
  • DELETE (DELETE)

Example Use Cases:

1. Lead Generation Webhook (Make.com)

  • Token setup: Grant CREATE only on tblleads.
  • Result: The integration can insert new leads from your landing pages but has zero ability to read, update, or delete existing leads, nor can it touch invoices or payments.

2. Custom Client Portal App

  • Token setup: Grant READ on tblclients, tblinvoices, and tblprojects. Grant UPDATE on tblclients (so they can update their profile).
  • Result: The portal can safely pull required data and update client info, but it cannot delete invoices or create new projects.

3. Third-Party Accounting Sync

  • Token setup: Grant READ on tblinvoices and tblpayments. Grant CREATE on tblexpenses.
  • Result: Accounting software pulls invoice data and pushes new expenses, without jeopardizing HR or support ticket data.

Defense in Depth: 6-Layer Sensitive Table Protection

What if an admin accidentally grants DELETE access on tblstaff to an API token?

Data Builder assumes human error is inevitable. Therefore, it implements a 6-Layer Sensitive Table Protection mechanism for critical system tables (tblstaff, tblcontacts, tbloptions, tbldata_builder_api_tokens).

Even if a token is granted write access in the UI, the API gateway enforces protection through:

  1. ResourceNameResolver — Centralized sensitive table registry.
  2. Api_tokens controller — Server-side enforcement that forces CUD (Create/Update/Delete) to false on sensitive tables for any user other than the Super Admin (ID = 1).
  3. AdminSessionBypassMiddleware — Restricts CUD operations for non-ID-1 admin sessions.
  4. ScopeVerifierMiddleware — Rejects any POST/PUT/DELETE payload to protected tables with a 403 Forbidden error.
  5. Resource Controller Double-Check — Final validation before query execution.
  6. GraphQL Schema Omission — Mutation fields for sensitive tables are entirely omitted from the schema.

Secure by Default

When building API-first workflows, trust should be explicit and scoped. By leveraging Data Builder's per-table permissions, you can confidently integrate your Perfex CRM with external tools knowing your sensitive data is cryptographically protected and operationally isolated.