Extend Your Solutions: Custom API + Field Mapping in Dataverse

Dataverse powers the heart of the Microsoft Power Platform, offering a rich relational data layer and a suite of tools for makers and developers. While low-code configurations can solve many business needs, there comes a point when complex business logic demands more.

Enter Custom APIs—your way to encapsulate server-side logic in a secure, reusable, and solution-aware package. Combine this with Field Mapping—which ensures automatic data population between related tables—and you unlock a powerful pattern for building sophisticated enterprise apps.

In this post, we’ll do a deep technical dive into:

  • What Custom APIs and Field Mapping are
  • Why they’re better together
  • Real-world scenarios
  • Best practices
  • Pitfalls to avoid

What is a Custom API?

Custom APIs let you define your own operations in Dataverse, complete with input/output parameters and server-side logic. Unlike workflows or Power Automate flows, they’re built for high performance and enterprise ALM.

Features of Custom APIs

  • Entity-bound or global
  • Secure (role-based access)
  • Plugin integration for C/JavaScript logic
  • Solution-aware for ALM pipelines
  • Callable from Power Apps, Power Automate, or even external systems

Example: Create a `SubmitServiceRequest` API that accepts `CustomerId` and `PriorityLevel`, and returns a `ConfirmationNumber`.

What is Field Mapping?

Field Mapping defines how attributes from one table populate another during create or update operations.

Say you're creating a Work Order from a Case:

  • `Case.Title` → `WorkOrder.Name`
  • `Case.Customer` → `WorkOrder.Account`
  • `Case.Address` → `WorkOrder.Service Location`

This ensures consistency without manual intervention.

Why Combine Custom API and Field Mapping?

By combining both:

  • Custom APIs handle business logic (create child record, call external APIs, enforce validations).
  •  Field Mapping automatically pre-fills related data.

This pattern creates clean separation of concerns:

  • No duplicated UI logic
  • Easier testing
  • Faster iterations

Real-World Use Case: Field Service Automation

Problem

When a case is escalated, you need to:

  • Create a Work Order.
  • Auto-populate customer info.
  • Send notifications.

Solution

  • Custom API handles creation and notifications.
  • Field Mapping pre-fills customer-related fields.

How to Implement (Step by Step)

Define a Custom API

In Dataverse:

 Go to Solutions > New > Custom API

 Set:

  • Name: `SubmitServiceRequest`
  • Binding Type: Entity-bound (bind to `incident`)
  • IsPrivate: `No`

Create Plugin Logic

public void Execute(IServiceProvider serviceProvider)

{

    var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));

    var service = (IOrganizationService)serviceProvider.GetService(typeof(IOrganizationService));


    Guid customerId = (Guid)context.InputParameters["CustomerId"];

    string priority = (string)context.InputParameters["PriorityLevel"];


    var workOrder = new Entity("msdyn_workorder")

    {

        ["customerid"] = new EntityReference("account", customerId),

        ["prioritycode"] = priority == "High" ? 1 : 2

    };


    Guid woId = service.Create(workOrder);

    context.OutputParameters["ConfirmationNumber"] = $"WO-{woId.ToString().Substring(0, 8)}";

}

Register this plugin step to your Custom API.

Configure Field Mapping

In the `incident → msdyn_workorder` relationship:

Map:

  • title` → `name`
  • customerid` → `serviceaccount`
  • `description` → `instructions`

Call from Power Apps

Patch(

    'SubmitServiceRequest',

    Defaults('SubmitServiceRequest'),

    {

        CustomerId: GUID(txtCustomerId.Text),

        PriorityLevel: drpPriority.Selected.Value

    }

)

Power Automate:

 Dataverse Connector → Perform a bound action → Select `SubmitServiceRequest`

Benefits


Limitations



Best Practices


Summary

Combining Custom APIs and Field Mapping allows you to build powerful, reusable, and maintainable enterprise-grade solutions in Dataverse. It separates UI from business logic while reducing duplication and ensuring consistent data handling.

Whether you’re a pro developer or a solution architect, this pattern will level up your Dataverse projects.

Comments

Popular posts from this blog

Effective Strategies for Debugging Plugins in Dynamics CRM

Connecting the Dots: FetchXML and Web API Integration in Dataverse

Exploring the Differences: Managed vs. Unmanaged Solutions in Dynamics CRM/Dataverse

Decode and Fix: “This Data Type is Unsupported for Evaluation” in Power Apps

L1, L2, and L3 Support Explained

Model-Driven Apps Command Bar: A Guide to PrimaryControl and SelectedControl

Stop Struggling with Plugins: Learn IOrganizationService the Smart Way

How to Write and Understand a Dynamics CRM Plugin

Plugin Execution Pipeline Demystified: A Must-Know for CRM Architects

How Every Plugin Action Travels Through Request, Service, and the Pipeline