Construction teams change constantly: employees transfer between jobs, subcontractors finish a scope, consultants join for a limited phase, and project executives need wider oversight than most field users. Procore access must reflect those changing assignments without forcing administrators to rebuild every tool permission by hand.
Procore permission templates provide a repeatable starting point. Its documentation distinguishes global templates, which can be assigned across projects, from project-specific templates limited to one project. Within those templates, tool access can use None, Read Only, Standard, or Admin levels, with granular permissions available for supported tools and levels.
Offboarding is not a single deactivate button. Removing a person from one Project Directory and deactivating the Company Directory account have different scopes, and the user's prior activity remains part of the record. Before either action, the project team should transfer open assignments and confirm who will own pending correspondence, commitments, observations, submittals, and other work.
Key decisions at a glance
- Separate global permission templates for repeatable roles from project-specific templates used for an individual project's exceptional access model.
- Use Procore's None, Read Only, Standard, and Admin levels with supported granular permissions only after mapping the tasks each role must perform.
- Assign default templates carefully because Procore permits only global permission templates to serve as company-wide defaults for new projects.
- Reassign open work and identify record ownership before removing a user from a project or deactivating the account at the company level.
- Preserve activity history while closing every current access path, and retain approval evidence that does not expose credentials or sensitive project data.
Design Global and Project-Specific Permission Templates
Build a role inventory from actual Procore work: project executives need portfolio visibility, project managers administer defined tools, superintendents coordinate field execution, accounting staff handle financial workflows, and external collaborators may need access to only a narrow part of the project. Describe required actions before choosing an access level.
Use a global permission template when the role should be reusable across many projects. Reserve a project-specific template for a genuine exception within one job, and document why the global role is insufficient. Procore notes that only global project permission templates can be assigned as defaults for new project access.
Do not interpret Standard as one fixed capability across every tool. Review the tool-level permission and any supported granular permissions together, then test a representative user. A permission matrix should record the business task, Procore tool, level, granular option where applicable, approver, and evidence of the successful test.
- Map project roles to required Procore actions before selecting None, Read Only, Standard, or Admin.
- Use global templates for stable company roles and project-specific templates only for documented job-level exceptions.
- Limit Admin access to named responsibilities that cannot be completed safely with a lower level and supported granular permissions.
- Test each template with a representative account and retain the result with the template's owner and review date.
Make Collaborator Access Assignable and Reviewable
A subcontractor supervisor, architect, owner representative, inspector, and internal employee should not receive a shared external-user template simply because they work outside the contractor's payroll. Create roles around the records and actions each collaborator needs, then link the approved template to a verified person, company, project, start date, and accountable sponsor.
When adding a user to a Project Directory, Procore permits an authorized administrator to assign a project permission template during the process or later. Make that decision part of intake, not an afterthought. If no approved role fits, pause the invitation and obtain an exception rather than granting a broad template to keep the schedule moving.
Review access at meaningful construction milestones, including notice to proceed, major trade mobilization, turnover between project phases, substantial completion, closeout, and a collaborator's contract end. The Project Directory, current roster, outstanding-work reports, and exception register should tell the same story.
- Require a named sponsor, project, company, role, requested duration, and permission template for each collaborator.
- Verify the recipient's email and employer before notifying the person that access is available.
- Record temporary exceptions with an owner and expiration date instead of silently changing the shared role baseline.
- Reconcile directory membership and template assignments at phase changes, closeout, and contract termination.
Reassign Open Work Before Removal or Deactivation
First determine the required scope. Removing a person from a Project Directory ends participation in that project, while company-level deactivation prevents the account from logging in across the company. A transfer between jobs may call for project removal; employment termination or a fully ended vendor relationship may require company deactivation after the responsible owners approve it.
Procore retains historical activity rather than deleting the user's contribution, which protects the construction record. However, open responsibilities still need an active owner. Before access closes, identify pending assignments, workflow steps, correspondence, submittals, RFIs, observations, punch items, meetings, approvals, financial reviews, and reports that depend on the departing person.
Complete offboarding through a tracked handoff: reassign or close open work, confirm the replacement owner, remove project membership where appropriate, deactivate the Company Directory record when the broader relationship ends, and review related identity-provider groups, devices, integrations, and vendor-support access outside Procore.
- Choose project removal or company deactivation according to the person's remaining relationship with the organization.
- Export or review open-work reports and assign every live item to an authorized replacement before access is closed.
- Retain the person's activity history and record the approver, effective time, scope, and completed control checks.
- Review single sign-on, email groups, managed devices, shared files, integrations, and support portals that may provide a separate access path.
Operate Procore Access as an Ongoing Control
Set an access-review rhythm that matches project risk. High-turnover jobs and sensitive financial workflows may justify monthly exception checks, while a broader quarterly review can reconcile active Company and Project Directory users with the human-resources roster, subcontract register, project assignments, and approved permission templates.
Useful evidence includes the template definition, current assignment, request and approval, exception expiration, last review, and offboarding completion. Keep passwords, multifactor codes, and confidential project exports out of that evidence. The register should prove why access exists without becoming another source of sensitive data.
ALLMSP can help construction organizations document Procore roles, review template assignments, coordinate directory cleanup and offboarding, strengthen surrounding identity controls, and build repeatable access reports. Procore administration, cybersecurity, and project operations should meet in one process rather than in separate ticket queues.
- Review elevated access and temporary exceptions more frequently than stable read-only project roles.
- Compare Procore users with employment, subcontract, and active-project records instead of reviewing one directory in isolation.
- Track remediation to completion when an owner, approval, project need, or expiration date cannot be demonstrated.
- Escalate suspected compromise or unexplained access immediately through the organization's incident-response process.
Vendor documentation and ALLMSP resources
- Procore: What Is a Permissions Template?
- Procore: Create a Project Permissions Template
- Procore: Manage Project Permissions Templates
- Procore: Assign Default Project Permissions Templates
- Procore: Add a User to the Project Directory
- Procore: Deactivate Company Directory Users
- Procore Project Directory Tutorials
- ALLMSP Software Support
- ALLMSP Cybersecurity
- ALLMSP Construction and Contracting
- ALLMSP Procore Support
- Contact ALLMSP
Frequently Asked Questions
What is a Procore permission template?
A Procore permission template is a defined set of tool access levels and supported granular permissions that can be assigned to a user for a project. It helps administrators apply a reviewed role consistently instead of configuring every user from scratch.
What is the difference between a company and project permission template in Procore?
Company-level administrators manage project permission templates. Procore distinguishes global templates, which can be used across projects, from project-specific templates that apply only to one named project.
When should a global Procore permission template be used?
Use a global template for a repeatable role that should work across multiple projects, such as a standard superintendent or project manager role. Give it a business owner, test it, and review it when duties or Procore features change.
When is a project-specific permission template appropriate?
Use one when a particular project has a legitimate access model that should not become the company default. Document the contract or operational reason, approver, affected users, and end-of-project cleanup plan.
Can granular permissions be added to every Procore access level?
Granular permissions are available only for supported tools and permission levels. Review the current Procore permissions documentation for the exact tool, configure the needed options, and test the resulting user experience.
Can a project-specific Procore template be the default for future projects?
No. Procore states that only global project permission templates can be assigned as default templates. A project-specific template remains limited to its associated project.
Should outside collaborators share one Procore account?
No. Give each person a verified individual record and an approved role. Shared access weakens accountability, complicates offboarding, and makes it difficult to determine who performed a project action.
Is removing a user from a project the same as deactivating the user in Procore?
No. Project removal addresses access to one project; company-level deactivation prevents the user from logging in to the company's Procore account. Choose the scope based on whether the person retains another authorized relationship.
Does Procore delete a user's history when access is removed?
Procore preserves historical activity rather than erasing the person's contribution. Before removal or deactivation, reassign open tasks and approvals so the retained record does not leave current work without an owner.
How can ALLMSP help with Procore access reviews and offboarding?
ALLMSP can map construction roles to Procore templates, review assignments and exceptions, coordinate open-work reassignment, document project removal and company deactivation, and examine related identity, device, integration, and vendor-access controls.
