Workflow & Approvals in Salesforce.com
Showing posts with label Workflow. Show all posts
Showing posts with label Workflow. Show all posts
Tuesday, March 4, 2014
Tuesday, February 11, 2014
Salesforce Custom Label
Custom Label maybe not so popular among Salesforce administrator compare
to other feature, such as: workflow, formula field and so on. Custom
Label enable developers to create multilingual applications by
automatically presenting information in a user's native language from
Apex class or Visualforce page.
Not only for developers, Custom Label actually also available for system administrators to be used in formula field. A value from a formula field can be depend on value from custom label referred, when display in page layout, it will be displayed based on language selected in user detail. Please note if you want to set Custom Label in multi-language, you need to enable Translation Workbench. To enable Translation Workbench, click Your Name | Setup | Administration Setup | Translation Workbench | Translation Settings and add languages to be supported.
To create Custom Label, click Your Name | Setup | App Setup | Create | Custom Labels. You only can add translation language for a custom label based on languages supported in Translation Workbench.
We can find Custom Label in Salesforce Global Variable start with $Label
And this is the final formula, it is just $Label.Label_Name
Here more information about Custom Label from Salesforce.
Not only for developers, Custom Label actually also available for system administrators to be used in formula field. A value from a formula field can be depend on value from custom label referred, when display in page layout, it will be displayed based on language selected in user detail. Please note if you want to set Custom Label in multi-language, you need to enable Translation Workbench. To enable Translation Workbench, click Your Name | Setup | Administration Setup | Translation Workbench | Translation Settings and add languages to be supported.
To create Custom Label, click Your Name | Setup | App Setup | Create | Custom Labels. You only can add translation language for a custom label based on languages supported in Translation Workbench.
We can find Custom Label in Salesforce Global Variable start with $Label
And this is the final formula, it is just $Label.Label_Name
Here more information about Custom Label from Salesforce.
Tuesday, February 4, 2014
Salesforce Time-Dependent Workflow and Entry Criteria
Time-Dependent Workflow is a very nice feature out-of-the-box from
Salesforce. You can easily configure it to do action such as: create
task, send email alert, field update and send outbound message. The
actions will only trigger when a certain date or hour hit as it is
configured.
Actions for Time-Dependent Workflow is exactly the same with Immediate Workflow, and you can share the same actions between Time-Dependent Workflow with Immediate Workflow, depend on your business needs, even to combine Time-Dependent and Immediate workflow in the same workflow rule.
One thing you need to note when create Time-Dependent Workflow is the Evaluation Criteria, make sure it is set to created or created, and any time it’s edited to subsequently meet criteria only. Created, and every time it’s edited will NOT allow you to have Time-Dependent Actions.
I get a request from my user to change a running Time-Dependent Workflow from 7 days before Birthdate to 14 days before Birthdate. Here is the step:
1. Screenshot existing Time-Dependent Workflow with the actions (for backup purpose)
2. Deactivate the workflow
3. Remove all existing actions in that Time-Dependent Workflow
4. Edit Time-Dependent Workflow and you will be able to modify the day to 7 days
5. Add back all existing actions for that Time-Dependent Workflow
6. Activate the workflow back
Few items to note:
1. All existing data will be NOT trigger again for Time-Dependent workflow, because it already met the entry criteria earlier. So, if your Entry Criteria is 'Evaluate the rule when a record is created, and any time it’s edited to subsequently meet criteria', you need to make the record to 'meet' the criteria again:
2. Monitoring, you can monitor record queue to be triggered for Time-Based Workflow from Setup - Administration Setup - Monitoring - Time-Based Workflow. You can select some criteria to monitor the queue or just leave all to --None-- and hit Search button.
Actions for Time-Dependent Workflow is exactly the same with Immediate Workflow, and you can share the same actions between Time-Dependent Workflow with Immediate Workflow, depend on your business needs, even to combine Time-Dependent and Immediate workflow in the same workflow rule.
One thing you need to note when create Time-Dependent Workflow is the Evaluation Criteria, make sure it is set to created or created, and any time it’s edited to subsequently meet criteria only. Created, and every time it’s edited will NOT allow you to have Time-Dependent Actions.
I get a request from my user to change a running Time-Dependent Workflow from 7 days before Birthdate to 14 days before Birthdate. Here is the step:
1. Screenshot existing Time-Dependent Workflow with the actions (for backup purpose)
2. Deactivate the workflow
3. Remove all existing actions in that Time-Dependent Workflow
4. Edit Time-Dependent Workflow and you will be able to modify the day to 7 days
5. Add back all existing actions for that Time-Dependent Workflow
6. Activate the workflow back
Few items to note:
1. All existing data will be NOT trigger again for Time-Dependent workflow, because it already met the entry criteria earlier. So, if your Entry Criteria is 'Evaluate the rule when a record is created, and any time it’s edited to subsequently meet criteria', you need to make the record to 'meet' the criteria again:
- Update the record NOT to meet the criteria, then update it back to meet the criteria.
- Example: if we are using Rule Criteria "Birthdate NOT EQUAL TO null", we need to make it to null first (make sure to backup first), then populate the original Birthdate back, so it will meet the criteria again.
2. Monitoring, you can monitor record queue to be triggered for Time-Based Workflow from Setup - Administration Setup - Monitoring - Time-Based Workflow. You can select some criteria to monitor the queue or just leave all to --None-- and hit Search button.
Thursday, January 16, 2014
Cross-Object Workflow in Salesforce.com
With Spring '12 Release, cross-object field updates in workflow rules
and approval processes now support standard objects.
Both custom-to-standard and limited standard-to-standard relationships
are supported.
This feature only available in Enterprise and Unlimited edition.
Only Master-Detail relationship support using cross-object workflow, so cross-object will not work in Lookup relationship.
Here is a sample case for using Cross-Object workflow.
Master object: Customer__c
Child object: Order__c
Company would like to know how much and when latest order for each customer, but date use to determine is payment date, not order date, and payment date will be blank when customer have not make payment.
So, here we go:
1. Create a workflow in Order which will run on create and every time edit
Rule criteria:
NOT ISNULL( Payment_Date__c ) &&
( Payment_Date__c >= Customer__r.Payment_Date_hidden__c ||
ISNULL( Customer__r.Payment_Date_hidden__c ))
Explanation:
- if payment date is blank, stop workflow
- if payment date in order is newer than stored payment date in customer, proceed workflow OR
- if stored payment date in customer is blank
2. Create field update in Order
a. Update Payment Date in Customer
Select object = Order
Field to Update = Customer, the select field Payment Date
Formula Value = Payment_Date__c from Order
b. Update Amount in Customer
Select object = Order
Field to Update = Customer, the select field Amount
This feature only available in Enterprise and Unlimited edition.
Only Master-Detail relationship support using cross-object workflow, so cross-object will not work in Lookup relationship.
Here is a sample case for using Cross-Object workflow.
Master object: Customer__c
Child object: Order__c
Company would like to know how much and when latest order for each customer, but date use to determine is payment date, not order date, and payment date will be blank when customer have not make payment.
So, here we go:
1. Create a workflow in Order which will run on create and every time edit
Rule criteria:
NOT ISNULL( Payment_Date__c ) &&
( Payment_Date__c >= Customer__r.Payment_Date_hidden__c ||
ISNULL( Customer__r.Payment_Date_hidden__c ))
Explanation:
- if payment date is blank, stop workflow
- if payment date in order is newer than stored payment date in customer, proceed workflow OR
- if stored payment date in customer is blank
2. Create field update in Order
a. Update Payment Date in Customer
Select object = Order
Field to Update = Customer, the select field Payment Date
Formula Value = Payment_Date__c from Order
b. Update Amount in Customer
Select object = Order
Field to Update = Customer, the select field Amount
Formula Value = Amount__c from Order
If you see in above field update process, workflow in Order will update field in Customer.
For more information and standard objects supported, see this release document and find section Cross-Object Workflow.
Saturday, January 4, 2014
Can we set Salesforce.com standard field to be unique?
Salesforce.com
administrators and consultants often get business requirement to set
standard Salesforce.com fields to be unique. In some companies, we need
to make sure every mobile phone in Contacts have to be unique (if it is
not blank).
And as we known, until now, we are not able to set standard Salesforce.com field be unique, only custom field have this option.
So, any solution? Yes, there are few ways to get this done, from a simple one until a difficult one.
1. Trigger
And as we known, until now, we are not able to set standard Salesforce.com field be unique, only custom field have this option.
So, any solution? Yes, there are few ways to get this done, from a simple one until a difficult one.
1. Trigger
Using trigger
may be not a simple way, we need a developer who well understand
Salesforce Apex Trigger. Developer need to write apex code in Developer
instance or Sandbox instance, make sure the test method coverage above
75% and deploy it to production.
Developer may be like this approach, although it is not something prefer by administrator. Trigger in Contact before insert and before update, query all Contact with mobile phone enter, if query result is > 0, add error and don't allow to save or update that Contact.
2. Using new custom field
Instead of using standard Salesforce.com standard field, using the same sample as above, we can build a new Mobile Phone field with field type = Phone. And hide standard Mobile Phone field from Field-Level Security (Prefer not just hide from Page Layout).
But, if this is an enhancement, it would be more effort to extract existing data to external file, verify there is no duplicate value and import the data back to the new fields. This even become worst, if the standard field has been used in many places, such as: reports, apex code, workflow, etc.
3. Workflow + Field Update
This is prefer option with less effort. Create a new custom field and enable Unique option then hide it from page layout. Create a workflow with criteria ISNEW() || ISCHANGED(MobilePhone). Create immediate workflow action to update the new field above.
This option may be more simple, but the error message shown is not clear as it is not say what field is duplicate, but just inform it is duplicate with which record, example: "Duplicate value on record: John Wood". User do not know exactly what is duplicate between Contact working on with John Wood, if we have more than 1 field need to be set unique.
Developer may be like this approach, although it is not something prefer by administrator. Trigger in Contact before insert and before update, query all Contact with mobile phone enter, if query result is > 0, add error and don't allow to save or update that Contact.
2. Using new custom field
Instead of using standard Salesforce.com standard field, using the same sample as above, we can build a new Mobile Phone field with field type = Phone. And hide standard Mobile Phone field from Field-Level Security (Prefer not just hide from Page Layout).
But, if this is an enhancement, it would be more effort to extract existing data to external file, verify there is no duplicate value and import the data back to the new fields. This even become worst, if the standard field has been used in many places, such as: reports, apex code, workflow, etc.
3. Workflow + Field Update
This is prefer option with less effort. Create a new custom field and enable Unique option then hide it from page layout. Create a workflow with criteria ISNEW() || ISCHANGED(MobilePhone). Create immediate workflow action to update the new field above.
This option may be more simple, but the error message shown is not clear as it is not say what field is duplicate, but just inform it is duplicate with which record, example: "Duplicate value on record: John Wood". User do not know exactly what is duplicate between Contact working on with John Wood, if we have more than 1 field need to be set unique.
