# How to launch a proof of concept for Data Cloud in under 30 days

One object, one match rule, one activation, a named owner, and a kill criterion. Unifying the enterprise is a programme, not a proof.

**Published:** 2026-03-04
**Canonical:** https://synconai.com/data-cloud-proof-of-concept-30-days
**Author:** SynconAI Architecture Team

## In short

A proof in under 30 days is one object, one match rule, one activation, a named owner, and a kill criterion. Identity resolution builds a unified profile from that source data in Data 360. It will not tidy the enterprise. Data Cloud was rebranded on 14 October 2025. The behaviour is unchanged. If the scope is every object, you are running a programme. Cut it before you start the clock.

## Sources

- **About Identity Resolution** (retrieved 2026-10-10)
  https://help.salesforce.com/s/articleView?id=data.c360_a_identity_resolution.htm&type=5
  > Identity resolution is the processing engine that generates unified profiles from source profile data stored in Data 360.
- **About Salesforce Data 360** (retrieved 2025-10-14)
  https://help.salesforce.com/s/articleView?id=data.c360_a_data_cloud.htm&type=5
  > As of October 14, 2025, Data Cloud has been rebranded to Data 360. During this transition, you may see references to Data Cloud in our application and documentation. While the name is new, the functionality and content remains unchanged.

## What to take away

- One source object, one match rule, one activation. Write them on a single page.
- Name an owner who can stop the proof, and a kill criterion you defined on day one.
- Identity resolution profiles that one object. It does not deduplicate the CRM.
- A 30-day attempt to unify the enterprise is a programme. Do not call it a proof.

## The guide


Teams ask for a proof in thirty days and then list every object in the CRM. Contacts, accounts, orders, cases, campaigns, three external files, and "the identity model." The calendar did not grow to fit the list. Fifty objects is a programme: mapping, consent, match-rule arguments, and a bill. Call it a programme and staff it. Do not call it a proof. The proof exists to answer one question you wrote before the kickoff. If the question does not fit in two sentences, you are not ready to start the clock.

## The costume problem

The product is Data 360. Salesforce rebranded Data Cloud on 14 October 2025. The behaviour is unchanged. You may still see the old name in the application and in the documentation. "While the name is new, the functionality and content remains unchanged." The rename did not add days to the month, and it did not make unification a cleanser.

Identity resolution will build unified profiles from the source profiles you store. It will do that for one object as honestly as for fifty. Unified profiles are keys. They are not a golden record. The engine does not pick a winning value and does not override source values. A proof that sets out to "deduplicate the CRM" has misunderstood the month. Deduplicating the CRM is a survivor rule in the CRM. The proof can show you that the profile points at the right source rows, or that the key is too dirty to use. Both are results. Neither is a merged golden person.

Example shape of the question, not a promise of outcome: can we relate this person object on this key, and activate this segment to this one destination, under this consent rule, without a surprise in the meter we cannot name. Fit it in two sentences. Pin it to the kickoff note. Every later request is judged against those sentences. If it does not serve them, it is out, even when it is interesting. Interesting is how the costume gets a budget.

## The five lines

Object. One source you can extract without a heroic integration. If the extract takes two weeks, it is the wrong object for a thirty-day proof. Pick the object that already leaves the CRM on a path someone understands. Heroics belong in a programme, where they can slip without lying about the date.

Match rule. One rule, on keys you have already counted for blanks. Identity resolution does not invent a better key halfway through week three. If the key is dirty, the finding of the proof is that the key is dirty. That is a successful proof. It is a reason to stop and fix the source, not a reason to add three more rules "to see if one of them works." Three rules is three arguments, and you will not know which one produced the sample. The counts to run before you trust the key are [the audit before you ingest](/audit-data-quality-before-data-cloud-migration).

Activation. One destination, or one CRM surface. Not both, and not four. Consent on the same rows. A proof with four destinations teaches you nothing about four destinations and misses the date. Confirm the destination exists in the org, with an admin who can see it. Do not invent a connector name to make the plan look specific. A destination you cannot open is a kill, not a stretch goal.

Owner. One person who can refuse scope. Not a committee. The owner reads the meter and the sample. If the owner is in meetings for the whole month, you do not have an owner. Name someone who can stop the work on a Tuesday.

Kill criterion. Written on day one, in counts or in facts, not in moods. Examples: match key blank above a count you set before you look at the data, consent missing on the rows you meant to send, the owner unavailable, the destination not actually available in the org. When the criterion hits, you stop. A proof that cannot die will consume the month and demand a phase two. Phase two of a proof that never answered its question is a programme wearing a costume.

## What you do in the month

Week one is the extract, the key count, and the consent count. Blanks. Conflicts. Rows that are not a person. If those counts fail the kill criterion, stop. You have learned the only thing that mattered, and you have learned it while the rest of the estate is still unconnected. Write the finding in a paragraph. Do not soften it into "we need more time to load the other objects." The other objects were never in the question.

Week two is the model for that object only, and the single match rule. Read a sample of profiles with the owner. You are checking that the profile points at the right source rows. You are not checking a golden record. The engine does not produce one. If a shared inbox or a switchboard number glued unrelated people together, the rule is wrong. Narrow it or stop. Do not add a post-step that overwrites the losers. There is no such step, and building one inside the proof is how the month becomes a CRM project.

Week three is the activation on the rows the consent rule allows, and a written note of who was refused. Blanks are refusals. Conflicts are refusals until a person resolves them. The stricter flag stands in the meantime. Record how many you offered, how many the destination accepted if a destination returns that fact, and how many you refused. Do not put a match rate you hoped for into the note. If the destination returns a figure, it is a result, not a commitment Data 360 made. This page will not invent one.

Week four is the readout. What unified. What you refused. What the meter did, in the sense of which meter moved, not a price. Whether the two-sentence question is answered. Then stop. Do not slide into "while we are here." While we are here is the sentence that adds the second object, the second ruleset, and the workbook.

## What you leave out on purpose

Other objects. Historical campaigns. A second identity ruleset. A BI rebuild. An agent. Any of those can be the next proof, with its own thirty days and its own kill line, after this one has a written result. Stacking them into the first month is how the costume gets a budget and the question goes unanswered.

Leave out any success metric you cannot measure inside the month. Revenue influence is not a thirty-day fact. A match-rate promise is not a thirty-day fact. The facts you can have are the profiles built, the sample review, the activation refusals, and the owner's decision to proceed or to kill. Those four are enough to decide whether a programme is justified. They are not enough to justify the programme by themselves. The programme still has to be staffed as a programme.

Zero copy is federation, not a latency promise, and it is a poor way to rescue a proof that is late. Connecting an external store with zero copy data federation, in week three, because the extract was hard, adds a pattern you have not measured. If the object does not extract cleanly, that is a finding. Federating around it does not answer the two-sentence question. It replaces the question. Park federation for a later proof whose question is the federation.

Tableau Next does not replace Tableau. A new chart is not one of the five lines. If someone cannot see the sample without a workbook, use the tool they already have, or read the rows in a list. Do not spend the month standing up a surface. The help page says you can expand Data 360 using Tableau or Tableau Next. Expansion is a later decision. The proof is whether one object, one rule, and one activation hold.

::: note
A dirty key is a successful proof if you stop. The month was spent to learn whether the question could be answered. "The key is blank on the rows that matter, so we do not activate" is an answer. Extending the scope to avoid writing that sentence is a new project.
:::

## What the readout is not allowed to say

The readout refuses three sentences, even when the month felt busy.

It refuses "the platform works." Of course a connector can land a row. That was never the question. Say whether this object, on this key, produced profiles the owner recognised in the sample.

It refuses a match rate, a revenue influence, or a peer comparison. None of those were measured, and this page will not supply them. If a destination returned an acceptance count, report that count as a result for this send only. Do not generalise it into a property of Data 360.

It refuses "phase two will tidy identity." Phase two can be a programme, with the pre-ingestion decisions staffed. It cannot be a promise that the engine will start overriding source values if you give it more objects. It will not. More objects are more keys. Dirty keys at larger volume are a larger finding, not a smaller one.

Write those refusals at the top of the readout, before the findings. A sponsor who only reads the first paragraph should still see what was not proved.

## The kill, practised before you need it

Read the kill criterion aloud on day one, with the sponsor in the room. Ask them to say what they will do when it hits. If the answer is "we will re-scope and keep going," you do not have a kill criterion. You have a wish. Rewrite it until stopping is a result the sponsor will accept in writing. The writing can be three lines. It has to be specific enough that a tired owner can apply it without a meeting.

| Line | In the proof | Out of the proof | Kill if |
| --- | --- | --- | --- |
| Object | One extract you already understand | Every CRM object, every file | The extract is a project of its own |
| Match rule | One rule, on keys you counted | A stack of fuzzy rules | Blanks or false links break the bar you set |
| Activation | One destination or one CRM surface | A tour of channels | The destination is not actually available |
| Owner | One person who can refuse scope | A committee | That person cannot read the sample |
| Question | Two sentences, fixed at kickoff | Revenue, parity, a platform decision | The work no longer serves those sentences |

The fifth row is the one that saves the month. Work that does not serve the question is not a small addition. It is a different proof, and it does not get to share the clock.

When you stop, write one page. The question. The counts. The sample, in prose, including the row that was wrong. The meter that moved. The decision: proceed to a programme, fix the source and run a second proof, or do not proceed. A steering pack that says "the proof was successful" without that page is the costume again. Success is a question answered, including answered in the negative.

The decisions a programme would then owe, if you proceed, are the ones that were deliberately out of scope here. What unified means for each use case, how strict the match stays, which attribute wins, whether each further object is copied or referenced, and who owns the ruleset. They are set out in [getting Data 360 right the first time](/insights/data-360-implementation-best-practices). The proof did not make those decisions. It told you whether you have a source clean enough to start them. That is the whole month, and it is enough.


## Questions

### What fits in a 30-day Data 360 proof?

One object, one match rule, one activation, a named owner, and a kill criterion set on day one. Anything wider is a programme. The question has to fit in two sentences before you start the clock. If the extract itself takes two weeks, it is the wrong object for this month.

### What does identity resolution prove in that month?

That it can build unified profiles from the source profiles you stored for that object. It does not cleanse the CRM or pick winning values. The profiles are keys, not a golden record, and the engine does not override source data. A dirty key is a successful finding if you stop. It is not a reason to add more rules in week three.

### When should we stop?

When the kill criterion hits: dirty keys, missing consent, no owner, or no real destination. Stopping is a result. Extending the scope is a new project. Write the criterion on day one in counts the sponsor has already accepted. If the response to a hit is to re-scope and continue, you do not have a kill line yet.

### Should the proof include every source we will ever need?

No. A second object is a later proof. The first month answers one question. Write that question in two sentences before you start. Historical campaigns, a second ruleset, a chart rebuild, and an agent can each be a later month. Stacking them into this one is how the date slips and the question goes unanswered.

### Is the product still called Data Cloud?

The name is Data 360 as of 14 October 2025. Behaviour is unchanged. The proof is the same work under the current name. You may still see Data Cloud in the application and the documentation. The rename did not add days to the month, and it did not turn identity resolution into a deduplication tool.

---

SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Data 360 (https://synconai.com/salesforce-data-360-services.html).