Closing the Loop on Return Logistics: Automating FedEx Shipment Tracking in Dynamics 365 Customer Service, for a USA based Consumer Appliance Manufacturer

From Shipment Creation to Shipment Visibility

In the previous implementation article (Check out my previous blog here – Transforming Return Logistics for a USA Manufacturer: Automating Shipment Processing with Dynamics 365 Customer Service), the primary objective was to eliminate the manual process of creating FedEx return shipments.

The customer service representative could initiate the shipment directly from the Dynamics 365 Case.

The system handled the rest:

1. Collect Case and customer information.
2. Register the shipment with FedEx.
3. Generate the return label.
4. Capture the tracking number.
5. Store the tracking number against the Case.
6. Send the return label to the customer.

That created a significant improvement in the shipment creation process.

However, there was still a gap.

The tracking number was now inside Dynamics 365, but the shipment status was still outside Dynamics 365.

This highlighted an important principle in integration design:

The second phase therefore asked a different question:

The answer was yes.

The Business Challenge

The existing process (Before FedEx Intg. Was implemented) required customer service representatives to manually monitor return shipments.

A typical workflow looked like this:

1. Open Dynamics 365 Customer Service.
2. Find the Case.
3. Copy the FedEx tracking number.
4. Open the FedEx tracking website.
5. Enter the tracking number.







6. Review the latest shipment event.







7. Determine whether the package had been handed over to FedEx.
8. Return to Dynamics 365.
9. Update the Case status.
10. Repeat the process for other Cases.

This created several operational challenges.

1. Repetitive Manual Work

Tracking information had to be checked repeatedly for multiple shipments.

2. Context Switching

Agents moved between Dynamics 365 and the FedEx tracking website to complete a single business process.

3. Delayed CRM Updates

Even when FedEx had already received a shipment, the corresponding Case could remain unchanged until somebody manually checked it.

4. Human Interpretation

FedEx returns multiple tracking events and statuses. Agents had to interpret those events and determine which ones represented meaningful milestones for the organization’s return process.

5. Poor Scalability

As the number of return shipments increased, the amount of manual tracking increased with it.

The business did not need another screen for agents to monitor. It needed the tracking information to come back to the system where the business process was already being managed: Dynamics 365.

Solution Overview

I extended the previous FedEx integration by introducing an automated shipment-tracking process.

The solution uses:

1. Dynamics 365 Customer Service
2. Dataverse
3. Integration
4. FedEx Tracking API

The high-level process is:

                 Dynamics 365 Customer Service
                              |
                              v
                    Active Cases with
                     Tracking Numbers
                              |
                              v
                      FedEx Tracking
                              |
                              v
                     Tracking Response
                              |
                              v
                    Interpret Scan Events
                              |
                              v
                  Determine Shipment Status
                              |
                              v
                   Update Dynamics 365 Case

The process runs automatically on a scheduled basis.

There is no requirement for a customer service representative to manually visit the FedEx website for every shipment.

Functional Integration Approach

The functional design was intentionally centered around the existing Case lifecycle.

The Case already contained the information required to identify the shipment.

The integration therefore did not introduce a separate tracking application or another user interface.

Instead, it used the Case itself as the operational source of truth.

The process can be summarized as:

Scheduled Trigger
       ↓
Find eligible Cases
       ↓
Read Tracking Number
       ↓
Call FedEx Tracking API
       ↓
Read Tracking Events
       ↓
Interpret Latest Status
       ↓
Determine Tendered / Not Tendered
       ↓
Update Case

This approach keeps the integration aligned with the business process rather than creating a separate operational process around the API.

Identifying Cases Requiring Tracking

The first important design decision was determining which Cases should actually be sent to FedEx.

There is no reason to query the FedEx API for every Case in Dynamics 365.

The flow therefore starts by retrieving only Cases that satisfy the business criteria.

The query is designed around conditions such as:

1. The Case is active.
2. The Case has a FedEx tracking number.
3. The Case has not already reached the relevant business status.
4. The Case has not already been processed for the required milestone.

Conceptually:

Active Case
     +
Tracking Number Exists
     +
Not Already Tendered
     ↓
Eligible for Tracking

This filtering is important for two reasons.

First, it reduces unnecessary API traffic.

Second, it ensures that the automation remains aligned with the business process.

The integration is not intended to become a generic FedEx tracking engine for every shipment ever created.

It is specifically designed to identify return shipments that still require tracking attention.

Calling the FedEx Tracking API

Once an eligible Case is identified, the flow extracts the tracking number and sends it to the FedEx Tracking API.

FedEx’s current Basic Integrated Visibility capability provides basic tracking information for FedEx shipments and supports tracking by tracking number.

The API request is made using an OAuth bearer token.

The request follows the general structure:

The request body contains the tracking number:

{
  "includeDetailedScans": true,
  "trackingInfo": [
    {
      "trackingNumberInfo": {
        "trackingNumber": "<tracking-number>"
      }
    }
  ]
}

The includeDetailedScans option is particularly useful for this integration because the solution is not interested only in a high-level shipment status.

It needs the underlying scan events to determine whether the shipment has reached a meaningful operational milestone.

The response contains tracking information including the tracking number, tracking results, and scan events.

A simplified response structure looks conceptually like:

output
 └── completeTrackResults
      └── trackResults
           ├── latestStatusDetail
           └── scanEvents

The Integration then works with these elements to determine what happened to the shipment.

Understanding FedEx Tracking Events

One of the more important parts of the implementation was not simply calling the API.

It was interpreting the information returned by the API in terms of the organization’s business process.

FedEx provides a number of tracking event codes, but this implementation does not need to process every event returned by FedEx. Instead, the flow identifies the specific events that indicate the return shipment has progressed into the carrier’s possession.

Return Shipment Events Used by the Flow

For this implementation, the flow specifically filters FedEx tracking events for the following event types:

These three events were selected because they provide the business signal required by the Case process.

DO – Dropped Off
The customer has handed the package to the carrier or a FedEx location.

PU – Picked Up
The shipment has been picked up by FedEx.

IP – In FedEx Possession
FedEx has possession of the shipment.

The flow therefore does not treat every tracking update as a business milestone. Instead, it first filters the returned FedEx events to identify whether one of these three relevant events has occurred.

The implementation then performs an additional validation against the latest tracking status. It checks that the shipment’s possessionStatus is true, confirming that FedEx currently has possession of the shipment.

At the same time, the flow explicitly excludes the DL – Delivered status from this possession check.

This distinction is important because a shipment being in the carrier’s possession is a different business milestone from the shipment being delivered.

The logic can therefore be summarized as:

This allows the integration to translate the carrier’s tracking information into a meaningful business event rather than simply copying the latest FedEx status into CRM.

In this implementation, DO, PU, and IP are the tracking events used to establish that the return shipment has entered FedEx’s possession, while the DL check ensures that the logic does not incorrectly treat an already-delivered shipment as an active possession milestone.

Determining Whether a Shipment Has Been Tendered

This was the key business rule in the implementation.

The requirement was not simply:

The actual requirement was:

That is a different problem.

A shipment may have a tracking number while still being physically with the customer.

For example:

Label Created
     ↓
Tracking Number Exists
     ↓
Customer Has Package
     ↓
Dropped Off
     ↓
FedEx Possession
     ↓
In Transit
     ↓
Delivered

The existence of a tracking number therefore does not mean the shipment has entered the carrier network.

The Integration implementation uses the tracking response to identify relevant scan events.

The scan events are filtered for:

These represent meaningful indicators that the shipment has entered the carrier-handling process.

The flow then determines whether relevant scan events exist.

Conceptually:

FedEx scanEvents
       |
       v
Filter:
DO / IP / PU
       |
       v
Any matching events?
       |
     Yes
       |
       v
Shipment has reached
the required milestone

The flow also captures the latestStatusDetail information returned by FedEx.

The information retained includes fields such as:

1. Status code
2. Derived code
3. Localized status
4. Description
5. Possession status

This allows the integration to retain the carrier’s detailed status while also deriving the business-level status required by Dynamics 365.

Updating Dynamics 365 Customer Service

Once the shipment has been evaluated, the integration determines whether the Case should be updated.

The implementation uses the FedEx response to determine the possession state and prevent a delivered shipment from being incorrectly treated as an active tendering event.

The business rule is conceptually:

Possession Status = TRUE
        AND
Latest Status Code != DL
        ↓
Shipment considered Tendered

This distinction is important.

The automation is not simply looking for a single string such as “Delivered”.

It is combining multiple pieces of information from the FedEx response to determine the business state.

When the condition evaluates to true, the flow updates the Case status reason to the appropriate Tendered state.

The process therefore becomes:

FedEx Tracking Response
          ↓
Latest Status + Scan Events
          ↓
Business Rule Evaluation
          ↓
Tendered?
      /        \
    Yes         No
     ↓           ↓
Update Case    Continue Monitoring

This means the Case becomes the operational representation of what is happening to the physical return shipment.

The customer service representative no longer has to manually determine this status.

Handling Exceptions and Empty Tracking Responses

External APIs cannot always be assumed to return the ideal response.

A tracking request may produce:

1. No scan events
2. An incomplete tracking result
3. An unexpected response structure
4. An internal server error
5. A shipment that has not yet generated meaningful scan information

The flow therefore includes defensive checks before attempting to process the tracking events.

For example, the response is checked to determine whether the expected scanEvents collection is empty.

Conceptually:

Tracking Response
       |
       v
Are scanEvents available?
       |
   +---+---+
   |       |
  Yes      No
   |       |
   v       v
Process   Continue /
Events    Retry Later

The flow also checks the response for internal server errors before attempting to process the scan events.

This is particularly important in scheduled integrations.

A single malformed response should not prevent the entire scheduled process from successfully handling other Cases.

Technical Architecture

At a technical level, the solution is implemented as a Integration cloud flow.

The flow is triggered on a recurring schedule.

The high-level architecture is:

                    ┌─────────────────────┐
                    │    Recurrence       │
                    └──────────┬──────────┘
                               │
                               v
                    ┌─────────────────────┐
                    │ Request OAuth Token │
                    │      from FedEx     │
                    └──────────┬──────────┘
                               │
                               v
                    ┌─────────────────────┐
                    │ List Active Cases   │
                    │ with Tracking No.   │
                    └──────────┬──────────┘
                               │
                               v
                    ┌─────────────────────┐
                    │      For Each       │
                    │       Case          │
                    └──────────┬──────────┘
                               │
                  ┌────────────┴────────────┐
                  │                         │
                  v                         v
          Compose Case ID          Compose Tracking No.
                  │                         │
                  └────────────┬────────────┘
                               │
                               v
                    ┌─────────────────────┐
                    │ FedEx Tracking API  │
                    └──────────┬──────────┘
                               │
                               v
                    ┌─────────────────────┐
                    │ Server Error Check  │
                    └──────────┬──────────┘
                               │
                               v
                    ┌─────────────────────┐
                    │ Filter Scan Events  │
                    │ DO / IP / PU        │
                    └──────────┬──────────┘
                               │
                               v
                    ┌─────────────────────┐
                    │ Evaluate Tracking   │
                    │ Result               │
                    └──────────┬──────────┘
                               │
                               v
                    ┌─────────────────────┐
                    │ Determine Tendered  │
                    └──────────┬──────────┘
                               │
                               v
                    ┌─────────────────────┐
                    │ Update Case Status  │
                    └─────────────────────┘

The implementation is therefore relatively lightweight from an infrastructure perspective.

There is no separate application server required for the orchestration.

Integration acts as the integration layer between Dataverse and FedEx.

Processing Multiple Cases

The integration uses a For each pattern to process the eligible Cases.

Conceptually:

List Cases
     |
     v
For Each Case
     |
     +--> Get Tracking Number
     |
     +--> Call FedEx
     |
     +--> Process Response
     |
     +--> Determine Status
     |
     +--> Update Case

This design keeps the Case-to-tracking relationship explicit.

Each tracking request can be associated directly with the originating Dynamics 365 Case.

It also makes the workflow easier to extend later.

For example, the same pattern could be extended to:

1. Detect delivery exceptions
2. Detect delayed shipments
3. Detect delivered shipments
4. Capture estimated delivery dates
5. Notify agents about exceptions
6. Automatically close or advance Cases
7. Trigger customer notifications

The tracking API therefore becomes more than a status lookup.

It becomes a source of operational events that can drive the Dynamics 365 service process.

Designing the Integration Around Business Events

One of the key lessons from this implementation is that integration design should begin with business events, not API fields.

FedEx returns many different pieces of information.

But the business does not necessarily care about every field.

The business cares about questions such as:

1. Has the customer handed over the package?
2. Is FedEx in possession of the shipment?
3. Is the shipment in transit?
4. Has it been delivered?
5. Has something gone wrong?

These are business questions.

The API provides the raw information required to answer them.

The integration layer is responsible for translating:

External API Event
        ↓
Business Interpretation
        ↓
Dynamics 365 State

This separation is what makes the solution useful.

Otherwise, the CRM simply becomes a mirror of the FedEx API response without actually improving the business process.

Business Impact

4. Consistent Status Interpretation — Example

For example:

DO / PU / IP
      ↓
FedEx possession milestone
      ↓
Tendered

6. Moving From Reactive to Event-Driven Customer Service

This creates an opportunity to move from reactive customer service to event-driven customer service.

Instead of waiting for a customer to ask:

the system can identify relevant shipment events before the customer needs to contact the support team.

FedEx Tracking API Limitations and Guardrails

An integration with an external tracking API should not be designed as though the API has unlimited capacity.

FedEx applies organization quotas, Track capability quotas, rate limits, and OAuth thresholds. These are particularly important for a scheduled integration processing multiple tracking numbers.

The integration flow addresses these limitations through a few key guardrails:

The key principle is:

Final Thoughts

In the previous article, we focused on automating the creation of return shipments from Dynamics 365 Customer Service.

This implementation completes the next part of that journey.

The business no longer has to manually move between Dynamics 365 and the FedEx tracking website to determine whether a return shipment has been handed over to the carrier.

Instead, the system continuously monitors eligible shipments, retrieves FedEx tracking information, interprets the carrier events, and updates the corresponding Case based on the business rules.

The transformation can therefore be viewed as two connected stages:

Stage 1
Dynamics 365
      ↓
Create FedEx Return Shipment
      ↓
Capture Tracking Number

Stage 2
Tracking Number
      ↓
FedEx Tracking API
      ↓
Interpret Shipment Events
      ↓
Update Dynamics 365 Case

Together, these capabilities create a much more complete return logistics process.

The important shift is from shipment automation to shipment intelligence.

The integration is no longer simply asking:

It is asking:

That distinction is where integration starts becoming more than system connectivity.

It becomes an operational capability.

And for organizations already using Dynamics 365 Customer Service as the center of their service operations, this creates an opportunity to bring carrier events, logistics milestones, and customer service processes into the same operational context.

Continue the journey: This solution builds directly on the FedEx return-shipment automation described in our earlier article, “Transforming Return Logistics for a USA Manufacturer: Automating Shipment Processing with Dynamics 365 Customer Service.”

For organizations looking to connect Dynamics 365 with logistics, shipping, or external operational platforms, the same architectural approach can be extended to create event-driven processes that reduce manual intervention while keeping the CRM system at the center of the business workflow.