Activity capture evaluation checklist: 5 failure tests to run before rollout

An activity capture pilot should prove five things: the candidate captures the right interactions, maps them correctly, creates usable Salesforce records, avoids duplicate writes, and preserves activity through cutover. A convincing demo proves none of those on your Salesforce configuration.

You’re protecting the reports that sales leadership already reads. A missing email makes a deal look quiet. A wrong opportunity match makes an unrelated deal look active. Both errors travel into deal reviews and forecasting without announcing themselves.

Use this protocol to evaluate each shortlisted candidate against the same source activity and acceptance criteria. Start with capture parity. Keep summaries, scorecards, and other advanced features out of the decision until the underlying records pass.

Complete, correctly mapped activity also supports workflows such as Weflow Deal Hygiene. Those workflows need trustworthy deal records before they can act on them.

Prepare a defensible activity capture pilot

Freeze the pilot scope, baseline, and approval gates before capture begins. Otherwise, every configuration change moves the target you’re trying to measure.

Your pilot charter should make these decisions explicit:

Select users, mailboxes, and Salesforce edge cases

Select pilot users for the failure cases they expose, rather than their willingness to try software. A pilot made entirely of friendly desktop users won’t tell you what happens in the field.

• Users and teams: Include sales, customer success, field sellers, and anyone who needs stricter capture controls.
• Mailboxes: Cover the Google Workspace or Microsoft environments you operate, including separate tenants and mobile clients.
• Salesforce records: Include duplicate contacts, shared account domains, incomplete opportunity contact roles, and required Contact fields.
• Selling motions: Test new business, expansion, renewal, implementation, and escalation conversations.
• Object model: Include custom objects, nonstandard record types, and parent-child account hierarchies.

Build a source-of-truth activity baseline

Use the mailbox and calendar as the baseline, not the incumbent’s activity count. Your current capture system may already miss interactions.

Create the expected destination before sending each controlled interaction. Keep excluded interactions in the ledger too, with an expected result of no write.

Retain source identifiers, timestamps, and expected relationships. Subjects alone won’t distinguish repeated messages or recurring meetings.

Set pilot duration and pass/fail thresholds

Plan around two weeks of testing, then extend the pilot if required scenarios haven’t occurred or defects still need retesting. Elapsed time alone doesn’t make the result meaningful.

We recommend the following acceptance gates. These are evaluation criteria, not a vendor service guarantee.

Set a minimum sample for each activity type before activation. Size it to cover every required scenario and repeat the ambiguous cases; don’t let a large outbound-email sample hide missing inbound mail.

Separate technical setup from capture activation

Treat access provisioning, mailbox reading, and Salesforce writing as separate approval gates. Ask each vendor exactly which action starts capture.

1. Provision access: IT approves the enterprise application; the Salesforce admin approves the integration user and package footprint.
2. Configure without enrollment: Prepare object choices, user scope, exclusions, and attachment policies.
3. Hold for approval: Security and legal confirm which test data the integration may process.
4. Activate the sandbox test: The Salesforce admin confirms the first write reaches the intended environment.
5. Approve limited production: RevOps signs off on test results and the current writer configuration.

Run security and commercial review in parallel

Start security, legal, and procurement work alongside technical preparation. A successful pilot shouldn’t sit idle while someone starts collecting vendor documents.

Confirm permissions, exclusions, residency, and AI scope

Validate the access model against your actual security policy before testing capture quality. A candidate that requires permissions you can’t grant won’t become a fit through configuration work.

• Salesforce access: Request required object permissions, field access, and the reason for each write permission. Test record visibility through the API, not just the Salesforce interface.
• Mailbox access: Confirm tenant-level and user-level scopes, enrollment boundaries, and the revocation process.
• Sensitive records: Test exclusions against existing Contacts and Accounts as well as unknown domains. Don’t assume those controls behave identically.
• Residency and retention: Document where email content, attachments, logs, and any recordings reside, including deletion terms.
• AI governance: Confirm whether capture can operate without AI processing and what administrators must disable.

List-view restrictions and hidden Lightning components aren’t substitutes for API-level permissions. Include a restricted user in the test and inspect what that user can actually access.

Normalize pricing, implementation, and renewal terms

Compare the full deployment cost, including the work required to leave the incumbent. An included Salesforce entitlement isn’t a removable saving if you’re keeping the edition that provides it.

Avoid pilot designs that hide capture failures

A weak pilot makes missing activity look like a configuration detail. Remove these sources of ambiguity before you score any candidate.

Test 1: Does capture match source activity?

Capture passes when every controlled eligible interaction produces the expected Salesforce activity within the agreed sync window. Unexpected writes matter just as much as missing ones.

• Setup: Freeze the source ledger, exclusions, object choices, and sync window.
• Procedure: Generate the interaction matrix, then reconcile each source item.
• Evidence: Keep source identifiers, Salesforce record IDs, timestamps, and exclusion results.
• Failure: Flag unexplained misses, prohibited capture, altered content, and persistent delays.
• Diagnostic owners: IT checks mailbox access; the Salesforce admin checks writes; the vendor investigates processing.

Run a controlled email and meeting matrix

Generate interactions across the clients, directions, and participant patterns your team uses. Mobile email belongs in the same test as desktop email.

Reconcile source activity against Salesforce records

Match each source interaction to its Salesforce result. A total count can look correct when one item is missing and another appears twice.

Calculate capture coverage as unique eligible source interactions captured divided by all eligible source interactions. Report mapping accuracy separately so an email on the wrong Opportunity doesn’t earn a clean pass.

Classify every miss before scoring the tool

Every mismatch needs a cause, an owner, and a retest.

1. Was the interaction eligible? Check the frozen enrollment and exclusion rules.
2. Could the integration read it? Inspect mailbox access and source availability.
3. Could the candidate resolve a destination? Check contacts, domains, opportunity contact roles, and mapping precedence.
4. Did Salesforce reject the write? Inspect permissions, required fields, validation rules, and the actual API response.
5. Does the record exist but disappear downstream? Check report filters, relationships, and user visibility.

Record the cause category, remediation, configuration version, and retest result in the defect log. Configuration failures still block rollout until you fix them, even when the vendor didn’t cause them.

Test 2: Does activity map to the right record?

Mapping passes when activity reaches the intended record or an explicitly accepted fallback. A wrong opportunity match is worse than an empty opportunity timeline because reports treat the wrong match as truth.

• Setup: Create ambiguous records and write down the expected destinations first.
• Evidence: Compare expected and actual record IDs, including any contact-role changes.
• Pass: Correct assignments and a workable correction path for ambiguity.
• Fail: Silent wrong-deal assignments or a fallback that cannot support your required deal reporting.
• Owner: RevOps defines the business destination; the Salesforce admin and vendor explain the mapping.

Create ambiguous opportunity and contact-role cases

Test several open opportunities on the same Account. That’s where a capture demo stops resembling your pipeline.

Inspect both the activity relationship and the contact roles after the test. Automatic role creation changes the inputs for subsequent mapping, so record what the candidate added.

Test corrections across threads and recurring meetings

A correction workflow passes only when the user can fix the mapping and understand what happens next. An override on one message doesn’t prove the rest of the thread follows it.

1. Open the proposed or completed mapping as a pilot rep.
2. Change the destination to the correct Salesforce record.
3. Send a reply, add a participant, and reopen the thread from another client.
4. Correct a meeting, then update a later occurrence in the series.
5. Inspect the original records, subsequent records, and any audit evidence.

Record whether each correction applies to one interaction, the thread, or the series. If reps must repeat the correction, count that work in the rollout decision.

Challenge custom objects, hierarchies, and post-sale records

Test mapping against the business’s actual record model. Correct child-account capture doesn’t automatically produce correct parent-account reporting.

Test 3: Can Salesforce use every captured record?

Captured activity passes this test when your required reports, flows, exports, and BI queries can use it. Timeline visibility alone isn’t proof of record usability.

• Setup: Select pilot records from each activity type and object configuration.
• Evidence: Save object queries, report outputs, Flow results, and external query results.
• Pass: Every required use case works under the permissions of its actual user.
• Fail: A required workflow depends on data that exists only in a vendor interface.
• Owner: Salesforce administration and the BI owner.

Confirm each candidate’s Salesforce storage model

Document the actual Salesforce objects each candidate writes. EmailMessage and Task support different reporting needs, so don’t treat the choice as a storage preference alone.

For each object, record editability, retention, and what remains after cancellation. A screenshot of a Salesforce page doesn’t answer those questions.

Verify Einstein Activity Capture storage in your org

Judge Salesforce Einstein Activity Capture (EAC) on your enabled configuration, not its historical storage model. Legacy EAC activity storage differs from the newer opt-in Sync Email as Salesforce Activity behavior.

1. Record the EAC configuration, enrolled users, and event sync direction.
2. Check whether Sync Email as Salesforce Activity is available and enabled.
3. Generate a new test email and inspect whether it produces queryable Salesforce records.
4. Run the same inspection on historical activity. Don’t assume a setting change converted existing history.
5. Document reporting access, automation behavior, retention, and any migration steps Salesforce requires for your org.

Keep the configuration evidence with the test result.

Test reports, flows, exports, and BI access

Execute the downstream workflows the business case promises. Don’t accept an architecture diagram in place of a working query.

Measure email and attachment storage impact

Project storage from the pilot’s observed Salesforce footprint. Native records give you control, but they also consume capacity your admin must manage.

• Measure record growth separately for emails, meetings, and contacts.
• Track attachment storage separately from activity record storage.
• Project volume using enrolled users, observed activity, and the required retention period.
• Include historical backfill in the projection.
• Test how a retention process identifies captured records without deleting unrelated activity.

If your org is near its allocation, storage approval belongs in the go/no-go decision. Don’t leave it as cleanup work after rollout.

Test 4: Do competing writers duplicate activity?

Coexistence passes when every interaction has one authoritative write path and reports count it correctly. Several Salesforce records can legitimately represent one meeting, so inspect the relationship model before labeling every extra row a duplicate.

• Setup: Inventory current writers and obtain an approved overlap design.
• Evidence: Record the source interaction, creating system, Salesforce IDs, relationships, and business count.
• Pass: No duplicate business activity, conflicting updates, loops, or omissions.
• Stop condition: Pause the test when unsupported overlapping writes appear.
• Owner: Salesforce administration, with each system’s administrator.

Inventory every current Salesforce activity writer

Inventory writers across departments, not just the sales stack. Customer success and support may operate separate capture paths.

Test supported coexistence without duplicate writes

Run concurrent capture only when the vendors approve the exact configuration. A request for a side-by-side evaluation doesn’t make overlapping production writes safe.

1. Reproduce the proposed coexistence settings in a sandbox or approved isolated scope.
2. Generate email through both the mailbox and the engagement workflow.
3. Create a meeting with multiple internal attendees, then reschedule it.
4. Inspect every resulting record and any calendar write-back.
5. Confirm that exclusions or duplicate checks didn’t suppress the interaction entirely.

For EAC replacements, use a planned cutover as the default. Changing event sync direction can address a calendar loop, but it doesn’t prove that two capture systems can safely write the same emails and meetings.

Assign one owner to each activity type

Assign write ownership where the activity originates, with documented exceptions. Keeping a forecasting system as a reader doesn’t require keeping its capture engine active.

Test 5: Can cutover preserve activity continuity?

Cutover passes when you can account for activity before, during, and after the switch, then recover a failed write without creating duplicates. An activation timestamp alone doesn’t prove continuity.

• Setup: Freeze the runbook, historical boundaries, source ledger, and rollback authority.
• Evidence: Save the last incumbent result, first candidate result, transition reconciliation, and recovery output.
• Pass: No unexplained gap, lost required history, or duplicate replay.
• Fail: The team cannot identify or recover activity from the transition window.
• Owners: IT controls mailbox access; the Salesforce admin controls writes; RevOps approves expansion.

Prove writes in sandbox before production

Prove configuration in a Salesforce sandbox, then repeat the essential tests in limited production. Sandbox success doesn’t verify production permissions or validation rules.

1. Sandbox: Test object creation, mapping, exclusions, and downstream automation using approved test data.
2. Connection change: Document any reconnection or reconfiguration required to move environments. Confirm the destination org before activation.
3. Production admin test: Use designated test records and verify actual production writes.
4. Live pilot group: Expand only after the Salesforce admin signs off on the production evidence.

Sequence incumbent shutdown and candidate activation

Define the shutdown and activation sequence before the cutover window. Name who checks each step, not just who clicks the button.

Tell reps which connections to use and which prompts to report. Salesforce mailbox warnings can confuse users when a separate server-side capture system already handles their activity.

Verify historical retention and backfill boundaries

Separate retained Salesforce records from recoverable mailbox history. Backfill from a mailbox isn’t the same as migrating every field the incumbent stored.

Write the earliest recoverable date into the business case. Don’t promise complete history when source availability or product limits leave a known boundary.

Test failed-sync recovery and rollback

Rehearse recovery with a safe, controlled failure before relying on it in production. A vendor’s promise to investigate isn’t evidence that replay preserves the right relationships.

1. Introduce an approved sandbox issue, such as a validation rule that blocks a test write.
2. Confirm how the failure reaches an administrator and whether the source item remains identifiable.
3. Fix the cause, then ask the candidate to retry or backfill the interaction.
4. Verify the recovered content, timestamp, destination, and duplicate behavior.
5. Rehearse stopping candidate writes before restoring the incumbent’s approved configuration.

Rollback restores capture ownership; it doesn’t automatically remove records the candidate already wrote. Identify those records before attempting cleanup, and preserve evidence for reconciliation.

How Weflow and Einstein Activity Capture handle the tests

Weflow and Salesforce Einstein Activity Capture should meet the same acceptance gates. Neither product earns a pass because a feature appears in its documentation.

Weflow is the Revenue AI Orchestration platform for sales, customer success, and RevOps teams. Built for Salesforce teams, Weflow writes captured activity into Salesforce records that customers can report on, use in flows, export, and retain.

United Fintech reported a 3x increase in captured activities after switching to Weflow and manually validating the interactions. That validation matters: a higher count only proves improvement after you rule out duplicates.

Validate Weflow against your Salesforce constraints

Weflow fits this protocol when your permissions, mapping needs, and mailbox topology support the deployment. These are the checks we’d expect your admin to challenge.

• Required fit: Weflow works exclusively with Salesforce. Correct mapping requires Account and Opportunity read access; automatic contact creation requires Contact create permission.
• Potential blocker: Weflow isn’t a fit if your security model permits Contact-only access.
• Contact creation: Test required fields and validation rules against the fields Weflow supplies. Inspect rejected writes rather than assuming contact creation succeeded.
• Mapping: Weflow prefers a Contact over a Lead, maps to a single qualifying open Opportunity through contact roles, and falls back to the Account when unresolved.
• Configurable fit: Automated, hybrid, and manual modes let teams choose different capture and correction policies. Test custom objects and post-sale rules explicitly.
• Privacy: Use the appropriate custom rule to exclude an existing Salesforce customer record. Don’t rely on domain exclusion alone.

Weflow’s email settings let admins choose the Salesforce object and attachment policy. Your pilot should test calendar capture choices before broad enrollment.

Weflow’s compatibility settings include duplicate checks and tracking-pattern exclusions. Use them to test supported engagement workflows, not as a blanket reason to leave another capture engine running.

Weflow reads no mailbox until a user joins an activity capture configuration. Package installation, integration-user connection, and enterprise-application setup can precede capture activation.

Weflow Activity & Contact Capture costs $19 per user per month, billed annually, with a 10-user minimum. Weflow charges no implementation fee; include the historical-backfill add-on and your internal migration work in the comparison.

Validate Einstein Activity Capture’s current configuration

Keep EAC if its configured behavior passes the requirements you actually have. Replacing reliable background visibility with a larger project needs a business reason.

• Verify the active email storage mode and event sync direction.
• Reconcile inbound and outbound capture against source activity.
• Test multiple opportunities, contact-role gaps, and multi-attendee meetings.
• Execute required reporting, Flow, BI, and historical-access tests.
• Review actual entitlements and incremental license costs with your Salesforce account team.

Turn pilot evidence into a rollout decision

Approve candidates through hard gates, not an average feature score. A good dashboard cannot compensate for prohibited capture or wrong-opportunity activity.

Your decision should identify what passed, what remains unproven, and who owns each remaining action. An untested requirement stays open.

Approve, remediate, or reject each candidate

Assign a disposition to every finding before recommending rollout. Separate a fixable org configuration from a product constraint, but require proof for both.

Package the decision for IT and sales leadership

Give stakeholders a short decision memo backed by the reconciliation ledger. Lead with operational risk and the rollout recommendation.

• Recommendation: Approve, remediate, or reject, with the specific deployment scope.
• Evidence: Capture coverage, mapping results, downstream tests, duplicate checks, and continuity results.
• Salesforce impact: Permissions, storage projection, reporting changes, and automation dependencies.
• Rep impact: Correction steps, authentication behavior, connection warnings, and support guidance.
• Commercial and security status: Full cost, contract terms, completed approvals, and remaining blockers.
• Execution: Cutover owner, stop conditions, rollback authority, and monitoring responsibility.

Bring the failed cases to the vendor conversation. You’ll learn more from how a candidate handles your ambiguous Opportunity than from another clean demo.

See how Weflow captures activity, updates Salesforce fields from calls, and rolls up your forecast. Book a 30-minute demo.

Activity capture evaluation FAQ

Evaluate adjacent channels, AI scope, and exit terms separately from email and calendar parity. Passing the core capture test doesn’t prove those capabilities.

Does activity capture include call recording?

Don’t assume it does. Email and calendar capture, dialer activity, and meeting recordings can belong to different products.

Weflow includes meeting recording in Weflow Conversation Intelligence, not Weflow Activity & Contact Capture. Revenue AI Foundation combines both products.

• Confirm which sources each quoted product captures.
• Identify which system writes the call or meeting activity.
• Price recording separately from basic capture if you need it.

Can activity capture be deployed without AI?

Separate capture procurement from AI activation, then require technical confirmation of the boundary. Weflow sells Weflow Activity & Contact Capture separately, but standalone packaging alone doesn’t settle an AI-governance review.

• Which features process data with AI during the proposed deployment?
• Can administrators keep optional AI features disabled?
• What processing continues when those features are off?
• Does the approved configuration match the contract and security review?

Weflow’s trust commitments include SOC 2 Type II, GDPR compliance, Zero Data Retention for AI processing, and no use of customer data to train AI models.

How should multiple mail tenants be evaluated?

Test each mail tenant as a separate administration boundary. A successful Microsoft 365 or Google Workspace connection doesn’t prove the same setup covers an acquired company.

• Document each tenant’s application approval and administrator.
• Verify user assignment to the correct capture configuration.
• Test messages between sibling companies as internal traffic.
• Validate exclusions against existing Salesforce records as well as domains.
• Check how administrators monitor failures across tenants.

Weflow requires capture configuration per mail tenant, with users assigned within the appropriate domain scope. Don’t assume one consolidated administrative view across tenants; confirm the operating model before approval.

How should field and in-person activity be tested?

Add field channels to the source baseline and score each separately. Capturing email sent from a phone doesn’t prove mobile call capture or in-person recording.

Weflow Mobile Copilot records and processes in-person meetings. Validate device availability and the required Weflow Conversation Intelligence scope during the pilot.

What monitoring should continue after rollout?

Monitor source-to-record health, not application logins. Background capture can work correctly even when nobody opens the product.

What happens to captured data after cancellation?

Records written into Salesforce and content hosted by a vendor can have different exit behavior. Weflow’s captured activity records persist in Salesforce after you stop using Weflow; that doesn’t mean every platform output or hosted recording lives there.

• Query retained activity and relationships after disabling capture.
• Export required vendor-hosted content before access ends.
• Confirm retention and deletion terms for each data category.
• Check package dependencies before uninstalling anything.
• Verify that reports and flows still work without the vendor application.

Make the data-exit test part of approval. Your next capture evaluation should start with usable history, not a reconstruction project.