Astralis 3.2.0 release notes

• 3.2.0: November 10, 2026

Astralis 3.2.0

Data Mapping

Detect and classify global data risks with comprehensive visualization for data mapping and reporting for modern Enterprise.

• Processes (Alpha): Behind the alphaProcessOntology feature flag, you can record your processing activities as processes and relate them to the systems and taxonomy elements they use.
  • A Processes page under Data Governance lists processes in a graph, and you can create one from that page, from the context panel or from the graph. Editing stages your changes and saves them together, and every save publishes a new process version you can browse in its version history.
  • Each process shows the regulations it falls under, based on where it takes place, and can have stewards. Systems can be linked to the processes they perform, and each system lists them. Linking or unlinking needs permission to update the system, and deleting a system or retiring a process removes its links.
  • Seven managed taxonomies (geography, legal basis, regulation, obligation, retention period, risk category and risk severity) are seeded, with managed relationships from geographies to the regulations that apply there. The geography taxonomy covers the places where privacy law differs and is shown on the taxonomy page.
  • The Astralis Home digest adds a stop showing the regulation and process graph.
  • Processes can be assessed directly. See Assess Processing Activities under Assessments. Includes database migrations.
• Risk Plane (Alpha): Behind the alphaRiskPlane feature flag, the Astralis app adds a map of website monitor resources at consent risk.
• Sample Values Stay Cached Longer: Sample value preview keeps sampled values in Redis for up to 15 minutes instead of 5, so reopening a field queries the data store less often. Values are still never stored in the database.
• Bug Fixes:
  • SQL discovery monitors that sample across several threads no longer leave database engines or Cloud SQL connectors open.
  • The name typed into a new monitor's form is kept when the integration's system finishes loading, so Next and Save are no longer stuck disabled.
  • The Action Center Activity tab loads connection logos for monitor tasks, and Action Center links in the Astralis app open the right system or integration tab.
  • The website monitor assets toolbar stays on screen at the minimum 1200px width.
  • Data map reports label system groups correctly when another taxonomy has an element with the same key.
  • Infrastructure and AWS monitor result banners use the Astralis name.

DSR Orchestration

Enterprise grade privacy request management and processing with a single orchestration layer for DSRs across vendors and systems

• Policy Versions: Each privacy request now records the version of its policy it was created under, and rules and webhooks are read from the policy's published version. This is the first step toward in-flight requests finishing under the policy they started with, rather than picking up later edits.
  • A storage destination or connection that a live policy version uses can no longer be deleted.
  • Rule and webhook keys are unique per policy version, and rule target keys per rule, so reusing a key from another policy or rule creates a separate entry instead of failing.
  • Includes a database migration. See the note below.
• DSR Policies (Beta): Behind the dsrPolicyWorkflows feature flag, the DSR policy pages introduced in 3.1 are now called Policies.
  • The policies list adds a status, last-edited date, sorting and paging, and the policy Key field is hidden.
  • A policy can be exported as YAML, and the Policy statement YAML view is easier to read. The Verify card links to the verification code template and warns when a property has none, and the Fulfill card groups data categories by parent. Preset options use segmented buttons.
  • Consent-only policies can now set their own identity verification and code expiry. See the note below.
• Identity Document Verification (Alpha): Behind the alphaDocumentUpload feature flag, access and erasure policies can require the data subject to upload an identity document, as well as or instead of a verification code.
  • The Verify card sets whether the code or the document comes first.
  • The requester gets a Verify your identity email with an upload link, from a new configurable template. The Privacy Center upload page asks for a photo of an ID, and files sent through the link are stored as identity documents.
  • Requests wait in Awaiting identity review until an analyst verifies or rejects the document from the Documents tab. The Request Manager can filter on that status.
  • Identity documents are marked as such and can never be added to the access package.
  • New holds need the flag. Requests already waiting can still be reviewed with it off. Includes database migrations.
• Privacy Center And Messaging:
  • Footer links: Privacy Center footer links can be added, edited and reordered in property settings.
  • Location fields: Request form location fields can be restricted to allowed countries and regions.
  • Location targeting display: Privacy Center actions show their location targeting as a tag with the locations in a tooltip, and group Edit form, Documents and Delete in a row menu.
  • Requester language per action: Each Privacy Center action can set the language used for requester messages, so several actions can share a policy and differ only by language or location. Finalize warnings explain when the operator's message will not be sent.
  • Template details: Messaging templates show which lifecycle event triggers them and which request types they apply to.
• Bug Fixes:
  • Privacy requests that reach datasets on S3, Entra, Okta or RDS MySQL integrations, which cannot run privacy requests, no longer complete with nothing done. The request now errors and names the integration until its datasets are unlinked or it is disabled, and new datasets can no longer be linked to those integrations. The datasets field is hidden on them. See the note below.
  • Traversal preview refreshes when a bridge dataset bound to another property, or its connection, is edited or disabled.
  • Request locations are kept when location fields use custom keys, and the Privacy Center shows the server's validation details when a submission is refused.
  • Duplicate privacy requests show their identity verification labels.
  • Manual task assignment honors Advanced RBAC permissions, and manual task field type help matches the selected request type.
  • Access approval and manual task completion logs name the right user.
  • Viewers no longer see write controls on DSR policies, and reading the default DSR policies needs policy:read instead of config:read.
  • Denial and deadline extension emails no longer add extra punctuation after the reason.
  • Privacy Center settings and form builder fields have accessible names.

Consent Management

Consent management and enforcement across web, mobile, and server-side surfaces

• GPP: No Section For States Without A Privacy Law, Server Side: When the 3.1 setting that sends no GPP section to visitors in U.S. states without a privacy law is on, the precomputed accept-all and reject-all strings in the experience metadata also leave the section out, matching FidesJS.
• TCF Vendor Translations Stay Current: Global Vendor List translations now refresh automatically, and the supported locales that had gone missing are restored.
• Janus Mobile SDK: This release ships alongside Janus iOS SDK 1.2.1 and Flutter SDK 0.4.1, which fix the iOS banner leaving the app usable above it, and the Janus React Native SDK, which can show web pages with the app's consent through useJanusWebView and Janus.webViewConsent. useJanusWebView needs react-native-webview 13.13.1 or later. See the Janus SDK 1.2 and Janus SDK 1.3 release notes for details.
• Bug Fixes:
  • Consent privacy request verification codes are sent again. When disable_consent_identity_verification is false, verification is always required.
  • FidesJS finds the right experience when the GPP extension is forced on, and GPP reports ready when consent is seeded through a TC string override.
  • Creating a custom TCF vendor offers legal basis selection again.
  • Publisher restriction Edit links no longer open an undefined or previously selected configuration while the selected TCF configuration loads.
  • Consent report dates and filters are kept when switching tabs, and consent settings no longer load with Save enabled before any edits.
  • TCF version history needs privacy-experience:read instead of privacy_experience_cache:read.

Assessments

AI-assisted privacy assessments

• Review And Approval Workflow (Alpha): Behind the alphaAssessmentsV2 flag, assessments go through a reviewer chain set on their plan.
  • Each assessment gets its own reviewers, copied from the plan's review chain. Reviewers submit, approve and withdraw approvals from the review rail on the assessment page, which shows whose turn it is and what the assessment is waiting on. Once every reviewer approves, the assessment is locked against edits.
  • An approved assessment can be reopened, which unlocks it and flags every approval for re-affirming. A reviewer can be swapped for another person who may review in that organization.
  • When a newer version is published, or a disputed answer is settled, approvals given before it are flagged until the reviewer re-affirms them.
  • When respondents' answers conflict, the finding stays open for a reviewer, citing every answer, and a reviewer can settle it by picking one. The pick is recorded as a human-confirmed answer for every assessment of the same subject and written to the assessment's history.
  • A new privacy_assessment:review scope, held by Owner and Contributor, governs who can review and send an assessment back. A new permission for answering assessment interviews lets a role answer without editing assessments. See the note below. Includes database migrations.
• Assessment Detail In The Astralis App (Alpha): An assessment page shows its evidence and risks, with tabs for the other assessments of the same subject.
  • Evidence cards show a source excerpt and where it came from.
  • Statement prose can be edited in place.
  • Risks can be added, edited, dismissed and restored, and carry likelihood and impact ratings.
  • Evidence uploads must pass a malware scan, and evidence can no longer be added or deleted once the assessment is approved. Includes database migrations.
• Assessment Plan Settings (Alpha): Plan leads can now edit a plan's settings, sections and topics from the plan page.
  • Settings: Plan leads set the reviewer chain and its order, the timeframe (from its sentence) and whether data subjects are consulted. A plan cannot be published until it has the settings its requirements demand, and a refused publish lists what is missing. A generated plan stays a draft until a person completes and publishes it. Settings freeze when the plan is published and carry onto its next version.
  • Content: Section paragraphs and instructions can be edited inline, with history, and topics can be edited, reordered (with a keyboard-friendly handle), removed and added. A criterion's wording can be changed on a draft, with the original shown beside it.
  • Applicability: A plan records which criteria decide whether an assessment applies, as coverage, threshold or exemption rules. When a purpose's answers show a published plan applies, a draft assessment opens automatically, and each decision is recorded in the audit log. Open assessments of a subject are re-checked when answers change.
  • History: The plan page lists the assessments run under it with the plan version each one uses, and earlier plan versions can be viewed read-only.
• Assessments List And Deadlines (Alpha): An assessment's deadlines now come from its plan's timeframe. The assessments list shows each assessment's due date, whether it is overdue, who it is waiting on and the plan version it uses. It sorts overdue and soonest-due first and filters by overdue, plan, location and Needs my action. An assessment's output reports a requirement as unmet when the plan's re-evaluation cadence is longer than the law allows. The assessments list and plans moved to cleaner URLs.
• Assess Processing Activities (Alpha): With the alphaProcessOntology flag on, a processing activity can be the subject of an assessment, pinned to the version being assessed.
  • Answers are prefilled from the activity's data categories, data subjects, legal bases and the systems that performed it at that version.
  • Assessments of an activity go to its stewards, and its editor lists them. A proposed activity can be approved once every assessment of it is approved.
  • An assessment can be started from a process, and what its assessments captured is written back to the process, including per-system retention. Includes database migrations.
• Organization-Aware Assessments (Alpha): An organization is offered the templates made for its country, and the systems of it and the organizations beneath it. An assessment can start with the organization's suggestions filled in, and plans can be copied down to other organizations and re-synced. Organizations can now record their locations. See Multi-Organization Scoping under Core.
• Interviews In Slack (Alpha): Assessment interviews reach each participant in a private Slack direct message, and their replies go back to the interview.
  • Each person has their own conversation, and answers are shared across the subject. Answers are kept in the respondent's own words, and values given with doubt or details the respondent does not know are flagged for the reviewer.
  • A screening interview opens on the first thing it still needs. New screening questions about where data subjects are, what data and processing an activity involves, and organization-wide facts let more criteria be decided automatically.
  • Answers that are only worded differently are no longer treated as conflicting. A conflict now needs one respondent to reject or correct another's answer. Answers that name several items keep every item, and CCPA assessments ask their own questions.
  • Participants are told when a message fails or the interview is done, failed posts are retried, and direct messages after the interview is done no longer go to it.
  • Stewards can be mentioned by matching them to Slack or Microsoft Teams users by email. Includes database migrations.
• Import Historic Assessments (Alpha): Template uploads accept several assessment types with their section and question order, and turn screening questions into plan criteria. Historic screening imports link to the completed assessments they produced. Imported assessments show their headings, source answers and original document, with an As recorded tag after each imported answer. Includes database migrations.
• Choose The Assessment Model: The models Assessments v2 uses are configurable, including models on AWS Bedrock.
• Bug Fixes:
  • Purpose screening and interviews work before an assessment exists.
  • Risks are drafted only once the requirements are complete, and an assessment draft still finishes when a proposed risk can't be tied to a finding. The assessment detail shows how many were dropped.
  • Transfer destinations accept common region names and ISO codes.
  • The same legal bases listed in a different order no longer count as a conflict.
  • The DPO advice topic is removed. The DPO contact on record now counts as evidence for who reviews and approves.

PBAC

Access policies and purpose-based access control

• Bug Fixes:
  • Access evaluation no longer treats a CTE named after a registered table as that table, and the BigQuery cached-query fallback no longer skips a table that shares a CTE's name.
  • MCP gateway deny rules match on HTTP method as well as path, so a method later added to a denied route stays denied.
  • The MCP gateway's native BigQuery tools read a managed connection's credentials through its secrets manager.

Integrations

• Manage Secrets Managers From Settings: A new Secrets managers settings page, in both the Astralis app and the Admin UI, lists the AWS Secrets Manager and HashiCorp Vault managers Astralis can read integration credentials from. See Secrets managers.
  • Administrators can add, edit, verify and delete managers, and rotate an AWS external ID. Each manager's health names its cause, and a secret read and a reachability check each keep their own result, so one passing no longer hides the other failing.
  • Each manager's integration count links to the integrations list, filtered to that manager. A manager cannot be deleted while integrations still read from it, and deleting asks for its name.
  • GET /api/v1/plus/secrets-manager is now paginated. See the note below.
• Integration Credentials Panel: When a secrets manager is configured, an integration's credentials are managed in a panel that switches between credentials entered in Astralis and a reference into a secrets manager, and checks the reference before saving. A saved secret reads Set · never displayed with a Replace action, and only a value typed into Replace is sent. An optional saved secret can be cleared. With no secrets manager configured, the integration form is unchanged.
• Safer Secrets Manager Credentials:
  • A connection type's eligibility can be narrowed with FIDESPLUS__SECRETS_MANAGER__ELIGIBLE_CONNECTION_TYPES. Unset, every type stays eligible, and [] turns the feature off. DataHub connections can no longer read credentials from a secrets manager. See the note below.
  • Only the keys a connection type asks for are read from the secret, a payload missing a required key is refused, and operator configuration stored with DataHub, website, DROP and Jira ticket connections is kept when the connection is linked to or unlinked from a manager.
  • Secret payloads are limited to 64 KiB by default, configurable per provider.
  • The AWS reachability check assumes the role afresh each time, so a revoked trust policy fails the check. A failure of the deployment's own AWS identity is reported as a deployment error, not as the manager's health.
  • Vault managers tell a rejected AppRole login apart from a read denied by policy, Vault connection tests no longer pass on a redirect or HTML answer, and IPv6 literal Vault addresses are refused.
  • The database refuses to delete a manager that any connection still references, and a manager create, edit or delete commits together with its audit record. Includes a database migration.
  • New fides.secrets_manager.* metrics report fetches, stale serves, failures, retries and cache age.
• Shopify Erasures Wait For Confirmation: Shopify customer erasures now wait for Shopify to confirm the deletion, or for eleven days, before completing. Masking request overrides support asynchronous polling.
• Bug Fixes:
  • Authorizing an OAuth integration from the Astralis app returns to the Astralis integration or system page, including after signing in again, instead of the Admin UI or a "Page not found" page.
  • A Jira ticket integration linked directly to a secrets manager can be switched back to manual credentials.
  • Dataset reachability no longer fails with a 500 when a SaaS connection has no stored secrets. The affected dataset is reported as unreachable.
  • A dataset configuration write that reuses a key already held on another connection no longer leaves an orphan dataset behind, and the error no longer names the connection or organization that owns the key.
• Security:
  • Jira credential linking is restricted to a source in the ticket connection's organization or the shared tier. See the note below.
  • OAuth secrets, tokens and secrets manager hosts are kept out of SaaS connector request logs, and values read from a secrets manager are kept out of Salesforce, S3, Okta and Entra monitor logs.
  • The data subject email and phone in the Jira ticket preview are masked unless the caller holds privacy-request:read.

Core

• Advanced RBAC On By Default: Database-driven roles and permissions are now on by default. On the first boot after upgrading, a one-time task aligns RBAC grants with users' existing roles, and deployments already on Advanced RBAC are detected and skipped. Set FIDESPLUS__RBAC__ENABLED=false to keep the legacy roles. See Advanced RBAC and the note below.
  • Invited users get their permissions under Advanced RBAC, and existing users who held a legacy role but no RBAC grant are healed.
  • RBAC activation fails loudly when its configuration cannot load, instead of guessing.
• SSO Account Linking: SSO logins now match users by the identity provider's stable subject identifier instead of the email address, which can change.
  • An SSO login can no longer take over an existing password-login account with the same email. Users link those accounts from their profile.
  • User management shows which users are linked to SSO, with link history and an unlink action. Unlinking is gated like a forced password reset and signs the user out everywhere.
  • Disabled users can no longer sign in over SSO. Links reset when a provider's identity settings change, and a provider can be limited to chosen email domains.
  • Linking, unlinking and refused claims are audited. See SSO authentication and the note below. Includes a database migration.
• Multi-Organization Scoping: Still inert for deployments not running Advanced RBAC with the alphaMultiOrgManagement feature flag.
  • Connections, datasets and the dataset configurations under a connection are scoped to the organizations a user can access. Datasets in the default organization stay readable from every organization. New connections and datasets belong to the caller's active organization. See the note below.
  • Selecting an organization narrows list views to that organization and the ones beneath it, without affecting records the user is granted elsewhere. The Astralis profile menu has an active organization picker, and switching organizations no longer collapses the account menu or blanks the app.
  • Organizations can record one or more locations, inherited from the nearest ancestor that has any. Locations are descriptive and have no effect on access.
  • Inviting a user on a tenant that requires organization scoping now requires an organization and role, and adding an organization-scoped grant offers to remove the user's global grant. Grant source tags carry an icon to tell global and direct grants apart.
  • Creating a system or policy document with an explicit default organization keeps it there. The default organization has its key on fresh installs.
• Astralis App Updates:
  • The side rail and context panel are replaced by one navigation rail. The rail stays open after a top-level click, closes shortly after a sub-page click, and reopens on hover after an unsaved-changes prompt.
  • Pages are shown according to feature flags, roles and the consent module, the same as the Admin UI. Navigation hides what a user cannot open, and a direct link to a hidden page shows the 404 page.
  • Ask Astralis from anywhere: selecting text in the Home briefing, or clicking a score tag, offers Ask Astralis and sends the quote or tag to the chat as context.
  • The command palette shows recent pages and Ask Astralis suggestions in two short sections.
  • Drawers float over the page with a fixed header and footer.
  • Fixes for dimmed secondary text in dark mode, unreadable labels on link buttons, frosted glass on chart hover cards and the chat dock, menu link weights, icon tag spacing, and forbidden configuration requests on page loads for limited users. Saving locations or regulations in settings refreshes the other section.
• Taxonomy:
  • Taxonomy element keys are unique within their taxonomy rather than across all taxonomies, so two taxonomies can both use a key such as high or low. Includes a database migration.
  • Taxonomy elements used by managed relationships can no longer be deleted or renamed, and default elements can no longer be deleted through the taxonomies API. See the note below.
  • fides push and fides annotate dataset keep custom taxonomy keys on dataset manifests instead of dropping them, and the dataset error for unrecognized custom taxonomy keys is capped in length.
  • Fixed a custom taxonomy's edit drawer showing the old description right after saving, the taxonomy menu covering the tree's root node, and allow lists left behind after a custom field is deleted.
• Telemetry Improvements: New metrics cover Celery queue depth and publishes, Temporal task queue backlog, and cache memory, evictions and rejected writes. The worker and queue health endpoints also report the DataHub, DROP and consent metrics queues. LLM call logs and metrics carry a use case, area and operation.
• Safer Database Upgrades: Every migration lock wait is bounded, and a migration that hits lock contention is retried. The 3.2 migrations take their strong locks first, run backfills after the upgrade, and build indexes on existing tables in the post-upgrade index task. Sessions blocking a migration are logged.
• Bug Fixes:
  • Privacy assessment and policy generation LLM calls time out after five minutes per attempt instead of ten.
  • The ClamAV scanner clears leftover work directories on start, so they no longer fill its volume and stop signature updates.
• Security:
  • Fixed findings from new blocking security scans across storage, OAuth and logging.
  • Updated grpcio and grpcio-status to 1.85.0, which removes the Comodo AAA Services and emSign ECC Root CA G3 roots from the bundled root store.

Database schema & data changes

• This release includes database migrations for policy versions, identity document verification, assessment reviewers, revisions and approvals, assessment plan settings and criteria wording, applicability rules, assessment stage timing, risk ratings, evidence source locations, interview conversations and Slack delivery, historic assessment imports, processing activities and their version history, ontology relationship definitions and relationships, the seven managed taxonomies, system-to-process links, organization locations, the assessment review and interview answer permissions, process scopes, SSO subject bindings, secrets manager health and reference constraints, taxonomy element keys unique per taxonomy, the default organization key, audit log values for access package reads, and denial email punctuation.
• Taxonomy element keys move from unique across all taxonomies to unique within each taxonomy.
• Consent-only DSR policies have any identity verification override cleared, since earlier releases ignored it.
• Every migration lock wait is bounded. If a migration cannot get its locks in time, the upgrade stops, only that migration rolls back, and rerunning the upgrade resumes from it.

Notes

• Advanced RBAC is on by default. On the first boot after upgrading, a one-time task aligns RBAC grants with legacy roles. Set FIDESPLUS__RBAC__ENABLED=false to keep the legacy roles. Turning RBAC off falls back to legacy roles without organization scoping, and changes made while it is off (new users, role changes) are not carried over when it is turned back on. If you run fides db upgrade out of band and are already on Advanced RBAC, mark the reconcile as done before upgrading so it is skipped: INSERT INTO post_upgrade_background_migration_tasks (key, task_type, completed_at) VALUES ('rbac_legacy_activation_reconcile', 'rbac', now()) ON CONFLICT (task_type, key) DO NOTHING;
• SSO logins match by subject, not email. A user with a password-login account must link it to SSO from their profile before signing in with SSO. Disabled users can no longer sign in over SSO.
• GET /api/v1/plus/secrets-manager is paginated. It takes page and size and returns a page envelope (items, total, page, size, pages) instead of a bare array.
• DataHub connections can no longer read credentials from a secrets manager. Enter DataHub credentials in Astralis.
• Existing Jira links to a source in another organization stop working. Relink them to a source in the ticket connection's organization or the shared tier. credential_source_key is read-only through the secrets endpoints. Use /api/v1/plus/connection/{connection_key}/jira/link-saas-credentials to link or unlink.
• Privacy requests that reach S3, Entra, Okta or RDS MySQL datasets now error. These integrations cannot run privacy requests. Unlink their datasets or disable the integration, and linking new datasets to them is refused.
• Policy rules and webhooks are read from the policy's published version. Rule and webhook keys only need to be unique within a policy version.
• Assessment answer and review permissions are split. Custom roles with only read access to assessments no longer answer assessment interviews unless an admin grants the new answer permission. Sending an assessment back needs privacy_assessment:review. Built-in roles keep what they could do, and Contributors can now read assessments.
• Taxonomy elements used by managed relationships are protected. They can no longer be deleted or renamed, and default elements cannot be deleted through the taxonomies API.
• Multi-organization dataset writes keep their organization. On the dataset PATCH routes, omitting organization_fides_key keeps the dataset's existing organization instead of resetting it to the default, and new datasets belong to the caller's active organization (X-Fides-Organization).
• The Janus React Native SDK needs react-native-webview 13.13.1 or later for useJanusWebView.