Restrict connector access to essential records: Grant API and record permissions only for required data types and operations.; Use HubSpot’s 'Their [Objects]' setting to limit contact access to owned records.; Verify token claims via jwt.ms to confirm restricted permissions in Microsoft Entra.
Image: Workflow Automation Guide

Authentication

Part of Workflow authentication and secrets

Limiting a connector's access to required records

A connector should read or change the smallest useful set of records.

Give the connector only the data types, operations and records required by each workflow step. Enforce that boundary through API permissions and the connected account’s record permissions, not just a filter in workflow logic.

Write the access matrix

For each workflow step, record the data type, operation, allowed records and reason. Keep read, create, edit and delete separate: copying approved invoice totals does not justify write access to every customer record.

A HubSpot example matrix row is: data type, Contacts; operation, View; record set, “Their [Objects]”; reason, let a sales rep communicate only with contacts they own. HubSpot says users with this setting see their assigned records on index pages, in the segments tool and in reports.

In HubSpot, open the CRM tab and expand Contacts to configure object permissions. Edit can be set to “Their [Objects]”, “Their team’s [Objects]”, “All [objects]” or “None”; Delete has those options too, while Create is controlled by a separate toggle. Leave operations disabled or restricted when the workflow does not need them.

In Microsoft Entra, configure API permissions on the App Registration for the workflow’s required operations; application permissions require admin consent. To check the token, use jwt.ms: application permissions appear in the roles claim, while delegated permissions appear in scp. Microsoft’s examples include User.Read.All in roles and Directory.Read.All User.Read in scp; treat these as examples, not a grant list.

For Power Apps and Power Automate on-premises data access, the ASD Blueprint calls for a service account for network access and database service-account access. Review both accounts’ permissions against the workflow’s required resources and operations: a narrow API permission cannot compensate for an account that can query every record.

Test denial and change

Choose a safe test record outside the permitted set and attempt the connector’s retrieval or update action. Confirm that access is denied and that the permitted operation succeeds; a workflow filter alone does not prove the underlying credential is restricted.

For Microsoft Entra, inspect the token claims with jwt.ms and compare the permission names with those configured on the App Registration. This verifies the permissions in the token, while the test record checks the connector’s access to records.

Document any capability the platform cannot restrict. When the workflow expands, revisit the matrix before adding permissions.

Assign a named owner for access reviews. OWASP’s Secrets Management Cheat Sheet recommends centralising secrets management to control access and support auditing; shared secrets can make the source of a compromise harder to identify.

Security Best Practices Summary

Shared Secrets Risk
High – harder to trace compromise source
Least-Privilege Principle
Enforce through API + record permissions, not just filters
Service Account Requirement
Use dedicated accounts for on-premises data access (e.g., Power Apps/Power Automate)

More from Authentication

Authentication

Comparing API keys with delegated and application access

Choose a workflow credential by asking whose authority the action should use and what it must be able to do.