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,
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?
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.
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.
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!
For quite a long time, we have been running a local service called SkolniLogin.cz which primarily focused on providing SSO experience for various systems at schools (primary and high schools) along with automatic synchronization with the school’s information system. Throughout the time we have hit a lot of edge scenarios, and compiled a best practices guideline.