If you are facing the login window appearing in the Excel sheet after creating a dynamic Excel export from an IFD-enabled CRM organization, then there’s still a way to get the data into the Excel sheet:
- Export the Dynamic Worksheets (or Pivot Tables) from Microsoft Dynamics CRM.
- Open the Dynamic Worksheets with Excel.
- Excel will display the ADFS sign in page or a Script is disabled error in the worksheet.
- Click on Data tab.
- Click on Connections.
- Within Workbook Connections click on Properties.
- Within Connection Properties click on tab Definition.
- Click on button Edit Query.
- This will redirect to ADFS login, enter in the user’s credentials and click on Sign In.
- YOU WILL GET AN ERROR, THIS IS OK! So, click on OK.
- Within Edit Web Query, click on Cancel.
- Within Connection Properties, click on Cancel.
- Within Workbook Connections, click on Close.
- Within Excel go to the Data tab
- Click on Refresh All.
This tip is brought to you by Ronald “I’ll be back” Lemmen.
Tipp Jarr’s Double Dipp
To my astonishment, these instructions do work! The painful part is the need to repeat the process every time worksheet is opened but this is infinitely better than no exported data at all!
CRM 1:N relationships that are “Configurable cascading” type allow you to customize several cascading behaviors. For example, in the system parental relationship between Accounts and Contacts, you can change the relationship type to “Configurable Cascading” and then set the “Share” permission cascading to “Cascade None” so that sharing an Account with George will not also share the related contacts.
The most misunderstood cascading permission is “reparent.” My experience is that if you ask five CRM configurators what “reparent” means, at least two will probably think that is reassigning the account.
Reparenting is changing the parent in the relationship. For example, if I have contact where the parent customer is Fabrikam and I change the parent customer lookup to Contoso, with the default reparent cascading, the owner of Contoso will now have access to the contact.
By setting the cascading setting for “reparent” to “Cascade None,” the owner of the new parent will not be granted access to the record when the parent is changed.
Entity Image is introduced Dynamics CRM 2013. This is a really useful feature where we could have better presentation to quickly glance on the record. As the adage says: “A picture is worth a thousand words”. It seems quite common requirements for customizing the form, but it is not automatically enabled on the form. To get the entity image to be displayed on the form: Navigate to the entity form customization > Form Properties > Display tab > check the “Show image in the form” option > Click OK > Save and publish the customization.
This tip is brought to you by Andre “I’ve got 88 in my handle” Margono.
Sometimes you need to perform checks or calculations against each record in a particular entity. If you have a sizable on premises deployment, it could be that the marketing department just came out with a new algorithm to rank the customers and some voodoo needs to be done for every account record. If you are an ISV, it could be some bulk data preparation that you need to perform (e.g. in our solution we had to analyze every phone number for every contact and account record in the system).
Whatever is your scenario, quite often these batch processes include hundreds of thousands or even millions of records, they are time-consuming and can span hours and days. Frequently, there are additional requirements of not running these during the business hours. So how do you keep track of which records have been processed already and which ones are still to be done?
Surely, we can create and fire up a small workflow for each record but having millions of workflows not going to win you any new friends among system administrators. We could add a simple boolean attribute to the target entity and update it after we process each record to indicate that we are done with this record. That’s better but not a very good choice for ISVs as it immediately drags the target entity into your managed solution thus introducing new dependencies without a good reason. In addition, changing this attribute would run unnecessary update on the target record, modifying timestamp and potentially introducing inconsistencies in the data.
That’s where native N:N relationship can help. Note: some steps below do require coding, we deliberately skip technical details to concentrate on the essence of the approach.
- Add a new entity called, say, Batch.
- Add a native N:N relationship between the target entity (e.h. contact) and batch.
- Create new batch record.
- Associate all target records with the batch record.
- Use either FetchXml or QueryExpression to find records associated with the batch record. Use pagination as required.
- Process records retrieved (one page at a time). Once record is processed, disassociate it from the batch.
- Rinse, repeat until all records are processed, i.e. the batch record has no associated entities.
- Delete batch entity (it’ll delete the relationship as well).
This approach has the following advantages:
- It’s non-intrusive. Adding an entity and N:N relationship to another entity has no impact, introduces no dependencies and adds no customizations for the latter. Nada, zip, bupkis. Visually, there will be additional link in the navigation bar but it’ll be gone once batch entity is removed.
- It’s durable and survives suspension of processing, system restarts, etc, etc.
- It can be expressed and used by a programmer. Note that we have a step of associating all records to be processed first. In theory, we could have gone the opposite way, i.e. associate processed records with the batch. However, that would have required NOT IN expression which is slowly making its way through but is not yet available in CRM.
- It’s simple to master and execute.
The final observation. If your target entity is contact, account or lead, marketing lists can be used instead of a custom batch entity but personally I prefer to keep unrelated functionality separate and would still recommend using a custom entity approach.
NOTE–this post has been updated as the original solution was insufficient to bring the button back. In the author’s defense, he tried several things to fix it and misidentified the real solution. Thanks to commenter Matt for pointing out the error of our ways.
In CRM 2013 SP1, the Associate View subgrid of contacts no longer displays the “Add Existing” button. This is fine if you don’t use it, but what if you wish to link existing contacts to an account?
To make it show up, create a solution that just includes the Contact entity
Open the solution in the Ribbon Workbench.
On the contact subgrid, you will see two buttons that say “Add existing.” Right click on the first one and select “Customize Command.”
Right click on the command for MSCRM.AddExistingRecordFromSubGridStandard and select “Edit Display Rules.”
On the right pane of the display rules selector, select the rule called “MSCRM.NotOnAccountForm.” and click “Remove”
Publish your changes and reset your browser temporary files, and you should now see the “Add Existing” button on the contacts subgrid from an account. Note this will not display additional buttons on the inline subgrid, but if you pop the subgrid out using the grid button or access contacts from the “Contacts” link on the navigation menu, you should once again see the “Add Existing” button.
If you’ve been paying attention to the most recent advances in server-side CRM entertainment, you are by now should be familiar with alerts. They are system messages that tells you when something is wrong (error), suspicious (warning), or neither (information). Open any server profile or mailbox record, click Alerts link on the left to find out what they look like.
My main gripe with alerts is that they are passive: administrator needs to login and navigate to Sales > Alerts to see if anything’s wrong with the system. (And if your system has been upgraded from 2011 you may be even missing this navigation area but this is totally different subject). Add the fact that alerts are not customizable and here you have it.
To start with, there is no entity called alert. Good news is that there is an entity called trace which seems to be the right one. The second piece of good news is that, while this entity is completely out of reach for customizations, it is possible to build a workflow that will proactively send notifications when bad things happen.
This simple workflow sending SMS messages to administrator when new alert is raised has been running on our system for the last few days with great results. I no longer have to login to verify that one of our mailboxes has been disabled for inbound processing, I get SMS about that. (And disabled mailboxes is a totally different subject).
From the “Great features that have been in the application for a long time but many users don’t know about” file
In CRM for Outlook user settings, you will see checkboxes for various activity types and contacts.
If these checkboxes are checked, when a user hits the new [appointment/task/Email/Contact] button in Outlook, that user will get the CRM form rather than the standard Outlook form.
This has several nice benefits
- It ensures that each contact or activity added will be tracked
- It gives access to custom fields or required fields not included in the standard Outlook form.
- It is less clicky than creating a contact, saving it, and then tracking it.
Note that there are some limitations to this tip. Checking these boxes does not force the CRM form from all locations in Outlook. If I check the box and go to the CRM tab and click “new contact,” the CRM form will appear. However, if I go to the People list in Outlook 2013 and click the new button, it will still use the standard Outlook form.
So it is not perfect, but with proper user training, it can be helpful.
Alternatively, you can also access CRM fields from the standard Outlook form by clicking the “CRM fields” button on the activity or contact ribbon after the record is tracked.
Not so long ago we experienced the wrath of an unhappy customer when, with all the good intentions we verified and normalized phone numbers for all contacts in the organization. This particular implementation had sophisticated business processes that kicked in on updates and modified on timestamp was used to calculate some performance metrics. With us barging in as administrators, ploughing through all the records and updating them all, we managed to screw up all the performance metrics business has cared about.
If you are planning any kind of massive batch update, make sure to:
- consult the business to ensure that there are no important metrics hinging on modified on or modified by attributes
- temporarily disable plugins and workflows that do not make sense to trigger on artificial updates
- mitigate some of the metrics “violations” by impersonating either the owner of the record or the last user who updated the record (depending on business expectations)
- consider schema modifications where resulting data (whatever they are in your case, it was sanitized phone numbers in ours) perhaps are better isolated into a separate “extension” entity so that primary record is not affected
A Dynamics CRM deployment should include the following functional administration roles. These hats can be worn one or more people, but somebody needs to be responsible for these areas.
- Trainer: The trainer is responsible for training new and existing users. Will be busiest around deployment and upgrade time.
- Business Analyst: The Business Analyst is responsible for streamlining and automating processes, identifying manual processes as candidates for automation in CRM, researching, identifying and suggesting improvements, and ensuring the company achieves an ROI. This role oversees the documentation and rationalization for implemented business processes and is responsible for change orders. This role needs to be able to communicate both with business end and technical end and be the right hand to the project manager during and after the implementation.
- Application Support: This has a server and client aspect. When users have an error message or performance issue, initial troubleshooting should be conducted on the client to identify if the issue is in the client or server side. Server side support will do tasks like checking SQL resources, checking event logs, and running server performance traces. Work with Microsoft Support as needed to resolve issues.
- SQL Admnistration: The SQL admin will be responsible for backups and ongoing SQL maintenance, such as rebuilding indexes, and management of SQL Reporting Services. Not needed for Online deployments..
- CRM Server Administration: The CRM server admin will be responsible for applying update rollup patches to the CRM servers and monitoring server performance. Not needed for Online deployments.
- CRM Deployment Administrator: The deployment admin has permission to log in to the Deployment Manager on the CRM server. By default, this is the user who installs CRM. Additional deployment administrators should be added. The deployment admin is needed whenever licenses are updated, plugins are deployed, organizations are created/imported, or something characteristic is changed with your deployment architecture. not needed for Online deployments.
- CRM Client Administration: The Client admin will be responsible for deploying the CRM Outlook client and applying patches as necessary. Also responsible for deploying tablet app.
- Exchange Administration: The Exchange admin will be responsible for the email router or server synchronization. Also responsible for troubleshooting emails with incoming or outgoing email and verification that new users mailbox settings are correct.
- AD Administration: If auto group management is turned off, the AD administrator will need to add people to the appropriate AD groups before they can be added as users in CRM. Not needed for Online deployments.
- Integration Administration: The Integration Admin will be responsible for the scheduling and monitoring of CRM integration jobs
If you are using CRM 2013 SP1, there is a great new keyboard shortcut to get performance metrics for a form. Open a record and press CTRL+Shift+Q.
When you first press it, you will see the performance center, but it will be empty. Click “enable,” then click “refresh.”
The form will reload and you will see some really snazzy performance metrics for the form load. Much more convenient than running tools like Fiddler.
Thanks Adam Vero for this fantastic tip!