Granular CRM permissions matter when the team includes regulated roles, external contractors, or multi-tenant customer scenarios. Strkr ships role-based access control, record-level sharing, workspace-plus-entity hybrid permissions, and audit log capture of every record read and write.
A team with granular permissions requirements has usually been burned by a prior CRM. The compliance team found that reps could see sensitive financial fields they should not see. The legal team found that external contractors had access to competitive deal data. The security team found that the audit log did not actually capture record reads. The sales ops team found that permission changes required an engineering ticket. The pain points below are what Strkr onboarding hears on every granular-permissions intake call.
Most CRMs ship role-based access control at the object level: a role either reads the Opportunity object or does not. The field-level control is either absent or buried in enterprise-tier add-ons. Strkr Layouts (Phase 1 shipping, Phase 2 in flight) exposes field-level permissions where the sales admin controls which role sees which field without an engineering ticket.
A sales contractor hired to work a region needs CRM access scoped to their region without seeing deals in other regions. Most CRMs model this with record ownership which breaks on shared accounts. Strkr ships workspace-plus-entity hybrid permissions where the contractor sees their workspace plus specific entities (accounts, deals, contacts) shared explicitly.
A marketing agency serving 11 clients each with their own CRM-managed data needs client-scoped isolation. Each client sees only their own data. Most CRMs do not model multi-tenant isolation. Strkr ships multi-tenant workspace architecture where each client lives in a workspace scoped by permission with explicit cross-workspace sharing for agency admins.
Compliance audits ask whether a user accessed a record on a date. Most CRM audit logs capture record writes (create, update, delete) but not record reads (view, export, print). Strkr audit log captures both reads and writes with 90-day default retention tunable per tenant to the compliance-required ceiling.
A legacy CRM permission change often routes through an engineering ticket because the permission model is embedded in custom code. Simple requests take 6 to 11 weeks. Strkr admin console exposes permission changes as self-service: role creation, role assignment, record sharing rules, and (on Layouts) field-level permissions all configure in minutes.
Sales management hierarchy drives visibility: an AE sees their book, a sales manager sees their team, a VP sees their division. Most CRMs model this with role hierarchy that only works for simple cases. Strkr ships manager_id self-reference on the user record with BFS (team) and direct-reports (immediate team only) scope options for forecast and reporting.
Strkr permissions run through seven layers that work in combination: workspace, role, record ownership, record sharing, team membership, field-level (on Layouts roadmap), and manager hierarchy. The cards below describe each layer.
A workspace is the tenant boundary: all data in a workspace is scoped to users with workspace access. For agencies serving multiple clients each client lives in a separate workspace. For enterprises with regional divisions each region can live in a separate workspace with explicit cross-workspace sharing where needed.
A role is a permission bundle (view Account, edit Account, delete Account, view Opportunity, create Opportunity, and so on across 54 resource types with CRUD granularity). Strkr ships seven default roles (admin, manager, AE, SDR, SE, CSM, RevOps) with per-tenant customization. New roles create in the admin console in minutes.
Record ownership drives default access: the owner reads and writes the record, the owner manager reads the record (per the manager hierarchy), other users read only if the role grants object-level read with ownership-unscoped access.
Record sharing lets a user grant read or write access to specific other users or roles for a record. The sharing captures as an explicit permission grant with timestamp and granter. For agency scenarios the owner shares specific accounts across the firm through explicit record sharing.
For records with shared team ownership (deal team, account team) Strkr ships a membership link table where multiple users carry a role (primary owner, secondary, support engineer, overlay) on a single record. The permissions follow the membership link.
Field-level permissions ship inside the Layouts module (Phase 1 ships visibility, order, sections, per-field permissions, related lists). The sales admin controls which role sees which field without an engineering ticket. Conditional field permissions are Phase 2.
Manager hierarchy drives forecast and reporting scope. The user record carries manager_id as a self-reference. Forecast permissions scope by BFS (full team under the manager) or direct-reports (immediate team only). The hierarchy supports arbitrary depth.
The Strkr admin console exposes permission management as self-service across the seven layers. The cards below describe the admin workflow for the common permission operations.
The role designer lists all 54 resource types with CRUD operations (create, read, update, delete) and scope options (all, ownership-unscoped, ownership-scoped, team-scoped, hierarchy-scoped). The admin builds a new role by toggling permissions and saving. The role is immediately assignable to users.
User role assignment runs through the user management view with bulk assignment, preview of permission changes before apply, and audit log capture of every assignment change. Teams onboarding a new cohort of hires can bulk-assign the right role in one operation.
Sharing rules define automatic record sharing based on criteria (account tier platinum shares across the firm, deals over $500k share with the regional VP, accounts in healthcare industry share with the compliance role). Rules evaluate on record create and record update. The sharing applies without manual intervention.
Inside the Layouts module the field-level permission matrix lets the admin set which role sees which field. The admin selects the Account object, the role (for example AE), and toggles which fields are visible, read-only, or editable. The matrix saves as part of the Layout. Users see the layout appropriate to their role.
The audit log view queries record access history by user, record, action, and time range. The compliance team sees who accessed what when with full context. The audit log exports to CSV for state regulator audits and internal compliance reviews.
The permission preview feature lets the admin impersonate another user to see the CRM exactly as that user does: which objects they access, which fields they see, which records they can edit. The feature catches permission misconfigurations before they ship.
For agencies serving multiple clients or enterprises with isolated divisions Strkr workspace architecture delivers tenant-grade isolation with explicit cross-workspace sharing where needed. The cards below describe the pattern.
For an agency serving 11 clients each client lives in a dedicated workspace with isolated data. Client A users do not see Client B data. The agency staff who serve both clients access each workspace through role-based assignment. The data separation is enforced at the data model level.
Agency staff who serve multiple clients access the relevant workspaces through workspace membership. Each workspace membership carries a role appropriate to the client scope. The staff person switches workspaces through the UI without a second login.
Workspace billing supports per-workspace seats (each client workspace counts separately for the per-seat invoice) or shared seats across the agency (a single invoice for all workspaces combined). The agency chooses the model that fits their business.
Workspace isolation enforces at the data model level: queries scope to the current workspace, record IDs do not expose cross-workspace, and the audit log scopes per workspace. The isolation satisfies GDPR data processor requirements for the agency delivering CRM-as-a-service.
Each workspace supports its own branding (logo, color palette) and (on the subdomain roadmap) its own subdomain. The agency can present each client workspace as a branded tenant surface without the agency Strkr branding showing through.
The workspace admin role manages that workspace users, permissions, and configuration independently from other workspaces. For client-side admins the workspace admin grants control over their own CRM without seeing agency internal data or other client data.
The comparison below is Strkr permission model versus a legacy CRM where field-level security and workspace isolation ship at enterprise tier or require custom development.
| Feature | Strkr | Legacy CRM with enterprise security tier |
|---|---|---|
| Object-level permissions | All 54 resource types with CRUD. | Standard across CRMs. |
| Field-level permissions | Inside Layouts module. | Enterprise tier add-on. |
| Record sharing | Explicit grant with timestamp. | Varies by vendor. |
| Workspace isolation | Multi-tenant per workspace. | Separate instance typical. |
| Manager hierarchy | manager_id self-ref with BFS scope. | Role hierarchy only. |
| Permission change velocity | Self-service admin console. | Engineering ticket typical. |
| Audit log depth | Record read and write. | Write only typical. |
| Audit log retention | 90-day default tunable to compliance ceiling. | 90-day default typical. |
| Permission preview impersonation | See CRM as another user. | Rare across vendors. |
The playbooks below are patterns Strkr onboarding sees across teams with granular permission requirements.
An 85-rep financial services firm needed to restrict access to certain client financial fields (net worth, assets under management, trading history) to specific advisor roles. Strkr onboarding configured the role model with field-level permissions (shipping inside Layouts Phase 1) and the audit log at 7-year retention per SEC requirements. The compliance team gained confidence that the sensitive fields were visible only to the right advisors.
A 42-staff marketing agency served 11 clients with per-client CRM scope. Strkr onboarding configured the workspace architecture with 11 workspaces (one per client) and shared agency staff accessing relevant workspaces. The data separation was enforced at the data model. GDPR data processor requirements closed cleanly.
A 120-rep sales team ran AMER, EMEA, and APAC regions with each region needing isolation from the others for compliance and competitive reasons. Strkr onboarding configured workspace-plus-entity hybrid permissions with regional workspaces and explicit cross-regional sharing on strategic global accounts. The global account team ran smoothly across regions while regional teams stayed isolated.
A 25-rep healthcare business process outsourcing firm served 8 healthcare clients with HIPAA scoping. Strkr onboarding configured the HIPAA BAA, workspace isolation per client, PHI field-level permissions, and audit log at 6-year retention. The firm closed three new healthcare clients in the first six months post-cutover due to the compliance posture.
A 60-rep enterprise sales team had 15 external contractor reps hired for regional expansion. The contractors needed scoped access without seeing competitive deals in other regions. Strkr onboarding configured workspace-plus-entity hybrid permissions with contractor roles seeing only their region accounts, deals, and contacts. Contractor churn did not expose competitive data.
Book a 30 minute call. We will walk through the seven permission layers, the Layouts field-level roadmap, and the audit log posture with your actual role model and compliance requirements.
Strkr permissions run through seven layers (workspace, role, record ownership, record sharing, team membership, field-level, manager hierarchy) with CRUD operations across 54 resource types. The granularity is comparable to Salesforce profiles plus permission sets with the trade-off that Salesforce has more mature advanced features (sharing rules with complex criteria, apex managed sharing, external org-wide defaults) built up over 20 years. For most mid-market and enterprise permission requirements Strkr covers the use case cleanly. For teams with hyper-complex permission requirements (government agencies with multi-level clearance, financial services with role separation under Dodd-Frank) Strkr can refer a Salesforce implementation partner if the complexity warrants it. The self-service admin console is a substantial advantage for teams that want admin velocity.
Field-level permissions ship inside the Layouts module Phase 1, which is in flight at the time of this writing. Phase 1 covers field visibility, field order, sections, per-field permissions by role, and related lists. Phase 2 ships conditional field permissions (field X visible when field Y equals Z). For teams whose immediate requirement is field-level permission by role, Phase 1 covers the use case. For teams whose requirement is conditional field permission (visible for VIP accounts, hidden for standard), Phase 2 is on the roadmap.
Yes. The workspace architecture places each client in a dedicated workspace with isolated data. Client A users do not see Client B data. The agency staff who serve both clients access each workspace through workspace membership with per-workspace role assignment. The staff person switches workspaces through the UI. The billing supports per-workspace seats or shared seats across the agency. For agencies that need per-client branding Strkr workspace branding (logo, colors) ships now and per-workspace subdomains ship on the subdomain roadmap.
The Strkr audit log captures every record read, record write, email send, document generation, and AI call with full context: timestamp, user, action, record ID, before and after values on writes, and request origin (web, mobile, API). The default retention is 90 days with tenant-level tuning available up to 7 years for compliance-required retention (HIPAA 6 years, financial services 7 years, state insurance department 7 years). The audit log exports to CSV for regulator audits and internal compliance reviews. For teams running HIPAA workloads the audit log retention automatically tunes to 6 years on BAA signature.
Strkr runs flat per seat at $29 Starter, $59 Pro, or $119 Scale per user per month with a 14-day trial. The granular permissions capabilities (role-based access, record sharing, team membership, workspace isolation, audit log) ship at every tier. The Layouts module with field-level permissions ships inside the Pro and Scale tiers. SSO via SAML or OIDC lives on the Scale tier through Clerk. For a 25-user team on Pro needing granular permissions the monthly spend lands at $1,475 plus $49 for Strkr AI Enhancement. The permission capability does not gate behind an enterprise-only tier the way most legacy CRMs do.
Strkr is HIPAA compliant with a BAA available on request (relevant for healthcare and life sciences workloads), GDPR and CCPA compliant today, and SOC 2 Type II is in progress with a target of 2026-Q4. Integration tokens live in AWS KMS, platform credentials live in AWS Secrets Manager, and the audit log captures every record read and write with retention tunable per tenant to the compliance-required ceiling. SSO via SAML or OIDC is live on Scale tier through Clerk, MFA with TOTP plus text-based verification is live across all tiers, Verified Domains are live on Scale tier. For federal government workloads requiring FedRAMP authorization Strkr is not FedRAMP authorized at the time of writing. For most commercial regulated workloads (HIPAA, PCI, state insurance, SOX for private companies) Strkr covers the posture.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
