Troubleshooting & FAQ

The sidebar only shows nav groups your workspace's edition actually has entitled — a Service Design-only workspace never shows Architecture Catalog, for example, because there's genuinely nothing in it to manage. This is different from a permissions problem: even an Admin account won't see a module the workspace isn't licensed for. Ask whoever manages your license/plan (Settings → Plan & Usage, or your platform operator) whether the module you're expecting is included.

Settings is Admin-only. Editors can create, edit and delete catalog data but never see Settings, user management, API keys or backups; Viewers are read-only everywhere. This is enforced on the backend too, not just hidden in the UI, so there's no URL workaround — you'd need an Admin to either change your role or make the specific change for you.

Three unrelated things produce the same symptom. First, and most common: you're signed in as a Viewer, which is read-only across all data by design. Second, the record may be governed and currently sitting in a review/approved/published state — most governed records lock further direct edits once approved, and a published Position Paper specifically can only be revised via Supersede, not by editing the published copy directly. Third, a record on a custom-field Survey or Recertification schedule can have its "seal" broken by anyone other than the field's original owner editing it — not a lock exactly, but it flags the record as needing re-review sooner than its normal schedule. Check the record's status/governance panel before assuming it's a bug.

Any new local-account user — including the very first bootstrap admin on a fresh install — is created with a forced password-rotation flag. The password an Admin (or the installer) set for you is, by definition, known to at least one other person, so the first real sign-in requires you to replace it with one only you know before you can do anything else. This only applies to local accounts; SSO/OIDC/LDAP sign-ins skip it entirely since Eidon never sees or sets that password.

Your workspace has multi-factor authentication turned on for local accounts (Settings → Security, Admin-only). It only applies to local username/password sign-in — SSO and LDAP sign-ins are unaffected, since MFA for those is handled by the identity provider instead, not by Eidon.

Confluence export (and Jira/Azure DevOps work item linking) both require the connectors plan feature to be entitled on your workspace's tier. If you don't see the export action at all, check Settings → Plan & Usage rather than assuming the integration isn't configured — a missing feature entitlement looks identical to a missing configuration from the button's absence alone.

Bulk Import silently skips any row whose name duplicates an existing record of the same entity type — it's treated as "already loaded," not an error. Check the import preview step before confirming; it shows which rows will be skipped so you're not surprised afterward. If you actually intended to update an existing record rather than create a new one, use Bulk Edit on the list page instead of re-importing.

If a record is on a Recertification schedule or a custom-field Survey, its "seal" breaks the moment anyone *other than the field's original owner* edits it — even a small, unrelated field change. This is deliberate: it's a safeguard against a record quietly drifting out of date because someone other than the accountable owner touched it. The fix is the same one-click "mark reviewed" action used for any other overdue recertification.

This is intentional, not a bug: for most governed record types the *creation/launch* is what's governed, but for an Architectural Service the governed transition is specifically retiring it, since decommissioning a service — especially a tier-1 one — is the operation with real blast radius. A service opens for editing straight to "active" with no review needed; only the retire action routes through Review Requests/Approval Chain.

Global Search only covers major catalog entity types (applications, decisions, capabilities, and so on) within your own workspace's data — it does not search this manual's text, and it never returns another workspace's records. If you're looking for a manual topic rather than catalog data, use this manual's chapter list (or its per-chapter browser find) instead.