Monday, 30 December 2013

Actions (Custom Messages) in MS Dynamics CRM 2013

Actions are another new feature in MS Dynamics CRM 2013. They are an intriguing new feature, which I must admit don't see much of a use case for right now.

In essence, they are a custom message, something like Create, Update, etc... but the actions that take place when the custom message is invoked are defined as a sort of Workflow, which allows custom code via Custom Workflow activities.

It then it gets a bit weird in that this can only be invoked via code. A potential workaround is to use a workflows with a custom Workflow activity or presumably, JavaScript hooked up to a button or other event.

I thought I would try to create a sample action. The action will create a task related to a Stamp (a custom entity), which is a mandatory input to the request. There is another non-mandatory input variable, if set to false, the action will not trigger. Finally, there will be an output variable, which will effectively confirm whether it's been actioned ...

At any rate, this is how one would create such an action. Navigate to Settings -> Processes -> New

I created this action to be global, it can be limited to an entity.
I added a few arguments and there are a few things that are annoying about this. The first one is that unless the Entity Type is set for Entity or EntityReference, you will not be able to use the argument, at least not from the GUI, so this limits a bit what can be done. Although I suspect no such limitations apply to code ... The second annoying thing is best explained by the next screenshot:
Essentially, 0 will be false, everything else is True, if the field is boolean, not sure why not just have True or False?



Make sure that the action is activated before calling it from code.

This is how you would call it:
private static void supadupaaction(IOrganizationService service, EntityReference target, Entity stamp, bool carryOut=true)
        {
            var parameters = new ParameterCollection();
            parameters.Add(new KeyValuePair<string, object>("Target", target));
            parameters.Add(new KeyValuePair<string, object>("RealTarget", stamp));
            parameters.Add(new KeyValuePair<string, object>("AreYouSure", carryOut));

            OrganizationRequest request = new OrganizationRequest()
            {
                RequestName = "new_SupaDupaAction",
                Parameters = parameters
            };

            var result = (OrganizationResponse)service.Execute(request);

            foreach (var item in result.Results)
            {
                Console.WriteLine("Result - Name: {0}. Value: {1}", item.Key, item.Value);
            }
         }
Target is an entity reference to the, yep, target entity, i.e. the entity against which the action/custom message is running. Stamp is the instance of the Stamp entity against which the task will be created.

Note that the RequestName is not all lower case, not sure if this is only for actions or a more generic shift in MS Dynamics CRM 2013 in general.

Frankly, I need to think what the benefit of this is/can be, because with this noddy example I am seeing none. I guess defining a type of operation can be quite handy as stuff can happen pre and post operation, e.g. register plug-ins to do this, so nothing ground breaking but perhaps simplifies things ...

Feel free to enlighten me...

Friday, 27 December 2013

Business Rules in MS Dynamics CRM 2013

I finally gave MS Dynamics CRM 2013 a whirl last night and found an interesting new feature: Business Rules.

Not sure what the exact definition is, but the idea is that these rules can be used to modify the form without the need to resorting to JavaScript. This is not only good because it means that non-developers can do it but also because it means no more JavaScript !!!!!, well maybe.

This is one of the myriad of features in MS Dynamics CRM that are always mentioned as non-developer feature, but in reality it's always the developers that work with these, but I digress.

Business rules seem to be entity wide, which is a bit of a shame as it would be handy to have business rules that apply to various entities, not entirely sure I see a reasonable business case, but, generally, the fewer limitations the better.

At any rate, I created a new Entity, added a few fields and edited the form, from where I added a Business rule.

The rule will make the Class field mandatory if the Cost field is greater than £10, for instance if this were an expense you could make a explanation/justification field become mandatory when a certain threshold was exceeded.


The conditions, as well as actions, can be chained, e.g. in the invoice example, make the explanation/justification field become mandatory if it's above a certain threshold AND it's a certain type of expense only. 


Not 100% what the description is supposed to do, as it does not appear to be displayed anywhere, probably it's just another field that will never be filled in.

An immediate downside is that in this example, you would need another business rule to set it back to not required if the field is changed to a value below £10.

Anyway, here's the result:


Another downside is the lack of OR on the rules. Is it really that complicated for non technical staff to understand the or operation? or is it complex for Microsoft to implement? I don't know but there is an or feature in Advanced Find. At any rate, the lack of or in the Check Condition Actions was really annoying on Dialogs and Workflows in 2011 and this seems to be still missing in 2013.

It's of interest to note that for numeric fields, simple formulas can be used instead of fixed values, no regex for string fields though :(, again not surprising given the audience, but it would've been nice.

Also the comparison can be made against another field in the entity.

The range of actions is interesting:
  • Show Error Message - Yahoo!!! no more javascript validation (in your dreams, sunshine)
  • Set Field Value 
  • Set Business Required
  • Set Visibility
  • Lock or Unlock Field
I guess this feature is a typical MS Dynamics CRM feature, where it seems like a great idea in principle but then in practice it's too limited or cumbersome but for the most basic of tasks. Designed for Power Users, used and hated by developers, more of the same.

All in all not a bad feature, I just need to start working on some MS Dynamics CRM 2013 projects now :).

Thursday, 26 December 2013

Add/Remove Programs Product Icon with Wix

This is a very simple change that can help your application look that little bit more professional.

Just add a Add/Remove Programs Product Icon with Wix:

<Icon Id="ProductIcon" SourceFile="Icon\myicon.ico"/>    
<Property Id="ARPPRODUCTICON" Value="ProductIcon" />

See What I mean:


You need to make sure that you store myicon.ico on a directory called Icon.

Friday, 20 December 2013

Get user group membership in Sharepoint from Powershell

A few days back I needed to find out whether the System account (SharePoint\System) was a member of a particular group and it turns out that this cannot be done from the GUI as it doesn't show up in the list of accounts that are members of that group so ... PowerShell to the rescue.

The following snippet will provide a list of users belonging to the desired group <Group Name>:
$site = Get-SPSite -WebApplication "<url>"
$mainsite = (Get-SPWeb -Site $site)[0]
$group = $mainsite.SiteGroups | ?{$_.Name -match "<Group Name>"}
foreach($user in $group.Users){$user}
As usual it needs to be run from the SharePoint PowerShell console or the Sharepoint PowerShell snap in needs to be loaded before running the above commands.