Key Tools and Browser Extensions for Dynamics and Power platform Developers:
- Level up for Dynamics (extension)
- Dynamics 365 Power Pane (extension)
- Microsoft power automate Desktop (extension)
Key Tools and Browser Extensions for Dynamics and Power platform Developers:
1. Artificial Intelligence (AI)
2. Machine Learning (ML)
3. Compute Vision
4. Natural Language Processing (NLP)
Principals:
Overview: General overview notes on setting up Power Platform projects/programs. Before I get into the mechanics, my overriding goal is to have high functioning teams, and be a member of high functioning teams. "Create an environment where team members can do there best work". for instance, I visit and work with a lot of businesses and I many teams that are in an "Artificial Harmony" state (pretend all is well with the world). Everyone says it's wonderful but it's a snake-pit with relationships and fear. Teams members need to be happy, open to conversations, accept risk and aware mistakes are going to happen. Basically, these teams need to be identified and trust build, this often involves an adjustment to a particular mid-level manager. The worst offenders tend to be offshore teams, and there are amazing teams and people so this definitely is a generalization. The teams tend to be hierarchical as opposed to flat or matrix. it's terrible for software projects. Look out for Technical leads, ISV Project managers, Deliver Leads, they can breed the wrong tone/attitude across multiple team members and teams. Check out Amy Edmondson's book the Right kind of wrong: the Science of failing well. Anyway, rant over.
Learn from mistakes, simple mistakes, remove them ASAP, strategically think automation, if we learn mistakes ensure they don't happen on the next project or sooner. Encourage transparency, and open communication.
Here are my notes for setting up ADO and guidance for Agile PP projects....
Agile Artifact Hierarchy:
Epics > User Stories (max 5 days work) > Tasks
> Bugs
Epics > Spike
Guide:
Flow of bugs and User Stories:
Example Status's |
Release Notes for Power Platform packages need to include the following fields in ADO against artefacts:
Example of ADO Release Notes assigned against tasks, bugs, and user stories. |
Quick fixes/urgent bugs/Emergency changes:
https://www.cloudsecuritea.com/2019/09/generate-an-overview-of-all-microsoft-flows-with-powershell/
![]() |
Use postman to Interact with an API - get the bearer token first. |
Overview: Power Automate can set retry policies on custom connectors, Canvas apps using a Custom Connector, does not have any retry configuration. FYI is the Custom Connector gets a 5.x.x error it shall retry 4 times. Proven using 500 and 502 errors. 408 (timeout) and 429 (to busy) errors appear to throw 4 times (retry driven by canvas app; using the Custom Connector trigger shall only try once).
My example: My Canvas app uses a custom connector, that calls my Azure Function, in turn this calls my APIM, and APIM calls the 3rd party.
Possible remediation:
1. Return a 418 HTTP response code (I am a teapot), my app calls the function using the custom connector once. So using 418 (also tested with 400 - but 400 is not the right response) errors behaves differently from the 5xx, 408, 429 errors from the API.
Note: Originally I was caught out as I trigger using the custom connector test rig, this only tries once. But when called from Power Apps, it shall try four times. Returning 408 is not a fix. Returning 418 ensures I only try once, get a better user experience and now I have 418 logs that I add error details to.
2. 3rd party API should not take 35 seconds, improve it.
3. I could set my timeout on the specific function to 40 seconds, however if the call starts going to 41 seconds, my canvas app will be locked for over 160 seconds.
4. Go to all API's and if they are fast set the timeout as short as possible so the app does not get locked out while waiting for the 4 responses.
Summary: Examine the 3rd party API's, get them stable and performant and per the agreed SLA's. If you only want to try once ensure that time outs on the 3rd arty are set to the SLA or if you intercept the request, you can choose the timeout, by examining the API's you can see the optimum time to avoid timeouts and using the 418 response code, the call only happens once.
Series
App Insights for Power Platform - Part 1 - Series Overview
App Insights for Power Platform - Part 2 - App Insights and Azure Log Analytics
App Insights for Power Platform - Part 3 - Canvas App Logging (Instrumentation key)
App Insights for Power Platform - Part 4 - Model App Logging
App Insights for Power Platform - Part 5 - Logging for APIM
App Insights for Power Platform - Part 6 - Power Automate Logging
App Insights for Power Platform - Part 7 - Monitoring Azure Dashboards
App Insights for Power Platform - Part 8 - Verify logging is going to the correct Log analytics
App Insights for Power Platform - Part 9 - Power Automate Licencing
App Insights for Power Platform - Part 10 - Custom Connector enable logging
App Insights for Power Platform - Part 11 - Custom Connector Behaviour from Canvas Apps Concern (this post)
Overview: One of our developers was asking about a log he was struggling to trace, and it took me awhile and a lot of help from the community to truly understand the issue. My scenario is shown below:
Scenario: I have a Dataverse change triggering a flow, the flow calls a Custom Connector, that in turn calls an Azure Function (that I control). So the flow fails, and I have used a pattern in the flow to catch the error and log it into Log Analytics. All good, then I don't see the event where the action calls the function, my function has logging enabled. I can see I am getting a 401 unauthorized error.
Initial Hypothesis: The Power Platform use APIM internally to implement Custom Connectors, and there is no access for clients/tenants to see the internal logging/traffic. Microsoft have provide the ability to use iLogger on the custom connector to log the traffic.
We have flows that intermittently get a 401, when the flow is manually rerun, the flow works and I can see the traffic coming into the Function.
The failure rate is extremely low and retries almost always fix the issue, and a third try always ensures the transaction goes thru.
Resolution: Add logging to the custom connector so we can speak with MS support about the issue. Add alerting to notify support, they can contact the user or chose to rerun the flow.
Alternative: If I enable the code, I can override the behaviour and inject C# code to work with the backend, or handle logic such as replacing text,...
1. In step "4. Code" tab of the custom connector, add the code below:
You can do any C# logic, I'm sending the original request thru and if it doesn't return me a 200, I'm logging it as critical. |
2. Update the connector, go to the next step "5. Test" > "Update Connector" (Tip: follow the steps)
3. Run the "Test operation", open the Response and validate the response body is correct, then open the "Code logs" tab. If it is blank, re-run the "Update Connector" (irritating but true).
304 return from the API, which is cached and not a problem, but 400, 500 would be an issue, could also look out for 429s. |
public class Script : ScriptBase
{
public override async Task<HttpResponseMessage> ExecuteAsync()
{
this.Context.Request.Method = HttpMethod.Get;
HttpResponseMessage response = await this.Context.SendAsync(this.Context.Request, this.CancellationToken).ConfigureAwait(continueOnCapturedContext: false);
Context.Logger.LogTrace("Custom Connector ListBooks called ");
if (response.StatusCode == HttpStatusCode.OK)
{ Context.Logger.LogTrace("Success"); }
{ Context.Logger.LogCritical("Critical | " + response); }
return response;
}
}
More Info:
https://learn.microsoft.com/en-us/connectors/custom-connectors/write-code (NB)
https://never-stop-learning.de/logging-in-custom-connector-code/ (NB) The 2nd part of this post on the Alternative , is a rehash of this amazing post - I amended the logic and now I'm wondering is I could write to App Insights using the SDK?
Series
App Insights for Power Platform - Part 1 - Series Overview
App Insights for Power Platform - Part 2 - App Insights and Azure Log Analytics
App Insights for Power Platform - Part 3 - Canvas App Logging (Instrumentation key)
App Insights for Power Platform - Part 4 - Model App Logging
App Insights for Power Platform - Part 5 - Logging for APIM
App Insights for Power Platform - Part 6 - Power Automate Logging
App Insights for Power Platform - Part 7 - Monitoring Azure Dashboards
App Insights for Power Platform - Part 8 - Verify logging is going to the correct Log analytics
App Insights for Power Platform - Part 9 - Power Automate Licencing
App Insights for Power Platform - Part 10 - Custom Connector enable logging (this post)
App Insights for Power Platform - Part 11 - Custom Connector Behaviour from Canvas Apps Concern
WIP
Problem: Bugs must not change scope - common to see a bug and it morphs into improvements, other changes.
Fix: Raise new bug. Don't keep amending and adding new features.
Problem: Team testers/automation testers do not understand the requirement. Cause by the User Story (US) or bug being ambiguous and Acceptance Criteria (AC)
Fix: Ensure User Stories are in a standard format i.e. "As a <>, I want to <>, so that <>.". Ensure Gherkin is used for AC (Scenario, Given, When, Then, and preferably more than 1 AC per user story. Could have: Annotate diagrams to clearly convey artefact information. Also a narrated recording for bugs. This could be the person recording the bug, the person that fixed the bug as proof to increase understanding.