A customer opens your Salesforce portal to check a claim, coverage detail, care program, grant application, or service request. The page loads, but a key FlexCard is empty.

Your internal user can see the data. The card works in an admin preview. The underlying records still exist. That combination can send a team toward caching, deployment, or data-quality investigations when the actual cause is a new external-user query gate.

In the week of October 12, 2026, Salesforce added a Winter ’27 release note for an OmniStudio FlexCard datasource object allowlist. For the affected Experience Cloud and OmniStudio configuration, enforcement is on by default. Guest users and authenticated community or portal users can query only the objects explicitly included in the allowlist. If a required object is missing, the FlexCard can return empty results. Internal users are not affected.

The wrong response is to disable the protection or add a broad list of objects until the card reappears. The better response is to identify each card’s true data dependency, restore only intended access, and validate the complete external journey as the real user.

First, confirm that the change applies to your implementation

Do not treat every blank Experience Cloud component as the same problem.

Salesforce’s Winter ’27 release note scopes this change to Experience Cloud Aura sites accessed through Lightning Experience in supported editions with OmniStudio for Managed Packages. Salesforce’s detailed setup document describes configuration paths for different OmniStudio and data-model arrangements. Because estates can include migrated Vlocity components, standard runtime, managed packages, and multiple sites, record the actual runtime and component path before applying a fix.

For each affected journey, confirm:

  • the site type and runtime;
  • whether the user is unauthenticated, an authenticated customer, a partner, or an employee;
  • the FlexCard name and active version;
  • its datasource type and every object referenced by the query;
  • whether parent, child, or relationship fields introduce additional object dependencies;
  • whether the same result occurs in a representative sandbox and production;
  • whether internal users still see data.

That final comparison matters. An admin-only test can produce a false sense of health because Salesforce says internal users are not affected by this allowlist.

Understand the four gates behind a visible FlexCard

The new allowlist is only one part of effective access. Treat FlexCard visibility as the result of four separate questions.

Can the user reach the component?

The page, component, active FlexCard version, and any required custom permission must be available to the external persona. A card that is not rendered is different from a rendered card whose datasource returns nothing.

Is the datasource type and execution path permitted?

OmniStudio can use SOQL, SOSL, Data Mappers, Integration Procedures, Apex, REST, and other datasource patterns. Each introduces its own execution context and permission checks. Trace the real runtime path rather than assuming the visual component tells the whole story.

Is every queried object on the new allowlist?

Salesforce’s setup guidance says to include every object referenced by the card, including objects reached through relationship fields. If even one referenced object is absent, the query can return no results.

This is why adding only the obvious primary object may not work. A card displaying a claim might query a member, policy, provider, or related service request. A grant card might traverse an application, applicant organization, review, or funding program. Build the list from the executed query and dependency path, not from the card label.

Does the user still have legitimate data access?

An allowlist entry does not grant broad access. Salesforce states that an external user can query allowlisted objects only within the limits of the user’s object and field permissions. Record sharing and the security behavior of the execution path still matter.

That layering is important. The allowlist should define which objects the FlexCard query mechanism may reach. The permission model should still define what each persona may read or change. Neither control should be used as a shortcut for the other.

A seven-step remediation plan

Step 1: Inventory external FlexCards by business outcome

Start with customer journeys, not a metadata dump. Rank cards by the consequence of missing or incorrect data:

  • claim or policy status;
  • appointment or care-program information;
  • provider or member service details;
  • grant application status and outstanding actions;
  • billing, eligibility, or coverage information;
  • case status, required documents, or next steps.

For each card, name a business owner and a technical owner. This keeps a successful page render from being mistaken for a successful customer outcome.

Step 2: Map the complete datasource dependency

Capture the primary object, every related object, datasource type, filters, integration procedures, data mappers, remote actions, and downstream systems. Where a FlexCard nests another card or launches an OmniScript, follow that path too.

Use evidence from the active component and runtime request. Stale design documents are useful clues, but they do not prove what the current version executes.

Step 3: Reproduce the problem as each external persona

Test at least:

  • an unauthenticated guest, when the site supports public access;
  • a correctly provisioned authenticated customer or member;
  • a user who should see a narrower subset of records;
  • a user who should not see the data;
  • an internal service or operations user.

Record whether the component fails to render, renders with an explicit error, or renders with empty data. Those are different diagnostic branches.

Step 4: Configure the minimum required object list

Keep `EnforceCardDatasourceSecurity` enabled. Salesforce explicitly warns against disabling it.

Populate `OmniStudioGuestAllowedObjects` through the configuration path appropriate to the org’s OmniStudio model. Add the API names of the objects genuinely required by the external FlexCard queries, including relationship objects. Do not copy a generic list across orgs or add all Industry Cloud objects as a precaution.

Salesforce also identifies security and metadata objects that remain blocked and cannot be allowlisted. If a design depends on one of those objects, redesign the data path rather than trying to work around the block.

Step 5: Revalidate permissions and data minimization

For each external persona, review:

  • object-level read or write access;
  • field-level security;
  • sharing and record visibility;
  • required custom permissions;
  • Apex class access where applicable;
  • guest-user restrictions;
  • encrypted-field behavior;
  • cached data and whether it is isolated appropriately.

Restore the smallest access necessary for the business task. A broad permission grant may make a test pass while creating a more serious problem than the blank card.

Step 6: Test positive, negative, and relationship cases

A useful test suite proves more than “the card has data.” It should confirm that:

  • authorized users see the correct records and fields;
  • unauthorized users see neither the data nor a revealing error;
  • guest and authenticated users behave as designed;
  • records outside the user’s sharing scope remain hidden;
  • cards with relationship queries work only when every justified dependency is included;
  • removing a nonessential object does not break the journey;
  • an intentionally blocked object remains inaccessible;
  • the complete action launched from the card succeeds and reconciles correctly.

Run the tests on a representative mobile viewport as well as desktop if customers use both. A data fix is not complete if the resulting state, error message, or next action is unusable.

Step 7: Operationalize the control

Add the allowlist and FlexCard dependency map to release governance. A new related field, datasource, managed-package update, or component version can introduce another object dependency later.

Monitor for empty-result anomalies and customer contacts after deployment. Retain evidence of the approved object list, test personas, expected negative cases, and business-owner signoff. Reassess the list periodically and remove dependencies that are no longer used.

What this means for healthcare, insurance, and nonprofits

In healthcare, an empty card can interrupt appointment, program, benefits, or service workflows. In insurance, it can obscure policy, quote, claim, coverage, or required-action information. For nonprofit foundations, it can hide application status, reporting obligations, award details, or review tasks.

The operational response should reflect the sensitivity and consequence of the data. That does not mean assuming that every blank card is a reportable incident or a compliance failure. It means involving the appropriate privacy, security, legal, clinical, or regulatory reviewers when the journey handles sensitive data or consequential decisions.

Teams operating in the United States and Europe should also validate that the restored view still follows their approved purpose, data-minimization, retention, and access policies. Platform configuration is only one part of that assessment and does not establish regulatory compliance.

Do not confuse a secure default with a complete security design

Salesforce’s 2025 OmniStudio security work provides useful context. Salesforce documented fixes and guidance concerning field-level security, encrypted data, guest access to Custom Settings, and server-side permission validation. The new object allowlist continues the direction of making external access more explicit.

But no single setting can prove an external portal is secure. FlexCards may sit on top of Data Mappers, Integration Procedures, Apex, external APIs, cached results, and nested components. Each layer needs an identified owner, an understood execution context, and tests that include denied access as well as successful access.

Likewise, a blank card is not automatically evidence of the new allowlist. Missing permissions, sharing, activation, runtime access, Apex access, filters, integration failures, and caching can produce similar symptoms. Diagnose from the actual external request and current component version.

The executive decision: restore the journey and preserve the boundary

The practical goal is not to make every FlexCard display data. It is to make each authorized customer journey reliable while keeping unneeded objects outside the external query boundary.

For leaders, the release gate is straightforward:

  1. Have we identified every affected external journey and its business owner?
  2. Can we explain every object on the allowlist?
  3. Have we tested as real guest and authenticated personas, including users who should be denied?
  4. Have we proved the full workflow, not just the initial card render?
  5. Can we detect and recover from a future dependency change?

If any answer is no, the portal is not ready to close the change.

Yuniq’s Salesforce services focus on adapting Salesforce solutions to business requirements and helping customers evaluate implementation options. For organizations with business-critical Experience Cloud and OmniStudio journeys, the most useful next step is a targeted portal continuity review: inventory the external FlexCards, map their effective access, remediate the allowlist with least privilege, and validate the complete customer workflows before the next release introduces another dependency.