CRM permissions

CRM permissions decide who can enter the system, what they can do and which customer records they can reach. Start with the work each person must do, then grant only the access that work requires. A salesperson may need to update their own accounts without seeing every account; a sales manager may need broader visibility without permission to change system settings.

For every role, a permission design should answer three questions: Which records can this person see? Which actions can they take? Which information should remain restricted? Test those answers against real account scenarios before applying the design across a team.

Separate the layers of access

A record restriction is ineffective if another permission grants broad access. Making a field absent from a screen is not necessarily the same as restricting it in reports, exports or integrations. Check the user’s effective access through every relevant route, including team membership, sharing rules and inherited roles.

Treat access design as an organisational control

For organisations covered by the Privacy Act, APP 11 requires reasonable steps to protect personal information from misuse, interference and loss, and from unauthorised access, modification or disclosure.

The OAIC states that reasonable steps include technical and organisational measures. CRM settings are therefore only one part of the control: role definitions, approval responsibilities and review practices also matter.

When deciding which CRM information needs access controls, consider whether the organisation has possession or control of the record. The OAIC notes that APP 11’s meaning of “holds” extends beyond physical possession to records an entity has the right or power to control.

Key Compliance Requirements under APP 11

Build a role matrix from tasks

List the people who use the CRM: sales representatives, team leads, operations staff, administrators and any external partners. For each group, write down the actions they need to complete. Then choose the smallest practical record scope: their own records, their team’s records, a defined territory, selected shared accounts or the whole organisation.

Keep business ownership separate from system administration. Someone responsible for a customer relationship may need to assign follow-up work; that alone does not justify changing permission sets, integrations or account-wide sharing. Give each exception a named owner and a reason. If exceptions accumulate, revisit the role design rather than continually adding individual grants.

Customer records rarely stand alone. Test whether access to an account also reveals contacts, opportunities, notes, activities, files and reports. The right answer may differ by item. A partner who needs to update a shared opportunity may have no reason to see internal pricing discussions or unrelated customer emails.

Use concrete access tests

Create a small set of test records with clearly different owners and contents. For example, use one account in the user’s team, one in another territory and one shared across teams. Sign in as test users with the proposed roles and verify both allowed and denied actions.

Can each person find the records required for a hand-off? Can they edit only what their job requires? Can a report, search result, attachment or export expose a record that the main account view hides?

Repeat the test when a user belongs to multiple teams, a customer changes territory or a manager needs temporary cover. A permission scheme that works only for the simplest ownership case will cause either unnecessary exposure or delays in ordinary work.

The exact controls depend on the CRM and subscription. HubSpot, for example, documents team-based record access with a subscription condition. Treat product settings as implementation details to verify in the account being configured, not as a substitute for defining the intended access first.

Where HubSpot team-only record access is used, include a user who belongs to multiple teams in testing. That user can access records owned by any of their teams, and permission changes take effect after they log out and back in.

Handle exceptional access deliberately

External partners need a narrower decision: which named accounts, related records and actions are needed for a defined period? Prefer a named user account and a clear end date. Check files, reports and export rights as well as the account screen.

Administrators can change configuration and may reach sensitive data. Record who holds those rights, why they need them and who approves changes. Review grants when duties change, and inspect available audit history for unexpected permission or sharing changes.

When someone leaves, stop their access promptly, then transfer active customer responsibilities. Deactivation and record reassignment are different operations: a disabled user may still own records or appear in workflow rules. Preserve the customer history needed for ongoing work while reviewing personal information no longer required under the organisation’s retention obligations.

Keep the model current

Review permissions when teams reorganise, territories move, partners finish work, integrations change or users leave. A scheduled review is useful, but these events should also trigger one. Compare the intended role matrix with actual grants, and test a few representative accounts after significant changes.