System Settings

Overview

System settings provide access to low-level configuration values organized by category. These settings control database connections, authentication, job processing, infrastructure, and AI model behavior. Navigate to Admin > Administer > System Settings.

Category	Icon	Description
LLM	CPU	AI model and API configuration
DB	Database	Database connection settings
AUTH	Shield	Authentication and security settings
CORE	Settings	Core application settings
JOBS	Briefcase	Job processing and queue configuration
ASYNC_PARSE	ScanText	The async document parser’s limits and timings, in the Async Parsing tab, right after Jobs Settings: how long a file may wait, how many files a person may queue, what the parser may use to read one file, and how Agent Flows wait for it. See Async Parsing Settings
INFRA	Server	Infrastructure and deployment settings
FEATURE_FLAGS	Flag	Features that ship switched off and are turned on per deployment

Viewing Settings

Settings are displayed as key-value pairs with:

Setting name
Current value (encrypted values are masked)
Read-only indicator (for settings that cannot be changed from the UI)

Editing Settings

Settings marked as editable can be modified directly from the admin panel. Read-only settings must be changed through environment variables or the Django admin interface.

Only settings marked “Show in Dashboard” in the Django admin are visible here. If you need to access additional settings, use the Django admin interface or configure them via environment variables.

Changing system settings can affect the behavior of the entire platform. Ensure you understand the impact of a change before saving. Some changes may require a server restart to take effect.

A deploy refreshes FALKOR_PASSWORD, NEO4J_PASSWORD, and RABBITMQ_PASS from the environment. Those services start with the Omnistrate secret, and the app reads the database copy. Other encrypted settings keep the value saved here. seed_config --update-from-env copies every environment value into the database.

Asking the Copilot

The Admin Copilot panel (⌘J / Ctrl+J) sees the settings of the category you have open and the reference below, and can:

Explain a setting in plain words — what it controls and what a value means in practice — citing this page. It checks that the admin guide is indexed first; if the index is out of date it says so and offers the re-index rather than answering from memory.
Propose a change when you ask (“set it to enforce”, “is this set up right?”) as a card listing setting · current → proposed · reason. Apply stages the value in the page’s form exactly as if you had typed it — it is not saved — and the page’s own Save persists it, with the same validation, confirmations, and permissions as a hand edit.

Encrypted settings are shown to the copilot only as set or not set and can’t be proposed — a person types those. If you can’t save on this page, the copilot explains without proposing.

Settings Reference

Legend: Settings prefixed with 🔒 store encrypted values. Settings marked (Dashboard) are visible in the admin dashboard UI. Settings marked (Client) are accessible to the frontend client application.

LLM Settings

Setting	Description	Default	Related Docs
`USE_AZURE_OPENAI`	Use Azure OpenAI for LLM	`True`	—
`USE_AZURE_OPENAI_EMBEDDINGS`	Use Azure OpenAI for embeddings	`True`	—
`USE_GOOGLE_GENAI`	Use Google Gemini	`False`	—
🔒 `AZURE_API_KEY`	Azure OpenAI API key	—	—
🔒 `GOOGLE_API_KEY`	Google Gemini API key	—	—
`GOOGLE_GENAI_MODEL`	Google GenAI model name	`gemini-2.0-flash`	—
`AZURE_CHAT_API_CONTEXT_WINDOW`	Azure OpenAI context window size (tokens)	`128000`	—
`AZURE_CHAT_API_DEPLOYMENT`	Azure OpenAI chat deployment name	`gpt-4o`	—
`AZURE_CHAT_API_VERSION`	Azure OpenAI API version for chat	`2024-04-01-preview`	—
`AZURE_CHAT_API_ENDPOINT`	Full Azure OpenAI endpoint URL for chat	(provider-specific)	—
`AZURE_CHAT_API_TEMPERATURE`	Temperature for Azure OpenAI chat	`0.0`	—
`AZURE_CHAT_API_FREQUENCY_PENALTY`	Frequency penalty for Azure OpenAI	`0.1`	—
`AZURE_CHAT_API_PRESENCE_PENALTY`	Presence penalty for Azure OpenAI	`-0.5`	—
`AZURE_EMBEDDINGS_API_DEPLOYMENT`	Azure OpenAI embeddings model name	`text-embedding-3-large`	—
`AZURE_EMBEDDINGS_API_VERSION`	Azure OpenAI API version for embeddings	`2023-05-15`	—
`AZURE_EMBEDDINGS_API_ENDPOINT`	Full Azure OpenAI endpoint URL for embeddings	(provider-specific)	—
`AZURE_EMBEDDINGS_API_DIMENSIONS`	Dimensions for Azure OpenAI embeddings	`1536`	—
🔒 `AZURE_EMBEDDINGS_API_KEY`	Azure OpenAI API key for embeddings (optional fallback)	—	—
`GOOGLE_GENAI_CONTEXT_WINDOW`	Google Gemini context window size (tokens)	`2000000`	—
`GOOGLE_GENAI_TEMPERATURE`	Temperature for Google Gemini	`0.05`	—
`CONTEXT_SAFETY_MARGIN`	Safety margin for context window (fraction of max)	`0.9`	—
`USE_AWS_BEDROCK`	Use AWS Bedrock	`False`	—
🔒 `AWS_BEDROCK_ACCESS_KEY_ID`	AWS Bedrock Access Key ID	—	—
🔒 `AWS_BEDROCK_SECRET_ACCESS_KEY`	AWS Bedrock Secret Access Key	—	—
`REASONING_MODEL_CONFIG` `(Dashboard)`	Default reasoning model configuration	`azure-gpt4o-reasoning-default`	Model Configurations
`EMBEDDING_MODEL_CONFIG` `(Dashboard)`	Default embedding model configuration	`azure-embedding-default`	Model Configurations
`CLASSIFICATION_MODEL_CONFIG` `(Dashboard)`	Default classification model config name or UUID	—	Model Configurations
`DECISION_MODEL_CONFIG` `(Dashboard)`	Default decision model config name or UUID (Microsoft-Decision-1, used by graph evaluation triage)	—	Graph Evaluation
`INGESTION_LARGE_MODEL_CONFIG` `(Dashboard)`	Default model config used for large-document ingestion paths	—	Model Configurations
`INGESTION_MEDIUM_MODEL_CONFIG` `(Dashboard)`	Model config for medium-tier primary ingestion (content-type `model_tier: medium`)	—	Model Configurations, Extraction Policy
`INGESTION_SMALL_MODEL_CONFIG` `(Dashboard)`	Model config used for small-document ingestion paths and secondary ingestion steps	—	Model Configurations
`LARGE_DOCUMENT_TOKEN_THRESHOLD`	Token threshold for large document handling	`5000`	—
`LEAD_PARAGRAPH_TOKEN_THRESHOLD`	Token threshold for lead paragraph extraction	`20`	—
`MAX_LIST_CONTEXT_CHARS`	Maximum characters for list context	`1000`	—
`PRODUCED_DOC_CONTEXT_CHARS`	Max characters of a single produced document included in chat context	`4000`	Agent Flows
`PRODUCED_DOC_CONTEXT_TOTAL_CHARS`	Max characters of produced documents included in one conversation’s chat context	`12000`	Agent Flows
`GRAPH_CONTEXT_TEXT_CHARS` `(Dashboard)`	Most characters of one graph node’s text (a clause or document body) that the chat’s graph context keeps. `0` leaves node text out. A change applies within 30 seconds	`2000`	Graph Text in Chat Context
`GRAPH_CONTEXT_TEXT_TOTAL_CHARS` `(Dashboard)`	Most characters of node text in the graph context of one answer, across all entities (40,000 is about 10,000 tokens). `0` leaves node text out	`40000`	Graph Text in Chat Context
`COPILOT_DOCUMENT_EMBEDDING_PRESET`	Embedding model for files attached in the knowledge-model copilot: `fast`, `balanced`, `quality` or `multilingual`. The `balanced` model ships in the server image; another preset is downloaded when a server first needs it, again after every container start (its cache is not on a persistent volume), and search falls back to keywords if it can’t load. A file the async parser reads is always embedded with `balanced` (the model baked into the parser image), whatever this setting says	`balanced`	Admin Copilot
`COPILOT_DOCUMENT_WORKERS`	Files attached in the knowledge-model copilot that one API process reads at once (1 to 4); the others wait their turn, taking turns between the people who attached them. Each file that needs a parser (not `.txt`, `.md`, `.csv` or `.json`) is read in a child process that may use up to `UPLOAD_EXTRACTION_MAX_MEMORY_MB` of memory (512 MB by default). Applies after a server restart	`1`	Admin Copilot
`COPILOT_SCHEDULES_ENABLED` `(Dashboard)`	Whether the admin Copilot can schedule follow-ups and due follow-ups run. Off: the Copilot offers no scheduling tool and the scheduler starts nothing; follow-ups that fall due meanwhile run once when it is back on. A change applies within 30 seconds	`True`	Copilot Scheduled Follow-ups
`COPILOT_SCHEDULE_MAX_ACTIVE_PER_USER` `(Dashboard)`	Follow-ups one person may have active at once, across all their Copilot conversations. At least 1. A change applies within 30 seconds	`10`	Copilot Scheduled Follow-ups
`COPILOT_SCHEDULE_MIN_INTERVAL_MINUTES` `(Dashboard)`	The shortest time between two runs of a recurring follow-up; a schedule that can run sooner is refused. At least 5; a smaller value means the default. A change applies within 30 seconds	`60`	Copilot Scheduled Follow-ups
`COPILOT_SCHEDULE_MAX_DAYS_AHEAD` `(Dashboard)`	How many days ahead a one-time follow-up may be scheduled (and a recurring one’s first run). At least 1. A change applies within 30 seconds	`90`	Copilot Scheduled Follow-ups
`COPILOT_SCHEDULE_RECURRING_EXPIRY_DAYS` `(Dashboard)`	Days after it was created that a recurring follow-up stops by itself. At least 1. A change applies within 30 seconds	`30`	Copilot Scheduled Follow-ups
`COPILOT_SCHEDULE_MAX_RUNS_SUB_HOURLY` `(Dashboard)`	How many times a recurring follow-up that can run more than once an hour runs before it stops by itself (possible only when `COPILOT_SCHEDULE_MIN_INTERVAL_MINUTES` is lowered below 60). 1 to 200: a larger number is lowered to 200, and a smaller one means the default. A change applies to follow-ups created after it	`10`	Copilot Scheduled Follow-ups
`COPILOT_SCHEDULE_MAX_RUNS_HOURLY` `(Dashboard)`	How many times a recurring follow-up that runs at most once an hour but more than once a day (every hour, or at 09:00 and 17:00) runs before it stops by itself. 1 to 200: a larger number is lowered to 200, and a smaller one means the default. A change applies to follow-ups created after it	`3`	Copilot Scheduled Follow-ups
`COPILOT_SCHEDULE_MAX_RUNS_DAILY` `(Dashboard)`	How many times a recurring follow-up that runs once a day or less often runs before it stops by itself (a weekly one usually reaches its time limit first). 1 to 200: a larger number is lowered to 200, and a smaller one means the default. A change applies to follow-ups created after it	`30`	Copilot Scheduled Follow-ups
`COPILOT_SCHEDULE_MAX_RETRIES` `(Dashboard)`	How many times a failed follow-up run is tried again before it is marked failed. `0` means no retry	`2`	Copilot Scheduled Follow-ups
`COPILOT_SCHEDULE_RETRY_BACKOFF_SECONDS` `(Dashboard)`	Seconds to wait before the first retry of a failed run; each next retry waits twice as long. At least 60; a smaller value means the default	`300`	Copilot Scheduled Follow-ups
`COPILOT_SCHEDULE_MAX_TOKENS_PER_RUN` `(Dashboard)`	The most tokens one scheduled run may use, counted as the provider reports them (the conversation is read again on every model call, and cached input counts in full). The lower of this and the Copilot profile’s per-turn token limit applies. At least 10000; a smaller value means the default. A run that reaches it stops and says so	`600000`	Copilot Scheduled Follow-ups
`COPILOT_SCHEDULE_MAX_SECONDS_PER_RUN` `(Dashboard)`	The longest one scheduled run may take, in seconds. The lower of this and the profile’s per-turn limit applies. Between 60 and 290 (it must stay under the database’s 300-second idle limit): a smaller value means the default and a larger one is lowered to 290	`270`	Copilot Scheduled Follow-ups
`COPILOT_SCHEDULE_MAX_CONCURRENT_RUNS` `(Dashboard)`	How many scheduled runs may be in progress at once on the whole instance, and so about how many start each minute; the others wait for the next minute. At least 1. A change applies at the next minute	`2`	Copilot Scheduled Follow-ups

Produced Documents in Chat Context

When a flow writes a document into a conversation, an excerpt of that document is included in the chat’s context as a head start on follow-up questions about it. The two caps bound that excerpt only — they are not the limit of what the assistant can see, because it can also list the documents produced in the conversation, search inside one, and read any part of it on demand (each read is access-checked for the person asking). They still matter, because the excerpt is what the assistant has before it goes looking. PRODUCED_DOC_CONTEXT_CHARS bounds the document text in a single excerpt. PRODUCED_DOC_CONTEXT_TOTAL_CHARS is spent on document text and on the sentences that announce a cut — an excerpt that had to be truncated carries that sentence on top of its own allowance, and the sentence is charged in full against the conversation budget. A conversation full of truncated documents therefore carries less document text than the total alone suggests. The conversation budget is spent newest first, so the document the flow just wrote — the one the user’s next message is almost certainly about — keeps its excerpt, and older documents give way instead. Nothing is dropped quietly: an excerpt that was cut short says so, and a document that got no budget at all is still named in the context as existing, with its body omitted. That announcement is deliberately exempt from PRODUCED_DOC_CONTEXT_TOTAL_CHARS — saying a document exists must not be starved by the budget it is announcing — so the injected text can exceed the total by one short fixed sentence for every document whose body was omitted. A truncation notice is never cut in half either, because half a notice reads as document text: when the leftover budget cannot hold body text plus a whole notice, that document degrades to the omission announcement instead of getting a sliver of body.

Graph Text in Chat Context

Some graph nodes carry prose: the body of a clause or a document, in their text property. When the assistant reads the neighborhood of an entity, that text goes into the context the answer is written from, and every model call of the answer carries it again. Without a bound, one entity with many long clauses could add hundreds of kilobytes. Two limits keep it in check:

GRAPH_CONTEXT_TEXT_CHARS cuts the text of each node. A text that was cut ends with …[truncated].
GRAPH_CONTEXT_TEXT_TOTAL_CHARS caps the node text of the whole answer. It is spent in the order the entities were found, so the first entities keep their text and the ones after the budget runs out lose it. An entity that lost its text is marked, so the assistant can say the text was left out for size and does not read as absent from the graph.

Both limits cut what the assistant reads, not what the graph stores. If answers about long clauses lack detail, raise them, and expect each model call to cost more. 0 leaves node text out of the context entirely.

Copilot Scheduled Follow-ups

The admin Copilot can schedule a follow-up: a message it receives later in the same conversation, once or on a recurring schedule, and acts on without anyone watching. The thirteen COPILOT_SCHEDULE* settings above bound it. They are on Admin > Administer > System Settings, in the LLM tab.

How many and how far. COPILOT_SCHEDULE_MAX_ACTIVE_PER_USER is the number of active follow-ups per person; COPILOT_SCHEDULE_MAX_DAYS_AHEAD how far ahead a one-time one may be set; COPILOT_SCHEDULE_RECURRING_EXPIRY_DAYS when a recurring one stops by itself. A request over a limit is refused and the Copilot names the limit.
How often. COPILOT_SCHEDULE_MIN_INTERVAL_MINUTES is the shortest gap between two runs of a recurring follow-up (0 * * * *, every hour, is exactly the default and is allowed; */30 * * * * is not).
How many runs. A recurring follow-up also stops by itself after a number of runs that depends on how often it runs. COPILOT_SCHEDULE_MAX_RUNS_HOURLY (3) applies to one that runs every hour or several times a day, COPILOT_SCHEDULE_MAX_RUNS_DAILY (30) to one that runs once a day or less often, and COPILOT_SCHEDULE_MAX_RUNS_SUB_HOURLY (10) to one that runs more than once an hour, which is possible only when COPILOT_SCHEDULE_MIN_INTERVAL_MINUTES is lowered. How often is the shortest gap between two of its runs, so every hour from 09:00 to 17:00 on weekdays counts as hourly. Whichever comes first, the run limit or COPILOT_SCHEDULE_RECURRING_EXPIRY_DAYS, ends the follow-up. Each run limit is 1 to 200; a larger number is lowered to 200. A change applies to follow-ups created after it, and those already running keep the limit they were given: to stop follow-ups from running right away, turn COPILOT_SCHEDULES_ENABLED off.
What a run may cost. Each run is a full Copilot turn that reads the whole conversation again on every model call, so COPILOT_SCHEDULE_MAX_TOKENS_PER_RUN counts that (cached input counts in full) and COPILOT_SCHEDULE_MAX_SECONDS_PER_RUN bounds the time. A run that reaches either stops and tells the person. Together with the number of follow-ups and their run limit they decide what scheduling can cost: ten hourly follow-ups make 30 runs in all, three each, and then stop until someone schedules them again. COPILOT_SCHEDULE_MAX_CONCURRENT_RUNS caps the runs in progress on the whole instance, so a crowd of follow-ups due at the same minute starts a few at a time and the rest wait for the next minute.
Failures. A failed run is tried again COPILOT_SCHEDULE_MAX_RETRIES times, the first retry after COPILOT_SCHEDULE_RETRY_BACKOFF_SECONDS and each next one after twice as long, then marked failed.
The switch. COPILOT_SCHEDULES_ENABLED turns the feature off: no scheduling tool, and nothing is started. Follow-ups that fall due while it is off run once when it is back on.

A change to a limit applies to the Copilot’s next turn within about 30 seconds, and to the scheduler at its next pass, without a restart. A value that cannot be read, or is below its minimum, means the default. Follow-ups are started by the flow runner that runs beside every server, which asks the API server over loopback at ASYNC_PARSE_DISPATCH_URL, so that setting must be right for follow-ups to start.

DB Settings

Graph connectivity uses GRAPH_PROVIDER plus either the Neo4j or FalkorDB connection group. See Graph backend (Neo4j & FalkorDB) for how switching works and when to run a migration.

Setting	Description	Default	Related Docs
`GRAPH_PROVIDER` `(Dashboard)`	Active graph backend: `neo4j` or `falkordb`	`neo4j`	Graph backend
🔒 `NEO4J_URI` `(Dashboard)`	Neo4j Bolt URI (used when `GRAPH_PROVIDER=neo4j`)	—	Graph backend
`NEO4J_DATABASE` `(Dashboard)`	Neo4j database name	`neo4j`	—
`DEFAULT_NEO4J_DATABASE` `(Dashboard)`	Default Neo4j database	`neo4j`	—
`NEO4J_USER` `(Dashboard)`	Neo4j username	`neo4j`	—
🔒 `NEO4J_PASSWORD` `(Dashboard)`	Neo4j password	—	—
`FALKOR_URI` `(Dashboard)`	FalkorDB Redis-style URI (used when `GRAPH_PROVIDER=falkordb`)	`redis://falkordb:6379` (cluster); devcontainer uses `redis://localhost:6380` on the host	Graph backend
`FALKOR_DATABASE` `(Dashboard)`	FalkorDB graph name	`experio`	—
`DEFAULT_FALKOR_DATABASE` `(Dashboard)`	Default FalkorDB graph name	`experio`	—
`FALKOR_USER` `(Dashboard)`	FalkorDB username	`default`	—
🔒 `FALKOR_PASSWORD` `(Dashboard)`	FalkorDB password	—	—
`GRAPH_READ_TIMEOUT_MS` `(Dashboard)`	Time limit, in milliseconds, for one interactive graph read: the reads that chat answers, agent flows, dashboards and the graph evidence shown with an answer wait for. A read that passes it is stopped and reported as the knowledge graph being unavailable. `0` or less turns the limit off, so a read runs until the graph server’s own limit (60 seconds on FalkorDB in the Experio deployment). A value above `55000` is lowered to `55000`. A change applies within 30 seconds	`15000`	Graph Read Time Limit
`FALKORDB_AGGREGATE_GUARD` `(Dashboard)`	Refuses grouped aggregations that FalkorDB 6.0.3 answers wrongly or crashes on, and tells the model how to rewrite them. Turn it off only on a FalkorDB release that contains the upstream fixes. A change applies within 30 seconds	`True`	FalkorDB Aggregate Guard

Older deployments may still list USE_NEO4J, USE_FALKOR, FALKOR_DB_USER, or FALKOR_DB_PASSWORD. Those keys are legacy; GRAPH_PROVIDER with NEO4J_* / FALKOR_* is authoritative for new installs and the dashboard. Prefer aligning configuration with the rows above.

Graph Read Time Limit

A graph read that a person is waiting for carries GRAPH_READ_TIMEOUT_MS: the retrieval behind a chat answer, the tools of an agent flow, the graph evidence shown with an answer, and dashboard widgets and records. Ingestion, enrichment and the other background work are not limited by it, and neither is the rebuild of the schema cache, because a limit there would leave the cache on its last good value. The limit works the same on Neo4j and FalkorDB. When a read passes the limit, the graph server stops it and Experio treats it as “the knowledge graph could not answer”, not as “no data”. A chat answer then says so (see When the Knowledge Graph Cannot Be Queried), and a dashboard widget or record answers The knowledge graph is busy. Try again in a moment. and is not retried automatically. The same applies when the graph is unreachable or a query hits FalkorDB’s per-query memory cap. Experio does not ask the model to rewrite such a query, because a rewrite would meet the same busy graph. A value above 55000 is lowered to 55000, so the graph server stops a query before the client’s own 60-second wait does. If answers report the graph as unavailable while it is healthy, the limit may be too low for the size of your graph.

FalkorDB Aggregate Guard

FalkorDB 6.0.3 answers some grouped aggregations wrongly and can crash on others (upstream FalkorDB issues 3375 and 3150). A grouped aggregation puts grouping columns next to aggregate functions, for example RETURN p.name, p.stage, p.code, count(i), sum(i.total). When a grouping column is computed in that same RETURN or WITH and sits after the variables in scope, a number can come back wrong (a sum that equals the row count, say), or the graph server can restart. That is the case when there are more grouping columns than variables in scope, and also when a grouping column is listed after an aggregate. With FALKORDB_AGGREGATE_GUARD on, the default, Experio refuses a query of that shape before it reaches FalkorDB, and explains how to write it: compute each grouping column in a WITH that also carries the variables the aggregates read, list the grouping columns first, then the aggregates. In chat, the model reads the explanation and rewrites the query. A dashboard widget shows an error that asks for the widget to be regenerated, or for its query to be edited the same way. Experio also refuses an aggregating query that names a variable or alias when, then, else, starts, ends, csv or on, because each of these is also a Cypher keyword and a query that uses one as a name can be misread and answered wrongly. The refusal asks for the variable to be renamed. In chat, the model renames it and runs the query again. Nothing is rewritten behind your back, and a query of any other shape runs as before. Turn the guard off only after FalkorDB is moved to a release that contains the upstream fixes. A change applies within 30 seconds. The setting has no effect on Neo4j.

AUTH Settings

Setting	Description	Default	Related Docs
`VITE_USE_AUTH0` `(Client)`	Enable Auth0 integration	`False`	—
`VITE_CLIENT_ID` `(Client)`	Auth0 client ID	—	—
`VITE_DOMAIN` `(Client)`	Auth0 domain	—	—
`AUTH0_ISSUER`	Auth0 issuer URL	—	—
`AUTH0_JWKS_URL`	Auth0 JWKS URL	`/.well-known/jwks.json`	—
`USE_PROPELAUTH` `(Dashboard, Client)`	Enable PropelAuth SSO authentication	`False`	SSO Configuration
`ALLOW_HYBRID_LOGIN` `(Dashboard, Client)`	Allow both password and SSO login	`False`	SSO Configuration
`SSO_BACKEND` `(Dashboard)`	SSO implementation: `native` (built-in OIDC) or `propelauth` (PropelAuth BYO sidecar)	`propelauth`	SSO Configuration
`PROPELAUTH_AUTH_URL` `(Dashboard)`	PropelAuth BYO sidecar URL	`http://propelauth:2884`	SSO Configuration
🔒 `PROPELAUTH_API_KEY` `(Dashboard)`	PropelAuth integration API key	—	SSO Configuration
`PROPELAUTH_SSO_USERS_ACTIVE_BY_DEFAULT` `(Dashboard)`	Auto-activate SSO users on first login	`True`	SSO Configuration
`OAUTH2_REDIRECT_DOMAIN` `(Client)`	OAuth2 redirect domain for callback URLs	`http://localhost:8080`	—
🔒 `GOOGLE_MCP_CLIENT_ID` `(Dashboard, Client)`	Google OAuth Client ID for MCP integration	—	Integrations
🔒 `GOOGLE_MCP_CLIENT_SECRET` `(Dashboard, Client)`	Google OAuth Client Secret for MCP integration	—	Integrations
🔒 `SLACK_NOTIFICATIONS_BOT_TOKEN` `(Dashboard)`	Slack bot token (`xoxb-...`) used to send flow run notifications as direct messages. Use Clear value to turn Slack notifications off.	—	Slack notifications
`ALLOW_PASSWORD_LOGIN` `(Dashboard)`	Allow users to log in with email + password. Disable to force magic-link or SSO.	`True`	—
`ALLOW_MAGIC_LINK_LOGIN` `(Dashboard)`	Allow users to request a one-time magic-link login email.	`False`	—
`ALLOW_SELF_REGISTRATION` `(Dashboard)`	Allow anonymous users to request an account via the public register form. Disable for SSO-only tenants.	`True`	—
`MAGIC_LINK_TOKEN_TTL_MINUTES` `(Dashboard)`	How long a magic-link token is valid for, in minutes.	`15`	—
`EMAIL_PROVIDER`	Transactional email provider. Single supported value: `azure_ecs`.	`azure_ecs`	—
🔒 `AZURE_COMMUNICATION_CONNECTION_STRING` `(Dashboard)`	Azure Email Communication Services connection string. Required when `EMAIL_PROVIDER=azure_ecs`.	—	—
`AZURE_ECS_SENDER_ADDRESS` `(Dashboard)`	Sender address (MailFrom) used by Azure Email Communication Services. Must be a verified address on the linked domain.	`login@experiolabs.ai`	—
`AUTH_FROM_DISPLAY_NAME` `(Dashboard)`	Display name rendered on the From: line of transactional emails (welcome, magic link, password reset, SSO pending approval).	`Experio`	—
`AUTH_REPLY_TO_ADDRESS` `(Dashboard)`	Reply-To address added to every transactional email. Should point at a monitored mailbox so user replies are not silently dropped.	`support@experiolabs.ai`	—

ALLOW_PASSWORD_LOGIN, ALLOW_MAGIC_LINK_LOGIN, and ALLOW_SELF_REGISTRATION control which authentication paths the public login/register pages expose. They compose with USE_PROPELAUTH and ALLOW_HYBRID_LOGIN:

For SSO-only tenants, set ALLOW_PASSWORD_LOGIN=False, ALLOW_MAGIC_LINK_LOGIN=False, ALLOW_SELF_REGISTRATION=False, USE_PROPELAUTH=True, and ALLOW_HYBRID_LOGIN=False.
Magic-link login requires a working email provider (see Transactional Email below). The link is valid for MAGIC_LINK_TOKEN_TTL_MINUTES minutes.

Transactional Email Deliverability

The AZURE_ECS_SENDER_ADDRESS, AUTH_FROM_DISPLAY_NAME, and AUTH_REPLY_TO_ADDRESS settings together control how outbound auth emails appear to recipients and to mailbox spam filters:

The From: line is rendered as "<AUTH_FROM_DISPLAY_NAME>" <AZURE_ECS_SENDER_ADDRESS> (e.g. "Experio" <login@experiolabs.ai>).
A Reply-To header points at AUTH_REPLY_TO_ADDRESS so replies land in a monitored inbox instead of bouncing off the no-reply sender.
Every send also sets Message-ID (with the sender’s host), Date, and Auto-Submitted: auto-generated, and ships a real plain-text alternative alongside the HTML body — these reduce the chance of the message landing in junk.
AZURE_ECS_SENDER_ADDRESS must be a verified MailFrom on the Azure ECS linked domain. Update it (and the corresponding domain verification) if you re-brand the sender.

SSO / PropelAuth

USE_PROPELAUTH, SSO_BACKEND, PROPELAUTH_SSO_USERS_ACTIVE_BY_DEFAULT, and ALLOW_HYBRID_LOGIN work together to enable enterprise Single Sign-On with either backend. USE_PROPELAUTH turns SSO on for both backends despite its name. PROPELAUTH_API_KEY and PROPELAUTH_AUTH_URL are used only when SSO_BACKEND is propelauth. See the SSO Configuration page for complete setup instructions, identity provider guides, and troubleshooting.

Google Workspace Integration

The GOOGLE_MCP_CLIENT_ID and GOOGLE_MCP_CLIENT_SECRET settings enable per-user Google Workspace MCP integration. See the Integrations page for setup instructions.

Slack Notifications

Users can receive flow run notifications (completed, failed, needs review) as Slack direct messages. This is off until you set SLACK_NOTIFICATIONS_BOT_TOKEN; the Slack column then appears in each user’s notification settings. See Notifications for what users see. To get a token:

In your Slack workspace’s app configuration at api.slack.com, open your Slack app (or create one) and add a bot user.
Under OAuth & Permissions, add these bot token scopes: chat:write, im:write, users:read, and users:read.email.
Under App Home, turn on the Messages tab, so the app can send direct messages.
Install (or reinstall) the app to the workspace.
Copy the Bot User OAuth Token, which starts with xoxb-.
In System Settings, paste it into SLACK_NOTIFICATIONS_BOT_TOKEN and save.

The token is stored encrypted and is never shown again in full. Select Clear value under the field to turn Slack notifications off. Users who saved a Slack choice keep it, and it applies again when a token is set. Experio sends each message to the Slack member linked to the user’s Slack integration, or else the member whose email matches the user’s Experio email. Notifications contain only the flow name, what happened, and a link.

Email Notifications

Email notifications use the same email provider as other transactional email (EMAIL_PROVIDER, see above). Without a configured provider, notifications still appear in the bell, but no email is sent.

CORE Settings

Setting	Description	Default	Related Docs
`STAFF_EMAIL`	Staff notification email address	`Experio <no-reply@experio.com>`	—
`DEFAULT_FROM_EMAIL`	Default sender email address	`Experio <no-reply@experio.com>`	—
`CLIENT_NAME` `(Client)`	Client branding name	`Experio`	Client Configuration
(Icon/wide logos)	Stored as `ClientLogo` uploads in Admin — not writable as `CLIENT_LOGO_*` keys	—	Client Configuration
`DJANGO_SERVER_URL`	Django server base URL	`http://server:8000`	—
`VITE_DEV_BACKEND_URL` `(Client)`	Development backend URL	—	—
`BOX_REDIRECT_URI`	Box API redirect URI	`http://localhost:8080`	—
`GOOGLE_DRIVE_REDIRECT_URI`	Google Drive redirect URI	`http://localhost:8080`	—
`SHOW_CHANNEL_ID_UI` `(Client)`	Show channel ID in the UI	`False`	—
`CLIENT_TRACING_ENABLED` `(Client)`	Enable client-side telemetry	`False`	—
`CLIENT_TRACING_SCOPE` `(Client)`	Client tracing scope (disabled, errors, errors_api, full)	`errors`	—
`CLIENT_SIGNOZ_ENDPOINT` `(Client)`	SigNoz OTLP endpoint for client telemetry	(provider-specific)	—
`CLIENT_SIGNOZ_INGESTION_KEY` `(Client)`	SigNoz ingestion key for client telemetry	—	—
`USE_KREUZBERG_PARSER`	Use Kreuzberg text extraction parser	`True`	—
`MCP_ENABLED`	Enable Model Context Protocol	`True`	MCP Servers
`MCP_CONNECTION_TIMEOUT`	MCP connection timeout (seconds)	`30`	MCP Servers
`SCOPE_MAX_COUNT_THRESHOLD` `(Dashboard)`	Max count threshold for scope phase. Counting stops at 1,001 rows, so above `1000` the count can never exceed the threshold: the step that asks the user to narrow a very large result never fires, and results are cut at 1,001 rows (a warning is logged)	`300`	—
`CHAT_TURN_DEADLINE_S` `(Dashboard)`	Seconds a chat answer may take before it is stopped and the user is told so. `0` or less turns the limit off; a value above `3600` is lowered to `3600`. Keep it under `300`, the database’s idle session limit: an answer cannot be saved after that anyway. Answers started with the Deep Research toggle are not limited. A change applies within 30 seconds	`270`	Chat Turn Limits and the Ingestion Notice
`CHAT_POST_ANSWER_TIMEOUT_S` `(Dashboard)`	Seconds the suggested questions, the filter suggestions and the conversation title may take once the answer is complete. Whatever is not ready by then is skipped. `0` or less turns the limit off; a value above `600` is lowered to `600`. A change applies within 30 seconds	`90`	Chat Turn Limits and the Ingestion Notice
`CHAT_ROUTER_LLM_TIMEOUT_S` `(Dashboard)`	Seconds one request of an assistant’s Router Model may wait for its provider before it is cancelled and sent once more. The wait is for the first reply and then for each next piece of a streamed reply, so a long answer that keeps arriving is never cut. `0` or less turns the limit off (the model keeps its own limit of 300 seconds and two retries); a value above `300` is lowered to `300`. Applies to Azure OpenAI and OpenAI models; a model whose configuration sets a timeout other than 300 seconds keeps it. A change applies to answers that start within 30 seconds	`30`	—
`CHAT_ORCHESTRATOR_LLM_TIMEOUT_S` `(Dashboard)`	The same limit for an assistant’s Orchestrator Model, the model that writes the progress notes between the steps of an answer. `0` or less turns it off; a value above `300` is lowered to `300`. A change applies to answers that start within 30 seconds	`30`	—
`CHAT_INTENT_RESOLVER_LLM_TIMEOUT_S` `(Dashboard)`	The same limit for an assistant’s Intent Resolver Model, which works out what a question asks. It is longer than the other two because this model’s calls take longer. `0` or less turns it off; a value above `300` is lowered to `300`. A change applies to answers that start within 30 seconds	`45`	—
`CHAT_ANSWER_LLM_TIMEOUT_S` `(Dashboard)`	The same limit for the models that write the answer: an assistant’s Report writer model (or the model a user picked for the question), its Report writer fallback models and its Reasoning model (default pipeline). It is longer than the other three because these calls are the longest of an answer; a long answer that keeps arriving is never cut, but some deployments send the whole reply at once when it is ready, and for those the limit bounds the whole call: keep it above the longest answer you expect. A request that stops after its first reply is not sent again by this limit: when nothing of the answer was shown yet and at least 65 seconds of the answer’s time limit (`CHAT_TURN_DEADLINE_S`) are left, the report writer sends it once more, with the time left as its limit; otherwise the user gets an apology for the answer instead of waiting for the time limit. Answers started with the Deep Research toggle are not limited (they have no time limit either). `0` or less turns it off; a value above `300` is lowered to `300`. A change applies to answers that start within 30 seconds	`180`	—
`CHAT_INGESTION_NOTICE` `(Dashboard)`	Show a “Data update in progress” note in a chat answer while files are being ingested or enriched. Off by default, because users see it. A change applies within about 30 seconds	`False`	Chat Turn Limits and the Ingestion Notice
`CHAT_SOURCE_DOCUMENT_PREVIEW` `(Dashboard)` `(Client)`	When on, a source document in chat opens the parsed text stored on the graph, and the viewer still offers the original link. Off by default, so the name stays a link to the document. A change applies on the next page load. While graph clearance is enforced, the preview answers only after an admin scopes the Document label; until then it is the same result as a missing document	`False`	Source document preview
`SKIP_CYPHER_VALIDATION` `(Dashboard)`	Skip LLM-based Cypher validation	`True`	—
`RESTRICT_SHARING_TO_SAME_DOMAIN` `(Dashboard)`	Limit non-staff search and sharing to same email domain (staff bypass)	`True`	—
`PERSONAS_ENABLED` `(Dashboard)`	Master switch for persona UI, identity injection, and persona graph steps	`False`	Personas
`REQUIRED_PERSONAS` `(Dashboard)`	Require persona selection at login (only when `PERSONAS_ENABLED` is on)	`False`	Personas
🔒 `TAVILY_API_KEY` `(Dashboard)`	Tavily API key for chat web search and agentflows web research	—	—

Persona feature flags

PERSONAS_ENABLED and REQUIRED_PERSONAS ship off so existing tenants are unaffected until you opt in. See Personas for the behavior matrix, admin workflow, and deploy checklist.

PERSONAS_ENABLED — Off hides persona gate, profile picker, and composer toggle; the agent does not inject identity or run persona graph nodes. Admin Settings > Personas stays available for seeding.
REQUIRED_PERSONAS — On (with master on) blocks the app until the user picks a persona. Seed active personas and gating forms before enabling.

Chat Turn Limits and the Ingestion Notice

Turn deadline. A chat answer used to have no time limit: a slow model provider could leave an answer waiting for many minutes while it held database connections. CHAT_TURN_DEADLINE_S now stops an answer whose agent run passes it. The user is told This answer took longer than the time limit, so I stopped it. Please ask again in a moment., and that message is saved in the conversation as the answer. Keep the limit under 300 seconds, the database’s idle session limit on Experio deployments: the database closes the connection that holds the answer’s state after 300 idle seconds, so a longer answer fails when it is saved anyway. Answers started with the Deep Research toggle are not limited. Work after the answer. Once an answer is complete, Experio prepares the suggested follow-up questions, the filter suggestions and, in a new conversation, the title. CHAT_POST_ANSWER_TIMEOUT_S bounds that work. Whatever is not ready in time is skipped, because the user already has the answer; a new conversation can then keep the title New Chat. Ingestion notice. While files are ingested, the graph can answer more slowly. With CHAT_INGESTION_NOTICE on, an answer that starts during ingestion shows a Data update in progress step with the sentence New data is being added right now, so answers may take longer than usual. Ingestion counts as running when any of these is true:

a file is in a download, parse, classify or ingest stage and was updated within the last 15 minutes;
a structured-data scan started within the last 12 hours is still running;
an enrichment job started within the last 12 hours is still running.

The time bounds keep a stuck record from showing the note for ever. The notice ships off because users see it. Whether ingestion is running is remembered for 30 seconds per server process. All three settings apply within about 30 seconds of a change, without a restart.

Source document preview

With CHAT_SOURCE_DOCUMENT_PREVIEW off, a source document in chat opens its original link. With it on, the same click opens the parsed text stored for that document, and the viewer still offers the original link. The setting ships off. A change applies the next time the page is loaded. While graph clearance is enforced, that preview is available only after the Document label is scoped. Until an admin scopes it, every preview is the same result as a missing document, including for a person who can otherwise open the original link. A superuser whose graph bypass is on can still open the parsed text.

JOBS Settings

Setting	Description	Default	Related Docs
`DOCLING_SERVE_ENDPOINT`	Docling service API endpoint	`http://docling:5001`	—
`INGESTION_THREADS` `(Dashboard)`	Number of ingestion worker threads	`6`	Jobs & Monitoring
`INGESTION_PARSER_CONNECTION_RETRIES`	Max retries for Docling connection	`20`	—
`INGESTION_PARSER_RETRY_SLEEP_SECONDS`	Sleep between Docling retries (seconds)	`30`	—
`INGESTION_USE_MULTI_THREADING`	Enable multi-threaded ingestion	`True`	—
`MINIO_RETENTION_DAYS` `(Dashboard)`	Pipeline file retention (days). The clean-up job deletes downloaded files, and the parsed text of ingested, skipped and failed files, that are older than this, wherever it runs (Parse only files keep theirs). An original file’s download stops with HTTP 410 after this many days	`7`	Async Document Parsing
`KREUZBERG_ENDPOINT`	Kreuzberg text extractor endpoint	`http://kreuzberg-text-extractor:8000`	—
`KREUZBERG_REQUEST_TIMEOUT_SECONDS`	Kreuzberg request timeout (seconds). With `KREUZBERG_MODE` set to `library` (the default), a file attached in the knowledge-model copilot, or a Test Ingestion sample, is also stopped at `UPLOAD_EXTRACTION_TIMEOUT_SECONDS`, which is shorter by default	`600`	—
`UPLOAD_EXTRACTION_MAX_MEMORY_MB`	Memory (MB) one first reading of an uploaded file may use on the API server: a file attached in the knowledge-model copilot, an upload in the main chat or a Test Ingestion sample, read in a child process of the API server with no OCR. Past it the reading is stopped and the file is handed to the async parser, which reads it with limits of its own (`ASYNC_PARSE_MAX_MEMORY_MB`) instead of failing it. A picture in Test Ingestion is read by OCR in place and cannot be handed over, so it has a budget of its own, never below 1,024 MB (a higher value here raises it too), and still fails as too large to read here when it needs more; a zip that expands past the unzip limits is refused, not handed over. The default used to be 3,072, and then 1,024: the first upgrade moves a setting that still holds its old default (3072, or 1024) to 512, and keeps any other value, as well as a 3072 or a 1024 you save after that. The limit applies to each reading, not to the server, and a reading can pass it by a few hundred MB before it is stopped. Whatever this setting says, a reading is also stopped, and its file handed over, when the server’s container or machine has less than 768 MB of memory left. With `KREUZBERG_MODE=api`, only the builtin parser’s reading is limited. A value that is not a positive number means the default	`512`	Admin Copilot
`UPLOAD_EXTRACTION_TIMEOUT_SECONDS`	Seconds one first reading of an uploaded file may take on the API server (a copilot attachment, a main-chat upload or a Test Ingestion sample; OCR included for a Test Ingestion picture). Past it the reading is stopped and the file is handed to the async parser, which has a limit of its own (`ASYNC_PARSE_TIMEOUT_SECONDS`); a Test Ingestion picture, read by OCR in place, cannot be handed over and has at least 300 seconds (a higher value here raises it too), after which it fails. The default used to be 300: the first upgrade moves a setting that still holds 300 to 60, and keeps any other value, as well as a 300 you save after that. It applies to each attempt, so a file that the builtin parser reads after Kreuzberg failed can take up to twice as long. With `KREUZBERG_MODE=api`, only the builtin parser’s reading is limited. A value that is not a positive number means the default	`60`	Content Types
`COPILOT_ATTACHMENT_OCR_MAX_PAGES`	No longer used. It limited how many pages of a scanned PDF attached in the knowledge-model copilot were read with OCR on the API server. The API server no longer reads anything by OCR for the copilot, the main chat or Test Ingestion (a Test Ingestion picture apart): a scan goes to the async parser, which asks first above `ASYNC_PARSE_OCR_ASK_ABOVE_PAGES` pages. Changing it has no effect	`1`	Admin Copilot
`COPILOT_ATTACHMENT_OCR_MAX_MEMORY_MB`	No longer used. It limited the memory of the OCR reading of a scanned PDF attached in the knowledge-model copilot, on the API server. The OCR of a scan is now the async parser’s, with `ASYNC_PARSE_OCR_MAX_MEMORY_MB`. Changing it has no effect	`1024`	Admin Copilot
`COPILOT_ATTACHMENT_OCR_TIMEOUT_SECONDS`	No longer used. It limited the time of the OCR reading of a scanned PDF attached in the knowledge-model copilot, on the API server. The OCR of a scan is now the async parser’s, with `ASYNC_PARSE_OCR_TIMEOUT_SECONDS`. Changing it has no effect	`120`	Admin Copilot
`SERVICE_SECRET_KEY`	Internal service authentication key	(auto-generated)	—
`STRUCTURED_DATA_THREADS`	Structured data processing threads	`4`	—
`ENRICHMENT_THREADS`	Enrichment job worker threads	`4`	Enrichment Rules
`GRAPH_EVALUATION_THREADS`	Graph evaluation job worker threads	`2`	Graph Evaluation
`GRAPH_EVALUATION_SHUTDOWN_TIMEOUT_SECONDS`	Seconds to wait for graph evaluation workers on shutdown	`600`	Graph Evaluation
`GRAPH_EVALUATION_SAMPLES_PER_CONTENT_TYPE`	Default samples per content type for LLM-judge runs (max 50)	`3`	Graph Evaluation
`GRAPH_EVALUATION_TRIAGE_SAMPLES_PER_CONTENT_TYPE` `(Dashboard)`	Default samples per content type for triage runs (max 500)	`25`	Graph Evaluation
`GRAPH_EVALUATION_AUTO_RUN_AFTER_JOB`	Automatically queue graph evaluation when all job files finish processing	`False`	Graph Evaluation
`GRAPH_EVALUATION_SAMPLE_CONCURRENCY` `(Dashboard)`	Samples evaluated in parallel within one run (`1` = one at a time, max 32)	`4`	Graph Evaluation
`GRAPH_EVALUATION_JUDGE_MODE` `(Dashboard)`	Default judge for new runs: `llm` (LLM judges every sample) or `triage` (decision model screens, LLM judges flagged samples). Falls back to `llm` until `DECISION_MODEL_CONFIG` points at an active decision model	`llm`	Graph Evaluation
`GRAPH_EVALUATION_TRIAGE_QUALITY_CONFIDENCE` `(Dashboard)`	Triage: minimum decision-model confidence in its quality rating to skip the LLM judge	`0.8`	Graph Evaluation
`GRAPH_EVALUATION_TRIAGE_ISSUE_PROBABILITY` `(Dashboard)`	Triage: issue-category probability at or above which a sample goes to the LLM judge	`0.5`	Graph Evaluation
`GRAPH_EVALUATION_TRIAGE_AUDIT_RATE` `(Dashboard)`	Triage: fraction of clean samples also sent to the LLM judge, to check the decision model	`0.05`	Graph Evaluation
`ENRICHMENT_NODE_CONCURRENCY`	Concurrent nodes per enrichment job	`4`	Enrichment Rules
`ENRICHMENT_RESULT_RETENTION_DAYS`	Days to retain `EnrichmentResult` rows before purge (`0` = keep forever)	`90`	Enrichment Rules
`SCALE_TO_ZERO_ENABLED` `(Dashboard)`	Enable scale-to-zero for job services	`False`	—
`SCALE_TO_ZERO_DRY_RUN` `(Dashboard)`	Scale-to-zero dry run mode	`False`	—
`SCALE_TO_ZERO_POLL_INTERVAL` `(Dashboard)`	Scale-to-zero polling interval (seconds)	`60`	—
`USE_MULTI_RESOURCE_SCALING` `(Dashboard)`	Let the autoscaler apply all pending scaling actions in one grouped Omnistrate call per cycle (instead of one action per cycle)	`False`	Jobs & Monitoring
`SCALE_UP_PENDING_TIMEOUT_SECONDS` `(Dashboard)`	How long an accepted scaling request may wait for resources to reach ACTIVE before the autoscaler abandons it (platform scale-ups normally take several minutes)	`600`	Jobs & Monitoring
`OMNISTRATE_SIDECAR_URL`	Omnistrate sidecar URL	`http://127.0.0.1:49750`	—
`ENABLE_FULL_SCAN_DOCUMENT_CHECK`	Check for existing documents during full scans	`True`	—
`MAX_PARSED_SIZE_MB` `(Dashboard)`	Max parsed file size (MB)	`20`	—
`MAX_INGESTION_CHUNKS` `(Dashboard)`	Max chunks per document	`120`	—
`INGESTION_TIMEOUT_SECONDS` `(Dashboard)`	Document ingestion timeout (seconds)	`900`	—
`INGESTION_COST_GUARD_CHUNK_THRESHOLD` `(Dashboard)`	Estimated chunk count above which full-mode extraction falls back to metadata-only (aligned with `MAX_INGESTION_CHUNKS`)	`120`	Extraction Policy
`INGESTION_PEAK_HOURS` `(Dashboard)`	Business hours during which scheduled flows wait, written `HH:MM-HH:MM` in the time zone below (for example `08:00-18:00`; `22:00-06:00` crosses midnight). A flow that falls due inside the window starts when the window ends. Manual starts and running flows are not held. Empty turns the hold off	(empty, hold off)	Business-Hours Hold
`INGESTION_PEAK_TIMEZONE` `(Dashboard)`	IANA time zone name (for example `America/New_York`) of the peak hours window	`UTC`	Business-Hours Hold
`INGESTION_PEAK_DAYS` `(Dashboard)`	Weekdays the peak hours window applies on, comma separated (`mon,tue,wed,thu,fri,sat,sun`), judged by the local date in the time zone above	`mon,tue,wed,thu,fri`	Business-Hours Hold
`MAX_EXCEL_SHEET_CHARS`	Skip LLM extraction on Excel sheets above this character count	`50000`	Extraction Policy
`MAX_EXCEL_INGESTION_CHUNKS_PER_SHEET`	Max LLM chunks per sheet in full-mode Excel extraction	`25`	Extraction Policy
`PHOENIX_TRACING_MODE` `(Dashboard)`	Phoenix tracing mode (disabled, central, cluster)	`disabled`	—
`PHOENIX_ENDPOINT` `(Dashboard)`	Phoenix endpoint URL	(provider-specific)	—
`PHOENIX_TRACING_SCOPE` `(Dashboard)`	Phoenix tracing scope (jobs, retrieval, all)	`all`	—

Business-Hours Hold for Scheduled Flows

A flow that re-scans and re-ingests your data writes to the knowledge graph for as long as it runs, and the graph answers other questions more slowly meanwhile. The usual answer is to schedule such flows for your night. As a guard for the day, you can set a business-hours window: while it is open, scheduled flows do not start.

INGESTION_PEAK_HOURS is the window, HH:MM-HH:MM in 24-hour time, from the start (included) to the end (excluded). A window that ends before it starts crosses midnight (22:00-06:00). Empty, or a start equal to the end, turns the hold off, and that is how it ships.
INGESTION_PEAK_TIMEZONE is the IANA name of the time zone the window is written in. It is UTC until you change it, so set it together with the hours.
INGESTION_PEAK_DAYS lists the weekdays the window applies on. The local date in that time zone decides. With 22:00-06:00 on mon,tue,wed,thu,fri, Friday night is held until midnight but its Saturday part is not, and Monday’s early morning is held although the night began on a Sunday.

The hold only delays. A flow that falls due inside the window keeps its due time, starts once on the first runner pass after the window closes, and is then scheduled as usual. Run Now and a run already in progress are never held. While flows are held, the flow runner’s log says how many and until when, at most every 15 minutes. A value that cannot be read (for example 8-18, an unknown time zone or an unknown weekday) turns the hold off and writes one warning to the log for that value, so a typo cannot stop the flow runner. If scheduled flows keep starting inside your business hours, look for that warning.

Async Parsing Settings

Setting	Description	Default	Related Docs
`ASYNC_PARSE_QUEUE_WAIT_SECONDS` `(Dashboard)`	Seconds a file may wait for the async parser to start reading it (queued, or queued for OCR). Past it the file fails with Parsing is unavailable right now; try again later. A file from an Agent Flow waits for its step’s own deadline instead. The check runs in a sweep of the flow runner, about once a minute	`3600`	Async Document Parsing
`ASYNC_PARSE_MAX_ATTEMPTS` `(Dashboard)`	Times the async parser may stop under one file (a crash, or the parser being killed) before the file fails with Reading this file failed after N attempts: the parser stopped each time before it finished. A parser that is shut down cleanly, and one that stops for lack of server memory, do not count	`3`	Async Document Parsing
`ASYNC_PARSE_STALE_HEARTBEAT_SECONDS` `(Dashboard)`	Seconds without a heartbeat after which another parser takes over a file that is being read (its reader is gone)	`120`	Async Document Parsing
`ASYNC_PARSE_HEARTBEAT_SECONDS` `(Dashboard)`	Seconds between the parser’s heartbeats while it reads a file; keep it well below `ASYNC_PARSE_STALE_HEARTBEAT_SECONDS`	`30`	Async Document Parsing
`ASYNC_PARSE_POLL_SECONDS` `(Dashboard)`	Seconds an idle async parser waits before it looks for the next file	`2`	Async Document Parsing
`ASYNC_PARSE_MAX_QUEUED_PER_USER` `(Dashboard)`	Files one person may have waiting or being read by the async parser at once, across the copilot, the main chat, Agent Flows and Test Ingestion. A scan waiting for the person’s OCR choice counts. Past it, a new file that needs the parser is refused with N of your files are already waiting to be read (at most N at a time) (HTTP 429) until one finishes. A small main-chat file that the API server reads itself is not held to it	`10`	Async Document Parsing
`ASYNC_PARSE_RETENTION_DAYS` `(Dashboard)`	Days a finished async parse (its text and chunks) is kept before it is deleted. A parse that a chat file or a copilot document still uses is kept for as long as that file or document exists	`7`	Async Document Parsing
`ASYNC_PARSE_NEEDS_OCR_EXPIRY_HOURS` `(Dashboard)`	Hours a scanned PDF waits for the person to choose Read with OCR or Skip. Past it the file skips OCR by itself and settles as a scan nobody read	`24`	Async Document Parsing
`ASYNC_PARSE_OCR_ASK_ABOVE_PAGES` `(Dashboard)`	Where a scan asks before it is read by OCR (the copilot and the main chat): a scan with more pages than this waits for Read with OCR or Skip, and a shorter one is read by OCR straight away. `0` asks for every scan	`2`	Async Document Parsing
`ASYNC_PARSE_OCR_SECONDS_PER_PAGE` `(Dashboard)`	Seconds one scanned page is estimated to take to read by OCR: the estimate on the Read with OCR (~N min) button and beside the elapsed time while OCR runs. It limits nothing	`10`	Async Document Parsing
`ASYNC_PARSE_MAX_MEMORY_MB` `(Dashboard)`	Memory (MB) the async parser may use to read one file (the first reading, with no OCR). Past it the reading is stopped and the file fails with this file is too large to read here (reading it needed more than N MB of memory); attach a smaller or text version	`3072`	Async Document Parsing
`ASYNC_PARSE_TIMEOUT_SECONDS` `(Dashboard)`	Seconds the async parser may take to read one file (the first reading, with no OCR). Past it the reading is stopped and the file fails with reading this file took too long (more than N seconds). Kreuzberg’s own timeout (`KREUZBERG_REQUEST_TIMEOUT_SECONDS`, 600 seconds by default) also applies inside the reading	`1800`	Async Document Parsing
`ASYNC_PARSE_OCR_MAX_MEMORY_MB` `(Dashboard)`	Memory (MB) the async parser may use for the OCR reading of one scanned PDF. Past it the OCR is stopped and the file fails with Scanned PDF: its pages are images, and reading them with OCR needed more than N MB of memory …	`3072`	Async Document Parsing
`ASYNC_PARSE_OCR_TIMEOUT_SECONDS` `(Dashboard)`	Seconds the async parser may take for the OCR reading of one scanned PDF. Past it the OCR is stopped and the file fails with Scanned PDF: its pages are images, and reading them with OCR took more than N seconds …	`1800`	Async Document Parsing
`ASYNC_PARSE_MAX_EMBED_CHUNKS` `(Dashboard)`	Chunks (about 1,000 characters each) of one file that the async parser embeds for the knowledge-model copilot’s search. The rest of a longer file is searchable by keyword only, and its chip says so. `0` embeds none. Only copilot files are embedded	`20000`	Async Document Parsing
`ASYNC_PARSE_EMBED_BUDGET_SECONDS` `(Dashboard)`	Seconds the async parser may spend embedding the chunks of one file for the copilot’s search, counted from when the embedding starts. The chunks it has not reached are searchable by keyword only; the file is still read in full. A value under 30 means the default	`600`	Async Document Parsing
`ASYNC_PARSE_PRECHECK_MAX_FILE_MB` `(Dashboard)`	Files larger than this (MB) go to the async parser without being read on the API server first: copilot attachments, main-chat uploads and Test Ingestion samples. `0` sends every file, except a Test Ingestion picture, which only OCR on the API server can read and is never sent	`1`	Async Document Parsing
`ASYNC_PARSE_PRECHECK_MAX_SPREADSHEET_MB` `(Dashboard)`	Spreadsheets larger than this (MB) go to the async parser the same way. The default `0` sends every spreadsheet, whatever its size: a few MB of cells can expand to gigabytes when read (at the earlier, higher limit, spreadsheets needed 170 to 365 MB in tests, a very sparse one about 660 MB). Raise it to have small spreadsheets read on the API server	`0`	Async Document Parsing
`ASYNC_PARSE_INLINE_TEXT_EMBED_MAX_CHARS` `(Dashboard)`	Characters of an already-parsed document picked into the knowledge-model copilot that are indexed on the API server. A longer document is indexed by the async parser. `0` sends every picked document there	`200000`	Async Document Parsing
`ASYNC_PARSE_FLOW_DEFAULT_TIMEOUT_SECONDS` `(Dashboard)`	Seconds an Agent Flow’s Parse documents (async) step waits for its files when its own Wait at most (seconds) is empty. Past it the step reports `timed_out` and cancels what is still being read	`1800`	Agent Flow Nodes
`ASYNC_PARSE_FLOW_MAX_TIMEOUT_SECONDS` `(Dashboard)`	The longest wait (seconds) a flow author may set on a Parse documents (async) step; a larger value is cut to this	`7200`	Agent Flow Nodes
`ASYNC_PARSE_DISPATCH_URL` `(Dashboard)`	Base URL the flow runner’s sweeps call to deliver a finished parse to the API server, and to start a due Copilot follow-up (the server’s own Daphne on loopback). Change it only where the API server does not listen on `127.0.0.1:8000`. A wrong value stops finished parses from reaching Agent Flows (the runs waiting for their files are not resumed) and stops due Copilot follow-ups from starting	`http://127.0.0.1:8000`	Async Document Parsing

The ASYNC_PARSE_* rows above configure async document parsing: how long a file may wait, how often a person may queue files, what the parser may use to read one file, and how Agent Flows wait for it. They are on Admin > Administer > System Settings, in the Async Parsing tab (right after Jobs Settings), where each one can be edited. They are also Configuration Settings in the Django admin (/staff/), in their own ASYNC_PARSE category (Async Parsing) rather than JOBS. The UPLOAD_EXTRACTION_* and COPILOT_ATTACHMENT_OCR_* rows, which stay in JOBS, are not listed on the page: they are edited in the Django admin only. The rows are seeded with the defaults shown, and a value you save is kept. A database that holds them from an earlier version, under JOBS and hidden from this page, has them moved to ASYNC_PARSE and shown by the next seed_config run (a deploy runs it), with the values it saved. For a number, a value that cannot be read, or that is below the setting’s minimum, means the default. The minimum is 1, except where a row says 0 is allowed (ASYNC_PARSE_OCR_ASK_ABOVE_PAGES, ASYNC_PARSE_MAX_EMBED_CHUNKS, ASYNC_PARSE_PRECHECK_MAX_FILE_MB, ASYNC_PARSE_PRECHECK_MAX_SPREADSHEET_MB and ASYNC_PARSE_INLINE_TEXT_EMBED_MAX_CHARS) and 30 for ASYNC_PARSE_EMBED_BUDGET_SECONDS.

INFRA Settings

Setting	Description	Default	Related Docs
`RABBITMQ_HOST`	RabbitMQ server hostname	`rabbitmq-0`	—
`RABBITMQ_USER`	RabbitMQ username	`admin`	—
🔒 `RABBITMQ_PASS`	RabbitMQ password	—	—
`RABBITMQ_PORT`	RabbitMQ server port	`5672`	—
`RABBITMQ_PUBLISHER_HEARTBEAT`	Publisher heartbeat interval (seconds)	`20`	—
`RABBITMQ_PUBLISHER_BLOCKED_TIMEOUT`	Publisher blocked connection timeout (seconds)	`60`	—
`RABBITMQ_CONSUMER_HEARTBEAT`	Consumer heartbeat interval (seconds)	`20`	—
`RABBITMQ_CONSUMER_BLOCKED_TIMEOUT`	Consumer blocked connection timeout (seconds)	`60`	—
`SIGNOZ_QUERY_ENDPOINT` `(Dashboard)`	SigNoz Query API base URL	—	—
🔒 `SIGNOZ_QUERY_API_KEY` `(Dashboard)`	SigNoz Query API access token	—	—

FEATURE_FLAGS Settings

Setting	Description	Default	Related Docs
`GRAPH_AUTHORIZATION_MODE` `(Dashboard)`	Graph access control: `disabled`, `shadow` (work out and log the decision, still answer from the unfiltered query) or `enforce` (filter every answer)	`disabled`	Graph Access Control
`GRAPH_AUTHZ_SUPERUSER_BYPASS` `(Dashboard)`	Let superusers read the graph without the access policy applied	`False`	Graph Access Control

Enter the policy before switching GRAPH_AUTHORIZATION_MODE to enforce. A label with no baseline row is treated as private, so on a deployment where the policy has not been entered yet, enforce makes the knowledge graph invisible to everyone. Use shadow first: it works out and records the same decision while still answering from the unfiltered query, so you can see what would change before anything does.

GRAPH_AUTHZ_SUPERUSER_BYPASS is one switch for all superusers, not a per-account setting. Turning it on means every superuser reads the graph unfiltered, immediately, with no further step. It exists so a tester or the customer’s own IT owner can check the whole graph; it is not a way to give one person more access.It has no effect unless the mode is enforce, and a bypassed read still works out the decision it is ignoring and records it, so the audit trail survives. Anyone whose session is bypassing sees a banner saying so — see What the AI can see.

Environment Settings

A few settings are read from the server’s environment when a process starts, not from a row in the tables above. The database timeouts have to be known before the first database connection opens, and a System Settings row can only be read through a connection that already works. These settings are not shown on this page, and a change takes effect when the process restarts. Of the variables below, two are exposed as Omnistrate deployment parameters: GRAPH_EXECUTOR_THREADS (graphExecutorThreads, see FalkorDB deployment parameters) and DB_POOL_MAX_SIZE (Database Pool Size per Process, dbPoolMaxSize, see Service scaling). The others keep their default unless the server’s environment sets them.

Variable	Description	Default
`DB_CONNECT_TIMEOUT_S`	Seconds the web server waits to open a new database connection. A connection that is already open, and a statement that is running, are not affected. `0` turns the limit off	`10`
`DB_LOCK_TIMEOUT_S`	Seconds a web request waits for a database lock that another transaction holds, for example a person’s other upload in progress. It bounds the wait, never the work done once the lock is held. `0` turns the limit off	`60`
`DB_STATEMENT_TIMEOUT_S`	Seconds one database statement may run in the web server. `0` leaves it off, and it ships off: set it only once you know the longest statement the web server legitimately runs, because a value that is too low breaks long reports	`0` (off)
`DB_POOL_MAX_SIZE`	Most database connections one web server process keeps in its connection pool. The web server borrows a pooled connection when a request needs the database and hands it back when the request ends, so a few connections stay open and are reused, instead of one new connection for every request. When all of them are borrowed, the next request waits for one (see `DB_POOL_TIMEOUT_S`) and the database never sees more than this many connections from that process for web requests and WebSocket calls. `0` turns the pool off: one new connection per request, as before the pool existed. A whole number is read as it is, with or without `.0` (`6.0` is `6`); a value that is not a whole number of 0 or more (for example `-1` or `2.5`) falls back to the default with a warning when the server starts. On a managed deployment the Database Pool Size per Process deployment parameter (`dbPoolMaxSize`) sets it, from 0 to 20, see Service scaling	`6`
`DB_POOL_MIN_SIZE`	Connections the pool keeps open in each web server process when the server is idle	`1`
`DB_POOL_TIMEOUT_S`	Seconds a request waits for a pooled connection when all of them are borrowed. After that the request fails with the message “couldn’t get a connection after N sec”, which in the server log means the pool is too small for the load or a request is holding its connection for too long. Keep it about as large as `DB_CONNECT_TIMEOUT_S`: the WebSocket database calls of a process share one thread, so a wait there holds up every open chat of that process	`10`
`DB_POOL_MAX_IDLE_S`	Seconds a connection above `DB_POOL_MIN_SIZE` may sit unused before the pool closes it (one connection per period), so a burst does not stay on the database’s connection count	`30`
`DB_POOL_MAX_LIFETIME_S`	Seconds after which the pool replaces a connection the next time it is returned, so no connection lives for ever	`3600`
`EXPERIO_PROCESS_KIND`	The kind of the process: `web` (the Daphne web server), `worker` (the long-running worker that reads uploaded documents), `job` (every other job runner) or `other` (management commands and scripts). Experio tells them apart by their command line; set this only for a process started in a way that detection cannot see	(detected)
`LANGGRAPH_SHARED_STORE_POOL`	`true` runs the chat agent’s memory store for every answer on one shared database connection pool per server process (at most 16 connections; a spare connection closes after 30 seconds idle), and the quick reads of a chat’s saved state on a second small pool (at most 4). `false` goes back to a separate pool for each answer and one short connection for each quick read	`true`
`GRAPH_EXECUTOR_THREADS`	Threads in the server’s graph executor, the pool that runs every graph read from chat, agent flows and dashboards. A value outside 1 to 32 is moved into that range, and one that is not a number falls back to the default with a warning. The deployment sets it for the server only; job workers keep the default. Raising it alone does not add graph capacity: FalkorDB runs queries on its own threads and queues the rest	`6`

The three database timeouts and the connection pool apply to the web server process only, because only there can one slow call hold up every connected user. The job runners, the document-reading worker and management commands such as migrate get no timeout and no pool, so a migration is never cut short by a lock wait. With several server processes in a pod (see Service scaling) each process has its own pool, so the most connections the web server can hold is the number of pods times the number of processes times DB_POOL_MAX_SIZE, in addition to the chat agent’s own connections. Every process tags its database connections with an application_name of experio-web, experio-worker, experio-job or experio-other, so pg_stat_activity shows which kind of process owns a connection. The connections the chat agent opens for its checkpoints and its memory store are tagged experio-langgraph and use the connect timeout of the process that opens them.

Getting Started

Data Sources

Knowledge Graph

User Management

Integrations

Settings

Monitoring

Overview

Categories

Viewing Settings

Editing Settings

Asking the Copilot

Settings Reference

LLM Settings

Produced Documents in Chat Context

Graph Text in Chat Context

Copilot Scheduled Follow-ups

DB Settings

Graph Read Time Limit

FalkorDB Aggregate Guard

AUTH Settings

Transactional Email Deliverability

SSO / PropelAuth

Google Workspace Integration

Slack Notifications

Email Notifications

CORE Settings

Persona feature flags

Chat Turn Limits and the Ingestion Notice

Source document preview

JOBS Settings

Business-Hours Hold for Scheduled Flows

Async Parsing Settings

INFRA Settings

FEATURE_FLAGS Settings

Environment Settings

Overview

Categories

Viewing Settings

Editing Settings

Asking the Copilot

Settings Reference

LLM Settings

Produced Documents in Chat Context

Graph Text in Chat Context

Copilot Scheduled Follow-ups

DB Settings

Graph Read Time Limit

FalkorDB Aggregate Guard

AUTH Settings

Login Methods

Transactional Email Deliverability

SSO / PropelAuth

Google Workspace Integration

Slack Notifications

Email Notifications

CORE Settings

Persona feature flags

Chat Turn Limits and the Ingestion Notice

Source document preview

JOBS Settings

Business-Hours Hold for Scheduled Flows

Async Parsing Settings

INFRA Settings

FEATURE_FLAGS Settings

Environment Settings