Skip to main content

Documentation Index

Fetch the complete documentation index at: https://help.loopiq.com/llms.txt

Use this file to discover all available pages before exploring further.

​
Permission Model and Tenant Safety

​
What this does

This article explains how LoopIQ keeps organization data separated and how administrators should think about roles, teams, permissions, and access boundaries.

​
Organization boundary

The organization is the main tenant boundary. Users should only see records that belong to their active organization and that their permissions allow them to access. If a user belongs to more than one organization, the active organization context matters. Users should confirm the organization before creating or reviewing records.

​
Tenant-safe administration

Administrative list views should be tenant-safe:
  • Organization Settings > Users should show only users in the active organization.
  • Grant/Revoke Access should show only users in the active organization.
  • Policies, compliance guidance, objectives, approvals, automation workflows, service requests, tests, and related governance records should be filtered to the current organization unless an explicitly authorized cross-organization admin workflow exists.
  • MCP tools should derive organization context from the authenticated user and selected organization, not from a fixed tenant value.

​
Team context

Many records are also team-specific. A user may have access to one team but not another team in the same organization. If a list looks empty, the most common causes are:
  • the wrong organization is active
  • the wrong team is active
  • the user does not have permission for that module
  • filters are hiding records
  • the record belongs to a different team or organization
  • the record is visible only through a specific relationship, such as requestor, coordinator, approver, assignee, creator, or team member

​
Role design

Good role design starts with real responsibilities. Avoid creating one-off roles for every user unless the organization is very small. Common role patterns include:
  • organization administrator
  • billing administrator
  • team administrator
  • manager or lead
  • contributor
  • tester
  • service desk agent
  • release manager
  • compliance reviewer
  • read-only stakeholder

​
Permission design

Permissions should be granted based on the work users need to perform. Use view permissions for users who need visibility. Use create and edit permissions for users who own records. Use delete permissions sparingly. Use approval permissions only for users who are allowed to make formal decisions. Use administration permissions only for trusted platform owners. A user with no permissions should not see business data. They should see a no-access message that tells them to contact an organization administrator.

​
Access review checklist

Review access regularly:
  1. Confirm each user belongs to the correct organization.
  2. Confirm team membership is accurate.
  3. Confirm roles match current responsibilities.
  4. Remove permissions that are no longer needed.
  5. Review billing administrator access.
  6. Review integration administrator access.
  7. Review AI and MCP access.
  8. Confirm external or trial users have appropriate boundaries.