What your IT team will ask, answered.

In your cloud or ours. It is the same software either way.

Weekly totals by store and category. DemandRadar does not need or store customer, shopper, payment or employee HR data.

Through your own identity provider, using OpenID Connect. Microsoft Entra ID, Okta, Auth0 and Ping are supported.

• Your provider, registered to your tenant. Every sign-in token is verified against your provider's own signing keys: signature, issuer, audience and expiry. A token from an issuer nobody registered is refused.
• No passwords are stored. Multi-factor sign-in and conditional access are enforced by your identity provider.
• Four roles: viewer, planner, analyst and admin. Permissions are checked on every API route, not only hidden in the screen.
• Roles assigned in your identity provider are the source of truth. A change takes effect on the user's next request. By default, a token that carries no DemandRadar role is refused even if the account exists, so removing the role removes access.
• Deactivating an account in Admin always wins, whatever the token says.
• No single sign-on of your own? A shared provider can serve several customers. There the signed tenant claim in the token selects the customer, and a token without it is refused.

In two layers, both covered by automated tests.

• In the application. Every query is filtered to your tenant, and a write aimed at another tenant raises an error.
• In the database. PostgreSQL row-level security is forced on every tenant table, and a test fails if a tenant table is added without it. It depends on the application connecting as an unprivileged role, and the supplied deployment files create one.
• The tenant comes from the verified token. An identity provider can be registered to one customer only, so a token from one customer's provider cannot be steered into another customer's data. No request header or unsigned value chooses a tenant.
• Background work follows the same rules. Scheduled runs and the retention purge each work inside one tenant, under both layers.

Every change made through the application writes an audit event: who, what, which record, when, and the request id. For settings, the before and after values are kept. Accounts created or given a new role at sign-in are logged too, as are identity provider changes and every retention purge. Admins read the log in the app.

Two limits to know about. The application only ever adds audit rows, but the database does not yet stop an administrator with direct database access from altering them. The operator commands that create a tenant or add a user are not audited.

It is optional. The built-in writer needs no outside service and is the default.

• Off until you turn it on. One of your admins must enable an AI writer and choose the provider.
• Aggregates only. The model receives the week's summarized facts. No raw rows and no user data.
• Every number checked. A draft containing a figure that does not match your data is discarded and the built-in writer is used instead.
• Azure OpenAI is supported, so inference can stay inside your own Azure tenant.
• No training on your data. DemandRadar does not use customer data to train any model. Your planners' confirmations and corrections stay in your tenant and you can export them.

• Locked-down containers. The API and scheduler run as a non-root user with a read-only filesystem.
• Encrypted in transit. TLS terminates at the ingress or load balancer in front of the app.
• Encryption at rest and backups come from the PostgreSQL service you choose, for example Azure Database for PostgreSQL or Amazon RDS.
• Secrets stay out of the database and the logs. They come from environment variables or your secret manager.
• Quiet logs. Structured, with no request bodies and no sales figures.
• Uploads are data, never code. Files are size-limited, parsed as CSV or Excel and never executed. A file with more than 20% bad rows is rejected so a bad export cannot overwrite good data.
• Rate limits in the API. Per signed-in user, per address for requests without valid credentials, and a tighter limit for uploads and run triggers. A refused request gets a 429 response.
• Retention is enforced daily. Sales data and the reviews built on it are deleted once older than the retention period you set (730 days by default, 30 at minimum). Audit events are kept for seven years by default.
• No third parties in the browser. The web app serves its own fonts and scripts and calls no outside origins.

Stated plainly, so there are no surprises in review.