Salesforce Delivery Management Integration

1. Configure Salesforce sales orders

Display the linked SuiteFleet task, sync status, delivery date, and receiving window on the Salesforce order.

1.1 Prerequisites

1.2 Object selection

Select Order, OrderSummary, or the org’s custom order object. Configure its line-item relationships, field API names, and lifecycle rules. See the Salesforce Order reference.

1.3 Identity and cardinality

• Correlation key: orgId:sourceRecordId:shipmentId.
• One shipment maps to one delivery task in this design. Split deliveries require distinct shipment keys.
• Persist the task ID returned by SuiteFleet. Store the Salesforce order number separately as a display reference.
• Keep source line IDs in the mapping to support quantity updates and partial delivery.

1.4 Export eligibility

Evaluate eligibility after the source transaction commits. Map the release condition to the org’s fulfillment status, such as Waiting to Fulfill.

Export released orders from the queue. Exclude unreleased and fulfilled records.

eligible = releaseStatusMatches
           AND businessHoldsCleared
           AND requiredDeliveryFieldsPresent
           AND deliverableQuantity > 0
           AND shipmentNotCancelled
           AND noExistingTaskForShipment

Update existing mapped tasks when orders change. Replayed release events must not create duplicates.

2. Map Salesforce fields to SuiteFleet

Authorize Salesforce REST API access through OAuth. Validate outbound and return mappings in a sandbox before production deployment.

1. Connect a Salesforce sandbox to a SuiteFleet test workspace using the supported authorization flow. Record which org and workspace are paired.
2. Assign the integration user a permission set with read access to the source objects and fields, plus write access to delivery results and exception records.
3. Configure the fulfillment eligibility rule and the connector’s supported trigger. For a custom implementation, choose a record change event, Salesforce automation, or scheduled read, and give one process ownership of task creation.
4. Map source fields, delivery units, time zones, and return fields. Store credentials in managed secret storage and define token renewal and revocation handling.

Outbound mapping: Salesforce → SuiteFleet

Replace example __c names with your org’s API names. Bind each destination to its connector field.

Validate addresses, quantities, identifiers, units, and receiving windows. Report field-level errors. Resolve customer, hub, and company IDs from workspace configuration.

3. Create SuiteFleet delivery tasks

3.1 Task creation sequence

1. Receive the release event or read an eligible order through the configured connector transport.
2. Read the committed header, lines, and shipment data. Re-evaluate eligibility.
3. Acquire the correlation key and check for an existing task mapping.
4. Validate and transform the outbound fields. Persist the pending operation before submitting it.
5. Create the task through the supported connector interface.
6. Persist the returned SuiteFleet task ID against the shipment key.
7. Write the task reference and successful sync timestamp to Salesforce. Mark the operation Synced after all required writes succeed.

If task creation succeeds but Salesforce writeback fails, retry writeback with the saved task ID.

Task creation through the API

For custom adapters, use SuiteFleet’s task creation API: POST https://api.suitefleet.com/api/tasks. Map customerOrderNumber, deliveryDate, and UTC receiving times. Example: 08:00–12:00 America/Chicago on 2026-10-14 converts to 13:00–17:00 UTC. Account for date rollover.

Validate the full task schema, including customer, consignee, task and delivery types, quantities, weight, value, volume, and COD amount. Use connector mappings for packaged deployments; use the API for custom task creation.

Prevent duplicate tasks

Enforce a unique orgId:sourceRecordId:shipmentId key and serialize competing creates. Reconcile ambiguous timeouts before retrying. Use provider idempotency where supported. Send post-dispatch changes for review.

4. Delivery assignment, execution, and exceptions

Review imported tasks, Salesforce references, dates, quantities, and driver assignments before delivery dispatch.

Assign delivery resources, dispatch tasks, and record progress in SuiteFleet. Preserve shipment mappings through reassignment or rescheduling. Track assignment, execution, and sync status separately.

Delivery planning with the lasso tool

Use Lasso select in Workbench to group delivery tasks on the map. Check receiving windows, quantities, and capacity before assignment and dispatch. Each task retains its Salesforce reference.

4.1 Delivery lifecycle configuration

Map supported connector statuses to these operational states. These labels are integration mappings, not provider API values.

4.2 Delivery changes and exception handling

Update addresses, windows, and quantities only when execution status permits; dispatched tasks require review. Preserve failed-attempt history and shipment links when rescheduling. Give unresolved exceptions an owner and next action.

4.3 Delivery-result fields

Bind these logical result fields to the connector’s actual completion schema.

4.4 Completion rules

• Validate delivered quantities against the shipment’s assigned quantities.
• Record partial delivery at line level and retain the outstanding quantity.
• Keep failed attempts and cancelled tasks outside delivered quantity totals.
• Close the delivery only after all configured completion requirements are satisfied.

Link proof of delivery when required. Process attachments separately from status and quantities.

5. Update Salesforce after delivery

Authenticate callbacks and persist events before acknowledgement. For polling, use durable checkpoints and overlapping reads to prevent missed updates.

1. Resolve the original record. Use the saved org, source-record, shipment, and task IDs. Quarantine any result that cannot be matched uniquely.
2. Validate the outcome. Check task identity, delivered quantities, completion time, and exception reason. Deduplicate repeated events and reject stale updates that would regress a completed delivery.
3. Write delivery fields. Update the configured delivery record or fields and line-level delivered quantities. Aggregate multiple shipments before declaring the whole order delivered.
4. Update exceptions. Write the failed-attempt or partial-delivery reason and outstanding quantities. Preserve unresolved work for follow-up or rescheduling.
5. Record success. Mark synchronization successful only after Salesforce accepts the writes. Keep delivery occurrence time separate from the integration processing time.

Return mapping: SuiteFleet → Salesforce

Write delivery status, received quantities, completion time, recipient, and the linked task to Salesforce using the return mapping below.

Keep delivery status separate from the commercial lifecycle. Map Delivered to a delivery field or object. Check configured values and transitions before updating Order.Status.

5.1 Field ownership and order aggregation

Write only delivery fields, quantities, task references, and exceptions. Preserve pricing, taxes, payment terms, and totals. Configure invoicing and case automation separately.

orderDeliveryComplete =
    every required shipment is complete
    AND every deliverable line has its required delivered quantity
    AND configured completion requirements are satisfied

Apply quantities once per shipment result. Prefer absolute quantities; deduplicate delta events before applying them. Serialize concurrent updates and aggregate order delivery totals from shipments.

5.2 Salesforce Flow configuration

Trigger Flows on committed delivery-state transitions. Persist processing markers to prevent repeated actions. Evaluate completion, outstanding quantities, and sync status in entry criteria.

5.3 Prevent synchronization loops

Trigger exports only on release or delivery-input changes. Exclude inbound-owned fields to prevent synchronization loops.

6. Error handling, reconciliation, and validation

6.1 Error classification

6.2 Recovery and reconciliation

Log record, task, and event IDs, operation, attempts, processing time, and sanitized errors. Retry transient failures with bounded backoff. Correct validation and permission failures before replay; escalate exhausted retries.

Reconcile orders without tasks, deliveries awaiting Salesforce updates, and unresolved exceptions. Keep delivery and sync status separate. Assign owners and latency targets for both directions.

6.3 Sandbox acceptance tests

Deploy mappings, permissions, status rules, and automation together. Test with production-equivalent permissions and active automation in the sandbox. Assign recovery ownership before activation.