How to manually create Contact record for external ID provider in Adxstudio

When configured to use an external ID provider (e.g. ADFS in our case), Adxstudio does not handle identity management functions such as creating user accounts in that external ID provider. When an external ID is authenticated and logged on to the Portal for the first time, Adxstudio automatically creates a new Contact record and associates it with the external ID.

Sometime you may want to customise this process. For example, you may want to do something like this:

  1. Create the Contact record first upon registration request
  2. Email user to confirm email address
  3. Provision user account in ADFS once user has confirmed email address (password may also be provided at this point)
  4. Link Contact record to ADFS account

Step 4 would require you to make appropriate update to the Contact record so that the Adxstudio Portal web app (the MVC app) can establish the link between the Contact record and the currently logon identity.

In order to achieve this you would need to update the following fields on the Contact record:

Field Value
Username (adx_identity_username) The ADFS account username, e.g. mydomain\user1
Login Enabled (adx_identity_logonenabled) True
Security Stamp (adx_identity_securitystamp) A GUID – seems that any GUID will do
Profile Modified On (adx_profilemodifiedon) If a value is not specified, the user will be taken to the Profile page upon login.

You also need to create an External Identity (adx_externalidentity) record and associate it with the Contact.

The fields for this record are:

Field Value
Contact (adx_contactid) The associated Contact record
Username (adx_username) The ADFS account username, e.g. mydomain\user1
Identity Provider (adx_identityprovidername) As we were using ADFS, we set this value to be the same as the value for the Authentication/WsFederation/ADFS/AuthenticationType Site Setting in CRM.

Also note that Adxstudio adds a new form for the Contact entity in CRM, namely Portal Contact. You can use this form to view and update the fields above.

Posted in Adxstudio, CRM Portal | Leave a comment

Does ‘Record status changes’ workflow trigger fire workflow on status change?

A weird post title I know..

One of the most confusing things in CRM is the State and Status (or Status Reason) of a record. These two things are very different in CRM, and it seems that the CRM UI itself often gets mixed up between the two.

When you create a new entity for example, the default label for the statecode field is Status, and for the statuscode field it is Status Reason.

When configuring a workflow, you can specify that it fires on after ‘record status changes‘:

Exactly what does this mean? Will the workflow fire when the record’s State (Active/Inactive) changes? Or will it fire when the record’s Status (‘sub-state’ within Active/Inactive) changes? Will it fire on both?

Well, as it turns out, this option will fire the workflow only when the record’s State changes. Enabling this option has the same effect as enabling the ‘record fields change‘ option and ticking the statecode field in the filter.

In fact, that’s exactly what CRM does behind the scene. Try this:

  • Tick the ‘record status changes‘ option
  • Tick the ‘record fields change‘ option. This enables the Select button to apply field filtering.
  • Now click the Select button. You will see that the statecode field is selected by default.
  • Untick the statecode field from the filter
  • You will see that the ‘record status changes‘ option is now unticked

So in conclusion…

Even though the option say ‘record status changes‘, it really means on record state (Active/Inactive) changes. Misunderstanding this option can cause workflows to fire (or not fire) unexpectedly in your system.

Posted in CRM | Leave a comment

How to get sign-in URL in Adxstudio portal web app for external ID provider

Recently I have been looking at customising the Adxstudio portal web app (the MVC app). One of the things I needed to do was to create a link that would take users to the login page for the portal. Our portal is configured to use ADFS as the external ID provider, and the link needs to take users straight to the ADFS login page.

The Adxstudio framework code has an extension method on the UrlHelper class that allows you to easily do this, namely SignInUrl(). This method accepts an optional returnUrl parameter, which is the URL that users will be redirected to once successfully authenticated.

From the C# code-behind, you can instantiate an instance of UrlHelper and invoke the extension method like so:

lnkLogin.NavigateUrl = new UrlHelper(Request.RequestContext).SignInUrl("/private/dashboard");

From the ASPX markup, you can use the Url property of the page/user-control to invoke the method:

<a href="<%: Url.SignInUrl() %>">Sign in</a>


The method uses the authentication settings configured for the website to return the correct sign-in URL for the external ID provider.

Important: This method returns the sign-in URL of the external ID provider only if that provider is configured to be used as the only provider for the website.

You can configure this using the Authentication/Registration/LoginButtonAuthenticationType Site Settings in CRM configuration. For ADFS for example, set the value of this Site Setting to be the same as the Authentication/Registration/LoginButtonAuthenticationType Site Setting.

For more information on these two Site Settings, please see and


Posted in Adxstudio, CRM Portal | Leave a comment

SPClientSideDeployment 3.3 adds option to publish on deployment

With SPClientSideDeployment 3.3 you can now have the file(s) published automatically on deployment from Visual Studio. This option is disabled by default as it would require additional calls to SharePoint during deployment.

To enable this option, go to Tools \ Options \ SPClientSideDeployment, and set the Publish on Deployment option to true.


You can download this extension from the Visual Studio Marketplace.

I hope you find this addition useful, and would love to receive feedback or suggestion.

Posted in SharePoint, SPClientSideDeployment | Leave a comment

CRMQuickDeploy 2.8 automatically adds web resources to CRM solution and allows right-click deploy from Solution Explorer

Add web resources to CRM solution on deployment

CRMQuickDeploy 2.8 now automatically adds web resources to CRM solution on deployment.

A new property has been added for project nodes in the Solution Explorer, namely CRM Solution Name:

When a web resource is deployed, it is automatically added to the CRM solution specified in this property. A warning is generated in the Output window if this property is not specified.

Right-click deploy from Solution Explorer

It is now possible to right-click multiple files and folders in the Solution Explorer and click the Deploy to CRM command from the context menu to trigger deployment for the selected items.

This command is available under the following conditions:

  • All selected items are under the WebResources folder – the command will deploy selected items as web resources.
  • A single RibbonDiff item is selected – the command will deploy the selected item as a RibbonDiff. Multiple selection of RibbonDiff items is not supported at this stage.


You can download this extension at the Visual Studio Marketplace.

I hope you find this addition useful, and would love to receive feedback or suggestion.

Posted in CRM, CRMQuickDeploy | Leave a comment

Identifying default organisation for user in CRM

This is a rehash of several posts by other people.

A user in CRM has a default organisation. This is the first organisation where the user was created. Use the SQL script below to identify the default organisation for a user:

select a.domainname, a.systemuserid, d.DatabaseName, d.uniquename 
from <Org Name>_MSCRM.dbo.systemuserbase a WITH (NOLOCK)
inner join MSCRM_CONFIG.dbo.SystemUserOrganizations b WITH (NOLOCK)
on a.SystemUserId = b.CRMUserId
inner join MSCRM_CONFIG.dbo.SystemUser c WITH (NOLOCK)
on b.UserId =
inner join MSCRM_CONFIG.dbo.Organization d WITH (NOLOCK)
on c.DefaultOrganizationId =
where a.domainname ='DomainUsername'

The script above was posted by Susan in the comment section of this post:, which describes how the underlying data hang together to determine the default organisation for a user.

When does this might come in handy?

When a user runs a report in CRM, CRM appears to check for the user against their default organisation. The report will not be rendered correctly if this organisation is disabled. I found this information at this post:

In our particular case, we found the below stack trace in the Event Viewer. My guess is that this is a MS bug that may one day be addressed. This was observed on CRM 2016 on-prem.


Exception type: CrmException

Exception message: The CRM organization you are attempting to access is currently disabled.  Please contact your system administrator

at Microsoft.Crm.BusinessEntities.SecurityLibrary.ValidateOrganizationState(IOrganizationContext context, LocatorServiceContext locatorServiceContext)

at Microsoft.Crm.BusinessEntities.SecurityLibrary.CheckDisabledStatus(IUser user, IOrganizationContext context)

at Microsoft.Crm.BusinessEntities.SecurityLibrary.ValidateUserEnabled(Guid userId, Guid organizationId)

at Microsoft.Crm.Authentication.Claims.AuthenticationProvider.Authenticate(HttpApplication application)

at Microsoft.Crm.Authentication.AuthenticationStep.Authenticate(HttpApplication application)

at Microsoft.Crm.Authentication.AuthenticationPipeline.Authenticate(HttpApplication application)

at Microsoft.Crm.Authentication.AuthenticationEngine.Execute(Object sender, EventArgs e)

at System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Posted in CRM | Leave a comment

Handling pre-save action for publishing pages in JavaScript for SharePoint

In SharePoint 2013 it is fairly well known that you can catch and handle the pre-save action in JavaScript for list item forms by implementing the PreSaveAction() method. This however does not work for publishing pages as this method is not called by SharePoint for publishing pages.

You essentially have two options for catching and handling the pre-save action for publishing pages in JavaScript:

  1. Hide the OOTB Save button and provide your own Save button
  2. Override the JavaScript function that the OOTB Save button uses

Hiding the OOTB Save button and providing your own Save button

The problem with this option is that there are multiple buttons that could trigger the save event, including:

  1. Main Save button (top left)
  2. Clicking on the drop down arrow on the main Save button above gives you these additional ones:
    1. Save
    2. Save and Keep Editing
    3. Stop Editing (clicking OK on the prompt will save the page)
  3. Main Check In button
    1. Check In button on drop down menu
  4. Main Publish button
    1. Publish button on drop down menu
    2. Submit button on drop down menu
  5. Save icon at top right

You’d need to replace all of the above buttons to ensure that you always catch the pre-save action.

If you do choose this option, then here is a good guide on implementing this:

The trick is to call the handler function of the original OOTB button, which can be done using the method SP.Ribbon.PageManager.get_instance().executeRootCommand (thanks to article above).

The other trick is working out the command ID of the OOTB button. More on this toward the end of this post.

Overriding the JavaScript function that the OOTB Save button uses

With this option you’d store the OOTB function into a variable and replace the OOTB function with your own. In your custom function, you’d execute your pre-save logic, and then invoke the OOTB function using the variable that you stored previously.

With this option there are less things to override as most of the OOTB buttons (that trigger the save event) use the same function.

The trick with this option is to locate the function that the OOTB buttons use. In case you are not already aware, JavaScript for ribbon buttons in SharePoint are defined in a thing call Page Component (or declaratively in XML – but not for the buttons we need to worry about in this scenario). Here is a good introduction to implementing Page Component:

Each Page Component has a handleCommand() function, and it is this function that performs the actual work of the ribbon button. It is this function that we need to replace.

Using the method SP.Ribbon.PageManager.get_instance().getPageComponentById() we can retrieve a Page Component by its ID. The Page Component ID that we want in this scenario is PageState.

The handleCommand() function however can be used to handle multiple ribbon buttons. Each button on the ribbon has a command ID, and this is passed to the handleCommand() function. In our custom function, we will need to check the incoming command ID and apply our pre-save logic only if the command ID is that of a button we are interested in.

The command IDs in this scenario are as follow (more on how to work out the command ID toward the end of this post):

Button Command ID
Main Save button (top left) PageStateGroupSaveSplit
Save (in drop down menu from main Save button) PageStateGroupSaveAndStop
Save and Keep Editing (in drop down menu from main Save button) PageStateGroupSave
Stop Editing (in drop down menu from main Save button – clicking OK on the prompt that appears will save the page) PageStateGroupStopEditing* (see special note below regarding this button)
Main Check In button  PageStateGroupCheckinSplit
Check In (in drop down menu from main Check In button)  PageStateGroupCheckin
Main Publish button  PageStateGroupPublishSplit
Publish (in drop down menu from main Publish button)  PageStateGroupPublish
Submit (in drop down menu from main Publish button)  PageStateGroupSubmitForApproval
Save icon at top right  PageStateGroupSaveAndStop

The JS below demonstrates how to hook in our pre-save action for each of the above buttons. One thing to note is that when invoking the OOTB handler, we need to restore the original this context back for the handler, i.e. the pageStateComponent object – and this is why the call method is used to invoke the original OOTB handler.

SP.SOD.executeOrDelayUntilScriptLoaded(function () {
	var pageManager = SP.Ribbon.PageManager.get_instance();
	var pageStateComponent = pageManager.getPageComponentById("PageState");

	var originalHandler = pageStateComponent.handleCommand;
	pageStateComponent.handleCommand = function (commandId, properties, sequence) {
		if (commandId === "PageStateGroupSaveSplit") {
			alert("Main Save button");
		} else if (commandId === "PageStateGroupSaveAndStop") {
			alert("Save button in drop down menu or Save icon at top right corner");
		} else if (commandId === "PageStateGroupSave") {
			alert("Save and Keep Editing button in drop down menu");
		} else if (commandId === "PageStateGroupStopEditing") {
			alert("Stop Editing button in drop down menu");
		} else if (commandId === "PageStateGroupCheckinSplit") {
			alert("Main Check In button");
		} else if (commandId === "PageStateGroupCheckin") {
			alert("Check In button in drop down menu");
		} else if (commandId === "PageStateGroupPublishSplit") {
			alert("Main Publish button");
		} else if (commandId === "PageStateGroupPublish") {
			alert("Publish button in drop down menu");
		} else if (commandId === "PageStateGroupSubmitForApproval") {
			alert("Submit button in drop down menu");
		}, commandId, properties, sequence);

	SP.Ribbon.PageState.ImportedNativeData.CommandHandlers["PageStateGroupSaveAndStop"] = "alert('Chose to save before continuing');" +
}, "sp.ribbon.js");

Special note for Stop Editing button

The one special case above is the Stop Editing button (on the drop down menu of the main Save button). This button presents the user with a JS confirmation box, and allows them to save the page before navigating away by clicking OK on the confirmation box. As you can see in the code above, handling the PageStateGroupStopEditing command ID only allows you to catch when the user has clicked the Stop Editing button – and not when they actually saves the page by clicking OK on the JS confirmation box.

When you click OK on the JS confirmation box, SharePoint evals a JS string that is stored in SP.Ribbon.PageState.ImportedNativeData.CommandHandlers[“PageStateGroupSaveAndStop”]. Therefore, to add a pre-save action for this particular scenario we’d need to update this JS with our custom code, such as below:

SP.Ribbon.PageState.ImportedNativeData.CommandHandlers["PageStateGroupSaveAndStop"] = "alert('Chose to save before continuing');" +

Working out the command ID of OOTB buttons

You can work out the command ID of most OOTB buttons by inspecting the HTML rendered on the page, and then cross-check with the CMDUI.xml file at SharePointRoot\TEMPLATE\GLOBAL\XML (which is the file that defines all OOTB ribbon buttons).

For example, inspect the Save button (in the drop down menu) and you can see that the aria-describedby (and also the id) attributes contain a value such as Ribbon.EditingTools.CPEditTab.EditAndCheckout.SaveEdit.Menu.SaveEdit.SaveAndStop.

Now search the CMDUI.xml file for this value and you should find a match such as below:

<Button Id="Ribbon.EditingTools.CPEditTab.EditAndCheckout.SaveEdit.Menu.SaveEdit.SaveAndStop" MenuItemId="Ribbon.EditingTools.CPEditTab.EditAndCheckout.SaveEdit.Menu.SaveEdit.SaveAndStop" Sequence="20" Alt="$Resources:core,save_15;" Command="PageStateGroupSaveAndStop" CommandValueId="PageStateGroupSaveAndStop" Image16by16="/_layouts/15/$Resources:core,Language;/images/formatmap16x16.png?rev=23" Image16by16Top="-197" Image16by16Left="-37" Image32by32="/_layouts/15/$Resources:core,Language;/images/formatmap32x32.png?rev=23" Image32by32Top="-103" Image32by32Left="-409" LabelText="$Resources:core,save_15;" ToolTipTitle="$Resources:core,save_15;" ToolTipDescription="$Resources:core,cui_STT_save;" />

The value of the Command attribute is the command ID for this button.


To attach a custom pre-save action your options include providing your custom ribbon buttons, or overriding the OOTB JS handler. Depending on the ribbon button/functionality you are targeting, one approach could be more advantageous than the other. The approach described in this post was specifically for the Save event, but should also be applicable to other events that are initiated from the ribbon.

Posted in SharePoint, SharePoint 2013 | Leave a comment