Thursday, August 23, 2018

Hide Group or SubArea from SiteMap in Dynamic 365 CRM

To hide specific area or a subarea we need to play around with following:

User Security Role
+
Sitemap Area Privilege
+
A Custom Dummy Entity (optional - can be achieved with standard entity).


Please jump on to the following blog for a more details understanding.


Thanks.
Vipin Jaiswal
vipinjaiswal12@gmail.com

Tuesday, August 21, 2018

Hide Navigation Menu in Dynamic 365 CRM


One of the most critical factor of choosing any CRM is user experience. Microsoft Team is continuously updating and coming up with great look and feel to make an awesome user experience especially with UI.

However, some factors needs to be taken care by the developer or consultant who is customizing Dynamic CRM for business. Today I am here with such an interesting topic.

! ! ! J ----- So many menu option ------ J ! ! !



Yes, you might have guess it correct what I am trying to convey here.  

We have different people in the organization with different role and people may belongs to various departments. A Classic example would be that few people are from Sales Department and few from Marketing. Marketing people do not want to see items, that belongs to Sales department. Moreover, a sales person may not be interested in the item which comes under Settings and that are exclusively for a CRM administrator to deal with.

To hide specific area/subarea we need to play around with:

User Security Role
+
Sitemap Area Privilege
+
A Custom Dummy Entity (optional - can be achieved with standard entity).

Guidelines to write good JavaScript code in Microsoft Dynamic CRM

https://vjcity.blogspot.com/2019/08/guidelines-to-write-good-javascript.html

Jumping on CRM Practical


Step ~1 
Create a dummy entity HideNavigationItem


Step ~2 
Decide on which security role that need to be adjusted so that users, which comes under that security role, will not see specific Area or Sub Area. 
I am considering Salesperson role here. 
I would enable only Read Privilege for HideNaivagtionItem Entity for Salesperson security role.




Step ~3 
Updating the Sitemap to hide specific area.
First, make a test solution and add only sitemap to it
Export the solution and we will edit the file customization.xml accordingly.



Search for <Area Id=Settings” ResourceId=Area_Settings

and then add:
 <Privilege Entity="new_hidenavigationitem" Privilege="Read" />



I have kept the setting only for subarea = Product Catalog to check what will be the effect of this.


Let’s play more hide n seek game with site map menu items.

In Order to hide complete Business Group under the setting Area, we have to apply our Privilege tag to each sub area as highlighted in below image.






Note :
  • We can also achieve above logic by making use of an existing entity and using a different privilege.
For an example
 <Privilege Entity="case" Privilege="Create" />

  • We are allowed to add tag only under and once all subarea are hidden, only then a Group can be hidden accordingly.


I wonder if such settings would be available in some tools soon.

Thanks.
Vipin Jaiswal

Friday, August 17, 2018

Dynamic 365 CRM Migration Tips and Consideration

We all want to get to latest version of Dynamic CRM as we are interested in getting new features attached to it.
Here in this blog I would try to list down following
  • Considering various Migration activities
  • Considering some important factors when doing migration
  • Understanding the reason for your migration – list down features that are not achievable in existing CRM


I have list down few of my thoughts, which I can think of when doing Dynamic CRM migration 

I have encounter specific issue related to Product Migration, you can look at same here.


Tools to consider for Data Migration


CRM Configuration Migration is the one tool I found very easy going for limited data migration.

Refer below blog for few effective tips for data migration


Pre-Configuration in Dynamic CRM


Business Units & Security Roles

Do we need to configure CRM with business hierarchy and have security around various users operating within dynamic CRM?
Does our business function across the globe?
The answer to such question will involve us in configuring business units and security role.

Users Configuration
A user must be configured in advance before we initiate the actual data migration within Dynamic CRM, so that the records can be associated with their specific owner.

What about the users who might have left the organization and which specific user must be used to replace when doing migration.

There are two types of records in dynamic CRM
Organization Owned: Like Products, Price-list, Competitors, Currency, etc.

User Owned: Like Contacts, Accounts, Sales Order, Invoice, etc. The records that are owned by a user or team, they’re connected to a business unit and specific security roles for the business unit. Therefore, these entities participate in role-based security.


Know the size of the database





  • How many customers we are migrating? (This typically decide the duration of migration activity as most of the entities are directly or indirectly related to customer base)
  • What all other entities linked to Contacts especially if there are some parent entity to contact like Account, Leads, or Organization? Can we list those?


Is Data Cleaning Required?




During the data migration phase, we get an opportunity to analyses if we can get rid of garbage data by not taking it forward to another fresh CRM. We can query the system to verify for what data needs to be migrated. Some of the example to query garbage data are:


  • Contact records that are not having any unique identification like email ID, phone number, social security number, etc.
  • Records that had created during the testing via some service accounts.
  • How many nulls or empty strings are there for some entities?
  • Are we having duplicate records with same unique identification?

Consider Time & Cost factor




It is the most crucial factor in deciding a migration process.
  • There are certain tools, which do the migration at their best, but they come with their added cost but save a lot of time. (Example – Scribe)
  • For large-scale data that need to be migrated an SSIS packages can be a good option where we can also define our own business conditions for data migration. This option require time and development efforts.
  • Dynamic CRM does come with default data migration tools as well, provided it require data to be formatted accordingly

Managing Workflow and other Triggering operation

Often we have business automation implemented in our CRM. For example to send, welcome email to a customer when a contact record is created in system or assign the lead to specific user or team. We need to be very cautious when doing data migration as they might trigger the business automation processes that we might not actually be interested.

Usually workflows are supposed to be in Draft or OFF state during the migration process and once all the data is migrated, they can be turned in ACTIVE or ON state.

Some of the processes that are specific to Dynamic CRM are:
  • Deactivate the workflow processes
  • Disable the Plugin Steps
  • Disable the custom workflow
  • Disable Database Indexes – For CRM On-Premise
  • Turn off tracing/logging for better performance.


Doing Trail and reducing the overall migration Risk

A recommended approach is to do a trail migration of subset of data and then after verifying the subset data migrated go for an actual migration.


Once we start data migration activity in Production environment, start-involving users to verify the data being migrated. Users know their data very well, they can identify any invalid entry, and we can reconsider our migration approach.

Run the Reports




Comparing report results provide the best way to verify if certain entities and their respective data is been properly migrated or not. 

Note : When you might be doing migration from CRM 2011 then if reports are build using SQL statement then it has to be converted to Fetch XML based when migrating to Dynamic 365 CRM.

An example quarterly, monthly sales analysis report.





Monday, August 13, 2018

Failed with error: Please check your account info and/or permissions and try again. Details: REST API is not yet supported for this mailbox


We often take a trail Dynamic 365 CRM instance from

but the trail instance will only give Dynamics 365 Customer Engagement Plan Enterprise Edition and often we wonder why the emails are not going out and status is always pending send.

This also applies when you try to configure Microsoft Flow and you ran into below error when configuring any step that require you to play with Office 365 services.

Failed with error: 'Please check your account info and/or permissions and try again. Details: REST API is not yet supported for this mailbox. This error can occur for sandbox (test) accounts or for accounts that are on a dedicated (on-premise) mail server.


You might have guess the probable solution to the problem and yes, we need to obtain subscription to the office 365 services as well.

How to add Office 365 Mail Functionality after getting Dynamics 365 CRM Trial instance.

For obtaining subscription accordingly, we need to navigate to Office 365 portal and navigate to 
Billing -> Purchase Services

Then look for Office 365 Enterprise E3 product, go for start free trail or Buy Now as you required.



Microsoft may further ask you about the Credit Card information to keep the unnecessary spam out of the system. Don’t worry Microsoft will not charge for the free trail.


We are finished with setting up the office 365 for our smooth business operation and solving other technical problem which we might be getting from it.

I hope I added a small value by solving the problem.

Thanks,
Vipin Jaiswal
vipinjaiswal12@gmail.com