When Systems Talk: Understanding Custom Services in Dynamics 365 F&O

Views (13)

HardikPatel523

155

Like(0)

Report

In the modern digital world, business systems rarely work alone.
They constantly talk to each other, exchange data, and trigger actions.

For example:

An MES system might finish a production order.
An e-commerce website might create a sales order.
A warehouse system might update inventory.

But how do these systems actually communicate with Microsoft Dynamics 365 Finance and Operations?
The answer lies in something called Services.

A Word with a History: Where “Service” Comes From

Before we dive into the technical details, let’s look at the word itself.
The word service comes from the Latin word servitium, which means - 'to serve or assist someone'.

Technology borrowed this idea.
In software terms, a service simply means 'One system asking another system to perform a task.'
It’s essentially 'a polite request between two machines'.

The Pizza Principle: How Software Services Work

Imagine ordering pizza through a food delivery app.
The process looks like this:

You place an order request
The restaurant processes the request
The delivery partner brings the response

Software services follow the exact same pattern.

External System → Request → Dynamics Processes → Response

The only difference?
Instead of a delivery bike, the message travels through APIs and JSON.
And thankfully, software deliveries rarely get stuck in traffic.

Why Custom Services Exist (And Why Direct Database Access Is a Terrible Idea)

Suppose you allowed every external system to access your Dynamics database directly.
That would be like allowing every food delivery driver to:

walk into your kitchen
open the fridge
cook their own meal

That would quickly become chaos.
Instead, Dynamics provides controlled entry points called services.
These services ensure:

Security
Validation
Controlled business logic
Proper data processing

In short:
Services protect the system while still allowing external communication.

The Anatomy of a Custom Service

Every custom service in Dynamics is built from five key components.
Think of them as the organs of the integration body.

Component	Role
Request Class	Receives incoming data
Response Class	Sends output back
Service Class	Contains business logic
Service Object	Exposes service externally
Service Group	Organizes services

Let’s explore each one.

The Request Class: Where Conversations Begin

Every integration begins with a request.

The request contains the information an external system wants to send into Dynamics.

Real-life analogy

When ordering food, your request might contain:

Item name
Quantity
Delivery address

Similarly, an external system must send structured data.

Example Request Class

[DataContractAttribute]
public class ProdTableRequest
{
    private ItemId gItemId;
    private Qty    gQty;

    [DataMember("ItemId")]
    public ItemId parmItemId(ItemId _itemId = gItemId)
    {
        gItemId = _itemId;
        return gItemId;
    }

    [DataMember("Qty")]
    public Qty parmQty(Qty _qty = gQty)
    {
        gQty = _qty;
        return gQty;
    }
}

Why DataContract and DataMember Matter

These attributes tell Dynamics - “This data should be exposed to the outside world.”

Without them, your class might look perfectly fine inside Dynamics, but external systems would simply say:

"Interesting class… but I have no idea what fields exist."

The Response Class: What Dynamics Sends Back

After processing the request, Dynamics returns a response.

This tells the caller what happened.

The response may contain:

Success or failure status
Error details
Debug information

Example Response Class

[DataContractAttribute]
public class Response
{
    private boolean      gSuccess;
    private ErrorMessage gErrorMessage;
    private str          gDebugMessage;

    [DataMember("Success")]
    public boolean parmSuccess(boolean _success = gSuccess)
    {
        gSuccess = _success;
        return gSuccess;
    }

    [DataMember("ErrorMessage")]
    public ErrorMessage parmErrorMessage(ErrorMessage _errorMessage = gErrorMessage)
    {
        gErrorMessage = _errorMessage;
        return gErrorMessage;
    }

    [DataMember("DebugMessage")]
    public str parmDebugMessage(str _debugMessage = gDebugMessage)
    {
        gDebugMessage = _debugMessage;
        return gDebugMessage;
    }
}

Real-life analogy

Returning to the pizza example, the response might say:

Order accepted 🍕
Order rejected ❌
Delivery delayed 🚴

In enterprise systems, hopefully the first option is the most common.

The Service Class: The Brain Behind the Operation

The Service Class is where the real work happens.
It receives the request, processes it, and prepares the response.

Example Service Class

public class ProdTableService
{
    public Response process(ProdTableRequest _request)
    {
        var response = Response::construct();

        try
        {
            response.parmDebugMessage(
                strFmt("Production order will be created for item : %1 for %2 qty",
                       _request.parmItemId(),
                       _request.parmQty())
            );

            response.parmSuccess(true);
        }
        catch (Exception::CLRError)
        {
            System.Exception interopException = CLRInterop::getLastException();

            response.parmSuccess(false);
            response.parmErrorMessage(interopException.ToString());
        }

        return response;
    }
}

You can think of this class as the chef in the restaurant.
The request is the order.
The service class prepares the meal.
The response delivers the result.

Opening the Door: Exposing the Service

Creating a service class alone is not enough.

We must tell Dynamics - “External systems are allowed to call this service.”

This is done through a Service object in AOT.

Steps

Add new item → Service
Set properties:
- Class → `ProdTableService`
- External Name → same name
Add a Service Operation
Operation method: 'process'

This becomes the entry point for external systems.

The Service Group: Keeping Integrations Organized

In large projects, there may be dozens of services.

Without organization, things become messy quickly.

That’s where Service Groups come in.

Think of them as folders for integrations.

Example:

IntegrationServices
- ProductionService
- SalesService
- InventoryService

Grouping services helps teams manage integrations more effectively.

The Moment of Truth: Calling the Service

Once deployed, the service can be accessed through an endpoint.

Example format:
<D365URL>/api/services/<ServiceGroup>/<Service>/<Operation>

Example:
https://environment.cloud.onebox.dynamics.com/api/services/IntegrationServices/ProdTable/process

External tools such as Postman can be used to test the service.

A Simple Example Request

Example JSON request body:

{
  "_request": {
    "ItemId":"STD-AWMS-WP",
    "Qty":2500
  }
}

One important detail:

The `_request` wrapper must match the parameter name in the service method.

Otherwise Dynamics politely responds with an error message — which is the system’s way of saying:

"I received something… but I don’t understand what you want."

What Actually Happens Behind the Scenes

When a service call reaches Dynamics:

Request reaches the Application Object Server (AOS)
JSON is converted into a Data Contract object
The service method executes
The response object is created
Response is converted back into JSON
JSON is returned to the caller

All of this usually happens within milliseconds.

Final Thoughts: Services as Digital Bridges

Custom services are essentially bridges between systems.

They allow external applications to interact with Dynamics while ensuring:

Security
Structure
Business logic validation

Whether it's:

MES systems
Mobile apps
E-commerce platforms
Warehouse automation systems

Services make modern system integrations possible in Microsoft Dynamics 365 Finance and Operations.

Once you understand how they work, integrations stop feeling mysterious — and start feeling like well-structured conversations between systems.

Community site session details

When Systems Talk: Understanding Custom Services in Dynamics 365 F&O

A Word with a History: Where “Service” Comes From

The Pizza Principle: How Software Services Work

Why Custom Services Exist (And Why Direct Database Access Is a Terrible Idea)

The Anatomy of a Custom Service

The Request Class: Where Conversations Begin

Real-life analogy

Example Request Class

Why DataContract and DataMember Matter

The Response Class: What Dynamics Sends Back

Example Response Class

Real-life analogy

The Service Class: The Brain Behind the Operation

Example Service Class

Opening the Door: Exposing the Service

Steps

The Service Group: Keeping Integrations Organized

The Moment of Truth: Calling the Service

A Simple Example Request

What Actually Happens Behind the Scenes

Final Thoughts: Services as Digital Bridges

Comments

Introducing the 2026 Season 1 community Super Users

Congratulations to our 2025 Community Spotlights

Congratulations to the January Top 10 Community Leaders