Skip to main content

Power Automate Dataverse Connector: Get a Row by ID Is Missing — And How to Get It Back

UPDATE: This is only an issue in the "Old Designer". If you moved to the "New Designer" the actions still appear. I would recommend moving over to the new designer, since Microsoft is depreciating the old designer.

A recent change to the Microsoft Dataverse connector in Power Automate has left many flows broken or incomplete. The familiar Get a row by ID and List rows actions appear to have been removed from the connector's action picker in multiple environments — and the issue is reproducible across different browsers and machines, ruling out a caching problem. In their place, a new Search rows (preview) action has been introduced. This post documents the behavior and a working workaround for restoring Get a row by ID functionality using the Power Automate Tools Chrome extension.

What Changed

When adding a new Dataverse action to a Power Automate flow, the expected actions — Get a row by ID, List rows, and others — are no longer available from the action picker. The connector now surfaces a new Search rows (preview) action instead. Existing flows that already contain Get a row by ID are unaffected — those steps continue to function and can still be configured and interacted with normally. The limitation is specifically that the action can no longer be added as a new step to any flow.

The replacement Search rows (preview) action maps to two distinct underlying operations depending on how it is configured:

  • GetItem — retrieves a single record by its GUID (equivalent to the former Get a row by ID)
  • GetRelevantRows — performs a relevance search across one or more tables (a true search operation)

The Power Automate designer currently only exposes the GetRelevantRows search behavior through the UI, making it impossible to replicate a simple row-by-ID lookup without a workaround.

The Workaround

Two workarounds are available for adding a Get a row by ID step to a flow:

Option 1: Copy an existing action

If the flow (or another flow in the same environment) already contains a Get a row by ID step, use Power Automate's built-in Copy to my clipboard action menu option to copy that step, then paste it into the target location. The pasted action retains the original operationId and can be reconfigured as needed. This is the fastest path when an existing step is available to copy from.

Option 2: Edit the flow JSON using Power Automate Tools

When no existing Get a row by ID action is available to copy, the Power Automate Tools Chrome extension provides direct access to the underlying JSON definition of a flow. By adding a Search rows (preview) action through the designer and then editing the JSON to swap the operation and parameters, a proper GetItem call can be constructed and saved successfully.

Follow these steps for the JSON approach:

  1. Add a Search rows (preview) action to the flow in the Power Automate designer.
  2. Configure a placeholder — set the Table name and a Search term variable. The exact values do not matter at this stage.
  3. Open the Power Automate Tools extension in Chrome and navigate to the flow's JSON editor.
  4. Locate the Search_rows_(preview) block in the JSON.
  5. Modify the operationId and parameters as described below.
  6. Save the changes via the extension. The flow will update and display the action as expected.

JSON: Before (Search rows — GetRelevantRows)

When added through the designer, the Search rows (preview) action produces a definition similar to this — note the GetRelevantRows operationId and the SearchRequest/search and SearchRequest/entities parameters:

"Search_rows_(preview)": {
  "runAfter": {},
  "metadata": {
    "operationMetadataId": "5e0d20a1-ef74-4cb3-8408-743350c36691"
  },
  "type": "OpenApiConnection",
  "inputs": {
    "host": {
      "apiId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps",
      "connectionName": "shared_commondataserviceforapps",
      "operationId": "GetRelevantRows"
    },
    "parameters": {
      "SearchRequest/search": "@variables('RecipientUserID')",
      "SearchRequest/entities": [
        "systemusers"
      ]
    },
    "authentication": "@parameters('$authentication')"
  }
}

JSON: After (Modified to GetItem — Get a row by ID)

Replace the operationId with GetItem and swap the parameters block to use entityName (the logical table name) and recordId (the GUID of the record to retrieve). The metadata, type, host connection details, and authentication remain unchanged:

"Search_rows_(preview)": {
  "runAfter": {},
  "metadata": {
    "operationMetadataId": "fb50c17a-8fb3-4281-a7cc-d5366bcf7182"
  },
  "type": "OpenApiConnection",
  "inputs": {
    "host": {
      "apiId": "/providers/Microsoft.PowerApps/apis/shared_commondataserviceforapps",
      "connectionName": "shared_commondataserviceforapps",
      "operationId": "GetItem"
    },
    "parameters": {
      "entityName": "systemusers",
      "recordId": "@variables('RecipientUserID')"
    },
    "authentication": "@parameters('$authentication')"
  }
}

After saving, the step label in the designer will still read Search rows (preview), but the underlying operation will execute as a Get a row by ID call. Outputs from this action can be referenced downstream in the same way as the original action.

Key Differences at a Glance

Property Search rows (default) Modified (Get a row by ID)
operationId GetRelevantRows GetItem
Table parameter SearchRequest/entities (array) entityName (string)
Record identifier SearchRequest/search (full-text search term) recordId (GUID)
Returns Collection of matching rows Single row

Bug, Glitch, or Intentional Change?

At this point it is not clear whether this is a temporary glitch, an unintentional oversight during a connector update, or the beginning of a deliberate shift toward consolidating row retrieval under the Search rows action. The evidence cuts both ways. The fact that existing Get a row by ID steps remain fully functional and editable suggests this may not be an intentional deprecation — a planned removal would more likely affect all uses of the operation, not just the ability to add new ones. On the other hand, the simultaneous disappearance of multiple actions across unrelated environments points to a deliberate connector metadata change rather than a one-off rendering issue.

Until Microsoft publishes official guidance, the workarounds above provide a reliable path forward. Monitor the Power Automate blog and the Power Platform admin center for any communication regarding changes to the Dataverse connector.

Labels:

Comments

Post a Comment

Popular posts from this blog

Validating User Input In CRM Portals With JavaScript

When we are setting up CRM Portals to allow customers to update their information, open cases, fill out an applications, etc. We want to make sure that we are validating their input before it is committed to CRM.  This way we ensure that our data is clean and meaningful to us and the customer. CRM Portals already has a lot validation checks built into it. But, on occasion we need to add our own.  To do this we will use JavaScript to run the validation and also to output a message to the user to tell them there is an issue they need to fix. Before we can do any JavaScript, we need to check and see if we are using JavaScript on an Entity Form or Web Page.  This is because the JavaScript, while similar, will be different.  First, we will go over the JavaScript for Entity Forms.  Then, we will go over the JavaScript for Web Pages.  Finally, we will look at the notification JavaScript. Entity Form: if (window.jQuery) { (function ($) { if ...
23 comments
Read more

Power Pages Update Last Successful Login Using JavaScript and Power Pages API

 Recently while working on a Power Pages implementation for a client, I had the requirement to show the last time a user logged in on their profile page.  I thought this would be easy to do as there is already a field on the contact record for "Last Successful Login" (      adx_identity_lastsuccessfullogin).  This use to update when a user logged in, but it appears Microsoft has removed that automation. While searching I came across a few different ways of achieving this task.  One used application insights in Azure and another one used an HTTP endpoint setup in Power Automate.  I thought, this needs to be simpler.  What I came up with is to use Liquid with JavaScript to tell if a user is logged in or not.  Then use the new Power Pages api to update the logged in users contact record to mark the last time they logged in. Here is the approach I setup: 1) Make sure you turn on the api for contact in Site Settings. 1) Link to Microsoft Do...
94 comments
Read more

Reusable Method To Get Record By Id

I have a handful of reusable code that I use when creating plugins or external process (i.e. Azure Functions) for working with DataVerse. The first one I am providing is Getting a Record By Id: 1: private static Entity GetFullRecord(string entityName, string primaryKey, Guid recordId, IOrganizationService service) 2: { 3: using (OrganizationServiceContext context = new OrganizationServiceContext(service)) 4: { 5: return (from e in context.CreateQuery(entityName) 6: where (Guid)e[primaryKey] == recordId 7: select e).Single(); 8: } 9: } entityName = The logical name of the entity primaryKey = The primary key field for the entity. If using late binding you can create this dynamically by doing: $"{target.LogicalName}id" recordId = Guid of the record to get service = Service to interact with DataVerse
7 comments
Read more