Teams, Roles, and Permissions
Understand how teams, roles, invitations, and permission checks control workspace access
MonitoringDog uses organizations, teams, roles, and permissions to decide what a member can access. Organizations group teams, teams own monitoring resources, and roles give members scoped access.
Organizations contain teams
An organization is the top-level workspace container. A team belongs to one organization and owns resources such as checks, incidents, integrations, escalation policies, status pages, API tokens, and on-call schedules.
New organizations start with a default My Team team. When a member creates another team, MonitoringDog adds that member to the new team with the default Admin role.
MonitoringDog also creates default escalation and severity records for the team, so the team has initial alerting configuration available for later monitoring setup.
Roles belong to the organization
Roles are created at the organization level. A member receives a role through a team membership, so the same person can have different access in different teams.
Each role contains permissions. A permission combines:
| Part | What it controls |
|---|---|
| Scope | The product area, such as Team Members, Checks, Roles, or Billing |
| Action | Whether the role can View or Manage that scope |
| Type | Whether MonitoringDog checks access against the organization, the current team, or the current user |
Organization-scoped permissions apply to organization-level actions, such as listing teams, creating teams, and managing roles. Team-scoped permissions apply to resources inside the active team, such as members, checks, incidents, integrations, and team settings.
Default roles
MonitoringDog creates default roles when it creates an organization.
| Role | Default access |
|---|---|
| Admin | Manage permissions across available scopes |
| Viewer | View access for team settings, team members, checks, incidents, escalation policies, status pages, integrations, API tokens, and on-call schedules |
The Role & Permissions page disables editing and deletion for default roles.
Custom roles are created with a name and a selected set of permissions. They are useful when a member needs narrower access than Admin or broader access than Viewer.
Invitations create membership
An invitation connects an email address, team, and role. The invitation starts with Pending status.
When MonitoringDog sends the invitation email, the acceptance link includes the invitation ID and email address. The invitee must sign in with the invited email address before the invitation expires.
| Invitation state | What it means |
|---|---|
| Pending | The invitation was sent and is waiting for acceptance |
| Resent | A new invitation email was sent and the acceptance window was refreshed |
Invitations expire after three days. Resending an invitation sets the status to Resent and starts another three-day window.
When an invited person accepts a valid invitation, MonitoringDog adds the person to the invitation's organization, assigns the selected role in the team, and removes the invitation record.
MonitoringDog blocks a duplicate active invitation for the same email address in the same team.
Permission checks use the active session
The dashboard reads the active team session and checks your role's permissions before rendering protected pages.
If the session does not include the required permission, MonitoringDog shows Access Denied. The backend also checks permissions for protected team and role APIs, so hiding or enabling a button in the UI is not the only access control.
Members may need to sign in again after a role change if an open session still shows older access.
Plan limits affect teams and members
Team creation counts against the organization's team limit. Invitations count against the organization's member limit.
When the current plan blocks more fixed resources, MonitoringDog rejects actions that would exceed the included quantity. The portal may show a plan warning before the action and can route the member to Billing & Usage after the backend rejects the request.
Plans that allow fixed-resource overage can permit the action instead of blocking it.