Tip #163: Create a 1:1 relationship

Creating a 1:N  or N:1 relationship between two entities is very straightforward, but what if you want to do a 1:1 relationship?
For example, say you have a subprocess that needs to be owned by a different user than the account owner, or you have a child relationship where only one record should be associated with the parent?

  1. Create a 1:N relationship and a N:1 relationship between the two entities.
  2. On the relationship definition, set the related records grid not to display in the navigation area
  3. Create a workflow that upon create of the secondary record updates the lookup field on the primary entity record.

For example: I have a custom project entity and I am adding a related technical audit entity for technical review of projects. Sure I could just add additional fields to the project entity, but this process is owned by a different user than the owner of the project, and adding all the fields will push me over the 75 field limit for CRM for tablets.

I create the technical audit entity and create a 1:N and N:1 relationship between projects and technical audit. I then add both lookup fields to their respective entities.

In this example, I want a technical audit record created every time a project reaches the approved stage. So I create a workflow that upon update of the stage to approved, creates the project technical audit linked to the project, then updates the project technical audit lookup field with a link to the technical audit

The result is a two-way relationship with a lookup field on both sides. Benefits include:

1.      I can look at a project and see that a tech audit has been created for the project.

2.      Give that it is a 1:1, nobody can create multiple related tech audits by mistake

3.      This gives me the flexibility to show technical audit fields on project forms and views and project fields and technical audit forms and views via quick view forms.

Tip #162: This action cannot be completed during synchronization

In CRM for Outlook, sometimes when you click the “track” or “set regarding” button, you will get an error telling you that the action cannot be completed during synchronization. I’ve noticed that sometimes I see this when tracking from the Outlook 2013 inbox view, rather than tracking from an individual email form.

If you see this error every time you track, it can be resolved by deleting the SQL CE database on the Client machine:

1. Close Outlook
2. Browse to C:\Users\<loggedinuser>\AppData\Roaming\Microsoft\MSCRM\Client
3. Delete the EmailCache.sdf and the OutlookSyncCache.sdf files
4. Browse to C:\Users\<loggedinuser>\AppData\Local\Microsoft\MSCRM\Client
5. Delete the CRMcache.sdf file and the GUIDFalse.sdf file <—the GUIDFalse.sdf file will be a long alphanumeric name
6. Re-launch Outlook and the files will get recreated.

Tip #161: ADFS vs Citrix for external access

When deploying Microsoft Dynamics CRM on premises, ADFS is the recommended approach for providing external access to the application. However, alternative methods, like Citrix and application virtualization can also be used. These alternative methods can do a good job of providing access to the core CRM web application, but do not provide full support for all CRM interfaces. It really depends on how users need to access the application.

ADFS Citrix
PC web browser Yes Yes
Outlook client Yes Yes (in Outlook virtualized on Citrix host, not natively installed Outlook)
Tablet browser Yes Citrix can be used to access the CRM PC browser experience on a tablet. This is not the tablet optimized browser experience you get when the CRM URL can be accessed directly from the tablet.
Tablet app Yes No
Phone app Yes No

 

Tip #160: If all I have is a Surface, how do I test Windows client?

My work laptop is a mighty Lenovo W530 with upteen cores, bazillion GBs of RAM and quadrillions of TBs of SSD drive space. The only problem is that carrying it around keeps my chiropractor very busy. So when I travel, I dock this monster behind the firewall and carry around something like Surface or the other tablet.

When I need to test something on a client, I can RDP back into my bazooka of the laptops and fire up appropriate VM. This kind of works but it’s always felt like bending backwards.

Now, there is better way to do client testing. If you are MSDN subscriber (if not, why not?) then not only you get $150 monthly credit in Azure, you can now provision Windows 7 and Windows 8.1 machines:

Windows 7 & 8 in Azure

That made my upcoming overseas trip about 17kg lighter (or whatever’s the weight of the Lenovo’s powerbrick).

Cost? Just skip that double caramel cappuccino and you’ll be able to afford 2 cores, 3.5GB RAM (A2 image) for a sweet $3.80 per day. Or how do you feel about 16 cores, and a whopping 112GB RAM (A9) for a cool $4.90/hour? Achievement unlocked.

Tip #159: PowerShell fails in IFD deployment

Microsoft Dynamics CRM Windows PowerShell snap-in is an excellent automation tool but on some Internet Facing Deployments even an innocuous call to Get-CrmServer can fail with a fairly generic message “The caller was not authenticated by the service“. One of the possible reasons is that the tool always runs on CRM server but for IFD purposes CRM URL has been reconfigured and instead of crmserver it’s now known as internalcrm.contoso.com.

You are potentially hitting the problem when locally hosted sites cannot be accessed using FQDN. The workaround includes adding some registry entries to cover internalcrm.contoso.com, and that seems to fix authentication in PowerShell.

Tip #158: If upgrading more than one version, recreate security roles

Let’s say you work for a company that uses CRM 4.0, you did not upgrade to 2011,  and you now are moving to CRM 2013. If you use custom security roles (and most people do), I recommend recreating your custom security roles.

Many new privileges were added in CRM 2011, and even more were added in CRM 2013. if you use standard roles, these new permissions are automatically added to your roles; however, if you use custom roles, these privileges are not added to the roles. If you continue to use your existing security roles, you are in for many “access denied” permissions surrounding privileges, tablet apps, processes, and other new features.

Updating a custom role when moving one version is a challenge. Updating a custom role when moving two or more versions can sometimes be more trouble than it is worth.

  1. Start with a standard role with minimal permissions, such as the Salesperson role.
  2. Copy the role, creating a new custom role.
  3. Open your existing security role and snap to the left side of the screen using windows key + left arrow.
  4. Open your new custom security role and snap to the right side of the screen using windows key + right arrow.
  5. Update the new role to match the entity level permissions on the Core Records, Marketing, Sales, Service, and Custom Entity tabs.
  6. On the bottom of the Core Records tab, verify new permissions around auditing are enabled if desired.
  7. On Business Management tab, leave the settings for CRM for Phones and CRM for Tablets and Field Security set, unless you specifically need to disable them.
  8. Leave the Customization tab as it is by default in the new role. Since we copied a role that has no customization permissions, this will not make your users system customizers, but will verify that they have the correct settings to view the new metadata components.

By doing this your users will have what they need to use the new features and also will eliminate the majority of the role related issues upgraders experience with CRM for tablets.

 

Tip #157: Beware of the human factor

When you design your business processes in CRM, one red should be if the success of the process depends on a user taking an action in CRM. For example, if you are designing an approval process, and your process says “After approving the record, the approver is going to click “share” and manually share with the sales manager,” that should be a red flag. What happens when the approver forgets to share the record after they approve it?

If your process is overly dependent on the actions of people, it will probably fail at some point.

A better choice would be to have an automated process. When the approve approves the record, have a workflow or plugin that automatically shares or assigns the record to the appropriate person.

You can’t totally get away from relying on human interaction–in our example, the approver still has to approve the record; however, you can minimize the number of steps the person has to take, incorporate notifications and routing rules to guard against a breakdown in the process (like the approver forgetting to approve the record), and then automate as much of it as possible (such as by automating the sharing of records rather than relying on users to manually share the records).

 

Tip #156: Why doesn’t my real time workflow do anything?

So you create a real-time (synchronous) workflow, and when you test it out, it doesn’t do anything. Say you have a workflow that should fire when an opportunity status is changed to “Won,” but you close an opportunity as “won,” and nothing happens, and there are no errors.

Most likely, you have the workflow definition set to happen “Before” the status change. When you create a real time workflow, the workflow can fire before a status changes or record is updated. This is the default setting.

Problem is, with “Before,” your change hasn’t happened yet. If you have a workflow fire before the status change, and you change a record status to “won,” the workflow fires before your change is applied, and when it checks the status of the record, it will see the old status, not the one it is changed to.

Rule of thumb: use before if you need to work with the prior value, use after if you need to work with the new value.

Tip #155: During the upgrade all your CRM are belong to us

When importing a CRM 2011 organization into CRM 2013 UR2 or SP1 environment, you may receive a cryptic message “Database having version 6.0.0.809 is not supported for upgraded”. As it turns out, it has nothing to do with the version of the database being imported.

If you are trying to import an organization database that has already been imported to an organization on that CRM server, you will get this error, because the organization has the same ID.

Deleting the other organization will do it. If you need both organizations, you can delete and re-import the already upgraded organization. This will assign it a new organization ID. Then you can proceed with upgrading the second copy.

(The resolution was provided by my fellow tipster Joel but, in a good “first come first served” tradition, I’m staking the claim.)

Tip #154: One pre-validate to rule them all

It may come as a surprise but when a contact is created as a side-effect of another operation, e.g. qualifying a lead or processing incoming message with contact auto-create in force, pre-validation plugin does not fire at all. It happens when operation performed is a compound message such as QualifyLeadRequest or DeliverPromoteEmailRequest.

This behaviour, unintuitive at first, is by design. The best explanation comes from David “Twice Chartered” Jennaway:

My general starting point is that I expect one message (QualifyLead) to cause one corresponding pre-validation step. If one message is implemented by several operations (Create contact, Create account etc.) then I’d expect one pre-operation step for each operation, so the behaviour you describe is as I’d expect.

Taking this further, in a scenario like this, the data in the message can affect which operations occur. For example, if the lead has no contact fields set (i.e. no name), would you expect an operation to create a contact?

The solution is to either move/copy your logic into pre-validation step of a relevant compound message or move your plugin to pre-operation step.