Organization settings

/settings configures the active organization. Tabs are permission-aware: viewers have read-only access, editors can manage operational content, and admins have settings management. Some billing actions are plan- and role-gated. The product prevents removal of the last admin.

General

Maintain company name, primary domain, industry, country, and logo. These values appear throughout Noru and can influence trust, report, and onboarding context. Organization deletion is destructive and requires name confirmation; export anything you must retain first.

Billing

Review plan, trial, renewal, invoice/subscription management, and checkout eligibility. Cancelling a trial can begin workspace deletion, so treat it as a data-lifecycle decision, not merely a payment preference. Enterprise billing may be managed through the Noru team.

Context

Organization Context is reusable background for Cortex and generated content. Describe what the company does, products, customers, architecture boundaries, and relevant operating constraints. Keep it factual, short, and free of secrets. Generated answers inherit errors and ambiguity in this context.

Members and roles

• Admin: full organization and settings access.
• Editor: can manage content and workflows with limited settings access.
• Viewer: read-only organization access.

Invite with least privilege, review pending invitations, change roles deliberately, and remove access at offboarding. Organization membership is separate from the Personnel directory: membership grants Noru application access; Personnel represents the compliance population and external identities.

Security

Admins can require multi-factor authentication for the organization. Members who do not meet the requirement are routed through the MFA-required experience. This protects Noru access; it does not enforce MFA in your cloud, HR, source-code, or vendor systems.

Frameworks

Select the standards/regulations genuinely in scope. Framework selection loads requirement mappings and can generate or regenerate baseline policies. Review generated policies and controls before approval: enabling a framework does not make the organization compliant, and enabling every framework can obscure the real program.

Developer

Create scoped API keys for REST API and MCP access. Give each key a recognizable name, the minimum scopes, and an expiry where practical. The secret is shown at creation; store it in a secrets manager. Revoke unused or exposed keys and review existing key status/last-use information.

The /oauth/mcp/consent page is the authorization-consent step for MCP clients. Confirm the client and requested access before approving.

Integrations

Configure organization-level REST API, MCP, Slack, and Microsoft Teams experiences. These are separate from the evidence/data-source connectors under /data-sources. Restrict chat and automation access to approved channels and remember that responses can expose organization compliance context to permitted users.