01 - Settings, Security
The Security tab under Settings is the central place for configuring account-level protections that apply to everyone signing in to your Flagright Console tenant. It covers Multi-Factor Authentication (MFA), brute force account blocking, session timeout, concurrent session limits, and password expiration. Enterprise SSO is also configured from this tab and is covered in its own section.
Multi-Factor Authentication (MFA)
MFA adds a second authentication factor on top of a user's password, significantly reducing the risk of unauthorized access even if a password is compromised.
Enable or disable MFA using the MFA toggle under Settings, Security.
Today, MFA is authenticator app based only (for example Google Authenticator or Authy). SMS and email codes are not part of the current setup.
When enabled, MFA applies to all users on the tenant. There is no per-user opt out.
Users configure MFA using any authenticator app during their first login after MFA is enabled. After entering their password, they provide a time based code from that app on every subsequent login (or every 30 days, depending on configuration).
MFA can be turned off at any time using the same toggle, which returns the tenant to password only login.
Tip: If a user loses their device or deletes their authenticator app, don't disable MFA tenant wide. Instead, reset MFA for that individual account from Team Management, Team Accounts, Reset MFA. This removes all MFA settings for that user only, and they are prompted to re-enroll from scratch on their next login. |
SSO users are a special case worth understanding separately, since they don't always go through Flagright's own MFA check.
Note: MFA behaves differently for SSO users. If your Identity Provider (IdP) already enforces MFA (for example Microsoft Entra Authenticator), SSO users authenticate with IdP-side MFA rather than Flagright's console MFA. |
Brute Force Account Blocking
Brute force protection automatically suspends a user account after repeated failed login attempts, reducing the risk of credential guessing attacks.
Go to Settings, Security and toggle on Brute force account blocking.
Once enabled, an account is automatically suspended after three consecutive failed login attempts.
Suspended users see an on screen error message when attempting to log in.
Suspended accounts are marked with a Brute Force tag in Team Management, Team Accounts.
Any user with Team Management access can reactivate a suspended account by toggling its status back to active.
Session Timeout
Session timeout automatically ends a user's console session after a period of inactivity, reducing exposure from unattended or idle browser sessions.
Inactivity is measured based on user interaction within the Flagright Console browser window specifically, such as clicks or navigation. A user may be active in other browser tabs, but if there is no interaction within the Console tab itself, the session is treated as idle and times out on schedule.
Go to Settings, Security.
Choose a session timeout duration (for example 30 minutes, 1 hour, or 24 hours).
Save your changes.
Once the configured inactivity period elapses, the user is automatically logged out and must log in again.
Concurrent Session Limits
Some tenants also have a maximum active sessions setting, which limits how many devices or browsers a single account can be logged into at the same time. When a tenant has this enabled and a user attempts to exceed the limit, the oldest session is signed out to make room for the new one.
Note: Because this setting interacts directly with the underlying identity provider's session handling, changes to it should be tested carefully, particularly for accounts that regularly switch between multiple tenants, such as internal support or super admin accounts. |
Password Expiration Policy
Password expiration reduces the risk of long lived, potentially compromised credentials by forcing periodic password changes, and prevents users from reusing a previous password.
Go to Settings, Security.
Select a password expiration period (for example 30 days, 3 months, or 1 year).
Once the selected period elapses, the user is automatically prompted to set a new password on their next login.
Password reuse is blocked by the system. An expired password cannot be reset to the same value.
Manual Password Resets
There are two distinct ways to manage password resets: an enforced, recurring policy that applies to every user on the tenant (described above), and a manual, one-off reset for an individual account.
To reset the password for an individual user: go to Team Management, Team Accounts, locate the account, click Edit, and select Require Password Reset.
Once enabled, the selected user is prompted to create a new password the next time they log in.
This is commonly used when a user has forgotten their password, when account compromise is suspected, or when you want to enforce stronger credentials for a specific user.
As with the recurring policy, the system will not allow the user to reuse their previous password.
02 - Single Sign-On (SSO)
Note: Flagright Console SSO is Enterprise SAML SSO, a login through the customer's own Identity Provider (IdP) such as Microsoft Entra ID, Okta, or Google Workspace. It is not "Social SSO" (a Sign in with Google or Microsoft button for personal accounts), and it is unrelated to internal AWS SSO tooling or to API OAuth2 client credentials authentication, which is a separate machine to machine mechanism covered in the next section. |
Architecture: PropelAuth
Flagright's authentication layer runs on PropelAuth. PropelAuth is the single source of truth for identity: authentication, token issuance, and session management. Flagright's own RBAC system remains the single source of truth for authorization. Roles and permissions are managed internally by Flagright and are never delegated to the IdP or to PropelAuth. A successful SSO login proves who a user is; it does not by itself grant access. The user must also be invited into Flagright with a role assigned.
Scoping: Per Tenant, Per Environment
Note: SSO is configured once per tenant, separately in each environment (dev, sandbox, and production). A working SSO setup in sandbox does not carry over to production. The entire setup (feature flag, Security SSO toggle, IdP metadata exchange, marking SAML live, and user invites) must be repeated in each environment where that tenant needs SSO. |
Setup Flow
Phase 1: Flagright enables SSO for the organization. A Flagright admin or CS contact confirms the environment and IdP, then enables the SSO feature for that organization. The customer's own admin then turns SSO access ON themselves, from Settings, Security, Single sign-on (SSO) access, and clicks Generate SAML setup link. The link is sent to the customer's IT admin and expires after 24 hours.
Phase 2: Customer IT configures the IdP. IT opens the setup link (no PropelAuth account required), selects SAML or Enterprise SSO, and creates a new SAML application in their IdP using the ACS URL and Entity ID provided by the setup page. In the IdP app, NameID format should be set to EmailAddress with email as a required claim (first and last name optional). IT then copies the IdP's own Entity ID, SSO URL, and X.509 signing certificate back into the setup page, and must explicitly assign users or groups to the new SAML app. This assignment step is required and is the most common point of failure.
Phase 3: Flagright goes live. Once IT confirms the metadata swap and user assignment are complete, the Flagright admin clicks Mark SAML live in Console, Settings, Security, SSO. Users must still be invited in User Management, and each user's Flagright role must be set in Flagright directly. IdP groups do not map to Flagright roles automatically.
Phase 4: Pilot test. Test with one pilot user who is both assigned to the IdP SAML app and invited in Flagright, using the correct environment URL, before rolling out broadly.
Note: Enabling SSO for a tenant only requires the underlying feature flag to be on. Once that's true, the customer's own admin can complete the rest of the setup end to end without needing engineering involvement for each step. |
Optional: Domain Verification & SSO Enforcement
For production rollouts, IT can add and verify company email domains and turn on SSO enforcement, which automatically redirects all users on that domain through the IdP and disables password login for those addresses. Without domain enforcement, some users may still see a mixed password and SSO login path.
SAML Terms Reference
Term | What it means in this setup |
ACS URL | Assertion Consumer Service URL. The Flagright endpoint the IdP sends the SAML response to after a user authenticates. |
Entity ID (Flagright side) | The unique identifier Flagright's SAML service presents to the IdP. Provided by the setup page. |
Entity ID (IdP side) | The unique identifier the customer's IdP presents back to Flagright. Copied from the IdP into the setup page. |
SSO URL | The IdP's login endpoint that Flagright redirects users to for authentication. |
X.509 certificate | The IdP's public signing certificate, used by Flagright to verify that SAML assertions genuinely came from that IdP. |
NameID | The identifier the IdP uses to represent the authenticated user, set to the user's email address in this setup. |
Troubleshooting
What you see | Who typically owns it | Is it a Flagright bug? | What to check first |
SSO still fails after the feature flag is on | Process or setup | No | Finish the Settings, Security SSO toggle plus IT SAML setup plus Mark SAML live |
User is asked for a Flagright password after SSO is on | IdP assignment or invite | Usually not | Check IdP app assignment and confirm the user has a Flagright SSO invite |
"Access Not Granted" | Flagright access check | No, this is expected | Invite the user in User Management for that org |
"User Not Provisioned" | Flagright provisioning | No, this is expected | Invite or attach the user to the correct tenant |
Redirect loop, SAML assertion, or certificate error | Customer IT metadata | No | Re-copy the ACS URL, Entity ID, SSO URL, and X.509 certificate |
Invite or confirmation emails missing or in spam | Email delivery | Not console logic | Check the spam folder; there is a known deliverability issue with automated PropelAuth emails |
Wrong permissions after SSO login succeeds | Flagright role assignment | Yes, an admin fix | Update the user's role in Console; IdP groups never map automatically |
Tip: If the IdP already enforces its own MFA, do not also require Flagright MFA for the same SSO users unless you have a specific reason to layer both. This can create confusing double authentication prompts. |
03 - API Authentication: API Keys & OAuth 2.0
Flagright's public APIs support two authentication mechanisms: the original API key model, and OAuth 2.0 Client Credentials for tenants who need short lived, industry standard machine to machine tokens. These run on separate API paths, each validated independently. However, enabling OAuth2 for a tenant is a one-time, irreversible action: once turned on, it cannot be turned back off, and Settings, Developers will show OAuth2 client credentials in place of the API key from then on. Any integration still relying on viewing, rotating, or managing the API key through the Console will lose that ability once OAuth2 is enabled. Only turn this on once you're ready to fully move server-to-server authentication over to OAuth2, not as something to test casually on a tenant with live API key integrations.
API Keys
Retrieve your API key from Settings, Developers, API Keys, then click the eye icon to reveal it.
Each API key can only be viewed up to two times by your team. Store it securely in your environment immediately after retrieval.
API key requests are authenticated using the x-api-key request header.
Example: A GET request to an endpoint such as /users/{userId} includes the header x-api-key: YOUR_API_KEY, along with the standard Content-Type: application/json header. |
OAuth 2.0 (Client Credentials)
OAuth2 is aimed at customers who want short lived, rotatable, standards based tokens for server to server integrations rather than a long lived static key. It runs on separate /oauth2/* API endpoints so that existing API key integrations are entirely unaffected.
Go to Settings, Developers, OAuth details, then click Create credentials.
Provide a credential name, description, and access token validity in hours (default is 24 hours).
Select the scopes the credential should have, for example flagright-api/public.consumer-users.read and flagright-api/public.consumer-users.write. Scopes apply globally across the application; if multiple endpoints share a scope, that scope unlocks all of them.
Click Create. The credentials table displays the Token generation URL, Base URLs, Client ID, and Client secret.
Common Scopes
Scope | Grants |
flagright-api/public.consumer-users.read | Read access to consumer user records |
flagright-api/public.consumer-users.write | Create and update consumer user records |
flagright-api/public.business-users.read | Read access to business user records |
flagright-api/public.business-users.write | Create and update business user records |
flagright-api/public.transactions.read | Read access to transaction records |
flagright-api/public.transactions.write | Submit and update transaction records |
Note: This is a representative list, not exhaustive. The exact scope names available to your tenant are shown in the scope selector when creating OAuth credentials in Settings, Developers, OAuth details. |
Generating and Using a Token
Send a client_credentials grant request to the Token generation URL with client_id, client_secret, and a space separated scope string. A successful response returns a JSON payload containing access_token, expires_in, and token_type of Bearer.
Example: A token request is a POST to the Token generation URL with Content-Type: application/x-www-form-urlencoded and a body of grant_type=client_credentials, client_id=YOUR_CLIENT_ID, client_secret=YOUR_CLIENT_SECRET, and scope set to a space separated list such as flagright-api/public.consumer-users.read flagright-api/public.consumer-users.write. A successful response looks like: access_token: (a long signed token string), expires_in: 3600, token_type: Bearer. |
Use the returned access token as a Bearer token in the Authorization header when calling the appropriate OAuth2 base URL, for example the FRAML APIs at the /oauth2 base, or the Management APIs at the /oauth2-management base. A subsequent GET request would include the header Authorization: Bearer YOUR_ACCESS_TOKEN.
Note: OAuth2 access tokens are short lived (commonly 24 hours by default, configurable). There is no refresh token in the Client Credentials flow. When a token expires, the integration must call the token endpoint again with client_id and client_secret to obtain a new one. This is standard OAuth2 behavior for machine to machine authentication, not a bug. |
Credential Rotation & Revocation
Action | Effect |
Rotate secret | A new client_id and client_secret are issued. The old credentials can no longer be used to request new tokens. Tokens already issued under the old credentials remain valid until they naturally expire. |
Revoke immediately | Used when active token theft or compromise is suspected. All existing tokens issued under the credential are immediately invalidated, and new credentials are issued. |
Tip: Rotation changes both the client_id and client_secret, which is a platform limitation of the underlying identity provider. Build integrations to reload both values from configuration rather than hardcoding only the secret. |
Troubleshooting: 403 Forbidden
A 403 response means either the token is invalid or expired, or the credential does not include the scope required by the endpoint being called. Update the credential to include the missing scope, generate a new token with the updated scopes, and retry the call. Scope changes do not apply retroactively to tokens already issued.
04 - Rate Limits, Burst Capacity & Quotas
Flagright's public APIs are protected by three related but distinct controls: rate limits, burst capacity, and quota limits. Understanding the difference helps diagnose throttling behavior correctly.
Term | Definition | Example |
Rate limit | The number of requests allowed within a specific short time window. | 10 requests per second allows up to 10 calls in any rolling 1 second window. |
Burst capacity | A temporary allowance above the standard rate limit to absorb short traffic spikes. | A burst capacity of 5 on top of a 10 per second limit allows up to 15 requests in a short burst before sustained throttling applies. |
Quota limit | The total allowable usage over a longer period, such as daily or monthly, not reset every few seconds like a rate limit. | A 1,000 call monthly quota blocks further calls once reached, until the next billing cycle. |
Default Limits by Environment
Environment | Rate limit | Burst limit | Monthly quota |
Sandbox | 3 requests/second | 6 requests | 5,000 requests |
Production | 50 requests/second | 75 requests | Set per contract; not capped by default |
To view your tenant's current rate limit, burst capacity, quota limit, remaining quota, and quota renewal date, log in to the Flagright Console and go to Settings, Developers. All relevant usage and limit data is displayed there.
Handling Throttling
When a request is throttled, the API returns a 429 Too Many Requests response. Integrations should treat this as a signal to back off and retry after a short delay rather than retrying immediately, which only extends the throttled period. If your integration processes bursts of activity (for example, an overnight batch), consider spacing out calls or using the batch endpoints described below rather than looping single-record calls.
Payload and Batch Size Limits
Beyond rate and quota limits, the API enforces fixed size limits on individual requests and entities. These are not configurable per tenant.
Limit | Value |
Single entity payload size (transaction, user, and similar objects, including executed and hit rules) | 400 KB |
Batch import request (consumer users, business users, transactions) | 200 items per request |
Maximum transactions in a single case | 500,000 |
Maximum alerts in a single case | 200 |
Maximum transactions in a single alert | 50,000 |
Note: A payload that exceeds these limits is rejected rather than partially processed. If an integration is intermittently failing on large payloads, check these limits first before assuming a bug. |
Rate limits and quotas are a separate, and more common, cause of unexpected failures worth checking too.
Note: Rate limits, burst allowances, and quotas are configured per tenant at the account or usage plan level. If your integration is being throttled unexpectedly, check Settings, Developers first before assuming it is an application side bug. |
05 - Webhooks
In addition to the on demand public REST API, Flagright supports webhooks: outbound, real time notifications pushed to a customer provided endpoint whenever a subscribed entity changes. For example, when a transaction's status is updated, Flagright pushes a transaction update event to the customer's server so they can react immediately in their own systems.
How Webhooks Work
You subscribe to a defined set of event types and provide an endpoint URL to receive them.
Each webhook delivery includes an X-Flagright-Signature header, an HMAC-SHA256 signature generated from the payload and a per-webhook secret key, so you can verify the event genuinely came from Flagright.
A delivery is considered successful on any 2XX response.
You can view the full delivery history (successes and failures) for each webhook subscription, including headers, payload, and the response received.
Common Event Types
The exact set of events available depends on which features are enabled for your tenant. Representative event types include:
Event | Fires when |
CASE_OPENED | A new case is created |
CASE_CLOSED | A case is closed |
ALERT_OPENED | A new alert is created |
ALERT_CLOSED | An alert is closed |
TRANSACTION_STATUS_UPDATED | A transaction's status changes, for example after manual review or a rule hit |
CRA_RISK_LEVEL_UPDATED | A user's Customer Risk Assessment level changes |
USER_TAGS_UPDATED | Tags on a user record are added, changed, or removed |
PEP_STATUS_UPDATED | A user's Politically Exposed Person status changes |
BATCH_COMPLETED | An asynchronous batch import finishes processing |
Verifying the Webhook Signature
Compute an HMAC-SHA256 digest of the raw request body using your webhook's secret key, then compare it to the value in the X-Flagright-Signature header. Always use a constant time comparison rather than a simple string equality check, to avoid timing attacks. In Node.js, this means hashing the raw body with crypto.createHmac('sha256', secret), then comparing the result to the header value using crypto.timingSafeEqual rather than the equality operator.
Note: A webhook may briefly have more than one active secret at once when a secret rotation is in progress. The old secret continues to validate signatures until its configured expiry, giving you a grace period to update your verification logic. |
Retry Behavior
If a delivery attempt fails (the endpoint returns an error status, times out, or does not respond), Flagright automatically retries using exponential backoff.
Environment | Backoff schedule | Retry window before stopping |
Sandbox | 10 minutes, then doubling (10, 20, 40) up to a 40 minute cap | 1 hour total |
Production | 10 minutes, then doubling up to a 360 minute cap | 24 hours total, or a custom limit if configured for your tenant |
Once the retry window is reached without a successful delivery, retries stop and the webhook may be automatically disabled, unless a different action has been configured for your tenant. If the endpoint succeeds at any point, retries stop immediately.
Note: A batch related delivery (for example a large alert closure with many transactions, or a batch completion notification) can occasionally hit platform level limits, such as an internal message size ceiling for very large payloads. In these edge cases the notification may not be delivered even though the underlying data was processed correctly. If you rely on completion webhooks for large batches, it's worth confirming completion through the API as a backstop. |
Replaying a Failed Webhook
If a webhook message fails to deliver, for example due to a network error or a temporarily unavailable endpoint, it can be manually resent from the Console, or through the API directly.
In the Console: go to Settings, Developers, Webhooks, click Edit on the relevant webhook endpoint to open its details drawer, then use the Event filter to locate the specific attempt (transaction ID for transaction updates, alert ID or case ID for alert or case updates, user ID for user attribute changes) and click Replay.
Via API: the webhook event resend endpoint accepts a delivery task ID, reconstructs the original request, and resends it synchronously, returning success or failure immediately rather than queuing it for background retry.
Note: Third-party systems cannot post webhooks directly into Flagright. Webhooks are strictly outbound from Flagright to a client controlled endpoint. If a third-party system, such as a card processor, needs to feed data into Flagright, that data must be sent through the client's own API integration, not received as an inbound webhook. |
06 - Role-Based Access Control (RBAC) & Team Management
RBAC governs what each Console user can see and do. Access is assigned by role rather than per user, so onboarding, offboarding, and access reviews scale cleanly as your team grows. Every console account has exactly one role. There is no role stacking or combining permissions from multiple roles.
Default Roles
Role | Access Level |
Root | Unrestricted access to everything, bypassing all permission checks entirely. Reserved for Flagright internal use. |
Admin | Full read and write access to all features, including inviting new accounts, with one exception: case and alert status fields remain read-only even for Admin. There can be multiple Admins on a team. |
Analyst | Unrestricted access to case management; read-only on Audit Log, Rules, and Risk Scoring. |
Approver | Unrestricted access to case management; read-only on Audit Log, Rules, and Risk Scoring. Also receives alerts when an analyst requires approval to close a case. |
Auditor | Read-only access to Dashboard, Case Management, Rules, Risk Scoring, and Audit Log, with the ability to download information. |
Developer | Unrestricted access to the Developer section under Settings; read-only on all other features. |
Note: These roles are non-configurable defaults. Any additional role your organization needs should be created as a custom role rather than by modifying a default. Also note that for every non-admin default role, Team Management permissions themselves are strictly read-only: Analysts, Approvers, Auditors, and Developers can see the team roster but cannot invite users or edit roles. |
Creating and Configuring Custom Roles
For an overview of different roles and access rights, navigate to Team Management in the Console and click Configure Roles. Alternatively, a new role can be added and adjusted according to your requirements.
|
Team Management, Configure Roles: default role list and feature permission tree.
Go to Team Management, Configure Roles, Create role.
Enter a Role name and Role description.
Tick the boxes for each feature area the role should have read-only or read/write access to.
Click Save.
|
Configure Roles, Create role: naming and describing a new custom role.
How Permissions Are Structured
Under the hood, each Team Management permission is a string of the form module/feature/action, for example case-management/case-details/* or settings/transactions/payment-approval/*. Reading a permission's structure helps when troubleshooting exactly what a role can and cannot do. For instance, approving or blocking a transaction in the Payment Approval tab requires write access on Case Management, Details specifically. The separate Overview and Export toggles for the same module do not grant that ability.
Permission Areas: Full Reference
Custom roles are built from a set of configurable feature areas. Read access generally controls visibility of a page or section; write access generally controls the ability to take action within it.
Accounts: Read access gives visibility to different accounts and their corresponding roles in the system. Write access enables the account to send invites, assign Maker, Checker, and Escalation roles, and reset passwords.
|
Configure Roles: granular Read/Write toggles for the Accounts feature area.
Audit Log: Read access makes the Audit Log page visible.
|
Configure Roles: the Audit Log feature area, with Export permission.
Case Management: Case assignment enables assigning cases to different accounts. Case details gives access to details of each case, and write access here is also what's needed for payment approval actions. Case overview gives access to the case and alerts table. Case reopen enables reopening of cases. Export enables export. QA enables QA features.
|
Configure Roles: the full Case Management sub-permission set, including case assignment, details, overview, reopen, export, and QA.
Copilot: Gives access to the generative AI Copilot feature, which creates narratives for alerts and cases.
|
Configure Roles: the Copilot feature area, controlling access to AI generated narratives.
Dashboard: Gives access to the Analytics page accessible via the main menu.
|
Configure Roles: the Dashboard feature area, controlling access to downloading analytics data.
Lists: Gives permissions to the Blacklists and Whitelists accessible via the Lists item on the menu; a separate Export permission covers list exports.
|
Configure Roles: the Lists feature area, with separate toggles for Blacklist, Whitelist, and Export.
Notifications: Enables the account to see notifications for them via the Notifications item on the main menu.
|
Configure Roles: the Notifications feature area.
Reports: Gives access to SAR reports with write access.
|
Configure Roles: the Reports feature area, covering generated SAR reports and report schema.
Risk Scoring: Gives permissions to view and/or edit features in the Risk Scoring page accessible from the menu, with granular sub-permissions for risk levels, risk factors, risk algorithms, and risk score detail views.
Roles: Gives permissions to view and/or edit the Configure Roles tab in Team Management.
Rules: Gives permissions to view and/or edit the Rules configuration from the side menu.
Sanctions: Gives permissions to the Screening search features from the side menu, including separate toggles for manual screening search and manual screening filters.
Settings: Gives permissions to the Settings features from the side menu. Access can be given or removed for each individual tab on the Settings page.
Simulator: Gives permissions to the Simulations feature within Rules and Risk Scoring.
Transactions: Gives permissions to the Transactions page accessible via the side menu. Overview gives access to the dashboard overview. Export enables permissions to export. Details gives access to click into each transaction.
Users: Grants permission to the Users page found in the side menu. Each permission for a subcategory lets the account use the related feature on that page, including a separate write permission for editing user tags, which is distinct from defining tag keys under Settings.
Team Management: Accounts
Only an Admin can invite accounts to the Console. Other roles will not see the invite button.
To invite: go to Team Management, click Invite, add the email address of the new account, define their role, and click Invite. Their role can be changed later.
|
Team Management, Team Accounts: the Invite button (Admin accounts only).
|
Invite user panel: email, role, and review permissions.
To change an existing account's role: only an Admin can change roles of team members. Go to Team Management, find the user whose role you want to change, click the Edit icon, select the new role, and click Save.
|
Edit account panel: changing a team member's assigned role.
To reset an individual user's password: Team Management, Team Accounts, Edit, Require Password Reset. The user is prompted to set a new password on next login and cannot reuse the previous one.
|
Team Accounts: the Edit action opens the account's edit modal.
|
Edit account modal: Reset password action.
To reset MFA for a specific user, for example after a lost device, deleted authentication app, or a changed phone: Team Management, Team Accounts, Reset MFA. This re-enrolls only that account, without disabling MFA tenant wide.
|
Team Accounts: the Reset MFA action for an individual account.
Accounts suspended by brute force protection show a Brute Force tag and can be reactivated by anyone with Team Management access.
Multi-Tenant RBAC (Enterprise)
For multinational institutions and resellers, Multi-Tenant RBAC allows designated Organization Accounts to be granted access across multiple Linked Tenants, a logical grouping of otherwise fully isolated tenants, while keeping each tenant's data, roles, and permissions completely independent.
Each linked tenant keeps its own database, encryption keys, API credentials, and user roster. Linking does not merge or move any data.
An account's role in one tenant has no bearing on its role in another. Permissions are never inherited across tenants and must be explicitly configured per tenant.
Users switch between tenants using an in-app tenant switcher without re-authenticating.
Designating an account as an Organization Account is done by Flagright on request. It is not self-serve, for security reasons.
Every action is still logged in the standard audit log of the specific tenant where it occurred.
Note: Multi-Tenant RBAC is an Enterprise tier capability intended for organizations operating across jurisdictions or reseller portfolios. Contact your Flagright customer success manager to discuss eligibility and onboarding. |
07 - Production Access Control
Production Access Control is a tenant level setting that governs whether Flagright's own support and engineering staff can access your production environment, for example to assist with troubleshooting or investigate a bug.
This control is available under Settings and is enabled by default for all tenants, allowing Flagright support to assist quickly when needed.
Turning it off blocks Flagright staff from accessing your production environment, including through the internal super admin panel. The tenant becomes greyed out and unselectable to Flagright administrators.
Disabling it will slow down troubleshooting and bug fixes, since Flagright's team will not be able to directly inspect your environment when you raise a support request.
Note: When you turn this setting off, the Console shows a confirmation prompt: "This will prevent Flagright support team's access to your environment and slow down troubleshooting & bug fixes. Are you sure you want to continue?" with the options Cancel or Block access. Make sure the team responsible for your Flagright relationship is aware before disabling this, so support requests aren't unexpectedly delayed. |
Network-Level Access Restrictions
Production Access Control governs Flagright staff access at the account level. It is separate from network-level restrictions, which control where console or API traffic is allowed to originate from.
Customers with stricter infrastructure requirements can request that console and/or API access be restricted to specific VPN or office IP ranges.
This is handled as part of private cloud or dedicated deployment configuration, not the standard Production Access Control toggle described above.
Because this affects network routing at the infrastructure level, it is set up by the Flagright team in coordination with your IT or infrastructure team rather than self-serve in the Console.
Tip: If your organization needs IP allowlisting for compliance or internal security policy reasons, raise this with your Flagright account team early in implementation planning, since it is a deployment-level configuration rather than a toggle you can turn on yourself. |
08 - Notifications
Flagright's Notifications and Collaboration feature keeps teams informed about case and alert activity without relying entirely on external tools. Notifications are delivered through up to four channels, each independently configurable.
|
The Notifications panel, showing unread case and alert activity for the signed-in user.
Channel | Description | Where it's configured |
Console notifications | Real-time alerts and updates shown directly within the Flagright Console. | Settings, Notifications, Console |
Flagright Slack App | A dedicated Slack app, found in the Slack app directory, that notifies individual users in their own Slack workspace without leaving it. | Settings, Integrations, Slack, then Settings, Notifications, Slack app |
Email notifications | Real-time email notifications, or a digest email grouping unread notifications together. | Settings, Notifications, Email |
Slack channel integration | Real-time notifications posted into a shared Flagright Slack channel as part of a workspace wide Slack integration. | Settings, Notifications, Add to Slack |
What Triggers a Notification
A case or alert is assigned to, or unassigned from, a user.
An assigned case or alert is updated, for example a status change, user status, KYC status, or risk score change.
Activity occurs on a related or assigned case or alert, such as a comment or file upload.
A user is tagged by a teammate in a comment.
Flagright platform updates, such as new feature launches, changelog entries, or knowledge base updates.
Configuring Notifications
Console notifications: Settings, Notifications, Console, configured per role (Analyst, QA, and so on).
Slack app notifications: first connect the integration at Settings, Integrations, Slack, then configure per-role notification behavior at Settings, Notifications, Slack app.
Email notifications: Settings, Notifications, Email, configured per role.
To have Slack alerts fire specifically when a new case is created, go to Settings, Notifications and click Add to Slack to connect your Slack workspace channels.
Note: Only Admins can configure notification settings, and configuration happens at the tenant level per role. Non-admin roles can see how notifications are configured for their role, but cannot change the configuration themselves. |
Collaboration
Notifications are paired with in-context collaboration: users can tag teammates directly within case and alert comments, keeping investigation-related discussion inside the platform rather than scattered across external tools. Tagging activity is not written to the Activity Log, but is captured in the Audit Log. If a comment containing a tag is later deleted, the notification itself is not deleted. Clicking it takes the user to the comment location with a message indicating the comment was removed.
Note: Role-level tagging, such as tagging "all Analysts," is not currently supported. Tags apply to individual accounts only. |
09 - Troubleshooting Quick Reference
A consolidated view of common support scenarios across authentication and access control, for fast triage.
Symptom | Likely area | First step |
User locked out after failed logins | Brute force protection | Team Management, Team Accounts, reactivate the Brute Force tagged account |
User can't complete MFA setup | MFA | Team Management, Team Accounts, Reset MFA for that specific account |
SSO login loops back to the login page | SAML metadata mismatch | Re-verify ACS URL, Entity ID, SSO URL, and certificate with customer IT |
SSO user sees a Flagright password prompt | IdP assignment or missing invite | Confirm the user is assigned to the IdP SAML app and has a Flagright invite |
API calls return 403 Forbidden | Missing OAuth2 scope or expired token | Check the credential's scopes and regenerate the token |
API calls return 429 | Rate limit or burst exceeded | Check Settings, Developers for current usage against limits, then back off and retry |
Webhook not received | Endpoint down, wrong URL, or retry window expired | Check delivery history in Settings, Developers, Webhooks, and replay if needed |
Custom role can't approve payments | Missing Case Management, Details write permission | Grant write access on Case Management, Details specifically, not just Overview |
Flagright support can't access your environment to help | Production Access Control disabled | Confirm with your team whether this was intentional; re-enable if support access is needed |
User isn't receiving case notifications | Notification channel not configured for their role | Check Settings, Notifications for that role across Console, Email, and Slack |