We’re redesigning our access control strategy for the asset management module and debating between pure role-based access versus a hybrid approach with permission sets. Currently we have about 15 different roles managing various aspects of asset lifecycle - procurement, maintenance, depreciation, disposal, etc. The role-based approach has been easier to audit since we can see exactly who has what access by looking at role assignments. However, we’re finding it inflexible when people need temporary access or cross-functional responsibilities. Permission sets seem to offer more flexibility for these edge cases, but I’m concerned about the ongoing maintenance burden and potential security gaps. What approaches have worked well for others managing complex asset management access requirements? Interested in hearing real-world experiences with both models.
We use a hybrid model that’s worked really well. Core access through roles (Asset Manager, Asset Viewer, Asset Approver) and then permission sets for specialized functions like bulk import, cross-subsidiary access, or temporary audit access. The key is having clear naming conventions and documentation for when to use each. Role-based access is definitely easier to audit - our compliance team loves being able to pull a simple role assignment report.
The ongoing maintenance considerations are real. We started with a permission set heavy approach and it became a nightmare. Every time someone changed departments or responsibilities, we had to review and modify multiple permission sets. Switched to role-based about a year ago and maintenance effort dropped by at least 60%. New hire? Assign appropriate role. Department transfer? Change role assignment. Way simpler. We kept permission sets only for our power users who genuinely need cross-functional access.
One thing people overlook with permission sets is the audit trail complexity. Role changes are logged clearly in NetSuite, but permission set modifications can be harder to track historically. If you go the permission set route, make sure you’re exporting and archiving the permission configurations regularly. We had an audit finding because we couldn’t prove what permissions a former employee had six months ago - the permission set had been modified since then and we had no historical record.
From an audit perspective, role-based access control is significantly easier to manage and demonstrate compliance. When auditors ask ‘who can approve asset acquisitions over $50K’, you can point to a single role with clear documentation. With permission sets scattered across users, you’re doing matrix analysis across multiple dimensions. That said, permission sets shine for temporary access scenarios. My recommendation: use roles for your standard 90% of users, reserve permission sets for the 10% edge cases, and implement quarterly access reviews regardless of which model you choose.
After implementing both approaches across multiple NetSuite instances, here’s what I’ve learned about balancing role-based access with permission sets for asset management:
ROLE-BASED ACCESS advantages that really matter in practice:
• Audit reports are straightforward - you can demonstrate segregation of duties by showing role assignments rather than analyzing permission matrices across users
• Onboarding and offboarding are dramatically simpler - assign/remove a single role rather than managing multiple permission sets
• Role templates can be cloned and customized for different business units while maintaining consistent base permissions
• Compliance documentation is easier because you’re describing roles and responsibilities, not granular permission combinations
• Historical access reviews are cleaner - you can see what someone’s role was at any point in time
PERMISSION SETS provide flexibility that roles can’t match:
• Temporary project access without creating one-off roles that clutter your system
• Cross-functional users who need capabilities from multiple roles without full access to everything in those roles
• Specialized functions like bulk data operations, API access, or advanced reporting that only a few users need
• Testing and training environments where you want to grant elevated access temporarily
• Exception handling for unique business scenarios that don’t fit standard role definitions
ONGOING MAINTENANCE reality check:
• Roles require less frequent review (quarterly is usually sufficient) because they change when job functions change organizationally
• Permission sets need monthly review because they accumulate - people get granted additional permissions but rarely have them removed
• Documentation burden is higher with permission sets - you need to explain WHY each user has each set, not just WHAT their role is
• Permission set sprawl is real - without discipline, you’ll end up with dozens of sets with overlapping purposes
• Training new admins on your access model is much harder when permission sets are involved
My recommended hybrid approach for asset management specifically:
Create 5-7 core roles that cover standard job functions:
• Asset Coordinator (create/edit assets, basic reporting)
• Asset Approver (approval workflows, nothing else)
• Asset Accountant (depreciation, GL posting, financial reporting)
• Asset Auditor (read-only access to everything)
• Asset Administrator (full access for system maintenance)
Use permission sets ONLY for these specific scenarios:
• Bulk Operations Set (for periodic data cleanup or imports)
• Cross-Subsidiary Set (for users managing assets across multiple entities)
• Temporary Audit Set (time-limited access for external auditors)
• API Integration Set (for service accounts running automated processes)
Implement strict governance:
• All permission sets require manager approval AND security team review
• Permission sets automatically expire after 90 days unless renewed
• Monthly report of all active permission sets sent to department heads for validation
• Quarterly full access review covering both roles and permission sets
• Document the business justification for every permission set in a central registry
The audit trail and security model complexity is significantly better with role-based access as the foundation. Permission sets should be the exception, not the rule, and each one should have a documented business case that explains why a standard role couldn’t meet the need.
Consider your organizational velocity too. If you have high turnover or frequent reorganizations, roles are much more manageable. Permission sets require more granular tracking and more frequent reviews. We review roles quarterly but permission sets monthly because they’re more prone to drift and accumulation of unnecessary privileges.