Health Cloud Discovery: Define One Workflow Before the Data Model

Topic inspiration: Salesforce Ben’s coverage of Health Cloud and specialist skills, published 28 October 2026. The practical framework below is original iTeknologies editorial analysis.

A Health Cloud discussion can expand quickly from one workflow into a long list of data sources, objects and possible automations. Keep discovery grounded by defining the first operational result the team needs.

Use a narrow administrative example: a coordinator receives an outreach request, checks the correct person has been identified, records who owns the work and logs the contact outcome. Clinical decisions and treatment recommendations are outside this example.

Describe the handoff in ordinary language

Start with the person performing the work. What arrives, where does it come from and what must the coordinator know before taking the next step? Ask what happens today when information is missing or contradictory.

Write the beginning and end of the workflow. In this fictional case, the beginning is an authorized outreach request. The end is a recorded contact outcome or an explicit handoff to someone who can resolve a problem.

A useful discovery session produces a sequence people recognize. Avoid selecting objects simply because their names resemble words used in the process. Confirm the meaning of each business term first.

Separate program concepts from clinical records

Salesforce’s Care Program data-model guidance distinguishes a care program from a care plan. It describes program participation and related activities. That distinction is a reason to clarify whether the workflow concerns membership in a program, an individual care plan or another administrative process.

For the outreach example, ask whether the request concerns an existing participant, a prospective participant or an unrelated follow-up. Decide which identifier connects the request to the person and who resolves an uncertain match.

Keep those questions in the discovery record even when the initial screen appears simple. An ambiguous relationship in the underlying data can make the resulting queue difficult to trust.

Map the minimum information the workflow needs

Create a field-level worksheet for the first workflow. Include the business meaning, source system, authoritative owner, destination, update direction and expected freshness of each value.

For example, a coordinator may need an outreach reference, a verified person identifier, the assigned owner and an approved contact outcome. Establish why each value is needed. Do not bring an entire source record into the workflow by default.

Salesforce’s clinical data-model documentation describes alignment with FHIR R4 while noting that the model does not include every attribute of every FHIR resource. Treat standards alignment as a starting point for mapping and validation, not proof that any source payload can be loaded unchanged.

Confirm the actual fields, relationships and supported integration approach for the selected product configuration. Where the source has information that does not fit the intended model, record the decision instead of silently dropping or repurposing it.

Define access and conflicting updates before automation

List the people and system identities that need to see or change each part of the workflow. Bring the organization’s privacy, security and operational owners into decisions about sensitive information, permitted use and retention.

For each shared field, specify which system may change it. If the coordinator and source system both update an outcome, decide whether one is authoritative or whether the conflict requires review.

Document the response to an uncertain identity. The process should make that state visible and assign responsibility for resolving it. The illustrative workflow does not automatically combine records or choose between conflicting person identifiers.

Also identify product access, integration dependencies and any licensing questions before committing to a build. A discovery plan should expose those dependencies; it should not assume that every feature is included in the existing contract.

Use exceptions to define the first acceptance test

Test the proposed workflow with synthetic or otherwise approved data in an appropriate environment. Include cases that challenge the handoff:

• A complete request reaches the correct coordinator.
• An uncertain person match is held for review.
• A missing contact detail produces the agreed next action.
• A source update arrives after the coordinator has changed the record.
• A user without the required access cannot view restricted information.
• A failed integration leaves enough information for the responsible team to investigate.

Review the actual record state and the coordinator’s next step after each test. A technically successful transfer is insufficient if the person doing the work cannot tell what to do.

Finish discovery with the workflow map, ownership decisions, unresolved dependencies and acceptance tests. Those artifacts make a focused first implementation easier to assess. For broader Salesforce planning and connection requirements, explore CRM strategy and consulting and integration and automation.