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

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.

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.

#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.

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. 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.