Roles
Security in sfPMS is role based. Through the Roles tool, you create roles that will later be assigned to users. Multiple roles can be assigned to users. Since roles grant access rather than restrict access to specific functions, there are no conflicts among roles. If you change a role, that change applies to all users who have that role assigned to them.
Some roles can be project-specific. For example, the Project Manager role can be assigned to company executives so they have access to all projects. And the Project Manager role can also be assigned to another user with a limitation to a specific project.
Capability Modules
Roles contain a list of capabilities that govern what the user can see and do within the system. Capabilities affect various aspects of sfPMS and are, therefore, grouped into modules. Currently there are six moduleks: CSTM, DOC, LIST, PAGE, PART. and SYS.
Permissions – Allow (RIUDS)
Once a capability is assigned to a role, permission levels must be selected. The Allow checkboxes indicate the permission level for that capability in that role. The checkboxes are in the order for Read, Insert, Update, Delete, Special.
Note: Only the permission levels that apply will be available for edits. For example, only the R checkbox can be edited for the Executive Dashboard because users cannot Insert, Update, or Delete the Executive Dashboard; they simply have access or do not have access. Checkboxes you cannot edit are grayed out. When the R checkbox is the only one that can be edited, the checkbox means Allow.
Conditions
Because the capabilities given to roles apply to all people with that role, sfPMS allows you to limit the capabilities of roles for certain people by four types of conditions—Project, Doc Type, Reference, and Document. For example, you might give subcontractors the capability of creating documents, but then limit that capability by project so a specific subcontractor can create documents for his project only.
Subroles
A fifth condition, SubRole, does not restrict, but rather designates the role as a possible SubRole. SubRoles can be included within roles. All capabilities and conditions of the nested SubRole apply to the role. For example, if you had a role called DocCreator, which had the capability of creating documents and was restricted by the Doc Type condition, and you made DocCreator a SubRole, you could include (nest) DocCreator in the role called Subcontractor. Subcontractor would then have the same capability of creating a document, restricted by the Doc Type condition. You could even go a step further and create a role called HVAC Subcontractor that included Subcontractor (which in turn would include DocCreator).
HVAC Subcontractor – specific capabilities plus those from:
Subcontractor – specific capabilities plus those from:
DocCreator – creates only Pay Request documents
DocCreator – creates only RFI documents
Responsibilities
A role’s responsibility tells sfPMS the “weight” of that role (i.e. what kind of role it is within a project) regardless of what you actually called the role. Internally, sfPMS understands the responsibilities of the following:
- Accountant
- Alternate CM
- Alternate PM
- Architect
- Associate
- Bonder
- Construction Manager
- Customer/Owner
- Development Manager
- General Contractor
- Lender
- Operations Manager
- Project Manager
- Project Staff
- Senior Executive
- Superintendent
For example, if you create a role called Project Assistant and give it the responsibility of Project Staff, sfPMS would know that a person with a role of Project Assistant is a Project Staff person. As another example, you could create several roles for your subcontractors such as Electrical Subcontractor or HVAC Subcontractor. You would then give them all the responsibility of Associate. sfPMS uses responsibilities to identify the roles needed in certain locations (such as the team Contacts on the Project Dashboard and on various reports).