SERP feature guide
Users, Roles and Permissions
Role-based permissions determine which SERP areas and actions each user can access.
What does users, roles and permissions do in SERP?
Role-based permissions determine which SERP areas and actions each user can access. SERP connects this work with administration & security, so users can review its operational context through the related records.
Business problem it addresses
Showing the same menus to everyone can blur the difference between entering a record, reviewing it and authorizing its effect.
Key functions
- Assign named user accounts and access roles.
- Check page and action permissions alongside company and location scope.
- Use user-activity and audit inquiries to investigate changes.
How the workflow works
- Identify responsibilities.
- Define access role.
- Assign user and scope.
- Test allowed and denied actions.
- Review access as work changes.
Example business scenario
A sales operator needs order entry while a supervisor handles the relevant approvals. Testing both accounts shows whether the intended separation works for normal activity and exceptions.
Controls and availability
Menu visibility alone is not proof of action authorization. No security certification, encryption standard or unverified authentication method is inferred from role support.
How to assess the result
Test representative accounts against both permitted actions and actions they should not perform. Review company and location scope separately. Use the relevant activity evidence when investigating a change, and revisit access when responsibilities change.
Connected SERP capabilities
Read the Administration & Security module guide for the wider process and SERP reporting for the distinction between a transaction document and an analytical report.
A few useful answers
Frequently asked questions
What is users, roles and permissions?
Role-based permissions determine which SERP areas and actions each user can access.
Which functions can I review in SERP?
Assign named user accounts and access roles; Check page and action permissions alongside company and location scope; Use user-activity and audit inquiries to investigate changes.
What is a practical example?
A sales operator needs order entry while a supervisor handles the relevant approvals. Testing both accounts shows whether the intended separation works for normal activity and exceptions.
What should we confirm before using this workflow?
Menu visibility alone is not proof of action authorization. No security certification, encryption standard or unverified authentication method is inferred from role support.
Where does this fit in the wider ERP process?
It is part of Administration & Security. Review the source requirement, the resulting transaction and the handoff to the next team.
Explore this workflow with your team.
Bring a representative requirement and the roles involved. Follow the records and review the result in a focused SERP demonstration.
Request a Demo → Discuss your requirements