Onboarding and workspace activation

Purpose

Onboarding turns a new Castlewatch account into an organization workspace. The workspace is the boundary for members, roles, incident ownership, trusted partner relationships, default sharing policy, mapped sites, and alert routing. A user can have a valid login while the organization is still incomplete, so onboarding should be treated as the first operational configuration step, not a marketing form.

For most teams, one trusted administrator should complete onboarding before inviting other users. That keeps the initial organization name, region, and billing path controlled by the person responsible for operating the workspace.

Before you start

• Confirm the official organization name that should appear in incident records and trusted partner requests.
• Choose a region label other churches or partner organizations will recognize, such as a metro area, county, or regional network name.
• Decide who will be the first organization administrator and who will be invited later as reviewers, reporters, or viewers.
• Know whether the workspace is only being evaluated or should be activated for live reporting immediately.

Activation steps

1. Create the first account from the Castlewatch signup page.
2. Complete the organization profile with the correct name and region.
3. Confirm the profile saves successfully and routes you into the workspace dashboard.
4. Review billing when the team is ready to use live operational workflows.
5. Open organization settings and configure members, sites, notifications, policy thresholds, and sharing defaults before broad rollout.

If onboarding repeatedly returns you to the onboarding page, verify that the organization region and profile fields were saved. An incomplete organization profile can block the rest of the workspace.

Administrator handoff

After onboarding, the administrator should document the operating expectations for the team. At minimum, define who may submit reports, who may review and verify reports, who may invite members, and who may request trusted partners. This prevents early confusion when the first real incident is submitted.

• Add mapped sites before relying on the dashboard map.
• Set organization notification defaults before inviting high-volume reporters.
• Confirm trusted partner policy thresholds before partner requests begin.
• Use the account page to configure personal alert preferences and account security.

Common mistakes

• Using a personal nickname instead of the organization name, which makes partner requests harder to recognize.
• Inviting the whole team before roles and policy thresholds are configured.
• Skipping mapped sites, then expecting incidents to appear accurately on the dashboard map.
• Assuming billing, notifications, and trusted partner workflows are ready before checking organization settings.