How Constructable Works
Permissions and Data Visibility
Constructable lets organizations give each person the access needed for their work without exposing every project, record, or action. A person's role, project access, record sharing, and workflow state affect what they can see and do across Constructable.
Constructable lets organizations give each person the access needed for their work without exposing every project, record, or action. A person's role, project access, record sharing, and workflow state affect what they can see and do across Constructable.
The access layers
Several controls work together:
- Package and workspace availability determine whether a capability is available to the organization.
- Organization membership and role establish organization-wide access and actions.
- Project membership and project access determine which projects a person can enter.
- Permissions determine which tools, records, and actions are available.
- Level-of-access choices can narrow a permission to records connected to the user, such as particular projects, companies, meetings, RFIs, or Submittals.
- Record sharing and workflow state can further limit a Topic, document, draft, or unpublished item.
- Platform support affects where an available action appears.
Passing one layer does not bypass the others. For example, viewing a published drawing does not automatically provide access to every RFI, Submittal, Quality Item, or Topic pinned to it.
Consistent visibility
Constructable applies the permitted record scope when making project data available and when retrieving information for Search and AI. Opening direct URLs, Threads, notifications, and drawing pins still requires access to their underlying records.
This consistency can make two valid user experiences look different. An administrator may see all RFIs, while a project partner sees non-draft RFIs and only their own drafts. A Topic can be shared with a narrow audience even when more people can view its drawing.
What this means for you
- A missing action may be caused by package availability, platform support, permission, access level, record state, or sharing.
- A notification or direct record link does not grant record access.
- Search and AI cannot be used to discover records outside a user's permitted scope.
- Adjust the narrowest relevant permission or sharing rule instead of changing a person's broad role when possible.
- Use the current Roles and Permissions matrix as the authority because organization defaults may have been customized.
Common boundaries
Permissions, visibility, status, and notifications are separate:
- Permission answers what a person may access or do.
- Visibility or sharing answers which permitted audience can see a particular record.
- Status answers where the record is in its workflow, such as draft, published, open, or archived.
- Notification settings answer which accessible changes should produce alerts.
Changing notification settings cannot expose a record. Publishing a drawing does not publish its connected RFI. Sharing a Topic does not grant access to every record linked from it.
If something is missing
- Confirm the organization, project, record, and workflow state.
- Check whether the capability is included and enabled.
- Check the user's project membership and project access.
- Review the specific permission and any level-of-access choice.
- Review record sharing, draft, archive, publication, or deletion state.
- Confirm that the action is supported on the current browser, device, and layout.
See Troubleshooting organization administration, Troubleshooting teams and directory, and Understanding drawing permissions and visibility.