Showing posts with label Workflows. Show all posts
Showing posts with label Workflows. Show all posts

Monday, January 28, 2013

Custom Workflow Activities for Microsoft Dynamics CRM Online

With Polaris it is now possible to register Custom workflow assembly for CRM Online as well. In continuation of our earlier series here where we provided the steps to use the Developer Kit, we have now added the steps to create Workflow activities for CRM Online using the new version of the developer toolkit that is available in the latest SDK and can be downloaded from http://www.microsoft.com/en-in/download/details.aspx?id=24004

To register the workflow in CRM Online follow below steps:

Open the Visual Studio; go to File → New Project → Dynamics CRM → Dynamics CRM 2011 Package and Click Ok. 





After that Connect to Dynamics CRM Server


 

On click of Ok button the package will open then add a new project to this package. Right click on solution → Add → New Project.




The below window will be pop up to select the project type. Select Dynamics CRM 2011 Workflow Library, give the project name and click Ok.




Once the project is loaded add a Class file for the workflow. To do this right click on project click “Add New Item”.

 

Select the Class type as Workflow Activity Class. This will generate the Class with the Execute method




You can implement your logic indicated by // TODO: as given in the below screen shot.



Once the logic has been implemented double click on “RegisterFile.crmregister” see below screen.



This will open the below file, here change the IsolationMode to “Sandbox”.



Build the solution and deploy. After that go to CRM and create a Workflow as per your requirement and add the Custom workflow assembly to this workflow as shown in below screen shot.



After adding the assembly activate the workflow. This will activate your workflow and you can check your workflow is running successfully.

Possible Errors during deploying the package:


1.      You may get an error “Plug-in assembly does not contain the required types or assembly content cannot be updated” this is because you may have changed the Class name or assembly name or Default Namespace and this class name or assembly or Default Namespace name has not been updated in the “RegisterFile.crmregister” file. You must update the changes in the “RegisterFile.crmregister” file.
2.      You may also get an error “Error registering plugins and/or workflows. Description name must be specified Parameter name: description”. This is because when we add a new Workflw Activity Class file in the project it will ask for the below assembly information.

 
All the above information are required, if you miss any of the above information you may get an error “Error registering plugins and/or workflows. [Parameter Name] name must be specified Parameter name: [Parameter Name]”


Tuesday, February 8, 2011

Workflows vs Dialogs

CRM 2011 introduces the new concept of Dialogs. We have discussed this in detail in our earlier blog that can be found at http://inogic.blogspot.com/2010/11/crm-2011-dialogs-explored.html"
Here we list out the differences between Processes (Workflows) and Dialogs.

Tuesday, January 4, 2011

CRM 4 to CRM 2011 Upgrade.

Recently we tried to upgrade a highly customized CRM 4 install to CRM 2011 and thought it would be worthwhile to list out our findings for the benefit for all.

CRM 2011 supports both in-place upgrade as well as a fresh CRM 2011 install with a later CRM 4.0 organization import into CRM 2011. We attempted the second way, that a fresh install of CRM 2011 and then tried to import the customized organization of CRM 4.0.

If you install the CRM 2011 beta copy and try the import you will receive the following error.

…lead.Address1 Country length 160 more than original value 100…

This appears to be a bug of the beta version that is probably rectified in the CRM 2011 RC released recently.

After a successful install, you can try to import the CRM 4.0 organization, it auto detects that it is an upgrade and would performs all the necessary operations on the database. Make sure you have another backup of the CRM 4.0 in case the upgrade fails mid-way you will need to go back and restore the original copy and start over again.

After a successful upgrade we found the following items we auto-upgraded to CRM 2011 standards by the upgrade tool.

Scripts:

All the scripts written on form save, load and Change will be automatically converted into web Resource and saved as Library with the name Entityname_main .see the display name below.
Select any Web Resource it looks as shown below.


On click of Form properties for any entity you will find that library is already added on the form and it is called on load event with function name.


The code written on the Load event would be put into a function named Form_onload. The OnSave event is changed to function named Form_onsave and Onchange becomes
Attributename_onchange.

Images:

All the Images used in the Custom entities will be saved as Web resource.

ISV buttons:

Any script written on custom button added through ISV in CRM will be converted to Application Ribbons. Buttons of CRM 4.0 are moved to Ribbons in CRM 2011 as shown below.

Plugins:

Plug-in registered in the CRM for entities will be saved as Plug –In Assemblies and Sdk Message Processing

Plug –In Assemblies shows Name ,Version, Culture Public Key Token and the date on which it was created and last modified date.

Sdk Message Processing shows Message, Event Handler, object type code ,Stage and Status

Workflow:

The Workflows would be auto-upgraded as Processes in CRM 2011 as can be seen from the screenshot below


Form Layout

The form layout is carried over as is during the upgrade from CRM 4.0 to CRM 2011. We however found a conflicts tab added to a couple of forms but were unable to trace the controls placed in this section to any of the controls in the original CRM 4 form.

There are sure to be many more items that were upgraded behind the scenes and we will update the list in times to come. However this is a pretty good reference point to start with for a CRM 4 to 2011 upgrade.

Sunday, November 29, 2009

How to Track the Next Action and Last Touch dates on Account

Quite often you need to monitor and have workflows designed based on the "Last Touch Date" or the "Next Action" date. While the former should reflect the last interaction made with the customer, the later is to keep track of the next upcoming interaction with the customer.

End users often believe the Modified date reflected on the Account form, is the "Last Touch Date". Well, that is not true. The Modified date on the Account Form is only updated when any changes are made directly to any of the attributes on the account form. Even adding of a note to the account does not update the "Modified Date". To track the true "Last Touch date", you would require to write a custom plugin or perhaps a Workflow could do the job as well.

How to track "Last Touch Date" using Workflow.

You need to trap the create/update/status change events of all the activities that you need to track for an account. Assuming that we would set the regarding to Account for each activity that we create.

1. New Worklow - Set the entity as Appointment - Event Create, Update and Status change


2. Add step to Update entity as shown as below screenshot.

3. Choose Regarding(Account) as shown as below screenshot.


4. Select custom date attribute for tracking "Last touch" set date = Workflow execution as shown in the below screenshot.

How to track "Last Touch Date"/Next Action Date using Plugins.

You need to write Plugin to trap the create/update/chnage status events of the activities. In the Post event, read the account associated with the activity and update the "Last Touch Date" with today's date.

For the next action date, in each of these events, you need to read the account associated with the activity. Using the RollupActivitiesforAccount “TargetRollupActivityPointerByAccount” you can get the next due activity and update the "Next Action Date" to this date.

Wednesday, July 29, 2009

How to use Parameters in Workflows/Plugins

CRM Plugins and Workflows provide the ability to pass external information to the plugins as well as receive information from plugin that can be used for further processing.

Plugins:


In case of Plugins, you can use the Secured Parameter and Unsecured Parameter that is available during Plugin registration to pass static information that can be used by the Plugin.
It is better to use the unsecured parameter as this is available in offline as well.


These parameters are available as parameters to the constructor of the Plugin.


public class AccountCreateHandler: IPlugin
{
public AccountCreateHandler(string unsecure, string secure)
{
// Do something with the parameter strings.
}
public void Execute(IPluginExecutionContext context)
{
// Do something here.
}
}

Workflows:

Workflows are allow for Input as well as Output Parameters. You can use the Input Parameters to pass static information to the Workflows. The Output parameter feature of Workflow is very interesting. The Output parameter defined in the Workflow Plugin, becomes available in the CRM Workflow window. You can use this output parameter in any of the Workflow steps.
It can be used in Wait/If condition block as a value to be checked for.




It can also be used in Create/Update step. Here the Output parameter becomes available only for the attributes that match the parameter data type.



If you had some complex logic to be evaluated before you decide who to assign the records to… you can create a Lookup type of Output parameter and assign the record to this.

Sunday, June 7, 2009

Call Workflow from ISV button

We had once given an option to one of our customers to perform an action using on-demand workflow. We provided them with the steps to run the workflow from the "Run Workflow..." button that is added to the entity in case and entity has on-demand workflows published against them.

The customer however wanted that we add a button with a descriptive lable that performed the job so that the users are not burdened with having to select the correct workflow from the list and it was a one-click solution.

We found that CRM has an inbuilt function made available that calls the workflow "launchOnDemandWorkflow"

The syntax of the function is
launchOnDemandWorkflow('crmGrid',ObjectTypeCode,Workflow ID) //when called from grid

launchOnDemandWorkflow('',ObjectTypeCode,Workflow ID) //when called from entity form

This function has 3 parameters.
The first one is left blank only if the button is on the record of that entity and workflow needs to be called on that record only. whereas, if the button is placed on the grid of CRM entity view then first parameter should be 'crmGrid' so that the workflow will get called for the records selected in that view.


Second parameter contains object type code of that entity

Third parameter is the id of the workflow to be fired

To get the workflow id, follow the below steps.

1. Go to Setting --> Workflow form.
2. Here open the workflow that you want to run on button click.
3. Now press "Ctrl + N" which will open the same page in the IE.
4. In the Address bar of IE you can find the id of workflow.

This should help provide users with the most familiar option of clicking a button to perform an action.

Wednesday, February 18, 2009

Design a workflow for performing repetitive tasks

Sometimes, there is a need to perform a particular task or action repetitively over a period of time. We were in a need to create a task activity after every 2 days against an account.

This can be done by creating child workflow and call it from the parent workflow. The child workflow would peform the actual job and the parent will call this child recurrsively.

Here are the steps to get this done:
  1. Create a workflow for required entity (For eg: account) with following triggers
    - On demand
    - As a child workflow
    - Record is created
  2. Set the scope of the Workflow as appropriate (For eg: organization)
  3. Now the structure of workflow will be as follows:

First is wait condition which says, wait for 2 days after the execution of this workflow. This condition is as shown below:

After this condition is fulfilled, a task is created and then again child workflow is started which is the same workflow created above (i.e. test recurring). So, the workflow runs recursively and creates a task after every 2 days.