Share via

Source Control for Power Platform not working properly

Thomas Lüscher 0 Reputation points
2026-06-05T20:14:16.5866667+00:00

Dear Customer Support

I have a DEV environment connected (as a solution) to a azure devops git repo (branch MASTER).

I have a PLAYGROUND environment connected (as a solution) to a azure devops git repo (branch FEATURE, which branched off of MASTER). The PLAYGROUND environment is an exact copy of DEV.

My plan is to make changes in DEV, commit them to branch MASTER, merge the changes (via pull request) from MASTER into branch FEATURE, and pull the changes to the PLAYGROUND environment.

However, I face the following challenges:

  1. Whenever I make a commit in DEV, I get the error message "An unexpected error occurred." However, the commit seems to have been successful according to azure devops.

2.When I make a "Check Updates" in PLAYGROUND environment after having merged the MASTER branch into the FEATURE branch, I get 86 updates all having to do with appactions. If I pull, I get asked if I want to remove them from the solution or from the environment. If I choose environment, I get the error "The 'Delete' method does not support entities of type 'appaction_appactionrule_classicrules'. MessageProcessorCache returned MessageProcessor.Empty.". If I choose solution, I get a message saying "Pull request completed successfully". However, none of the changes arising from the fact that I have just merge another branch (MASTER) into my branch (FEATURE) is displayed.

How to fix this?

Azure DevOps

2 answers

Sort by: Most helpful
  1. Pravallika KV 17,025 Reputation points Microsoft External Staff Moderator
    2026-06-05T20:29:43.1233333+00:00

    Hi @Thomas Lüscher ,

    It sounds like you’re using the Power Platform (native) source control integration with Azure DevOps Git, and you’re hitting two related symptoms: (1) an “unexpected error” on commit in DEV, and (2) a “pull/check updates” that brings appaction-related changes but fails to apply them (or reports success yet doesn’t actually bring over the merged code changes).

    Based on the documentation provided, here are the key points you can use in a forum response and the likely areas to investigate.

    1) About your intended branching workflow

    The native source control integration is designed around working with branches you bind to environments/solutions, but there are important constraints:

    • The feature “currently works with a single branch that you specify when you bind the environment or solutions to your repository.”
    • Deployment-style workflows (DEV → PR → merge → propagate to another environment) are possible, but the recommended way to move changes to upstream environments is typically via:
      • export/build from source control, or
      • pipelines, rather than expecting the environment “pull” to behave exactly like a classical release pipeline.

    So, with your setup (DEV bound to MASTER, PLAYGROUND bound to FEATURE, and you merge MASTER into FEATURE), the “Check Updates” behavior depends heavily on how the integration interprets changes for your specific solution components.

    2) Why you might see unexpected errors or appaction rule issues when pulling

    In your second issue, you specifically see errors mentioning:

    • appaction_appactionrule_classicrules
    • delete not supporting that entity type
    • sometimes “Pull request completed successfully” but the expected changes don’t show in the environment

    While the provided docs don’t mention appaction_appactionrule_classicrules specifically, they do highlight that the integration expects solution component changes to be represented correctly when syncing/pulling, and that managed vs unmanaged representation is handled differently now:

    • “Git should only include your source code and unmanaged customizations.”
    • “Managed versus unmanaged is determined when building and releasing the solution.”

    If your merge causes changes that the sync engine interprets as removals/updates of objects that can’t be deleted in that form (or that don’t map cleanly into the integration’s expected entity handling), you can get exactly the kind of “Delete method does not support…” behavior you’re seeing.

    3) A common “fix path” suggested by the docs

    From the documentation provided, these are the most relevant troubleshooting/behavior points you can try:

    1. Disconnect and reconnect PLAYGROUND to the FEATURE branch
      • The FAQ notes you can “disconnect and reconnect to different branches” and pull latest changes that way.
      • This can help if the environment’s cached mapping between branch state and environment state got out of sync.
    2. Confirm the environment is correctly enabled for source control integration
      • If you ever see “Source Control Integration is not enabled for this environment,” the docs call out BYOK encryption as a cause and require re-connect after key changes.
    3. Confirm your repository/branch setup
      • The FAQ calls out that if the repo default branch isn’t initialized, some operations can fail. (Related to a different error message, but still worth verifying that MASTER/FEATURE are set up as expected.)
    4. Validate that what you expect to deploy is the right kind of artifact
      • If the integration is expecting unmanaged/source-code style items in Git, but your process effectively relies on managed solution content changes being represented directly, the pull may not result in the objects you expect in the environment.

    It looks like you’re using the native Power Platform source control integration with Azure DevOps Git, where each environment/solution is bound to a specific branch. Since the integration currently “works with a single branch that you specify when you bind the environment or solutions,” merges you do in Azure DevOps don’t always translate 1:1 into what the environment pull will apply, especially if the changes include objects that the integration can’t delete/reconcile cleanly.

    Please try disconnecting and reconnecting the PLAYGROUND environment to the FEATURE branch, then pull again. Also ensure your Git repo contains the expected unmanaged/customization representation (managed vs unmanaged is determined during build/release), and confirm the environment is properly enabled for source control integration.

    Hope this helps!


    If the resolution was helpful, kindly take a moment to click on User's imageand click on Yes for was this answer helpful. And, if you have any further query do let us know.

    Was this answer helpful?


  2. AI answer

    2026-06-05T20:14:51.74+00:00

    The described behavior aligns with current limitations and expected behavior of Dataverse Git integration rather than a misconfiguration in Azure DevOps.

    Key points from the supported model:

    1. Single-branch binding per environment/solution
      Git integration for solutions is designed to work with a single branch at a time. The environment/solution is bound to that branch, and all commit/pull operations are scoped to it. Branching and merging (e.g., MASTER → FEATURE) are expected to be handled in Git (Azure DevOps), and then the environment is re-bound if needed. From the documentation:
      • The feature currently works with a single branch that is specified when binding the environment/solution to the repository.
      • Environments can be disconnected and reconnected to different branches, and Azure DevOps is used for PRs and merges.
      Recommended pattern:
      • Connect DEV to a “developer” branch.
      • Use PRs in Azure DevOps to merge into other branches (e.g., MASTER or FEATURE).
      • Disconnect and reconnect the solution in the target environment to the branch that should be the source of truth when needed.
    2. Unexpected error on commit in DEV
      The context does not provide a specific root cause for the generic “An unexpected error occurred” message when committing, but it confirms that:
      • After connecting to Git, changes are tracked in Dataverse and committed via the Source control page.
      • Conflicts must be resolved first; then changes should be pulled, validated, and only then committed.
      Given that the commit appears in Azure DevOps, the error is likely in the UI/operation layer rather than the Git operation itself. The supported mitigation path is:
      • Ensure all conflicts are resolved on the Conflicts tab.
      • Pull any updates from Git first, validate the app, then commit again.
      • If the error persists while commits still succeed, this is a platform issue and should be escalated via Microsoft Support.
    3. Appaction-related updates and delete prompts in PLAYGROUND
      When pulling updates:
      • The system checks for objects deleted in Git and prompts whether to remove them from the solution (object remains in environment) or delete them from the environment.
      • This is expected behavior: deletions in Git must be reconciled either at the solution level or environment level before the pull completes.
      In the described case:
      • Choosing to delete from the environment triggers an error involving appaction_appactionrule_classicrules and a Delete method not supporting that entity type. This indicates a platform limitation/bug in handling deletions of those specific objects via Git integration.
      • Choosing to remove from the solution (object remains in environment) allows the pull to complete successfully, but the expected merged changes are not visible. This suggests that the incoming changes are primarily deletions or that the environment’s solution state and the branch’s YAML state are out of sync.
      Supported remediation steps within the documented model:
      1. On the PLAYGROUND environment’s solution Source control page:
        • Resolve all conflicts first, explicitly choosing either “keep existing changes” (environment) or “accept incoming changes” (Git) per object.
        • After conflicts are resolved, pull updates again.
      2. If the appaction deletions continue to fail when deleting from the environment:
        • Prefer the “remove from solution” option so the pull can complete.
        • Then manually adjust the solution content (e.g., re-add or remove the relevant components) and commit back to Git.
      3. If the solution still does not reflect the merged MASTER→FEATURE changes after a successful pull:
        • Disconnect the PLAYGROUND solution from Git.
        • Reconnect it explicitly to the FEATURE branch again, ensuring the branch is initialized and up to date.
        • Use Check for updates and Pull once more.
      4. If the behavior persists (especially the appaction_appactionrule_classicrules delete error), this falls outside the documented normal flow and should be handled by Microsoft Support as a product issue.
    4. Working model recommendation for the scenario
      Within the supported pattern:
      • Keep DEV bound to a single branch (e.g., a dev branch). Commit all changes from DEV there.
      • Use Azure DevOps PRs to merge from the dev branch into MASTER and/or FEATURE.
      • For PLAYGROUND, either:
        • Bind directly to the branch that should drive it (e.g., FEATURE), or
        • Disconnect/reconnect when switching which branch should supply updates.
      • Always resolve conflicts on the Source control page, pull, validate, then commit.

    If the generic commit error in DEV and the appaction_appactionrule_classicrules delete error continue after following the above, the supported next step is to open a ticket with Microsoft Support, as these indicate platform-level issues not resolvable via configuration alone.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.