In scalable Power Platform solutions, it’s common to build flows that interact with multiple Dataverse tables — especially when records share a common process such as approvals, logging, or status updates. These flows often need to determine the correct table at runtime, without hardcoding logic for each entity.
Typical use cases include:
- Approval workflows triggered by various record types across departments
- Audit logging that tracks changes across multiple entities
- Status updates pushed from external systems into Dataverse
- Generic notifications or escalations tied to different business objects
To keep flows modular and maintainable, you can dynamically extract the entity name, pluralise it, and route the update to the correct Dataverse table — all within a single Power Automate flow.
Extracting Entity Metadata
Start by capturing the following fields from your trigger or input payload:
EntityLogicalName
— e.g.contact
,opportunity
EntityId
— the GUID of the recordType
— optional, useful for polymorphic lookups
Use a Filter array or Parse JSON action to isolate these values. Then extract them with expressions like:
first(body('Filter_array_EntityLogicalName'))?['value']
replace(replace(first(body('Filter_array_EntityId'))?['value'], '{', ''), '}', '')
If your payload uses type
instead of value
, adjust accordingly:
first(body('Filter_array_EntityType'))?['type']
Extracting Entity Metadata
Start by capturing the following fields from your trigger or input payload:EntityLogicalName
— e.g.contact
,opportunity
EntityId
— the GUID of the recordType
— optional, useful for polymorphic lookups
first(body('Filter_array_EntityLogicalName'))?['value']
replace(replace(first(body('Filter_array_EntityId'))?['value'], '{', ''), '}', '')
type
instead of value
, adjust accordingly:
first(body('Filter_array_EntityType'))?['type']
Pluralising the Table Name
Dataverse uses pluralised Entity Set Names in its Web API and connector actions. These names aren’t always intuitive, so here’s a basic expression to handle common pluralisation rules:
if(endsWith(outputs('Compose_EntityLogicalName'), 'y'),
concat(substring(outputs('Compose_EntityLogicalName'), 0, sub(length(outputs('Compose_EntityLogicalName')), 1)), 'ies'),
if(or(endsWith(outputs('Compose_EntityLogicalName'), 's'), endsWith(outputs('Compose_EntityLogicalName'), 'x'), endsWith(outputs('Compose_EntityLogicalName'), 'z'), endsWith(outputs('Compose_EntityLogicalName'), 'ch'), endsWith(outputs('Compose_EntityLogicalName'), 'sh')),
concat(outputs('Compose_EntityLogicalName'), 'es'),
concat(outputs('Compose_EntityLogicalName'), 's')))
Routing the Update
Once you’ve pluralised the table name, use a Switch control or a lookup table to route the update. This keeps your flow modular and avoids hardcoding logic.
Example mappings:
contact
→contacts
opportunity
→opportunities
clientrecord
→clientrecords
For maximum flexibility, store these mappings in a Dataverse table with columns for LogicalName
and EntitySetName
. This allows you to override edge cases and future-proof your flow.
Handling Polymorphic Lookups
In polymorphic scenarios, the type
or EntityLogicalName
becomes essential. Use it to:
- Determine which Dataverse table to query or update
- Log activity against the correct entity without hardcoding
- Build scalable flows that adapt to new entities over time
This approach supports modular architecture and aligns with governance-first design principles.
Final Thoughts
By extracting and pluralising entity names dynamically, you can build flows that are scalable, governance-friendly, and easy to maintain. This technique empowers you to handle diverse record types without duplicating logic — ideal for consultancy-grade builds where flexibility and clarity are paramount.