Team and company setup
Why can’t this user see a project, work item, or action?
JobBuddy access is built from several layers: subscription, company modules, user roles, project scope, Item Type permissions, participation, and record status. Check them in that order to correct the smallest setting responsible.
Before you begin
- Write down the affected user, exact project, Item Type or module, missing action, and current record status.
- Compare with a user who can complete the action only when they work in the same project and record state.
- You need company-administrator access for roles and company settings, or project-management access for project permissions.
- Do not solve a narrow access issue by making the user a company administrator.
User Admin → Users or Roles; project → Permissions
Check access in this order
-
Check company access first
Confirm that the company can use the portal normally. A payment-required company is redirected before ordinary feature permissions are evaluated.
If only Plan & Payments and Help Center open, a company administrator must resolve the company-level billing requirement.
-
Check the company module
Open My Company → Company Settings and confirm that the required optional module is on.
If the feature depends on QuickBooks, Instagram, or another connection, confirm that the connection is healthy too.
-
Check the user’s roles
Open User Admin → Users, select the user, and review User Roles. Then open each applicable role from User Admin → Roles.
Confirm the module permission and the Item Type action needed for the task.
-
Check project scope
Confirm that the role has Access to all Projects or that the user, role, crew, or connected company has permission on this project.
Project membership controls scope; it does not automatically grant every action inside the project.
-
Check the Item Type permission
In the role, find the Item Type and verify View, Create, Update, or Delete for the exact action that is missing.
If Restrict to Participants is selected, confirm that the user participates in the individual work item.
-
Check owner, assignee, or approver rules
Some actions depend on who owns, is assigned to, submitted, or must approve the record.
Confirm the person’s relationship to that record rather than widening the whole role.
-
Check the record state
Approved, issued, posted, archived, closed, or pending records can limit actions even when the user has permission.
Look for the current status and use the supported next action instead of assuming access is missing.
-
Retest the exact path
After correcting the narrow layer, have the user refresh JobBuddy and repeat the same route and action.
If it still fails, keep the route, exact message, record status, and approximate time for support.
Expected result: The intended action becomes available without exposing unrelated projects or administrative features.
Match the symptom to the access layer
The pattern usually identifies where to look first.
The whole module is missing
Menu destination or feature card is absent
Check company and role. Verify the module is enabled, then confirm the required administrative permission or per-user setting.
One project is missing
Other projects are visible
Check project scope. Review project permission or all-project access.
One work type is missing
The project opens but a workflow does not
Check Item Type View. Also check participant restriction and whether the Item Type is active.
The record opens but cannot be changed
Fields or actions are read only
Check Update and status. Permission and lifecycle state can each make a record read only.
A financial action is missing
Estimate, budget, payment, invoice, or expense action
Check the specific admin level. Read-only access is intentionally different from manage access.
Only one person is affected
Another user with similar work can act
Compare roles and participation. Also review direct user settings such as Job Clock enablement.
Change one layer at a time
Retest after each narrow correction. Changing several roles and project permissions at once makes future access reviews harder.
Troubleshooting
The user still sees the old access after a role was saved.
Have the user refresh or sign in again, then repeat the exact route. Confirm that the user is assigned to the role you changed.
The menu link is visible but the route is denied.
Treat the denied route as authoritative. Recheck the server-enforced module, role, and project requirements rather than relying on menu visibility alone.
An external collaborator can open the project but not its work.
Confirm the connected-company or project permission and the Item Type permission granted through that relationship.
The user can view estimates but cannot see amounts or send them.
Check whether the user has Estimate Read Only. Use Estimate Admin only when the person should create, edit, delete, and send estimates.
The action disappeared after the record changed status.
Confirm whether the record is approved, issued, posted, archived, closed, or pending. Use the action supported for that state or follow the related correction workflow.
What happens next
- The corrected user should repeat the original action, not just confirm that the menu changed.
- Record why broad permissions such as all-project access were granted when they are genuinely required.
- Remove temporary access used during diagnosis after the intended role is verified.