How to connect Checktiv to Salesforce for automated KYC checks

Instead of copying guest-verification progress between inboxes and customer records, connect Checktiv to Salesforce through a shared-link workflow and a record-triggered review task. This guide separates guest verification from Salesforce follow-up, so a CRM update never becomes an unsupported claim that a guest has passed KYC.

Why this matters

A guest-verification workflow has two jobs: collect the verification and help you decide what happens next. Salesforce can organize that decision, but a task marked complete is not evidence that identity verification succeeded.

Checktiv guest verification is best for independent short-term rental hosts who want zero-code shared links. Salesforce adds a place to track the booking relationship, assign follow-up and record your decision. The trade-off is an extra record update unless you implement a separately documented technical connection.

For this 2026 setup, start with a link-based process you can inspect. Use Salesforce Flow to create an internal task when you mark a verification ready for review. Do not configure a CRM field change to approve a guest without checking the underlying result.

This distinction also matters when someone calls the process KYC. Identity verification is a component of customer checks, not a blanket declaration that every legal or business requirement has been satisfied.

Before you start

• Accounts and access: Have access to your verification account and Salesforce. Ask your Salesforce administrator to confirm permission to create Contact fields, build flows and create Tasks.
• A consistent record: Choose the Salesforce Contact that represents the guest being verified. Keep booking-specific decisions separate when the same guest has multiple stays.
• The setup gotcha: A Salesforce record-triggered flow responds to Salesforce changes. It does not learn that an external verification finished just because you sent a shared link. This guide requires you to update the Contact before the review task appears.

Use a Salesforce sandbox for configuration and testing when your organization provides one. Prepare a designated test Contact and use an authorized test process for verification, rather than collecting someone else's identity documents for a demonstration.

If you need results to move between systems without that record update, use the ID verification API integration guide for developers as a separate technical starting point. Confirm the documented capabilities before designing that connection.

Guest record configuration

Build a small, readable record structure first. The following are proposed custom fields you create, not existing product settings or claims about a connector.

Create the tracking fields

1. Open Salesforce Setup, then Object Manager.
2. Select Contact, then Fields & Relationships.
3. Select New and create the 4 fields below, using the specified field types.
4. Set field access for the people responsible for verification, then add the fields to their Contact page layout.

For Verification status, create these values: Not requested, Requested, Ready for review, Reviewed and Follow-up needed. Keep these labels consistent across your records and flows.

Do not label a value Passed unless your team has defined exactly what that means and what evidence supports it. Reviewed describes an action; approved describes a decision. A single status should not silently stand for both.

Put only the information your team needs in the reference and decision fields. Do not copy identity-document images or detailed screening information into general Contact notes merely to make everything visible in one place.

Expected result: An authorized user can open the test Contact, identify the verification stage and record a review without searching through unrelated notes.

Decide which record owns the decision

A Contact is suitable for this basic guide because it represents the person. A booking-specific decision belongs with the relevant stay when your Salesforce configuration includes booking records.

If your organization already tracks reservations in a custom object, ask the administrator to adapt the same pattern there. Do not create a second guest Contact for every stay just to keep decisions separate.

For your 2026 configuration, write down the chosen record and the person responsible for updating it. That ownership rule is more useful than adding another status field nobody maintains.

Shared-link delivery

The guest-facing process stays simple: get a link, send it with clear context and review the verification. Salesforce holds the follow-up information, not the guest's identity documents.

Send the verification request

1. Sign up for or access Checktiv and get a shared verification link through the available account workflow.
2. Open the correct guest Contact in Salesforce. Confirm that you are working with the person who will complete the verification.
3. Send the link through your established guest communication channel. Explain who is requesting verification, what booking it relates to and what the guest should do next.
4. Set Verification status to Requested. Add a reference that lets you match the request to the correct guest and stay.
5. Save the Contact.

A useful message explains the purpose without promising a result: ask the guest to complete identity verification for the booking and explain that you will review it afterward. Do not say that opening the link completes the check.

Keep the request separate from arrival instructions. A guest should understand whether they are completing verification, reading house rules or receiving access details.

Expected result: The guest receives a clear request, and the Contact shows Requested. No review or approval has been recorded yet.

Keep the handoff visible

The operational sequence is Send link, Update record, then Review verification. Each action has a different owner or purpose, even when you handle all three yourself.

*Sending a link starts the request. Reviewing the result supports the hosting decision.*

Keep the reference useful but minimal. It should help you find the right verification, not become a second storage location for sensitive information.

If a guest asks for help, confirm which step they reached before sending another request. That avoids confusing a delivery problem with an incomplete verification.

Salesforce review-task configuration

Configure Salesforce to assign follow-up when you update Verification status to Ready for review. This is internal workflow automation, not a connection that transfers verification results.

Build the record-triggered flow

1. In Salesforce Setup, find Flows, then select New Flow.
2. Choose Record-Triggered Flow and select Create.
3. In the start configuration, select Contact as the object and trigger the flow when a record is created or updated.
4. Add an entry condition using your custom Verification status field, the Equals operator and the value Ready for review.
5. For updated records, choose Only when a record is updated to meet the condition requirements.
6. Select Actions and Related Records for the flow optimization, then finish the start configuration.

That entry condition matters. Without it, editing an unrelated Contact field while the status remains Ready for review can create another task.

Your Salesforce administrator should use the actual API name generated for your custom status field. The label you see on the Contact and the API name used in configuration are not interchangeable.

Create the review task

1. Add a Create Records element to the flow.
2. Configure it to create a single Task record.
3. Set the Subject to Review guest verification.
4. Set WhoId to the triggering Contact's ID and OwnerId to the triggering Contact's owner ID.
5. Set Status and Priority to active values accepted by your organization's Task configuration.
6. Save the flow with a clear name, test it and select Activate only after the test succeeds.

The Task field API names above identify the person associated with the task and its assigned owner. Do not use a booking reference as the Contact ID.

Expected result: Changing the test Contact from Requested to Ready for review creates 1 review task for its owner. Editing an unrelated field afterward does not create another task.

Run the 2026 test checklist

Run these 3 test cases before using the flow with guests:

• Change Requested to Ready for review. Confirm that one task appears on the correct Contact.
• Edit an unrelated field while the status remains Ready for review. Confirm that no additional task appears.
• Change Ready for review to Reviewed. Confirm that the flow does not create another review task.

These are acceptance checks for the workflow you are building, not product performance figures. Verify task assignment as well as task creation.

Verification review and closure

A review task tells you to act. It does not tell you what the verification found.

Record the hosting decision

1. Open the verification associated with the guest reference through your verification account.
2. Review the available result before making a booking decision.
3. Record the decision in Verification decision, keeping the explanation relevant to the booking.
4. Enter Verification reviewed at and change the status to Reviewed, or Follow-up needed if another action is required.
5. Complete the Salesforce review task only after recording what happened.

Do not complete the task just because the guest says they submitted their information. Submission, review and booking approval are separate events.

Expected result: Another authorized operator can see when the verification was reviewed and understand the hosting decision without interpreting an empty task history.

Second variant: create a delivery task when verification is requested

If someone else sends guest messages, create a separate flow that starts when Verification status changes to Requested. Its task tells the assigned operator to send the verification link.

Use the same Salesforce configuration pattern, but change the entry condition to Requested and the task subject to Send guest verification link. Keep the entry behavior restricted to records newly meeting the condition.

Choose the review task first if you manage the guest relationship yourself. Add the delivery task only when it resolves a real handoff between people.

Neither variant should claim that Salesforce performed identity verification. In this 2026 workflow, Salesforce coordinates work around the check.

Troubleshooting

No review task appears

Confirm that the flow is active and the Contact changed into Ready for review. Check the configured field API name and picklist value. Have the administrator inspect the failed flow details if the condition matched but task creation failed.

Duplicate review tasks appear

Check the flow's updated-record entry behavior and look for other flows that create the same task. A separate transition back into Ready for review can also create another task, so define when reopening a review is appropriate.

The task belongs to the wrong person

Check the Contact owner and the flow's OwnerId assignment. If guest reviews belong to a dedicated operator instead, have the administrator configure an eligible task owner rather than assuming the Contact owner handles verification.

The CRM says Reviewed but nobody recorded a decision

Treat that as an incomplete handoff. Ask the reviewer to enter the decision and review time. Then adjust your internal procedure so changing the status is the last review step, not the first.

Customize your workflow

Extend the record structure only after the basic handoff works. Add booking context, a responsible reviewer or a follow-up reason when each field answers a specific operational question.

For technical result transfer, establish a documented connection, record matching, permission controls and failure handling before replacing the human update. Keep that implementation separate from the guest-facing shared-link experience.

Recheck ownership whenever your team changes. A functioning flow assigned to the wrong person still leaves the guest waiting.

One last thing

The most useful safeguard is separating Reviewed from approved. A clear review record lets you change a hosting decision without rewriting what happened during verification.

Keep that distinction in your 2026 operating procedure. Your CRM should explain the decision, not manufacture evidence for it.

Related guides

• ID verification for short-term rental hosts
• Identity verification for fintech companies
• Identity verification APIs ranked by integration speed