Nishant Rana

How to – Delete solution components from Managed Solution without “Clone Solution” in Dynamics 365

Recently while moving a managed solution from Development to Test, UAT and Production Environment, we realized the if we increase the version number of the solution manually during export and try importing it, we get the option of Stage for Upgrade + Applying Solution Upgrade.

This is basically the same option we get when we clone the solution and use it for deleting the component or working with patch solution.

https://nishantrana.me/2016/10/16/how-to-delete-components-from-managed-solution-in-dynamics-crm-2016-without-using-holding-solution/

https://nishantrana.me/2016/09/22/creating-patches-solution-management-in-crm-2016/

So basically wanted to check if we can remove components from solution by simply increasing the version number, instead of cloning the solution.

Created a solution in Dev, added a custom entity with a field named test field.

Exported it as managed and imported in the Test (version 1.0.0.0).

Then removed the field from dev.

And increased the version number to 1.1.0.0 before exporting it as managed.

While importing selected Stage for Upgrade and Overwrite Customizations. Maintain customizations should also work.

After successful import, selected Apply Solution Upgrade.

The solution upgrade was successful.

And it removed the field.

So basically, we do not need to clone a solution explicitly in our Dev, we can increase the version number while exporting and select Stage for Upgrade + Apply Solution Upgrade to remove\delete the components.

Hope it helps..

SecLib::AccessCheckEx failed ObjectTypeCode: 2500 AccessRights: WriteAccess error on User Entity UI Settings in Dynamics 365

Recently one of users started getting the below error when he tried to open a record from grid.

Details: –

We checked, and the user was having the Write Access to User Entity UI Settings entity (2500) through the Team’s security role that he was member of but wasn’t having the rights through the security role assigned to him.

The first arrow shows the missing Write access through a security role assigned to the user and remaining are Write access through the Teams he is part of.

To fix the issue we had to give Write access to the user on the security role directly assigned to him. Basically, user needs to have this right explicitly in his role, as it is User specific entity.

The helpful posts

http://mscrmshop.blogspot.ae/2012/12/strange-behaviour-when-using-security.html

http://piers7.blogspot.ae/2011/05/permissions-issues-in-dynamics-crm-2011.html

Hope it helps..

Fixed – The CREATE UNIQUE INDEX statement terminated because a duplicate key was found for the object while creating Alternate Key in Dynamics 365

We might get error while creating Alternate Key as shown below.

The CREATE UNIQUE INDEX statement terminated because a duplicate key was found for the object name ‘dbo.sab_fash_transactionheaderBase’ and the index name ‘ndx_for_entitykey_sab_fash_headername’. The duplicate key value is (0000001414).

The reason was because there was already records created for that entity and had the field (alternate key one) having duplicate values. Deleting the duplicate record allowed us to create the alternate key on that field.

Hope it helps..

Using Alternate key in the Dynamics 365 for Sales Connector in Informatica Cloud

In our recent project we were using Dynamics 365 for Sales Connector of Informatica Cloud to push data into CRM from SQL DB.

To update the lookup instead of using GUID we decided to us the Alternate Key.

From the below KB article, it looks like the older version of the informatica connector wasn’t supporting the Alternate Key

https://kb.informatica.com/faq/7/Pages/15/377766.aspx

However, the newer and the recent version of the connector based which is based on Web API supports the alternate key.

To set the alternate key we basically need to use the below syntax,

EntitySetName(keyfield=’keyfieldvalue’)

i.e.

sab_fash_transactionheaders(sab_name=’value’)

Hope it helps..

Common Data Service for Apps – Business Rules (Server-Side Logic) – Part 6

Another interesting article on Modern Driven Apps by the author

Bansal Blogs - Dynamics 365, PowerApps, Microsoft Flows, Power BI

CC1

With Spring 2018 release, Microsoft introduced several types of server-side logic including Business Process Flows, Workflows, Calculated & Rollup Fields and Business Rules which do not require any coding. Part 5 of this series covers Calculated & Rollup Fields. In this blog we will explore Business Rules.

Business Rules: Declarative logic comprises of conditions and actions for data accuracy and consistency across applications. Business Rules provide a nice graphical UI for defining these rules and actions that will be executed synchronously when a record is created/updated. These rules are created at entity level in common data services, hence you do not need to write separate logic for individual apps (canvas & model driven apps)

You can perform below actions using business rules:

Set field values
Clear field values
Set field requirement levels
Show or hide fields
Enable or disable fields
Validate data and show error messages
Create business recommendations based…

View original post 483 more words

Error while setting the lookup and publishing the workflow in Dynamics 365

Recently while trying to configure a Team in Assign step we were getting the below error

With following details (not much useful)

The only way we figured out to set that field was to first chagne the Entity in the Assign Drop down and then selecting the team in the lookup dialog bx.

Below we have changed the Entity to Brand (custom entity) from Lead and then changed it back to Lead and then tried setting the team from the lookup dialog box.

We were successful this time.

Or setting the lookup through quick search view instead of opening up the lookup dialog box as shown below

The other issue we were facing was while trying to publish the workflow we were getting the below errorà “The selected workflow has errors and cannot be published. Please open the workflow, remove the errors and try again.”

This we realized in one of the Check Condition steps we had the values repeated for one of the lookup field.

This was because the workflow was imported to the target environment and later the records of the lookup entity that is being referred were deleted and added back which eventually led to 2 duplicate values i.e. same display name and different GUID thing. (1 non-existing in that environment, but still there inside workflow step). Removing it fixed the issue and we were able to publish the workflow.

Hope it helps..