Onboarding Checklist

note

API paths that contain tenant keep that word for compatibility. In the product it means your workspace.

Follow this sequence when activating a new workspace. Share the checklist with the customer's admin so both sides stay aligned. If a term is unfamiliar during setup (for example EvidencePack, quota, or rate limit), open the Glossary.

First login to first successful outcome walkthrough

This is the fastest low-risk path for a brand-new workspace operator.

When a workspace user signs in for the first time on that browser, Dralvia opens the in-platform Getting Started page and displays a short walkthrough tour. The tour explains the first steps in order: review Getting Started, confirm the workspace and plan, create a workspace API key, run one scan, and open evidence. Users can choose Skip tour at any time. Skipping only hides the walkthrough; the Getting Started page remains available from the left navigation.

Signed-in pages show your workspace ID (derived from your sign-in identity) and your plan by its customer name: Free Evaluation, Starter, Pro, or Enterprise. The same plan names appear on Usage, License & Plan, API Keys, and the Pro Tier console, so what you see always matches what you bought.

#/getting-started now opens on Overview and separates the rest of the route into:

• Quick wins for first proof-point workflows
• Checklist for the five onboarding tasks
• Tracks for design-partner workflow patterns
• API for connectivity validation

Checklist auto-detection and first value

The onboarding checklist verifies itself against live workspace data, so progress is real instead of self-declared:

• Steps the platform can prove (active license, workspace API key, active webhook, first scan activity, first escalation) show a green Detected badge instead of a manual toggle. Detection comes from your workspace records, not from anything stored in the browser.
• Steps the platform cannot verify yet keep the manual Mark done toggle, and that manual progress stays on the device you used.
• The Overview tab shows a First value row: Reached with the date of your first workspace activity, or Not yet with the suggested next step.

Automation can read the same status: GET /tenant/onboarding/status returns the five checklist steps with completion evidence, the completed count, and the first_value block. The endpoint is workspace-scoped and uses your signed-in session or API credentials.

Prerequisites

• Workspace owner/admin account already invited.
• Workspace API key created for your environment.
• At least one test domain and one internal test user ready.

Screenshot checklist (capture during your run)

Capture and store these screenshots in your internal workspace onboarding record:

1. First successful login landing page (#/).
2. API key created successfully (#/api-keys).
3. First successful scan result and score (#/phishing).
4. First EvidencePack (Dralvia's exportable evidence report) verification pass (#/trust-verify).
5. First readiness probe result (#/autonomous-readiness).

Annotated screenshots (reference)

Use these annotated screenshots while running the checklist. They mirror the expected operator flow.

Figure 1: First login and workspace context check.

Figure 2: API key creation in settings.

Figure 3: First successful scanner result.

Figure 4: Evidence verifier pass flow.

Figure 5: Autonomous readiness probe flow.

Walkthrough: first login to first success

1. Sign in and confirm you are in the correct workspace context.
2. If the first-login tour appears, either follow it or select Skip tour.
3. Open API Keys and create an API key for this environment.
4. Open URL & Phishing Scanner, run one scan for a known test domain.
5. Confirm scan result appears with non-empty findings.
6. Open Evidence Verifier, load latest entry, and run verify.
7. Open Autonomous Readiness, run one probe, and confirm status loads.

Expected result

• Operator can authenticate, run one scan, verify one EvidencePack, and run one readiness probe without support intervention.

Rollback path

1. If wrong workspace context was used, sign out and re-authenticate in the correct workspace.
2. Revoke accidentally exposed API keys and create new scoped keys.
3. Remove mistaken test data and repeat walkthrough with approved test artifacts.

1. Environment readiness

• Confirm your workspace base URL, admin console URL, and sign-in method with your Dralvia CSM.
• Decide which identity provider you’ll connect (Dralvia-managed users, SAML/OIDC federation, etc.).
• Capture your desired feature set (SWG dry-run, adaptive shadow browsing, email protection, EDR) so Dralvia can enable the correct toggles on day one.

2. Access provisioning

Artifact	Owner	Notes
Admin console invite	Dralvia CSM	Receive the Dralvia sign-in invite and workspace URL.
API key	Workspace admin	Generate per environment (dev/stage/prod) under Settings → API Keys.
Evidence storage	Workspace admin	Decide where to archive EvidencePacks (local download, S3, SIEM, etc.).
Support contacts	Both	Capture escalation matrix (SOC lead, dev lead, Dralvia CSM).

3. Tool rollout

1. Browser extension
   • Install the signed MV3 build provided by Dralvia (or follow the dev-mode instructions in the Browser Extension guide).
   • Configure the default API endpoint + API key once, then push via your browser management tool.
2. Email protection
   • Configure journaling/SMTP relay to POST messages into /email/protect.
   • Validate safe-link rewriting by clicking the rewritten URLs in pilot mailboxes.
3. EDR sensors
   • Deploy the platform-specific sensor package supplied by Dralvia.
   • Register sensor IDs in the admin console so isolation commands map correctly.
4. Identity telemetry
   • Wire IdP/SSO logs into /identity/events using the provided JSON schema.
   • Work with your CSM to enable impossible-travel alerts after the first event tests pass.

4. Train the team

• Walk through the workspace playbook sections (Developer, Security Ops, Compliance).
• Review EvidencePacks, TicketBridge workflow, and SWG policy controls in a live session.
• Point engineers to the public SDK source on GitHub (https://github.com/Dralvia/dralvia-sdk) and the Postman collection in the Docs portal so they can self-serve. The SDK is public; there is no onboarding-gated download.

5. Success criteria

Milestone	Target
First scan + EvidencePack	Day 1
Email safe-link rewrite running	Week 1
SWG policies tuned with inline coaching	Week 2
EDR/Identity alerts flowing into SOC	Week 3

Track these in the pilot KPI dashboard (#/pilot-kpis). Escalate blockers via the support guide if timelines slip.

Who this is for

This guide is for workspace owners, workspace admins, and security operators who need clear, repeatable steps without support intervention for day-to-day execution.

Role-based start here

• Workspace Owner: Start with Before you start, then complete Step-by-step and Known limits and rate limits.
• Workspace Admin: Focus on Step-by-step, What each button does, and API and automation.
• Security Analyst: Start at Day-2 operations and Troubleshooting, then use API error quick reference.
• Integrator/Engineer: Start at API and automation, then validate with Step-by-step and FAQ.

Before you start

Use this short checklist before making changes:

1. Confirm you are signed into the correct workspace account.
2. Confirm your role includes the permissions needed for this page.
3. Confirm your browser session is fresh (if pages behave unexpectedly, sign out/in once).
4. Confirm required prerequisites (API keys, agent enrollment, license, upstream integrations) are already in place.

Step-by-step

Follow this sequence for predictable results:

1. Open the workspace from the workspace menu.
2. Review current status/health/last update indicators before making changes.
3. Apply one change at a time and save.
4. Run the available validate/probe/refresh action.
5. Confirm the expected output appears (status change, new event, successful result).
6. If behavior is not as expected, use Troubleshooting below before repeating actions.

Day-2 operations

After initial setup, keep this surface healthy with a simple routine:

1. Daily: verify data freshness and error banners.
2. Weekly: review trends, limits, and failed actions.
3. Monthly: review permissions, keys/tokens, and stale entities.
4. After any incident: capture evidence and update your internal operating notes.

What each button does

Button labels can vary by module, but behavior is consistent:

• Refresh: reloads the latest data from backend APIs without changing configuration.
• Save: persists workspace-scoped configuration changes.
• Run/Probe/Validate: executes a non-destructive health or verification action.
• Download: fetches workspace-scoped artifact(s) (for example bundle, checksum, signature, or report).
• Verify: checks integrity/consistency and returns pass/fail details.
• Enable/Disable: toggles module behavior for your workspace; audit evidence should be recorded.

If a button appears disabled, check role permissions, required fields, and workspace license/feature entitlement first.

Self-check playbook

Use this 5-step isolation flow before escalating:

1. Configuration: confirm required inputs are present and formatted correctly.
2. Permission: confirm your role can perform the action (401/403 usually indicates authz/authn mismatch).
3. License/feature: confirm the feature is enabled for your workspace plan and module toggles.
4. Quota/rate limit: check for 429 responses and cooldown windows.
5. Service health: if you see 5xx, retry once after 30-60 seconds and capture exact error text.

If still failing, escalate with workspace ID, UTC timestamp, route, action, payload shape (no secrets), and screenshot/error response.

Troubleshooting

Use this quick triage order to reduce time-to-fix:

1. Auth/session: refresh token by signing out/in.
2. Workspace context: confirm you are in the correct workspace.
3. Inputs/config: verify required fields and formats.
4. Quota/license: confirm limits and feature entitlement.
5. Service health: retry after short delay if backend is transiently degraded.

For escalation, include workspace ID, timestamp (UTC), route name, action attempted, and full error message.

API and automation

Everything in this page should remain workspace-scoped. If your team prefers automation, use the corresponding API endpoints with the same guardrails as the UI:

• Use authenticated requests bound to your workspace context.
• Use idempotency/retry controls where available.
• Validate outcomes in the UI after automated runs.

If your endpoint mapping is not obvious, start from Help Center and follow the linked API docs.

Next best actions

After finishing this page, continue with related workflows so your workspace setup stays end-to-end complete:

• EDR response and host actions
• Web Access Protection and dry-run events
• Identity risk and OAuth response
• EvidencePack verification and transparency log
• Risk economics and plan recommendation

FAQ

Q: I clicked save but nothing changed. A: Refresh once, confirm permissions, and verify required fields.

Q: Why do I see missing API key/unauthorized errors? A: Confirm your workspace API key/session is valid and mapped to the correct workspace scope.

Q: Can non-admin users use this page? A: Usually read-only access is possible; write actions require workspace-admin or equivalent roles.

Next steps

After finishing this guide:

1. Validate the result in the related dashboard/workspace.
2. Export or capture evidence if this affects compliance/incident operations.
3. Share the same runbook internally so other operators follow identical steps.
4. Return to Help Center for adjacent workflows.

API error quick reference

Use this matrix when a UI action fails with an HTTP/API error.

Error	Meaning	What to do now
401 Unauthorized	Session token is missing/expired or request is not authenticated.	Sign out/in, refresh once, then retry. Confirm your session is active in the correct workspace.
403 Forbidden	You are authenticated but your role is not allowed to perform this action.	Confirm your role includes the required permission for this button/action. Ask workspace admin to grant access.
404 Not Found	The route/resource does not exist in current workspace context (or feature not enabled).	Confirm URL/route, workspace context, and feature availability. Refresh and retry; if persistent, capture timestamp and route and contact support.
429 Too Many Requests	Rate limit/quota window was exceeded.	Wait for cooldown/reset window, retry once, then reduce burst traffic/backoff if automated.
500 Internal Server Error	Backend failed unexpectedly while processing the request.	Retry after 30-60 seconds. If still failing, escalate with workspace ID, UTC time, route, action, and full error text.

Known limits and rate limits

These limits can vary by plan and feature, but behavior is consistent:

• Burst traffic can trigger 429 Too Many Requests.
• Workspace quotas apply per feature/module and reset on configured windows.
• Repeated retries without backoff can extend recovery time during saturation.

Recommended operator behavior:

1. Retry once after cooldown for 429 responses.
2. Use exponential backoff in automation.
3. Monitor usage/quota dashboards for sustained high utilization.
4. Request quota review when normal workload regularly approaches limits.