Decision LighthouseDecision Lighthouse documentation
Open Admin Dashboard
For Decision Lighthouse platform operators

Super Admin Guide

Manage Decision Lighthouse across organizations while preserving tenant isolation, identity integrity, auditability, and safe operational change.

Super admin access is cross-organization administrative access. Use it only for platform operations and documented support work.

Operating principles

Least privilege

Use the organization-scoped admin role for organization work. Use super admin only when the task crosses an organization boundary or requires platform control.

Explicit organization context

Select the target organization before acting. When no organization is selected, treat cross-organization views as a platform overview—not as permission to edit everything casually.

Audit everything

Administrative, user, report, presentation, template, schedule, and organization changes are governance events. Record the reason and ticket or change reference in your approved system.

Protect secrets

Never place passwords, API keys, private keys, session tokens, or connection strings in Decision Lighthouse content or support notes.

Organizations

Create an organization

  1. Open the Admin Dashboard and confirm you are signed in as a super admin.
  2. Create the organization with its approved name and domain. Verify the domain before onboarding users.
  3. Configure organization-level settings, including an HTTPS PATHScan URL when applicable.
  4. Create the first organization admin. Confirm the target organization and role before saving.
  5. Verify the organization appears in the organization list and that the user count and status are correct.

Select and inspect an organization

Use organization selection for scoped user lists, statistics, assessments, reports, tasks, and operational review. Before making a change, confirm the selected organization in the dashboard and the user or resource identity in the response.

Delete an organization

Destructive action: organization deletion is allowed only when the organization has no users. Related vulnerability decisions and outcomes, rankings, tasks, reports, assessments, webhooks, scheduled reports, and audit logs are cascaded. Obtain explicit approval, export or retain required records, and verify the organization is empty before deletion.

Users and identity

Create or import users

  1. Create users in the correct organization with the minimum necessary role. Normal user creation provisions the identity through Auth0 and can show a pending provisioning state.
  2. Use CSV import for a controlled batch. Validate email, name, role, module, and trial date before importing. The supported module is cybersecurity.
  3. Do not create a super admin for normal organization work. Assign that role only through an approved platform access process.
  4. After provisioning, verify the user’s active state, role, organization, and login status.

Update, disable, reset, and delete

  • Update: change name, role, active state, module, permissions, organization, or trial expiration only when the change is authorized.
  • Disable: deactivate access promptly when a user leaves or no longer has a business need.
  • Reset: use the supported reset-password action. The user must follow the Auth0 or local password flow and change temporary credentials as required.
  • Delete: cannot delete your own account. Deleting a user clears foreign-key ownership references but preserves audit and invitation/signup records for auditability.
  • Transfer: organization transfer changes the user’s tenant context. Confirm the receiving organization, business owner, and downstream access before committing.
Role safeguards: organization admins cannot manage super admin accounts, assign the admin role to a lower role, or transfer users across organizations. Super admins are responsible for enforcing those boundaries, not bypassing them.

Trial and access lifecycle

Set and review trial expiration dates deliberately. A newly created user defaults to 30 days when no date is provided. When changing a trial date, communicate the effective date to the organization owner and record the reason outside of Decision Lighthouse’s secret-bearing fields.

  • Review organizations with upcoming expirations.
  • Confirm the organization’s contract or access approval before extending access.
  • Disable inactive accounts rather than leaving unused access active.
  • Check Auth0 provisioning status before diagnosing a login problem as an application problem.

Reports, assessments, and presentations

Super admins can review cross-organization history when platform support or governance requires it. Prefer the narrowest organization filter and the smallest necessary time range.

  • Use report detail and assessment history to reconstruct a decision journey.
  • Use report HTML export or stakeholder presentations only for approved recipients and approved retention purposes.
  • Presentation generation requires a completed assessment. Confirm the stakeholder audience before selecting a presentation type.
  • Review report deletion requests for retention, legal hold, incident response, or audit requirements before deleting.
  • When a report has missing historical interview data, allow the detail view to backfill or recover it through the supported application flow rather than editing storage manually.

Governance controls

Audit logs

Use audit logs to investigate user changes, report actions, organization changes, scheduling, webhooks, templates, and other administrative events. Preserve the evidence needed for the platform’s governance policy.

Scheduled reports

Review schedules for organization, recipients, cadence, and scope. Remove schedules that no longer have an owner. Confirm that generated reports do not exceed the recipients’ authorization.

Webhooks

Validate endpoint ownership and security before enabling a webhook. Treat the destination as a data processor: confirm classification, transport security, access controls, and incident contacts.

Presentation templates

Manage organization templates only after checking file type, size, branding, and owner approval. Keep organization templates scoped to the intended organization.

Vulnerability and remediation operations

  1. Review or establish the organization’s vulnerability policy with the security owner.
  2. Confirm governance documents and vulnerability lists are authorized before analysis. Source bytes and descriptions should not be treated as retained records.
  3. Check rejected-row validation notices before approving a prioritization.
  4. Use approved history, comparison, and captured outcomes to support remediation governance.
  5. When an outcome changes the organization’s future decision policy, document that change in the organization’s approved governance process rather than silently changing historical decisions.

Strategic Plan Prioritization operations

Super admins should help organizations understand the privacy boundary and decision mechanics:

  • The source plan or pasted text is used for extraction and analysis but is not saved as an approved ranking record.
  • The interview is adaptive, bounded, and capped at 10 questions.
  • Ranking requires a server-calculated 100% context score.
  • Unknowns remain unknown; dependencies are displayed by name, and inferred dependencies do not automatically change scores.
  • Only an explicitly approved derived ranking is retained for comparison, with its name, rationale, and approval date.

Security and incident response

  • Use Auth0 status and provisioning information when troubleshooting identity.
  • Do not ask users to paste credentials, tokens, or private keys into chat, tickets, reports, or Decision Lighthouse fields.
  • Use organization-scoped views first and avoid downloading broad cross-tenant data.
  • For an unexpected access or data-boundary event, preserve audit entries, identify affected organization and users, disable access if authorized, and follow the organization’s incident process.
  • Do not make direct database edits to repair application state unless the approved engineering recovery process explicitly requires it.

Super admin runbook

SituationSafe first response
User cannot sign inCheck active state, organization, role, Auth0 provisioning status, and trial expiration before resetting the password.
Admin sees the wrong organizationConfirm session organization and selected organization, then inspect the server-scoped response and audit log.
Report should be removedCheck retention and legal-hold requirements, confirm the report/organization, then use the supported delete action.
Organization should be retiredExport or retain required records, remove users through the approved process, verify the organization is empty, then request deletion approval.
Webhook or schedule is suspiciousDisable or remove it if authorized, preserve the audit record, validate the destination owner, and follow incident response.