Detect first. Disclose only what is permitted.
Vinculo does not need broad access to a partner's customer base. The relationship governs both what may be disclosed and whether Vinculo may act automatically, must request approval or consent, or can only prepare a human action.
- which signals are eligible
- which accounts qualify
- what use is permitted
- what information may move
- what may execute automatically and who must approve or consent
- what action may occur
- when the permission expires
Identity and commercial disclosure move only as far as the relationship rules allow. Customer identity can remain inside the signal owner's environment until the applicable relationship rule allows it to move.
Companies already share sensitive data with outside software
What they usually do not allow is uncontrolled access to their customer relationship.
Companies already let outside platforms work with private CRM, account, financial, support and customer data.
They do.
The recurring pattern is narrow access, customer control, and staged disclosure under the applicable relationship authority.
Crossbeam can ingest private CRM and account data while sharing nothing with the partner by default. Matching happens before disclosure.
Customers decide which partners, which populations, which fields, and how much another partner can see. A partner can see only an overlap count without seeing the underlying account identity.
Vinculo can process a customer signal without automatically exposing that customer to the partner.
AWS does not immediately give a partner the full opportunity. The partner sees limited information first, accepts or rejects, and only then does more information move into the partner workflow.
Opportunity first. Broader customer disclosure only after the relationship owner approves.
LiveRamp created value from first-party customer and identity data while reducing what downstream participants directly receive, through identity resolution, tokenization and controlled collaboration.
The useful commercial signal does not always need to carry the underlying customer record with it.
These are not direct analogues to Vinculo. Each demonstrates a different piece of the permission model, and none proves the complete Vinculo workflow.
The core trust mechanisms already exist elsewhere.
Vinculo applies them one step earlier: a private operational signal creates a permitted partner action before anyone has declared a lead.
- The customer may push one approved event or derived signal.
- In higher-risk environments, identity can stay inside the customer until approval.
- Often Vinculo needs an event, not a CRM connection.
Two permissions, not one
Collapsing these into a single approval is what makes the ask feel large.
Vinculo may receive and process a defined signal.
Approved information may move to the destination when the relationship authority permits it, including after approval or customer consent where required.
Where the data sits
Customer · Vinculo · Partner
- Private customer data: records, activity, operational events
- Permission A: receive and process a defined signal
- Authority: act automatically or request the required decision
- Signal qualified against deterministic eligibility rules
- Permitted action or required decision prepared
- Nothing has reached the partner
- Permission B: approved payload crosses only under configured authority
- Approved opportunity only, at the selected disclosure level
What each function has to do to make this acceptable
The exact approval path changes by customer. These are the decisions Vinculo has to support.
Sales
Sell a narrow permission, not broad access
- 1 partner
- 1 signal
- 1 action
- 1 approver
- 1 data source
- who owns the customer relationship
- what signal creates value
- what can leave the company
- what must stay private
- who approves external disclosure
- unclear customer ownership
- no economic benefit
- untrusted partner
- broad access required before value is proven
Customer
The customer decides what Vinculo can know
- 1Nothing
- 2Count only
- 3Pseudonymous signal
- 4Named opportunity
- 5Approved referral payload
The customer can stop at any rung.
Partner
Opportunity access is not customer-base access
- only approved opportunities
- only approved fields
- only after required approval
- permitted use
- no prospecting outside approved referrals
- accept and reject SLA
- attribution
- outcome reporting
Product
A permission system before it is an intelligence system
- signal definition
- exclusions
- per-partner permissions
- disclosure level
- human approval
- revocation
- expiry
- audit
- outcome tracking
- Signal
- what triggers
- Eligible accounts
- who qualifies
- Partner
- the destination
- Approved use
- permitted purpose
- Disclosure level
- which rung
- Authority
- what executes automatically; when approval or consent is required
- Action
- what happens
- Economics
- who benefits
- Expiry
- when it lapses
Glean respects the permissions of the underlying enterprise systems rather than creating a new independent access model.
Task visibility should inherit the customer's existing permissions where possible.
Tech
Minimize what enters Vinculo
- 1Customer-generated signal
- 2Pushed event
- 3Narrow export
- 4Read-only integration — only if necessary
For many use cases, Vinculo needs an event, not a CRM.
AI
AI should not increase the data burden
Off
Deterministic rules and templates.
Assistive
AI explains an already-qualified signal.
Contextual
AI receives broader approved context.
V1 should default to Off or Assistive. AI should explain an already-qualified opportunity, not decide whether customer information can be disclosed.
Salesforce's trust layer can mask sensitive fields before information reaches an external model, while respecting existing field permissions.
AI should receive less information than the core Vinculo system, not more.
Security and legal
Make the permission enforceable, not just promised
- explicit purpose
- named fields
- retention
- deletion
- logging
- named subprocessors
- revocation
- no training unless explicitly permitted
- separate permission for external action
Ordinary B2B
Faster review, often named accounts, fewer approvers.
Bank and healthcare
Pseudonymous mode, deeper diligence, shorter retention, stricter audit.
Same core model. Different control settings.
What actually happens to the data
Eight steps in a relationship that requires employee approval. Other relationships can execute automatically or require customer consent.
Customer defines the signal
One condition, written by the customer, in their own system. For example implementation_help_needed = true.
Customer sends minimum data
Account ID, signal type, owner, eligibility flags. In higher-risk environments, a pseudonymous ID and no direct identity.
Vinculo checks eligibility
Is this signal eligible for this approved relationship? Deterministic wherever possible.
Check execution authority
If authorized, act. If not, surface only the missing decision, with the customer benefit and exactly what would be shared.
Employee decides when required
For this example, the relationship requires employee approval. Other relationships can act automatically or require customer consent.
Only approved information moves
The customer-controlled payload is sent only when the relationship permits it, at the selected disclosure level and no higher.
Partner accepts or rejects
Within the agreed SLA. The partner sees nothing beyond the approved opportunity.
Outcome returns
Confirm receipt and record the verified next state. Accepted, rejected, contacted, converted, duplicate, or customer declined are distinct outcomes.
AWS partner opportunities require an explicit accept or reject step. Opportunities should not sit indefinitely.
Every relationship needs an acceptance SLA and an expiry rule.
What Vinculo has to maintain
The ongoing cost of the model.
- data source
- signal definitions
- exclusions
- approvers
- retention
- eligible use cases
- permitted fields
- acceptance SLA
- economics
- attribution
- expired permissions
- changed agreements
- customer exclusions
- revoked access
- failed deliveries
- false positives
- employee declines
- partner rejects
- duplicates
- missing outcomes
The pattern across precedents
Five mechanisms, each solving a different part of the same problem.
| Precedent | Trust mechanism | Vinculo implication |
|---|---|---|
| Crossbeam | Compute before disclose | Process signals without exposing the customer base |
| AWS ACE | Stage disclosure and require acceptance | Partner gets more only after approval |
| LiveRamp | Separate identity from usable output | Minimize raw identity movement |
| Enterprise AI | Minimize model access | AI stays outside the permission decision |
| Plaid | Scoped and revocable access | Ask for the narrowest connection that works |
We no longer think Vinculo requires a company to hand over its customer database.
The minimum viable version may require only:
- one approved signal
- a narrow payload
- customer-controlled exclusions
- configured authority, with approval or consent only when required
- a limited partner disclosure
- Will companies let Vinculo process a private operational signal before it becomes a declared sales opportunity?
- Will they let that signal become a partner action when the relationship owner remains in control?
- Can Vinculo maintain these permissions across many partner relationships without becoming a bespoke services business?
Some of Vinculo is new. The trust mechanisms are not.
The research de-risks the mechanism. The live test has to prove the willingness.
We now have precedent for how access, disclosure, identity and approval can be controlled. What we do not yet have is evidence that customers will grant those permissions for Vinculo's specific pre-lead partner workflow.