In this article
“I cannot see it” is a useful symptom, not a diagnosis. Work out which record, which person and which boundary are involved before changing access.
Start with a precise observation
Ask what the teammate expected to see, where they looked and whether the problem affects one record or a whole category. Keep the request free of passwords, verification codes and screenshots containing unnecessary tenant data. A missing work order might involve assignment, property scope or role permissions; these are different questions.
DoorLoop’s documentation distinguishes user roles from property and bank-account access on individual users. It also describes separate task visibility options, such as seeing assigned tasks rather than all tasks. A role name alone therefore does not tell you everything about a person’s effective access.
Check three layers in order
- Identity: is the person using their own intended account?
- Scope: does the intended property or other record fall within their authorized access?
- Action: is the required activity viewing, editing, creating or something else?
This sequence avoids the tempting but blunt response of granting full access. Being able to view one work order does not imply a need to delete records or read every financial report. Describe the actual work requirement first so an authorized administrator can compare it with the intended permission boundary.
Treat product and plan limits honestly
The current DoorLoop user-role guidance says Starter plans cannot create or edit user roles. This article does not promise that every control exists in every account. If the available settings do not match the public guide, check the current documentation and the account’s plan rather than improvising a workaround.
A permission change affects more than whether a page loads. It can expose information or enable actions elsewhere. Keep changes with the authorized administrator, review the scope and verify the result using an approved test method. Never borrow an administrator login to avoid the intended boundary.
Make the verification about the job
Fictional access review
A maintenance coordinator can see assigned tasks for one property but not a new work order. The administrator checks assignment and property scope before changing the role. The eventual test is whether the coordinator can do the authorized job, not whether every menu is now visible.
A good test includes the expected permission and a relevant boundary that should remain closed. For example, confirm access to the intended task while preserving unrelated property restrictions. Use suitable test records where possible, and avoid exporting real data just to demonstrate that a permission is working.
Record the reason and revisit changes
Keep a short internal note of the business purpose, approved scope and verification result. Temporary responsibilities should have an appropriate review point. This publication does not administer accounts, enforce access policy or certify a configuration as secure.
Return to work-order handoffs when the issue is actually incomplete task context. Read owner information packets before treating owner portal access as a staff-account problem. The generic checklist helps identify a missing handoff step, but never changes permissions.
Sources and scope
Official public sources checked October 21, 2026. The coordination methods and fictional examples are original editorial analysis, not a tested DoorLoop account workflow or legal, accounting or emergency advice. Features depend on plan, settings, permissions and product changes.