MSCRM in Scotland

Over in Ronald's blog he has a good trouble shooting list for when your callout does not work.

He has missed one thing out though that still affects one of my sites.

In it the callout did not fire because the entity was updated by a workflow. Someone changed a bit value to indicate they had checked the record, the record had a status on a dropdown updated and that update should have then triggered a web service call to inform a third party of its existence and passage through a QA procedure.

After some experiments we discovered that if you changed the status of the dropdown by hand and saved it the callout was fired but if we allowed the workflow to change it then it did not. On googling MSDN this turned out to be a known issue pre rollup 1 but my client was only a week from go-live when we (I) discovered this. They have still not got around to applying the roll up as far as I am aware and the workflow was altered to create a task against an admin person to change the status by hand.

Not pretty but worth knowing.

With thanks to the ICU-MSCRM blog who started me off in this direction.

A customer is looking to use the CRM to run their recruitment and training company. They are not particularly IT-literate and my spec as been a series of required fields and free reign in developing ways of tracking the recruitment and training progress of candidates.

Each training candidate has a series of targets that consist of a target date, an actual date and some details. Depending on the course they could have between 1 and 16 different targets to reach. This became a custom entity with a relationship to the Contact account (renamed Person).

Each Account (renamed Company) has can either have a collection of trainees associated with it or a number of positions needing filled. Or both. Trainee is another custom entity with some basic details of the person and who their supervisor is and the job vacancy is just a custom entity with a couple of details about the job (temp/perm, hourly rate that kind of thing) related back to the person to record who was recruited for the job.

To keep things simple for the user I decided to use an IFrame to show the lists of vacancies, trainees and targets in the relevant entities. This was because I felt the company would benefit from having this information in line with the main application form rather than jumping about the categories in the left hand pane.

So using the IIS logs I tracked down the URL for each of these lists so that they can be included in the Iframe source. It turns out that they have a relatively straight forward format. Each of the lists differed only by the value of the tabSet at the end of the line (assuming we don't count the object id because it is being passed as a variable anyway).

I also work with two shortcuts on my desk, one to take me to CRM and one to take me direct to the Loader.aspx page so that I can view page sources. This gave me the ability to find the ID for each of the menu entries in the left hand pane relating to the lists themselves. For simplicity I will remove them to avoid confusion. Lastly I did not want to waste time trying to display anything when I was creating a new account.

So the code for the account form was :

document.all.nav_account_new_vacancies.removeNode(true);
document.all.nav_account_new_trainees.removeNode(true);

if (crmForm.FormType == 1)
{
document.all.IFRAME_recruitment.src="about:blank";
document.all.IFRAME_trainees.src="about:blank";
}
else
{
document.all.IFRAME_recruitment.src="/sfa/accts/areas.aspx?oId=" + crmForm.ObjectId + "&oType=1&security=852407&tabSet=account_new_vacancies";
document.all.IFRAME_trainees.src="/sfa/accts/areas.aspx?oId=" + crmForm.ObjectId + "&oType=1&security=852407&tabSet=account_new_trainees";
}