I’m preparing for my Dynamics 365 Field Service (MB240) renew certification, and as part of my journey, I’m creating blog posts that reflect my study notes and revision. I hope that these posts will serve as a helpful resource for anyone else working toward the same goal.

Based on past exam patterns, Microsoft frequently includes questions that require selecting multiple correct answers and organizing them into a specific sequence. These types of questions assess both knowledge and the ability to logically structure information. Therefore, candidates should be prepared to both identify the correct options and arrange them in the required order.

In this study note, we identify discuss Connected Field Service / IOT.

One‑line example scenario

A device in the field reports that pressure has exceeded the acceptable threshold —
this triggers an IoT alert.

1. What components do we need?

1. Azure IoT Platform

You can use:

• Azure IoT Hub (PaaS) or
• Azure IoT Central (SaaS) or
• An external IoT hub (via API integration)

2. Dynamics 365 Field Service

Connected Field Service (CFS) extension (out‑of‑the‑box)

This study note focuses on CFS, not Azure configuration.

2. High‑Level Flow

Below is the simplest possible sequence of what happens when a device sends an alert.

A) Azure IoT Hub

1. Device telemetry is received by Azure IoT Hub.
2. Rules and alerts are configured in IoT Hub (e.g., pressure > threshold).
3. When a rule is triggered, an alert is raised and sent to Dynamics 365 via the CFS integration.

B) Connected Field Service (CFS)

B.1 – Alert arrives in Dynamics 365

• The alert appears on the IoT Alerts page.
• The alert payload includes the IoT Device ID.
• CFS checks whether this IoT Device already exists in Dynamics 365.

B1) IoT Device exists in CFS

1. CFS links the IoT Alert record to the IoT Device record.
2. CFS checks whether the IoT Device is linked to a Customer Asset.

B1.1) IoT Device is linked to a Customer Asset

• CFS links the IoT Alert to the Customer Asset.
• CFS performs a full device data pull (device twin / telemetry snapshot).

This allows Field Service to:

• Create a work order
• Trigger an incident type
• Start automated workflows

B2) IoT Device does not exist in CFS

If the IoT Device is new:

1. CFS creates a new IoT Device record.
2. CFS creates a new Customer Asset record (but without a customer assigned).
3. The customer link must be manually backfilled later.

This ensures the device is tracked even if it was never registered in Field Service before.

Memory Hook: “HUB → ALERT → DEVICE → ASSET → ACTION”

Think of it as a five‑step chain.
If you remember the chain, you remember the whole process.

1. HUB – “Rules fire in Azure”

Telemetry hits IoT Hub, rules trigger, alert is generated.

Phrase: “Hub fires first.”

2. ALERT – “CFS receives the signal”

The alert lands in IoT Alerts inside Field Service.

Phrase: “Alert arrives.”

3. DEVICE – “Do we know this device?”

CFS checks if the IoT Device exists.

• Exists → link alert to device
• Doesn’t exist → create device

Phrase: “Device? Yes or no.”

4. ASSET – “Is it tied to a customer?”

If the device is known, CFS checks for a Customer Asset.

• Exists → link alert to asset
• Doesn’t exist → create asset (no customer yet)

Phrase: “Asset? Link or build.”

5. ACTION – “Pull data and trigger work”

CFS performs a full device data pull and can trigger workflows or work orders.

Phrase: “Data pulled, action ready.”