Showing posts with label accounts. Show all posts
Showing posts with label accounts. Show all posts

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, August 26, 2009

How to Bulk Edit Attributes that show up Disabled on the Bulk Edit Form

We came across this really tricky situation and we would like to thank Microsoft for having a KB article (http://support.microsoft.com/kb/949941) for this.

We wanted to bulk edit a few of the accounts using the Actions => Edit option. The form that comes up here displays all attributes available for the Account entity. You would however notice that some of them are disabled though. Since we had 2 custom picklist type of attributes, one showing up as enabled the other disabled, it was easy to identify the possible reasons for disabling this one had custom code written on its onchange event while the other did not.

But we still wanted to be able to Bulk Edit this attribute without having the need to create a custom page just for editing a custom picklist attribute. Our search lead to the following KB article that explains the steps to enable this.

To have this explained in short, the entity customization file has a property “BehaviourInBulkEditForm” for the event tags. This determines the behavior of the attribute and the code written on the event. The valid values are

Enabled -- If you use this value, the field is enabled. Additionally, the code for the event is run when the event is called.
Disabled -- If you use this value, the field is disabled.
EnabledButNoRender -- If you use this value, the field is enabled. However, the code for the event is not run when the event is called.

Exporting the customization and making the below change should enable the attribute and not have the code written on the onchange event fired

<event name="setadditionalparams" application="true" active="true" behaviorinbulkeditform="EnabledButNoRender">