Quick answer
Revit Server itself does not provide a detailed permission model by user, project, discipline and operation. A gateway must identify the user and request, apply central rules, and deny actions outside the assigned responsibility before they reach Revit Server.
What the team sees
External participants can open projects outside their scope. Engineers see model disciplines that do not belong to them. Administrators depend on instructions and manual supervision, and removing access at the end of a contract takes too long.
Why it keeps happening
The visible incident is an access problem, but the process cause is the absence of one authoritative responsibility matrix. Accounts, projects, model disciplines and allowed actions are not connected by enforceable rules.
A controlled way to solve it
- Create one identity for every internal and external participant.
- Assign access to explicit projects instead of the whole server.
- Split permissions by model discipline or section and by allowed action.
- Use roles for repeatable rules and individual exceptions only when necessary.
- Log every allowed and denied request so the rule can be verified.
Expected result
A participant can work only in the projects and model areas assigned to them. Access changes are applied centrally, onboarding and offboarding become predictable, and every decision is supported by an audit trail.
Related RS-Systems solution
Revit Server Guard
Access control, auditing, administration and protected operation of Autodesk Revit Server infrastructure.
Revit Server Guard →Questions and answers
Can this be solved only with Windows folder permissions?
No. Revit Server requests are not equivalent to ordinary file access, and folder permissions do not express project, model-discipline and operation rules.
Will designers need a different Revit workflow?
The control should be applied by the server gateway. Designers continue using Revit, while disallowed operations are blocked centrally.