Skip to main content
This page collects the issues we see most often at the Organization scope. Each section starts with the symptom and walks through the checks in order — fast checks first.

​
An administrator can’t sign in to the Admin Portal

The default Admin Portal authentication is Form Login. If a colleague tells you “I can’t sign in,” walk through these in order:
  1. Are they listed under Administrators? Search the table by their email. No row → no access. Invite them, or check whether the invitation expired before they accepted (the row would show Pending Invite with Invite expires:).
  2. Is the row Pending Invite? Pick Resend invitation from the action menu to issue a fresh link. The old link stops working immediately.
  3. Do they hold at least one role? A row with no role pills has no effective access. Pick Modify and tick at least one of Organization Owner / Organization Context Manager / Organization Member.
  4. Is the network they’re signing in from covered by your Admin Dashboard Access whitelist? Open Organization Settings and confirm the whitelist either is 0.0.0.0/0 (allow all) or includes a CIDR that matches their current public IP.
  5. Is Mandatory Email MFA on, and are they hitting the MFA prompt? A user who never receives the MFA email — check their inbox, spam folder, then forwarders / aliases. If the email never arrives, the account they were invited under may be one their mail server silently drops; ask them to confirm the address or invite a working alternate.
If they’re trying to sign in via SAML, see the next section first.

​
SAML sign-in fails

Whether for the Admin Portal or the Self-Service Portal, the most common SAML failures fall into a handful of categories. From the sign-in error page or the IdP’s failure log, narrow first.
  1. The IdP’s signing certificate has expired. This is the most common SAML failure in production. Open the relevant SAML page (Admin Portal or Self-Service Portal) and replace the IdP X.509 Certificate (Base64) with the IdP’s current certificate.
  2. The IdP isn’t sending the username attribute the platform expects. The default attribute name is the Microsoft email-address claim (http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress). If your IdP uses a different attribute, either reconfigure the IdP to use that one, or have the IdP send the email under the alternative attribute https://adminconsole.netsign-in.se/saml/attributes/username — the platform reads either.
  3. The user isn’t assigned to the IdP application. Most IdPs require explicit user / group assignment before SAML assertions are issued for that user. Confirm the user is assigned to the right application in your IdP.
  4. The role attribute the IdP sends doesn’t map to anything. Only relevant for Admin Portal SAML with Override Default Role Mapping. If the IdP returns a role string that isn’t in Custom SAML Role Mappings, the user lands on a sign-in error. Either add the missing mapping or change the IdP’s role attribute output.
  5. The Admin Portal SAML toggle is off. Open Admin Portal authentication and confirm Enable SAML 2.0 Admin Dashboard Authentication is ticked. Same for Self-Service Portal: the Enable SAML 2.0 Self Service Authentication toggle. A saved-but-not-enabled configuration is one of the easier mistakes to make.
While you’re debugging, stay signed in as Form Login on a separate browser session. If you sign yourself out of Form Login to test SAML and SAML doesn’t work, you have no way back in except a break-glass account.

​
A webhook isn’t delivering

Open the webhook’s detail page and look at Recent Deliveries.
  1. The webhook is disabled. The Status column on the list page should be Enabled (green). Open the webhook’s detail and tick Webhook Active under the Active card.
  2. The webhook isn’t subscribed to the event you expect. At Organization scope the only event is organization.configuration.audit; confirm the Webhook Events card has the Configuration Change checkbox ticked.
  3. The endpoint is returning 4xx or 5xx. Open the most recent delivery in Recent Deliveries. Each Delivery Attempt has a Response sub-tab showing the HTTP status, headers, and body. A consistent 404 usually means the path is wrong; a 401 or 403 usually means an authentication header is missing or wrong; 5xx means your endpoint is erroring.
  4. Outbound network is blocked. The platform retries failed deliveries with increasing back-off. If even the first attempt times out completely (no response at all), check whether your endpoint’s public DNS resolves and is reachable from the public internet — many corporate endpoints aren’t.
  5. The deliveries you’re missing are older than 3 days. Recent Deliveries keeps each delivery for 3 days. The webhook configuration itself is preserved indefinitely; only the per-delivery records are on a TTL.
If the endpoint is now fixed and you want to backfill the missed events, replay them from the Audit Log or from your own change source of truth — failed deliveries cannot be retried from the platform.

​
An audit row I expected isn’t there

  1. A filter is still applied. Click Clear at the top of the Audit Log to reset all three filters (User, Timestamp from, Timestamp to).
  2. The change happened inside a Service Context. The Audit Log shows every change in the Organization, but the Context column will be set for Context-scope changes. Look at the Context column when scanning, or filter by the user who made the change.
  3. The change was a read, not a write. Read-only operations (filtering, viewing a Sign-In Module, opening an admin) don’t emit audit rows. Only changes do.
  4. The timestamp is in your Organization’s timezone. If your team works across timezones, what looks like “yesterday” to you may be tomorrow to the audit feed. Filter by username first if the date range is genuinely uncertain.
There is no way to back-fill or correct an audit row from the admin. The log is append-only; if a change is missing, it wasn’t captured.

​
A change saved but downstream behaviour didn’t match

The most common case: an admin changes a configuration value, the change is audited, but the user-facing behaviour doesn’t update.
  1. Caching at the user side. Some changes (Login Button Text on a SAML page, Self-Service Portal copy) cache aggressively in the user’s browser. Have them hard-reload (Shift-Reload).
  2. The change was inside a Service Context, not at Organization scope. Confirm where you saved by looking at the breadcrumb / left-nav highlight at the time of the change. Service Context-level changes don’t propagate to the Organization layer or to other Contexts.
  3. A Sign-In Module is hot-cached. Some Sign-In Module changes (terms text, captive-portal logos) require Sign-In session re-validation before users see them. Open a fresh captive- portal session to test.

​
I locked myself out by tightening Admin Dashboard Access

The Admin Dashboard Access whitelist is enforced strictly: a sign-in attempt from an IP not covered by any listed CIDR is refused. If you tightened the whitelist and your current network isn’t in it, the platform will not let you in. The recovery requires another Organization Owner who can still sign in to undo the change. This is one of the situations where having a second Organization Owner who routinely works from a different network (a colleague who works remote, a break-glass account that’s reachable from any network) is exactly what you need. If no other Owner can sign in and you have no break-glass account, contact Netgraph support — the Admin Dashboard Access whitelist can be cleared on your behalf. This is one of the rare interventions the platform team performs manually.
  1. Check the user’s mail filtering. Email Magic Link emails come from the platform’s transactional email infrastructure; some corporate mail servers tag transactional mail aggressively as junk. Have them check the spam / junk / promotions folder.
  2. Confirm the email address is the one they were invited under. A Self-Service User can only receive a magic link at the address listed in their Self-Service User row inside the relevant Service Context. If they read mail at a different address, they need to ask the Service Context’s admin to re-invite.
  3. Check the Mail Login Token Lifetime. A user who clicks the link long after it arrives gets a “link expired” page. Either they need a fresh link, or the lifetime in Organization Settings → Self-Service Portal Settings is too short for your audience’s reading habits.

​
Where to go next

Admin Portal authentication

Configure Form Login, MFA, and SAML 2.0 for administrators.

Self-Service Portal authentication

Configure Email Magic Link and SAML 2.0 for end users.

Webhooks

Recent Deliveries is your first stop for any delivery issue.

Audit Log

Filter by user and date to corroborate or rule out a change.