Prevent Duplicate Work

Guarantee one active instance per human, and decide what happens when the same work arrives twice.

See the situation

Start with the situation below. Next, we will work through an example together before you try the activity.

Samir · Workflow operator

The case

Two records, one person, both eligible

Deduplicate on an explicit verified identity policy. A shared email or second event may need review rather than a merge.

Record A: Lead from the form, created today, three fields populated
Record B: Contact on the existing account, two years of history
Match: Same email address
Both enrolled: Yes, within an hour of each other
What the person sees: Two approaches from one company, saying different things

Your task

Check the identity evidence. Choose which workflow instance stays active and where a later request belongs.

Need a little guidance?

You’re done when: Duplicate delivery produces one business effect and an inspectable receipt.

Duplicate records and duplicate work are different failure modes.

Need a reminder? Reopen the worked example

Watch one example first

Two deliveries with the same verified person ID can represent repeated work for one person. Two names sharing a mailbox do not, by themselves, establish one identity.

Why this follows from the evidence

Deduplication needs a stated identity rule and a separate policy for repeated events. A convenient matching field is not automatically trustworthy identity evidence.

GTM Lab

Saved locally

Workflow Specification · 0 of 8 sections started

Saved locally to your browser.

Case evidence

Two records, one person, both eligible

Record A: Lead from the form, created today, three fields populated
Record B: Contact on the existing account, two years of history
Match: Same email address
Both enrolled: Yes, within an hour of each other
What the person sees: Two approaches from one company, saying different things

Two records, one person, both eligible, both enrolled within an hour. Write the rule that makes that impossible.

Workflow workbench

Resolve identity before collapsing work

Use the stated verified identity rule, choose which active instance survives, and attach a later legitimate event to the existing work.

Identity evidence · matching email is not enough by itselfCompare each statement with its source. The labels show the state of this example.

Lead and account contact

Same account · same verified person ID · matching email

Source: CRM identity review

Not checked

Two people at a shared address

Generic team inbox · different names · no person-level match

Source: Form and account records

Not checked

What establishes that the lead and contact are the same person in this example?

When two verified records have different workflow progress, which instance survives?

A second legitimate event arrives while that person already has an active instance. What happens?

Duplicate arrival · before and afterCompare the original state with the proposed change. This preview does not change live records.

Duplicate arrival · before and after
Item	Before	Proposed	Why
Active workflow count for one verified person	Two records each started a separate instance	Choose the identity and survivor rule	Uniqueness is per verified person, not merely per database row.
Second qualifying event	Could send a second approach	Choose the retrigger behavior	A new event can matter without requiring a second workflow instance.

Active workflow count for one verified person: BeforeTwo records each started a separate instance; ProposedChoose the identity and survivor rule; WhyUniqueness is per verified person, not merely per database row.
Second qualifying event: BeforeCould send a second approach; ProposedChoose the retrigger behavior; WhyA new event can matter without requiring a second workflow instance.

Changes save in this browser as you work.

Inspect the example policy saved by this activity

These are the supplied example-plan entries, not another test. Complete the workbench above to save its result.

What is the workflow unique on?: Use the stated identity policy to connect records. A matching email can be evidence, but is not by itself proof that two records identify the same person.
You find two. Which one survives?: The most-progressed record is the one that knows what has already happened. This is the same reasoning 1b applied to a merge, arriving at the same answer from the other direction.
The same person legitimately triggers again while the first instance is still running.: This example keeps both the new signal and the completed work. Another workflow may choose a different policy if it states what happens to the earlier instance.

Your place saves as you go.

Chapter 7 of 80 complete