Loading...

Bound vs Unbound Custom APIs: How to Decide

Bound vs Unbound Custom APIs: How to Decide

Choosing between a bound and unbound Custom API in Dataverse depends on the scope and context of the business logic you need to implement. A bound Custom API is linked directly to a specific table or record, making it ideal when your logic operates on a single entity—such as approving an Opportunity, recalculating a Quote Line, or validating a Case—while also benefiting from inheriting the table’s security model and enabling easy form or ribbon integration. In contrast, an unbound Custom API runs at the organizational level and is not tied to any single table, making it the better choice for cross-entity operations, batch processing, orchestration logic, or reusable services such as compliance checks or data synchronization. In general, use a bound API when your logic is entity-specific and user-triggered, and choose an unbound API when your logic is global, shared, or not dependent on record context.



 In Microsoft Dataverse, Custom APIs allow you to define your own operations that can be invoked from plugins, Power Automate, JavaScript, Canvas Apps, external applications, and more.

A Custom API can be:
  • Bound → tied to a specific table (entity)
  • Unbound → not tied to any table; operates at the organization level

Both serve different purposes, and choosing correctly is key to designing clean, maintainable server-side logic.

1. What Is a Bound Custom API?

A Bound Custom API is associated with a specific Dataverse table.
This means:

It runs in the context of a record or a table

It can be executed for:
  • A single record
  • Multiple records
  • The table itself (entity-level binding)

Examples of When a Bound API Is Suitable
  • Approve or Reject an Opportunity
(Because the logic applies to a specific Opportunity record)
  • Recalculate price for a Quote Line
(Action applies to that row)
  • Close a Case with extra validation
(Bound to incident table)
  • Generate a Document for a Given Account
(Logic depends on the Account ID)

Characteristics



Why Use It?
  • When the logic is directly tied to an entity field or lifecycle
  • When you want to enable easy use from command bar or ribbon
  • When you want row-level security to apply naturally
What Is an Unbound Custom API?
  • An Unbound Custom API is not tied to any specific table.
  • It operates at the global, organization, or system level.

Examples of When Unbound Is Suitable
  • Running a batch job
    • Recalculate scores for all customers
    • Synchronize data with external API
    • Trigger a search or indexing process
  • Orchestration logic
    • Run end-of-day processing
    • Run compliance rules
    • Generate summaries or analytics
  • Reusable services
    • Currency conversion
    • Validation against external services
    • Global configuration fetch
Characteristics

Why Use It?

  • When the logic is not tied to a record
  • When you need a shared service across multiple tables
  • When you require batch processing
  • When you want clean separation from entity-level triggers
Choosing Between Bound vs. Unbound (Decision Framework)

Use this checklist to make the right decision:

A. Is the logic specific to one record or one table?

Yes → Use Bound

No → Use Unbound

B. Does the user need to trigger the API from a form or grid?

Yes → Use Bound (easier ribbon integration)

No → Either type is OK

C. Should row-level (record-level) security apply?

Yes → Bound (inherits table permissions)

No → Unbound (requires custom privilege)

D. Do you need global operations across multiple tables?

Yes → Unbound

E. Is this logic a reusable service used by multiple entities?

Yes → Unbound is usually better

F. Will this be called from external systems via Web API?

Both work, but:

Bound → easier when passing a single record

Unbound → easier for complex automation and reporting

Real-World Examples to Clarify the Difference


When You Should Avoid Bound APIs

Avoid Bound APIs when:
  • Logic affects multiple records across several tables
  • Logic does not use any entity fields
  • Security should not depend on record access
  • You need global or scheduled execution (Power Automate)
Because Bound APIs:
  • Cannot be triggered without a record reference
  • Are awkward for batch operations

When You Should Avoid Unbound APIs

Avoid Unbound APIs when:
  • The logic is clearly tied to one record
  • You need ribbon commands on forms (extra setup for unbound)
  • You want to leverage natural Dataverse security
Because Unbound APIs:
  • Require custom privilege setup
  • Cannot automatically inherit table permissions

Conclusion

Choose Bound Custom APIs when your logic is entity-specific, user-triggered, and security-inheriting.

Choose Unbound Custom APIs when your logic is global, batch-oriented, reusable, or unrelated to a specific table.



Published on:

Learn more
Need help with this product?

We can help you with Bound vs Unbound Custom APIs: How to Decide

If you want help implementing, troubleshooting, or improving this product, contact us and we’ll point you in the right direction.

Power Platform , D365 CE & Cloud
Power Platform , D365 CE & Cloud

Dynamics 365 CE, Power Apps, Powerapps, Azure, Dataverse, D365,Power Platforms (Power Apps, Power Automate, Virtual Agent and AI Builder), Book Review

Share post:

Related posts

Copilot Studio: Agent Integration Approaches — Tools, Knowledge, and Agents

In Copilot Studio, agent integration employs the same fundamental integration concepts and patterns used in traditional enterprise integration...

1 month ago

Copilot Studio: How to Plan Integration with Enterprise Systems

Integrating Microsoft Copilot Studio agents with enterprise systems transforms a basic chatbot into a secure, intelligent digital teammate tha...

1 month ago

Book Review : The Manager 's Path : A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier

 After a long time, I came across a book that is truly valuable for engineering students and professionals, especially those working in t...

1 month ago

Power Platform Environment Deep Dive (Part 2)

In Microsoft Power Platform, choosing the right environment type is important because each environment is designed for a different business pu...

1 month ago

Power Platform Environment Deep Dive (Part 1)

Today, in the business enterpriese world, Power Platform enables organization to build application, automate workflow, analyze data  crea...

1 month ago

Book Review : Life 3.0 by Max Tegmark

This is the third book I’ve read this year, and even though I’m still in the early chapters, it already feels like my favorite read of the yea...

2 months ago

Dataverse Views Demystified: Making Data Work for You

In Microsoft Dataverse, users do not always see all the data stored in a table. What they can view depends on their security permissions, role...

3 months ago

Decode & Fix : Shared App host initialization has timed out in Microsoft Power Apps

 Issue :While working with apps in the Microsoft Power Platform, we encountered a critical issue where the application failed to load pro...

6 months ago

Newsletter

Get the latest Dynamics 365 and Power Platform content in your inbox

A curated digest of community blogs, product news, videos, and podcasts — delivered without the noise.

Weekly updates Unsubscribe anytime Fresh community picks
We use your email only for the newsletter and you can unsubscribe at any time.
By subscribing, you agree to the privacy policy.