Bound vs Unbound Custom APIs: How to Decide
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.
- Bound → tied to a specific table (entity)
- Unbound → not tied to any table; operates at the organization level
- A single record
- Multiple records
- The table itself (entity-level binding)
- 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)
- 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
- An Unbound Custom API is not tied to any specific table.
- It operates at the global, organization, or system level.
- 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
- 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
- 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)
- Cannot be triggered without a record reference
- Are awkward for batch operations
- 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
- Require custom privilege setup
- Cannot automatically inherit table permissions
Published on:
Learn moreRelated 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...
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...
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...
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...
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...
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...
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...
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...
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 ...
