List Sync — Salesforce

The QuickFlo Connector is a lightweight Salesforce package that watches records you care about and sends each change to a QuickFlo workflow as a webhook. Use it to keep external systems in sync, enrich leads on the fly, build an audit trail, or kick off automation when records match specific criteria.

This guide walks through installing the package, configuring which objects and events to track, and where to look when something goes wrong. The Salesforce-to-Five9 field and list mappings are defined separately in QuickFlo — see QuickFlo: Configure List and Field Mappings below.

How It Works

When a Salesforce record is created, updated, or deleted, an Apex trigger on the configured object evaluates your rules and — if they pass — enqueues an asynchronous job that POSTs a JSON payload to your QuickFlo webhook endpoint. You configure what to send in Salesforce; QuickFlo decides where it lands and how it’s shaped.

For the technical detail of how the trigger handles bulk volume, retries, and failures, see Salesforce: Under the Hood below.

Salesforce: Install the Package

Note

The QuickFlo Connector package is password-protected. Your QuickFlo implementation resource will provide the installation key — it is not listed in public docs.

1. Open the install link

   Click this link while logged in as a Salesforce admin:

   Install QuickFlo Connector

   For a sandbox, replace login.salesforce.com with test.salesforce.com in the URL.

2. Enter the installation password

   Paste the installation key you received from your QuickFlo implementation resource.

3. Choose “Install for Admins Only”

   Recommended so that regular users can’t modify the connector’s configuration. Triggers still fire on every user’s DML regardless of this setting — it only controls who can see and edit the setup tab. Grant access to specific non-admin integration managers via the QuickFlo Admin permission set.

4. Assign the permission set

   Once install completes, assign the QuickFlo Admin permission set to yourself (or whichever user will manage the configuration). Setup → Permission Sets → QuickFlo Admin → Manage Assignments.

Salesforce: Add the Remote Site

Salesforce blocks outbound HTTP callouts to any domain not registered as a Remote Site. Before the connector can deliver events, you need to whitelist the QuickFlo endpoint.

1. In Salesforce, go to Setup and search for Remote Site Settings in the Quick Find box.

2. Click New Remote Site.

3. Fill in the form:

   • Remote Site Name: QuickFlo
   • Remote Site URL: https://run.quickflo.app
   • Active: checked

4. Click Save.

Note

You only need to do this once per org. If the URL changes in the future, update the existing entry rather than creating a new one.

Salesforce: Connect to QuickFlo

Open the QuickFlo Setup tab from the App Launcher.

1. Endpoint URL — Paste the webhook URL from your QuickFlo workflow. It will look like https://run.quickflo.app/w/<id>/<workflow-slug>.

2. API Key — Paste the shared secret from the same workflow. QuickFlo sends this in the Authorization header so your workflow can verify the request is legitimate.

3. Active — Toggle on to enable outbound syncing. Leave off during initial setup if you want to configure everything before firing any events.

4. Batch Threshold — Maximum number of records per HTTP request. Default 10. Large DML operations are automatically split into batches of this size. Raise for high-throughput integrations, lower if your receiving endpoint is slow.

5. Debug Logging — Enables verbose System.debug output for troubleshooting. Leave off in production unless you’re actively debugging, since it generates a lot of log volume.

6. Click Save Connection, then Test Connection to send a ping and confirm credentials are valid.

Salesforce: Subscribe to Objects and Events

The Synced Objects section lists every object the connector can track. Standard objects (Lead, Contact, Account, Opportunity, Campaign, CampaignMember) are preconfigured. Click + Add Custom Object to track a custom object.

Each object has three toggles that control which DML events are sent:

Toggle	When it fires
Track Creation	A new record is inserted
Track Updates	An existing record is updated
Track Deletes	A record is deleted

Why Is “Track Creation” Off by Default?

Salesforce typically fires an update trigger immediately after an insert — for example, when an assignment rule, validation rule follow-up, or downstream automation writes back to the new record. If you track both creation and updates, you’ll usually receive a duplicate event a few seconds after every new record.

For most integrations, tracking updates alone captures the full record state (including the freshly created one) without the duplicate. Only enable Track Creation if your workflow specifically needs to distinguish a create event from any subsequent update.

Salesforce: Filter with Trigger Rules

If you only want to fire the webhook on specific changes, expand the Rules panel on any object and add one or more rules.

A rule consists of:

• Field — the field to evaluate
• Operator — one of equals, not equals, changed, contains, is blank, is not blank, etc.
• Value — the comparison value (disabled for valueless operators like changed or is blank)
• Applies To — which events the rule gates:
  • C — record matches the rule at creation
  • U — record matches the rule after update (regardless of previous value)
  • D — record matched the rule at the time it was deleted

Multiple rules on the same object are evaluated with AND logic — every rule must pass for the event to fire. If no rules are configured, every change passes through.

Tip

The default for new rules is C + U checked, D unchecked. That matches the most common use case: “fire the webhook when a record enters this state.” Delete-with-filter is rare; leave D unchecked unless you specifically need it.

QuickFlo: Configure List and Field Mappings

Everything above decides what Salesforce sends. The QuickFlo workflow decides what to do with it — which Five9 list each record lands in, which fields map where, and any transforms on the way through.

Those mappings live in a QuickFlo data store. Your implementation resource wires them with you on a call. Typical contents:

• Salesforce object → Five9 list (e.g. Leads in Campaign X → Inbound_Q2)
• Salesforce field → Five9 column (e.g. MobilePhone → number1)
• Transforms — phone formatting, timezone, disposition normalization

Tip

Mappings live in QuickFlo, not the package. Add a field, swap a list target, onboard a new campaign — we update the data store and it’s live. No Salesforce redeploy, no reinstall.

Salesforce: Under the Hood

How the trigger handles volume and failures — useful if you’re evaluating operational risk or debugging unusual behavior.

• Asynchronous — The trigger never blocks the user’s save. Payloads are sent from a Queueable job after the transaction commits.
• Per-record batching — Bulk operations (data loader, list views, flows) are chunked into batches so a 10,000-row update doesn’t hit Salesforce’s callout or heap limits.
• Retry with backoff — Transient failures (5xx, timeouts) are retried with exponential backoff. Permanent failures (4xx) are recorded once and not retried.
• Dead-letter queue — Every failed delivery lands in a QF_Sync_Error__c record with the full payload, status code, and reason, so nothing is silently dropped.

QuickFlo: View Sync Results

When a record isn’t showing up in Five9, the QuickFlo side is usually the first place to look — not the Salesforce dead-letter queue. The DLQ only catches failures where Salesforce couldn’t deliver to QuickFlo. If the payload arrived in QuickFlo but something went wrong transforming or pushing it to Five9, the DLQ is empty but QuickFlo has the full record.

Sync Dashboard

The Sync Dashboard is the primary investigation tool. It logs one row for every attempted CREATE, UPDATE, or DELETE operation against a Five9 list — successful or failed — with the error kind and error message inline.

Use it to:

• Find a specific record — search by Salesforce ID, list name, or operation type
• Triage a batch of failures — filter by date range and error kind (OPERATIONAL, EXECUTION, etc.)
• Spot patterns — the donut chart shows overall success/failure mix; the bar chart shows volume per Five9 list

Common error kinds you’ll see in the table:

• OPERATIONAL — Five9 accepted the request but rejected the record (e.g. NoMatchesInContacts when deleting a record that doesn’t exist in the target list)
• EXECUTION — the workflow itself failed before reaching Five9 (e.g. list name refers to a list that doesn’t exist)

Most issues can be resolved from the dashboard alone — the error message column usually tells you exactly what went wrong.

Executions view (deep dive)

When the Sync Dashboard row doesn’t give you enough detail, open the underlying Execution for a full per-step trace: input/output at every step, timing, and stack traces.

1. In QuickFlo, open the List Sync workflow → Executions.
2. Filter by status or by a searchable attribute (e.g. Salesforce ID if tagged).
3. Click into a failed execution to see which step failed, the exact payload each step received, and the Five9 API response.

Tip

If the Sync Dashboard shows zero rows for an operation that should have fired, the problem is on the Salesforce side — skip to Salesforce: View the Dead-Letter Queue or Salesforce: Read Debug Logs.

Salesforce: View the Dead-Letter Queue

Every failed webhook delivery is recorded as a QF_Sync_Error__c record. To view them:

1. Open the App Launcher and search for QuickFlo Sync Errors.

2. Each record shows:

   • Object and Record ID that triggered the event
   • Event Type (Insert / Update / Delete)
   • HTTP Status Code returned by QuickFlo
   • Error Message — the first 32 KB of the response body
   • Request Payload — the first 131 KB of what was sent

3. After fixing the downstream issue, you can re-send failed records by toggling the source record (any trivial update will re-trigger the webhook), or by running a data fix in Apex.

Salesforce: Read Debug Logs

When a webhook isn’t firing and there’s no dead-letter record, the Apex trigger itself may be the issue. Turn on debug logs to see what’s happening:

1. Enable Debug Logs

   Setup → Debug Logs → New. Set the Traced Entity to the user who’s making the changes, and use a log level with Apex: FINEST and Callouts: FINEST.

2. Reproduce the change

   Perform the DML operation (create, update, or delete a record on a tracked object).

3. Open the log

   Back in Debug Logs, click the most recent entry. Search for QuickFlo — the connector prefixes every debug line so it’s easy to find.

4. What to look for

   • QuickFlo: Rule eval — shows which rules passed or failed
   • QuickFlo: Enqueueing batch — confirms the async job was scheduled
   • QuickFlo: HTTP 200 / QuickFlo: HTTP 5xx — the response from your webhook
   • QuickFlo: Retry #N — backoff attempts on transient failures

Caution

Debug logs also require Debug Logging to be enabled in the Connection Settings — otherwise the connector only emits error-level logs (via System.debug(LoggingLevel.ERROR, …)), which still appear in standard debug logs but without the per-rule detail.

Troubleshooting

Webhook Fires Twice for Every New Record

Track Creation and Track Updates are both enabled. Disable Track Creation — see Why Is “Track Creation” Off by Default? above.

Nothing Fires at All

• Open the QuickFlo Executions view first — if you see the event arrive there, the Salesforce side is fine and the issue is in the workflow itself.
• If QuickFlo shows nothing, check the Active toggle in Connection Settings.
• Confirm the object’s Active toggle is on.
• Confirm at least one of Track Creation / Track Updates / Track Deletes is checked.
• If you have Trigger Rules, confirm the record actually matches them — add a temporary “always true” rule (e.g. Id is not blank) to isolate whether the rules are the gate.
• Check QuickFlo Sync Errors in Salesforce for delivery failures.

”Unauthorized endpoint” Callout Error

This means the Remote Site wasn’t added (or was added with a different URL). See Add the Remote Site above.

Duplicate Events After Bulk Import

By default, data loader and similar tools will trigger webhooks for every imported record. If you’re seeding data, temporarily toggle Active off in Connection Settings, perform the import, then toggle it back on.