Hi, today I came across JSON parser error in Microsoft Flow. I used auto-generated schema and everything had been working just fine until a connector I used had started to return null values for strings.Continue reading “Quick Fix: Microsoft Flow Error – Invalid type. Expected String but got Null.”
If you are developing Model-driven app (business application) above the Microsoft Power Platform and you want to follow the best practices, you should deliver your complete solutions (zip packages) as managed solutions to all downstream environments.
Your goal should be to deploy your Model-driven app through AppSource. To achieve that, your app should be separated in smaller packages that can work on their own. For better understanding let’s say, that your app is separated in three main groups.Continue reading “Merging Forms and Views – managed vs unmanaged (Microsoft Power Platform and CDS)”
With v9 a lot of changed. One of the major changes is client web API, some of calls were made deprecated and some were added. For example, Xrm.WebApi.
The new ‘Xrm.WebApi.retrieveRecord(entityLogicalName, id, options).then(successCallback, errorCallback)’ can’t be made synchronous. But imagine situation, in which you need to go through multiple entities (lookups). In this scenario, you need the result of retrieved record to access the next record. So how can this be done?Continue reading “Making Xrm.WebApi.retrieveRecord Synchronous calls in Common Data Service (D365 fo CE)”
We have recently deployed a strict DMARC policy (p=reject; sp=reject) on our domains. While this adds greater security while sending e-mail and prevents spoofing, we noticed that certain mails forwarded within our organization stopped coming in.Continue reading “SendGrid, forwarding and DMARC policy”
There’s no breakthrough in this blogpost… It’s just to show you how does the new .csproj look like, what basic things can be done in msbuild and how-to setup ILRepack for common data service painlessly.
System.Runtime.Serialization.SerializationException: Type is not resolved for member ‘Newtonsoft.Json.JsonSerializationException’
If you ever run into this exception without any trace available it is most likely not like it seems. Microsoft’s internal wrapper for launching CodeActivity catches it and ignores your trace log entries. So if your code throws this exception the platform treats it like internal exception. It is probably because it serializes parameters for CodeActivity into JSON and this process can produce the same exception (in Microsoft’s internal code).
Hello there, fellow power platform customizers/developers! Have you tried to override the default open behavior in subgrid and failed?
What I’ve found in my research:
Documentation by Microsoft says: “You can now create a command definition for an entity with Mscrm.OpenRecordItem as the value of the Id attribute (<CommandDefinition> (RibbonDiffXml)), and define custom action for the command <Actions> (RibbonDiffXml). Customer Engagement will look for this command Id for an entity when you try to open a record from the entity-bound grid, and if present, will execute the custom action instead of opening the entity record (default behavior).”
IMPORTANT NOTE: This feature is supported only for Unified Interface.
Did this. No luck. What now? Google…
Sometimes we need to work with a variable inside a loop section. Whether it’s a precomputation or just a helper variable. Logic Apps allows us to do so. Yet the variable must be initialized on a global level (above all loops).
Here comes the problem:
By default, foreach runs in parallel, in 20 threads (instances). Now, because there is no such thing as mutex in Logic Apps, there is no way how to create a critical section. Critical section is a section only one thread at a time can enter. That results in dirty reads.
We can solve this problem by running the loop synchronously. You can do that by editing settings of the foreach block.
Now only one thread at a time will execute the foreach loop and no other thread will modify our variable while we work with it.
Finally, it’s the weekend and I have some time to focus on an issue which bothered our team for a few months. As always we wanted to do it the right way so it will be fast, reusable, continuous integration compatible and without spawning unnecessary workflows and plugin instances.
We have had the group-based licensing option available in preview for over a year. While this service is in preview, it makes provisioning hundreds of users from Active Directory really simple.
You simply create users in your on-premise Active Directory, assign them a valid User Principal Name, add them to the correct group and then sync them with Azure AD Connect, right? Not that fast cowboy!