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.