- Audience
- Organization administrators preparing the workspace for live operations.
- Read first
- Onboarding to complete the organization profile.
- Read next
- Trusted partners once thresholds and sharing defaults are set.
- Outcome
- Roles, sites, alerts, and policy thresholds aligned to operating reality.
Purpose
Organization settings are where the workspace stops being a generic Castlewatch tenant and starts behaving like your security operation. The settings page exposes six related groups of controls: members, mapped sites, notification defaults, policy thresholds, sharing defaults, and the organization profile. Each affects what other roles see and what they can do.
Treat the page as a configuration surface, not a dashboard. Changes here ripple into reports, review decisions, partner workflows, and notifications. Make changes deliberately and document them in the team's operating notes.
Members & roles
Members belong to an organization and receive exactly one role. Keep roles aligned with actual duties, not seniority alone. A small team may start with one administrator, one or two reviewers, and reporters who can submit incidents.
Role reference
| Role | Can do | Cannot do |
|---|---|---|
| Org admin | All organization configuration: members, sites, notifications, policies, sharing, profile, partners (subject to policy thresholds). | Nothing within the workspace; external billing-portal actions still depend on the billing account. |
| Reviewer | Claim, verify, request changes, reject, and return reports; comment on incidents; log sightings. | Manage members, change organization settings, or initiate partner requests unless thresholds allow it. |
| Reporter | Submit incidents, comment on their own reports, log sightings. | Approve or moderate reports; access reports outside their visibility scope. |
| Viewer | Read incident records inside their visibility scope. | Submit, moderate, comment, or change settings. |
Maintenance
- Review the member list quarterly and after staffing changes.
- Disable accounts immediately when someone leaves the security team.
- Avoid one-person dependencies — always have a second org admin.
- Promote a member's role only after confirming they have read the relevant article in this knowledge base.
Mapped sites
Mapped sites provide known coordinates for reporting and dashboard map placement. Add campuses, common event locations, or other operationally relevant places. Use labels that reporters will recognize quickly during an incident.
Site reference
| Field | Purpose | Tips |
|---|---|---|
| Label | Selectable name shown in the reporting form and on the map. | Use names staff already say aloud: "Main Campus", "North Lot", "Family Center". |
| Address | Human-readable location reference. | Use the street address even if coordinates are entered directly. |
| Coordinates | Latitude/longitude for map placement. | Verify with a map preview after saving — incorrect coordinates cause the most map-placement complaints. |
| Notes | Internal context for reviewers. | Note access points, blind spots, or operating hours if relevant. |
Accurate mapped sites improve the incident map. They also reduce location ambiguity in reports and review decisions. If incidents are not appearing on the map, see Troubleshooting → Map placement.
Notification defaults
Organization notification defaults define the baseline alert policy for incident events. They should be reviewed before inviting a large reporting group. Personal account preferences can layer on top of organization defaults, but organization defaults should reflect the leadership team's operating posture.
What organization defaults control
- Which events trigger alerts at the organization level (new submission, verified, changes requested, rejected, sighting, partner action).
- The minimum severity an event must reach before generating an alert.
- Whether new members start with notifications opted-in or opted-out.
- Quiet-hours guidance applied as a default (each user can adjust their own).
See Notifications & access for the personal-preferences layer and channel detail.
Policy thresholds
Policy thresholds decide which role is required to manage members, request partners, change organization settings, and update notification defaults. These thresholds are important because they turn trust into explicit permission rather than assumptions.
Threshold reference
| Action | Typical minimum | Reason |
|---|---|---|
| Invite members | Org admin | Affects who can act on behalf of the organization. |
| Change roles | Org admin | Direct security implication; should not be delegated casually. |
| Request partner connections | Org admin or trusted reviewer | External trust decision; harder to undo than internal settings. |
| Change notification defaults | Org admin | Affects how the whole team is alerted. |
| Edit mapped sites | Org admin or reviewer | Affects map accuracy across all incidents. |
| Change sharing defaults | Org admin | Implicates trust posture with partners. |
- Use the lowest role only when the task truly needs broad delegation.
- Keep partner requests restricted to people who understand the organization's trust posture.
- Review policy thresholds after leadership or security team changes.
- Document the chosen thresholds where the team can find them.
Organization profile
The organization profile contains the public-facing name, region, status, billing state, and plan context shown inside the workspace. Keep the profile current so trusted partners and team members can identify the organization accurately.
- Update the name promptly after a rebrand or merger.
- Update the region if the organization relocates or joins a different regional network.
- Use the billing portal link for plan changes and invoice access.
- Confirm the profile is up to date before requesting new trusted partners.
Common scenarios
Onboarding a new reviewer
Invite the member, assign the reviewer role, point them at the review workflow article, and confirm their personal notification preferences are set before they claim a report. Add them to any internal coordination channels you use.
A reporter cannot select a mapped site
Confirm the site exists, the coordinates are saved, and the reporter has refreshed the page. If the site is brand-new, the reporting form may still be cached — reload the workspace.
Partners are sending requests you do not recognize
Tighten the partner-request policy threshold so only org admins can accept incoming partner requests. Cross-check the requesting organization name and region against your trust list before accepting.
Notification volume is too high
Raise the organization minimum-severity threshold for non-critical events. Then ask the team to review personal alert preferences and quiet hours. See Notifications.
Frequently asked questions
Can two people share an org admin role?
Yes — and you should. Always maintain at least two org admins so a single departure does not lock the workspace.
What happens when a member's role is downgraded?
Their access changes immediately. Prior incidents they submitted remain under their authorship. Past comments are not retroactively removed.
Can a mapped site be deleted?
Sites can be archived or replaced. Existing incidents that referenced the site keep their location data. Avoid renaming sites mid-incident-investigation.
Do policy thresholds apply retroactively?
No. They apply to new actions from the moment they are saved. Existing partner connections and member assignments are not undone by tightening a threshold.
How often should settings be reviewed?
Quarterly, plus after any leadership change, regional realignment, or significant incident pattern.