Sonoma Partners Microsoft CRM and Salesforce Blog

CRM 2013 - Refresh Web Resources on Activate and Deactivate

If you are building an editable custom Web Resource in CRM that will be embedded into a record form, typically you would want to make the Web Resource read-only when the record is deactivated.  To do this, you would have your Web Resource check the form type and toggle between editable and read-only mode appropriately.  In CRM 2011 this works great but in CRM 2013 you will notice that the form does not refresh after “Activate” or “Deactivate” in the Command Bar is used.  Therefore your Web Resource doesn’t refresh and is still in the same mode that it was before.

Luckily with only a handful of JavaScript, we can trigger our Web Resources to refresh on Activate or Deactivate.  First, in the OnLoad of the form, register an OnChange event for the statecode attribute.  Whenever the record is Activated or Deactivated from the form, this event will trigger.  Then you can refresh any Web Resources from your OnChange event.


Topics: Microsoft Dynamics CRM 2013 Microsoft Dynamics CRM Online

Adventures with PersonAccounts

Recently I had a chance to play with PersonAccounts while working on a project. If you’re unfamiliar with them, PersonAccounts are account records in Salesforce that act like Contacts, and even have the Contact custom fields available to them. They allow you to use the record almost anywhere you could use a Contact record or an Account record. This is especially useful for businesses that don’t really distinguish between Accounts and Contacts (like consumer facing retail stores), and would like to have the full functionality of native Accounts in Salesforce while retaining the common fields of Contacts like mobile phone numbers and home addresses.

In the particular scenario I was working in, the requirement was that whenever certain criteria happened on an Opportunity related to the PersonAccount, I needed to relate specific other PersonAccounts to the Opportunity based on some data in custom fields we had created. We planned on using the OpportunityContactRole native object to capture both which PersonAccounts should be related to the Opportunity and why (via the Role column).

Whenever I get a requirement like this, if I’m not sure about something I just attempt it through the UI first. I navigated to the Contact Roles related list on a test Opportunity and clicked the new button, which brought me to a screen where I could search for and select the test PersonAccount to relate to it:


After clicking save, I was returned to the Opportunity with the PersonAccount added:


No problems so far, so I started writing the code I thought I would need:

Seemed simple enough. Save and test:


So that definitely wasn’t what we wanted. Reading the error message closely we can see that the root cause is “Contact ID: id value of incorrect type”. What?! Why doesn’t this work when I just did the same thing through the UI?

After some head scratching and unsuccessful web searching, I decided to take a closer look at the records Salesforce was actually creating. There’s a neat trick in Firefox where if you hover over a link, it will tell you where the link will take you in the lower left. Hovering over the link in the related list on the opportunity gave me:


Notice the ID (highlighted) which starts with 003. I know from experience that the Account prefix is 001, so this seemed a little strange to me.

At this point, I decided to go back and review the documentation more carefully to see what I could dig up. Eventually, I found it: on the Account object’s page there’s a snippet towards the bottom detailing a field called PersonContactId, which is the ID of the ‘Contact’ that the PersonContact is ‘related to’. Firing up the developer console, I ran a query against this record to see what was in the database:


And there we have it, both IDs in one place. So what’s happening in the background is that Salesforce is using the PersonContactId to relate the PersonAccount record to the Opportunity instead of the ID field. Once I updated the code to use the Account.PersonContactId field instead of Account.Id all was well with the world again.

Need someone who knows the ins and outs of the Salesforce platform? Need a partner who can guide your project to success, and offer advice on best practices and change management? Just want someone to bounce ideas off of? Contact us and we can help.

Think there’s something we should cover but haven’t? Curious about some specific piece of the platform? Let us know in the comments below!

Topics: Salesforce