How to build partner deal registration

What matters here

• Check against pipeline in seconds, not days. A partner waiting a week has already had the conversation you are adjudicating.
• Write the conflict rule down before the first dispute. Deciding case by case teaches partners that arguing works.
• Protection is a fixed window, not a permanent claim. Registered and dormant is not the same as working the deal.
• Expire visibly with a warning and an appeal. A silent expiry is discovered when the partner tries to claim the payout.
• Report acceptance rate per partner. A partner whose submissions are mostly rejected does not understand the programme.

Who this is for

You run partner or channel operations. Registrations arrive by email or a form, somebody checks them against the CRM by hand, and conflicts are settled by whoever escalates hardest.

How it works in practice

The path from a partner submitting a deal to knowing whether they have it.

1. 1

   The submission is checked against pipeline immediately

   Existing opportunities, other registrations, and whether the account is already a customer.

2. 2

   The conflict rule decides, not a person

   Written down in advance, applied the same way every time, and visible to partners.

3. 3

   Accepted registrations get a fixed protection window

   Ninety days, extendable once with evidence of activity.

4. 4

   The partner is told within minutes, either way

   A rejection with a reason is workable; silence is not.

5. 5

   Expiry warns before it happens

   With one route to extend, so protection lapsing is a decision rather than a surprise.

6. 6

   Closed deals link back to the registration

   Which is what makes the payout calculable rather than negotiated.

Paste these into Claude Code or Codex with the Tray Headless plugin installed. Each stage runs on its own. The systems named in them are the worked example rather than a requirement, and every prompt says so.

Once per project, run /tray-workflows:set-workspace to pick the workspace these build in. Point it at a sandbox first.

1. 1

   Set up, then write the conflict rule first

   Before any code, because the rule is the programme.

   Headless skills build-workflow

   Copy

   Use build-workflow. The systems in play are Salesforce, or whatever we
   run in those seats.
   
   Before building, write the conflict rule down. My starting position:
   
     An open opportunity created before the registration wins, and the
     registration is rejected with the reason
     An existing customer account is not registrable for the same product
     Two partner registrations: the earlier submission wins outright
     A partner registration on an account with no activity for 90 days is
     accepted even if an opportunity exists, because a dormant deal is not
     a worked deal
   
   Tell me where each of those facts lives in the CRM. The rule has to be
   computable, and if it is not, it will be adjudicated by whoever shouts,
   which is the situation we are replacing.

2. 2

   Check in seconds, not days

   A partner waiting a week has already had the conversation.

   Headless skills build-workflow

   Copy

   Use build-workflow. On submission, check immediately:
   
     Match the company to an account: domain first, then fuzzy name, then
     parent hierarchy, the same way lead-to-account matching works
     Open opportunities on that account, with created date, owner, stage
     and last activity
     Existing registrations from any partner, active or expired
     Whether the account is already a customer for this product
     Whether the named contact already exists and who owns them
   
   Return a decision within minutes. A partner who waits a week for an
   answer has already had the conversation you are adjudicating, and by then
   any decision is retrospective.

3. 3

   Apply the rule the same way every time

   Consistency is the whole value to a partner.

   Copy

   Apply the written rule mechanically and record which clause fired.
   
   Accept, reject with a reason, or send to review where the rule genuinely
   does not cover it. Keep that third category small and treat a growing one
   as a sign the rule needs another clause, not more reviewers.
   
   Tell the partner either way, within minutes, with the reason. A rejection
   a partner can understand is workable. Silence, or a rejection with no
   reason, is how a partner stops registering and starts competing with you
   quietly.
   
   Never let a rejected registration disappear. Keep it, because the same
   account will come back and the history matters.

   Recording which clause fired is what turns a dispute into a two-minute conversation, not a meeting.

4. 4

   Protect for a window, and expire visibly

   Registered and dormant is not the same as working the deal.

   Headless skills tray-gotchas

   Copy

   Use tray-gotchas, then set a fixed protection window of 90 days.
   
   Extend once, on evidence of activity: a logged meeting, a quote, or a
   contact registered. Do not extend on request alone, because indefinite
   protection is a claim on a deal nobody is working.
   
   Warn at 14 days and again at 3 days before expiry, with one route to
   request an extension.
   
   When protection expires, move it to a lapsed state that stays visible in
   history instead of deleting it. A partner discovering expiry when they
   try to claim the payout is a partner you have lost, and the record is
   what makes the conversation survivable.

5. 5

   Link the outcome, and report by partner

   Because the payout has to be calculable instead of negotiated.

   Copy

   When a registered deal closes, link the opportunity back to the
   registration so the payout is derived, not argued.
   
   Then report per partner: submissions, acceptance rate, rejection reasons,
   protection expiring in the next month, registered pipeline, closed
   registered revenue, and average days from registration to close.
   
   Acceptance rate is the number to watch. A partner whose submissions are
   mostly rejected does not understand the programme, and that is a briefing
   problem rather than a partner problem. Left alone it becomes a partner
   who stops submitting.

6. 6

   Check it end to end, then hand the rule to partner ops

   Because the conflict rule will change and it belongs to them.

   Copy

   Run the per-step schema checks and the whole-workflow audit before this
   touches production.
   
   Then open the same workflow in Tray Build so partner operations can amend
   the conflict rule, the protection window and the extension criteria in
   the visual canvas. Publish the rule to partners as well, because a rule
   they cannot read is one they will dispute.

What it connects to

Registrations arrive from outside and have to be checked against everything inside.

Named systems are the ones most teams run, not the only ones that work. Each is an authentication in your Tray workspace, referenced by name, so the workflow never holds a credential. Where we have a connector page, the name links to it.

Questions people ask

Related guides