Construction software access is unusually contextual. A superintendent may need schedules, Daily Logs, and field files across five active jobs but no accounting integration; a bookkeeper may require bills and financial records while needing little field visibility. If both receive broad administrative access because it is easier, Buildertrend becomes a larger operational and financial risk than the job requires.
Buildertrend's current Internal Users guidance assigns permissions through roles rather than one-off switches on each person. It provides default roles, allows custom roles with View, Add, Edit, and Delete choices, separates Org Owner from Admin, and distinguishes Active, Inactive, Archived, and Deleted user states. Job Access and notification settings add additional layers that must be tested alongside the role.
This guide turns those controls into an identity lifecycle for employees and long-term internal users. It also explains the narrower scope of Buildertrend's documented multi-factor authentication requirements, which currently center on payment and Xero integration permissions. The goal is to make onboarding, access changes, sensitive actions, and departures predictable without overstating what the platform enforces.
Key decisions at a glance
- Manage permissions through Buildertrend roles and reserve Org Owner or Admin access for the few people who genuinely require it.
- Treat feature permission, job access, notification delivery, and account status as separate checks during onboarding.
- Scope MFA statements accurately: Buildertrend currently documents mandatory MFA for specific payment and Xero-connected permissions.
- Disable login access promptly during a departure, transfer operational responsibility, and archive rather than delete a previously active user.
- Review internal users, subcontractor access, and trusted payment authority on a recurring schedule, not only after an incident.
Design Roles Around Duties and Consequences
Begin with a responsibility matrix rather than Buildertrend's permission screen. List who may view client information, change schedules, publish Daily Logs, approve scope, manage bills or purchase orders, connect accounting, edit users, and administer subscription or payment settings. Then map those duties to a default role or a narrowly tailored custom role. This makes every permission traceable to a business need instead of a person's seniority.
Buildertrend currently differentiates Org Owner and Admin, and its permission matrix describes more focused roles such as Project Manager, Bookkeeper, Field Crew, Purchasing Coordinator, and others. Use the least-powerful suitable baseline. Where a standard role includes too much or too little, create a custom role and document why its View, Add, Edit, or Delete capability is necessary for each feature.
Do not create many near-identical roles. Name each custom role for a stable job function, record its owner, and compare it with the current Buildertrend permission matrix after significant product updates. High-impact rights deserve explicit review: Internal Users, accounting integration, client invoices, purchase and payment functions, and deletion of financial or project evidence. A role inventory that no one understands is not a control.
- Limit Org Owner assignments to accountable executives and keep Admin membership small enough to review by name.
- Separate ordinary project management from user administration, accounting connection, and payment authority where staffing permits.
- Document the business reason and owner for every custom role, then retire unused or overlapping variants.
- Review View, Add, Edit, and Delete separately because the ability to remove evidence carries a different consequence than reading it.
Onboard With Four Separate Access Checks
Buildertrend says Org Owners and Admins can add or edit internal users, assign a role, and send an invitation. Use a verified company email address and a named manager's request before the invite is sent. The selected role answers what features the person may use, but it does not by itself prove which projects they should enter, which alerts they need, or whether their login should already be Active.
Test four layers for every new internal user: role permissions, Job Access, notification settings, and login status. Ask the manager to validate a sample open job from the user's perspective and confirm access to only the needed statuses and features. Buildertrend's troubleshooting guidance notes that a person may be absent from a notify list when they lack the relevant Job Access or feature permission, which is why a successful login is not a complete acceptance test.
Treat subcontractors and vendors as a distinct population rather than making them internal users for convenience. Buildertrend provides Sub/Vendor profiles, job-specific access, an invitation flow, and tailored feature visibility. Job Access can be required for assignment even when a Sub/Vendor is inactive, while the invitation that enables portal credentials is a separate decision. Document which external companies may see schedules, files, Daily Logs, purchase orders, or approved changes on each job.
- Require a manager-approved request that states role, job list, start date, notification needs, and any financial responsibilities.
- Use a company-controlled email identity and complete adjacent email, device, and file-access onboarding in the same checklist.
- Test one representative Job and one sensitive feature before declaring the account ready for production use.
- Review client and Sub/Vendor portal access separately; external collaboration should never depend on shared internal credentials.
Apply MFA Where Buildertrend Actually Requires It
Avoid claiming that every Buildertrend login is protected by mandatory MFA. Buildertrend's current help content documents MFA requirements for Bill Pay and for users whose permissions connect them to certain Xero financial actions. For Bill Pay-only use, its guidance says participating users must complete MFA; when Client Payments and Bill Pay are both used, the documented requirement may center on Org Owners. Confirm the current rule shown in your account and help center before changing payment access.
Buildertrend's setup flow supports SMS or an authenticator application and provides a recovery code. Prefer a managed authenticator method when company policy supports it, protect the recovery code in an approved credential vault, and do not store it in a project note or shared job folder. The person enrolling should complete a controlled test before being trusted with a live payment deadline.
MFA does not replace payment segregation. Review which people can send payments, edit subcontractor or vendor contact details, mark bills or purchase orders paid, or connect financial systems. Buildertrend describes a Trusted Payments concept for authorized payment users, with Org Owners receiving authority by default in the documented workflow. Pair that platform setting with an independent approval rule and a call-back procedure for changed banking instructions.
- Inventory every Buildertrend user who can process payments or exercise a permission that triggers the documented MFA workflow.
- Record the enrolled method and recovery custodian without collecting one-time codes or secrets in ordinary support tickets.
- Use a second-person review for new payees, changed banking details, and unusual outbound payment requests.
- Recheck Buildertrend's current payment and integration documentation whenever roles, features, or accounting connections change.
Offboard Access Without Erasing the Project Record
At the effective departure time, turn off Buildertrend Login Access so the internal user becomes Inactive. Buildertrend explains that an Inactive user cannot log in but may still appear in assignments for internal tracking. Coordinate the same cutoff across the person's company email, identity provider, mobile device management, remote access, password vault, and shared drives; changing Buildertrend alone does not close those adjacent paths.
Before archival, transfer operational responsibility. Search active Jobs for schedules, To-Dos, Daily Logs awaiting follow-up, RFIs, approvals, purchase commitments, client conversations, and accounting tasks assigned to the departing person. Reassign each item to a named owner and verify any Trusted Payments or financial permissions have been removed. A manager should sign off that the field and office know who now owns urgent decisions.
Buildertrend recommends archiving a previously active internal user rather than deleting the record. Archiving prevents login and removes the person from dropdown menus while preserving historical activity for reporting and reference; deletion erases much of that history, although certain records may remain. Keep an offboarding evidence record outside the departed person's mailbox, and conduct a follow-up check after the next payroll, billing, and project-review cycle.
- Disable login at the agreed time, then confirm the user is no longer Active before the offboarding ticket closes.
- Reassign open Jobs, schedule items, To-Dos, approvals, financial duties, and customer or trade communications by name.
- Archive a previously active user to preserve history unless Buildertrend support and your retention policy justify a different action.
- Review recent login, payment, contact-change, and project activity when the departure is contentious or compromise is suspected.
Vendor documentation and ALLMSP resources
- Buildertrend: Internal Users Overview
- Buildertrend: Setup and Customization FAQs
- Buildertrend: Multi-Factor Authentication with Payments
- Buildertrend: Xero Integration MFA
- Buildertrend: Subcontractor Overview
- ALLMSP Software Support
- ALLMSP Buildertrend Support
- ALLMSP Construction and Contracting
- ALLMSP Cybersecurity
- Contact ALLMSP
Frequently Asked Questions
Are Buildertrend permissions assigned directly to each internal user?
Buildertrend's current model assigns permissions through the user's role. A person can be moved to another default or custom role, while custom roles define their View, Add, Edit, and Delete capabilities.
What is the difference between a Buildertrend Org Owner and Admin?
Both are high-privilege roles, but Buildertrend separates certain subscription and payment capabilities from ordinary administration. Review the live permission matrix and keep both groups limited to people with accountable duties.
Can a Buildertrend custom role start from an existing role?
Yes. Buildertrend documents an Add from role option that pre-populates permissions from an existing role. Review every inherited permission before assigning users rather than assuming the baseline is safe.
Why can a Buildertrend user log in but not see a Job?
Feature permission and Job Access are separate controls. Confirm the Job is selected for the user and that the assigned role permits the relevant feature and job status.
Does giving a Buildertrend Sub/Vendor Job Access send an invitation?
No. Buildertrend treats Job Access and the portal invitation as separate actions. Job Access may make the profile assignable, while an invitation activates credentials for in-platform collaboration.
Is MFA mandatory for every Buildertrend user?
Buildertrend's public help documentation currently describes mandatory MFA in specific financial contexts such as Bill Pay and permission-triggered Xero integration access. Verify the current requirements visible in your account rather than assuming a universal policy.
Which MFA methods does Buildertrend document for supported financial workflows?
Buildertrend documents SMS text messages and authenticator applications, followed by a recovery code. Protect that code in an approved secure location and test recovery before a critical payment date.
What does making an internal Buildertrend user Inactive do?
Turning off Login Access makes the user unable to sign in, while the profile can remain available for assignments and internal tracking. It is a useful immediate cutoff before completing reassignment and archival.
Should a departed Buildertrend user be deleted or archived?
Buildertrend strongly advises archiving previously active users because archival blocks login and removes them from dropdowns while retaining historical activity. Deletion removes much more of the record and should not be the routine offboarding choice.
What should a Buildertrend offboarding review include?
Verify login cutoff, job and task reassignment, payment authority removal, customer and trade handoffs, device return, and closure of connected email, remote-access, file, and password-vault accounts. Recheck after the next operating cycle.
