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
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

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...

2 days 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...

3 days 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...

1 month 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...

2 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...

4 months ago

Dataverse Integration Patterns: Sync vs Async vs Event-driven (Real Use Cases)

As organizations start using Microsoft Power Platform, Microsoft Dataverse is no longer just a place to store data—it becomes a key part of ho...

4 months ago

Book Review : Don't Believe Everything You Think by Joseph Nguyen

My second book of this year is "Don’t Believe Everything You Think" by Joseph Nguyen. This book was recommended by a friend who strongly belie...

5 months ago

Book Review : Scary Smart by Mo Gawdat

The first book I read in 2026 was Scary Smart by Mo Gawdat, the former Chief Business Officer at Google.In today’s world, Artificial Intellige...

6 months ago

Managing Temporary User Access in Dataverse with Access Teams

Access Teams let you give people access to one specific record, not the whole table.Access Teams in Microsoft Dataverse are a powerful way to ...

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.