Notifications, roles, billing & access

Role-based access

Castlewatch roles determine which actions appear and which workflows are available. If a button or section is missing, role permissions should be checked before assuming the feature is unavailable. Organization policy thresholds can further restrict who manages members, partner requests, settings, and notification defaults.

Role hierarchy, lowest to highest privilege: Viewer → Reporter → Reviewer → Org Admin. See Organization settings → Members & roles for full capability reference.

Billing gates

Some operational areas require an active subscription before live use. This protects the workspace from partial production operation. If reporting, moderation, incident access, or organization administration appears locked, confirm the organization's billing state and plan status.

What is gated

• Submitting incidents.
• Reviewer actions (claim, verify, reject, request changes).
• Trusted partner request initiation.
• Some organization settings related to live operations.

What still works without active billing

• Organization profile and basic configuration.
• Adding mapped sites.
• Reading the knowledge base and user guide.
• Inviting members for evaluation.

Billing checkout and billing portal flows intentionally navigate away from the current page because they depend on a hosted payment or account management flow. Return to the workspace when complete.

Notifications

Notification behavior has two layers. Organization defaults define broad operating expectations. Personal alert preferences let each user control delivery per event, channel, severity threshold, quiet hours, and SMS destination when applicable.

How the layers combine

1. The platform checks organization defaults to see if an event is enabled for the org at the chosen severity.
2. Then the user's personal preferences filter further — channel choice, quiet hours, opt-outs.
3. If both layers allow the notification, it is delivered.

This means org defaults set the maximum alerting; personal preferences refine downward. A user cannot enable a notification their organization has disabled.

Channels & severity

Use each channel for the signal it suits best. Mixing them well is the difference between useful alerting and notification fatigue.

Severity-channel pairing (typical)

• Set quiet hours carefully so urgent notifications still reach the right people.
• Always include a real SMS destination for users who opt in to SMS.
• Configure quiet hours by role, not by individual schedule, when possible.

Account settings

The account page manages profile details, sign-in posture, chat visibility, and personal notification preferences. Profile updates and alert preference changes happen on-page with visible success or error feedback.

MFA & sessions

Castlewatch supports authenticator-app multi-factor authentication. Administrators and reviewers should enable MFA where possible because their actions affect the whole workspace.

Enrollment

1. From the account page, start MFA enrollment.
2. Scan the displayed QR code with an authenticator app (1Password, Authy, Google Authenticator).
3. Enter the current six-digit code to confirm enrollment.
4. Save the recovery code somewhere your team can access without depending on the same device.

Session behavior

• Password changes revoke all active sessions — you will be signed out everywhere.
• MFA enrollment does not retroactively revoke sessions, but the next sign-in will require the code.
• Sign out manually on shared devices.

Security posture

• Use recognizable display names and current email addresses.
• Enable authenticator MFA for administrators and reviewers where possible.
• Review role assignments after staffing changes.
• Disable accounts that should no longer have operational access.
• Keep chat visibility aligned with how the team uses internal coordination.
• Maintain at least two org admins so the workspace is not single-person dependent.

Common scenarios

Frequently asked questions

Related articles