By now I hope most people know the https://pcf.gallery (run by Guido Preite). A great page for sharing community components (PCF) and exposing awesome contributions to the rest of the world. 🌎
What I like about the PCF Gallery is the simplicity of the site only being about PCF components. This is why I asked Guido if we could create a similar site for other components regarding the Power Platform. He was so kind to share his code for the project, so Matt Beard and I decided to give it a go. 🤗
First out in list of future galleries is the CONNECTOR gallery . This site will contain all sorts of custom connectors for Power Platform that you can share with the community. If you want to contribute to this gallery, you only have to share the custom connector file you have on GitHub, and we will post it out!
There have been several posts on the environment variables, but I think Microsoft just released a pretty GREAT update recently. I honestly don’t have a clue when this function was released, but it made my day a LOT easier:) This is how we used to refer to Environmental Variables:
Sure you can migrate variables/records between systems and be sure to never overwrite, but it can be time consuming to maintain.
Microsoft has introduced environmental variables to Dynamics / Dataverse to fix this exact problem. You create a new Environmental variable in your solution, and you can se the value for each environment. Within CRM you can refer to the environmental variable instead of hardcoded values:)
Within the solution explorer you can add Environmental variables that can be used across the different systems. In this test I am using a variable to define what environment I am working in “Test or Production”.
I wont be writing about the Environment variables in detail, as you can read more about them in other posts, but I wanted to cover the new way of using this within Power Automate!
Accessing the Environmental Variables in Power Automate Flow
Start by creating a new Power Automate, and add compose function
Check out that bad boy! 🤗😎 No longer need for get record calls from entities etc. A nice improvement that will save a few minutes here and there.
There are many ways of getting the current environment URL, but this is the quick and dirty version of doing just this 😏 Next week I will post about Environment variables as I know this is a possible approach that is better.
The intention about this blog is to show how to use Json to parse just a small part of an action body to get what you want exposed.
So this could be a typical flow in Power Automate for Dataverse. We have a trigger on top and an action below to get more data from the element that triggered.
The BODY of the trigger doesn’t contain environment information, but only Opportunity data:
But the Action contains a lot more interesting data for this.
In order to get this data we need to parse the Json returned here to retrieve the “Odata.ID” that includes the URL for our environment.
Even though we all wish it wasn’t so, Document Locations still rule the integrations between Dynamics 365 and SharePoint. I’m not saying that I have a better idea what would be a smarter way of solving it, but it all seems a bit “2011” ish.
Last week I encountered a problem with the Document Locations for Teams, and I was surprised when I couldn’t find them in the Document Locations at first. The list only contained the SharePoint sites that the standard SharePoint connector uses.
In this list I was missing all of the Teams locations. Turns out that the view is only showing Active SHAREPOINT locations.. hehe
All you have to do is add the “MS TEAMS” to the search, and you should see all of the document locations for that also
After a lot of painful digging I finally found the issue. Someone had decided to install SharePoint in Norwegian when they first setup the tenant!!! hehe. This meant that the URL the SharePoint URL was wrong.
Wrong URL ⛔
Correct URL ✅
Microsoft Support didn’t see a fix in the near future for language support, so I guess it’s time for a small work around 🙂 Not really exciting fix, but you need to create a Workflow or Power Automate on create to change the name of the document location to your local language.
Why a workflow you may ask? When is the last time a workflow failed you I answer 😎
WOW… Simply WOW. It’s the best way to summarize this years hackathon.
Normally this 3 day hackathon is situated in the beautiful hill of Holmenkollen, but this year we were forced to go online for obvious reasons. One little difference we did do was to open up for teams to gather locally at their companies offices. This way we could add a social factor within safety regulations without having to keep everyone 100% at home office.
We decided to have a participation fee for the event, and everything that was extra would be given to children’s cancer www.barnekreftforeningen.no ❤
This project has consumed most of my time the last few months being a part of the committee, and getting it all together has not been easy.
We were 5 teams total and almost 40 participants that dedicated 3 whole days of fun where this years topic was LEGO.
I have allready posted about the Customer Lookup, but there is a bug ATM that will prevent you from setting the customer lookup correctly.
Luckily Microsoft has provided us with a temporary workaround while they figure out how they are going to support polymorphic lookups like Customer in dataflows 👌
When trying to map customer lookup you won’t be able to see the correct lookup in the DataFlow. It may differ what you see, but it could be a different combination of fields like this:
All of the fields that have “Fieldsomething.Fieldsomethingelse” are lookups. The Customer lookup does not work as intended here, even though the field “ParentCustomerID” is the correct field to use. In a previous post I showed how to get around this issue, but Microsoft removed the projects configuration options. After talking to support, they showed me how to make it work again !!🙏💪
In our system for billing, we have the following structure. A debitor (aka Account), can potentially have lots of projects connected. The only way to connect data in DataFlow is via KEY’s in the Dynamics configuration. In our case we have a key “AccountVAT”. This ID is a unique organization number used in Norway.
Both tables know AccountID, but only the Account table holds the AccountVAT number. As you see on the image above, the Project doesn’t know what AccountVAT to connect to. Lets fix that.
So I load up my 2 tables in dataflow. If you wonder how this is done, check my other posts on DataFlow.
Select the MERGE QUERIES option
Here we match the 2 tables based on AccountID. As you see here there are lots of options for matching, but now you also get a nice visual for matching status at the bottom.
Next step is choosing what data to “join” into the projects table.
So I select the AccountVAT number as the field to join.
As you see in the picture below, the Debitor.Foretaksnr is now visible. This column is now joined from the Debitor table to the Project table.
The selected row below is a special field. You see that the Debitor.foretaksnr is a field in another table, and you see the destination field being special. The destination field is of type Lookup, and is expecting “AccountNumber” as matching.
The result is projects record linked to the correct account in CRM 👍💪
I applaud Microsoft for listening and moving in the right direction🙏🙌👍, but they seem to still be missing the point of SAAS for Dynamics 🤷♂️.
Think of Dynamics like a phone with storage. The OS takes up parts of the storage and you can freely use the rest of the storage.
The whole point of SAAS is that I am paying for a service. I am not buying any hardware and installing something from scratch. I am a part of a larger shared solution, where I pay for what I use. Either include the system tables in the price, or reduce the storage included in Dynamics. Either way it is only reasonable for a customer in SAAS to pay for what they produce of data.
Thank you for all the votes and the attention that this received, because it only goes to show that Microsoft does actually listen if we come together. In the future I hope we use our voices more often, because the number of votes on these issues are nothing compared to the number of consultants out there. We need to come together in numbers 🙂
MAAAAAASIVE update in the search experience for Dynamics, and I am extremely excited about it. The global search has received a major face-lift and is now looking really good. I personally never used the old relevance search, because I thought it looked bad and was confusing for the end customer.
My customers personally fond this search confusing when the database started to grow. I therefore always told the users to chose categorized search instead.
This way it was easier for the user to find the Accound/Contact/Oppty they were looking for.
New Search experience ✨🎉👍
The new search places the search bar in the middle on top, just like many other office applications. A fairly intuitive placement for the global search, and the results look awesome!!!