Background: how to make certain Validation Rule only effect for Production instance, but not in sandbox instances?
Solution:
1. Deactivate the validation rule in sandbox
This is very basic and simple solution, it works, but not really nice if you have many validation rules need to deactivate in sandbox, admin need to deactivate each validation rule in all objects.
Also, when sandbox refresh, admin need to re-deactivate all validations rule again.
2. Modify the validation rule only work in Production instance
Step 1. Get your Salesforce Production Organization Id
Go to Setup - Administration Setup - Company Profile - Company Information
Look for Salesforce.com Organization ID
Step 2. Add Organization ID into validation rule
Example, your current Validation Rule error formula:
Type__c = "A" & Amount < 1000
Modify this to:
Type__c = "A" && Amount < 1000 && $Organization.Id='00D300000000SHq'
Done, but see this blog that Salesforce will automatically change the value of Organization Id in Validation Rule and Workflow formula when you use $Organization.Id formula of production instance.
Pages
Thursday, August 15, 2013
Tuesday, August 13, 2013
How to check Record Type enabled for Salesforce Profiles easily?
To check if a record type is enabled for specific profile is easy, just open the profile and scroll to "Record Type Settings" sections. You can see and edit record type for specific standard or custom object. But, hang on, how about if I have 100 profiles? It mean, you need to open all 100 profiles and check it one by one. Hmm, not a good idea.
As of now (Summer '13 Release), there is no way to check this in Salesforce easily - which profiles are enable to specific record type. Admin have to manually open each profiles, then scroll to "Record Type Settings" section to check if the record type is enable for that profile. Can you imagine manual work if you have 100 profiles?
There is an idea posted in IdeaExchange, you are welcome to vote it https://success.salesforce.com/ideaview?id=08730000000BqaiAAC
Solution:
Use Force.com IDE to identify which profiles have record type enable in specific object easier.
Here we go:
1. Open Force.com IDE (assume you have install Force.com IDE, if not Google it)
2. Add objects and profiles related into Force.com IDE
Make sure to include ALL objects you want to check into Force.com Project Contents in Force.com IDE, otherwise you will not see the record type information in the profile.
3. Open the Profile
Yes, you need to open all profiles in Force.com IDE, but of course this is faster and easier than open each profile in Salesforce. Look for <recordTypeVisibilities> tag, and you will see <visible> and <default> tags inside. Record Type with visible = true is Enabled for that profile; and for default = true is default record type when user create new record in Salesforce
Next, can we update using Force.com IDE?
Yes, you can just simply change the value from false to true; or from true to false. Once you save in Force.com IDE, it will save in Salesforce instantly.
Have fun....
As of now (Summer '13 Release), there is no way to check this in Salesforce easily - which profiles are enable to specific record type. Admin have to manually open each profiles, then scroll to "Record Type Settings" section to check if the record type is enable for that profile. Can you imagine manual work if you have 100 profiles?
There is an idea posted in IdeaExchange, you are welcome to vote it https://success.salesforce.com/ideaview?id=08730000000BqaiAAC
Solution:
Use Force.com IDE to identify which profiles have record type enable in specific object easier.
Here we go:
1. Open Force.com IDE (assume you have install Force.com IDE, if not Google it)
2. Add objects and profiles related into Force.com IDE
Make sure to include ALL objects you want to check into Force.com Project Contents in Force.com IDE, otherwise you will not see the record type information in the profile.
3. Open the Profile
Yes, you need to open all profiles in Force.com IDE, but of course this is faster and easier than open each profile in Salesforce. Look for <recordTypeVisibilities> tag, and you will see <visible> and <default> tags inside. Record Type with visible = true is Enabled for that profile; and for default = true is default record type when user create new record in Salesforce
Next, can we update using Force.com IDE?
Yes, you can just simply change the value from false to true; or from true to false. Once you save in Force.com IDE, it will save in Salesforce instantly.
Have fun....
Sunday, August 11, 2013
Mass update Chatter user Email Setting
With CollaborationGroupMember object, you can mass add users using API tools, such as: Data Loader. We discussed on how to add users to Chatter group in this blog.
By default, email setting for each user in a group will be Daily Digest, whether you create using API tool or add users manually in Salesforce.com
But, is there anyway to mass update email setting, let's to Weekly Digest, Every Post or even Turn Off?
YES, you can use the same object CollaborationGroupMember with API tool. When you insert users to a group with field: CollaborationGroupId (for Chatter Group) and MemberId (for User). There is another field NotificationFrequency in the same object, this field use to set email alert for each user in a Chatter group.
CollaborationGroupMember object is available in API version 19.0 and later. This field can only be set by the member or users with the “Modify All Data” permission. The valid values are:
• D - Daily
• W -Weekly
• N - Never
• P - On each post
Done, hope this blog help.
By default, email setting for each user in a group will be Daily Digest, whether you create using API tool or add users manually in Salesforce.com
But, is there anyway to mass update email setting, let's to Weekly Digest, Every Post or even Turn Off?
YES, you can use the same object CollaborationGroupMember with API tool. When you insert users to a group with field: CollaborationGroupId (for Chatter Group) and MemberId (for User). There is another field NotificationFrequency in the same object, this field use to set email alert for each user in a Chatter group.
CollaborationGroupMember object is available in API version 19.0 and later. This field can only be set by the member or users with the “Modify All Data” permission. The valid values are:
• D - Daily
• W -Weekly
• N - Never
• P - On each post
Done, hope this blog help.
Tuesday, August 6, 2013
Salesforce: FeedTrackedChange
In previous blog, we touch on FeedTrackedChange object, this object is use to store individual field change, with information: FieldName, OldValue, NewValue. A FeedTrackedChange is a child object of a record feed, such as AccountFeed, ContactFeed, etc. This object is available in API version 18.0 and later.
Although this object is query-able as it said in the SOAP API Developer's Guide.
But, if you look at Force.com IDE, there is no access to this object.
What does it mean? Meaning you cannot query this object directly. See this query:
SELECT FieldName, OldValue, NewValue FROM FeedTrackedChanges
Above query will throw error 'sObject type FeedTrackedChanges is not supported'.
FeedTrackedChange records for standard feeds can only be queried via the parent feed object. A standard feed is a record feed, such as AccountFeed. Sample:
SELECT Id, ParentId, (Select FieldName, OldValue, NewValue FROM FeedTrackedChanges), CreatedDate FROM AccountFeed WHERE ParentId = '0015000000o0WUd'
OR
SELECT Id, ParentId, (Select FieldName, OldValue, NewValue FROM FeedTrackedChanges), CreatedDate FROM FeedItem WHERE ParentId = '0015000000o0WUd'
Reference: FeedTrackedChange
Although this object is query-able as it said in the SOAP API Developer's Guide.
But, if you look at Force.com IDE, there is no access to this object.
What does it mean? Meaning you cannot query this object directly. See this query:
SELECT FieldName, OldValue, NewValue FROM FeedTrackedChanges
Above query will throw error 'sObject type FeedTrackedChanges is not supported'.
FeedTrackedChange records for standard feeds can only be queried via the parent feed object. A standard feed is a record feed, such as AccountFeed. Sample:
SELECT Id, ParentId, (Select FieldName, OldValue, NewValue FROM FeedTrackedChanges), CreatedDate FROM AccountFeed WHERE ParentId = '0015000000o0WUd'
OR
SELECT Id, ParentId, (Select FieldName, OldValue, NewValue FROM FeedTrackedChanges), CreatedDate FROM FeedItem WHERE ParentId = '0015000000o0WUd'
Reference: FeedTrackedChange
Monday, August 5, 2013
Salesforce: ISBLANK() or ISNULL()
To determine if an expression has a value or not, you can use ISBLANK() function in Salesforce. It will return TRUE if it does not and return FALSE if it contains a value. You can use this function in the formula field, validation rule, and workflow.
Syntax: ISBLANK(expression) -- replace the expression with the expression you want to be evaluated, sample: IF(ISBLANK(Main_Amount__c), 0, 1)
A field is not considered "empty" if it contains a character, blank space, or zero. For example, a field that contains a space inserted with the spacebar is not considered empty.
When using this function with a numeric field (currency, number, and percent field type) in a formula field, select Treat blank fields as blanks in the Blank Field Handling section. Otherwise, if you select Treat blank fields as zeroes, it will give the blank field value with zero, so none of them will be null.
Syntax: ISBLANK(expression) -- replace the expression with the expression you want to be evaluated, sample: IF(ISBLANK(Main_Amount__c), 0, 1)
A field is not considered "empty" if it contains a character, blank space, or zero. For example, a field that contains a space inserted with the spacebar is not considered empty.
When using this function with a numeric field (currency, number, and percent field type) in a formula field, select Treat blank fields as blanks in the Blank Field Handling section. Otherwise, if you select Treat blank fields as zeroes, it will give the blank field value with zero, so none of them will be null.
ISBLANK() works with the following field type: Text, Email, Text Area, Picklist (Multi-Select), Number, Currency, and Percent.
But, it does not work directly with fields type: Picklist, Long Text Area, and Rich Text Area.
For Picklist field, we can use TEXT() function before ISBLANK(), example: ISBLANK( TEXT(Ini_Picklist__c) ) or ISPICKVAL(Ini_Picklist__c, "").
For Long Text Area and Rich Text Area field, instead of using ISBLANK(), use LEN() function, for example, LEN(Ini_Long_Text_Area__c) = 0, but not for formula field.
** Long Text Area and Rich Text Area fields are not supported in the Formula field.
You also can use BLANKVALUE(expression, substitute_expression) function to determine if an expression has a value, it will return a substitute expression if it does not. If the expression has a value, returns the value of the expression.
sample: BLANKVALUE(Payment_Due_Date__c, StartDate +5)
You should use the same data type for both the expression and substitute_expression.
How about ISNULL()?
Use ISBLANK instead of ISNULL in new formulas. ISBLANK has the same functionality as ISNULL but also supports text fields. Salesforce will continue to support ISNULL, so you do not need to change any existing formulas.
The same goes for NULLVALUE(expression, substitute_expression) function, it is similar to BLANKVALUE(), with the exception:
But, it does not work directly with fields type: Picklist, Long Text Area, and Rich Text Area.
For Picklist field, we can use TEXT() function before ISBLANK(), example: ISBLANK( TEXT(Ini_Picklist__c) ) or ISPICKVAL(Ini_Picklist__c, "").
For Long Text Area and Rich Text Area field, instead of using ISBLANK(), use LEN() function, for example, LEN(Ini_Long_Text_Area__c) = 0, but not for formula field.
** Long Text Area and Rich Text Area fields are not supported in the Formula field.
sample: BLANKVALUE(Payment_Due_Date__c, StartDate +5)
You should use the same data type for both the expression and substitute_expression.
How about ISNULL()?
Use ISBLANK instead of ISNULL in new formulas. ISBLANK has the same functionality as ISNULL but also supports text fields. Salesforce will continue to support ISNULL, so you do not need to change any existing formulas.
The same goes for NULLVALUE(expression, substitute_expression) function, it is similar to BLANKVALUE(), with the exception:
- Avoid using NULLVALUE() with text fields because they are never null, even when they are blank. Instead, use the BLANKVALUE() function to determine if a text field is blank.
- Don’t use NULLVALUE() for date/time field.
Sunday, August 4, 2013
Salesforce: Enable Feed Tracking versus Set History Tracking
A few months back, I wrote a blog on Chatter feed items and the structure, that blog explains "Feed Tracking" and the data structure. When selected fields are enabled for feed tracking, any changes to those fields will be shown in the record Feed. You can find this feed at top of the page layout,
If the user change value of more than 1 field in one update, it will be captured into only one feed (no matter how many fields are changed).
You can hide the feed by clicking the "Hide Feed" link or clicking "Fewer Updates" in Show: to show only the feed created manually (The feed automatically created by Feed Tracking will not be shown).
Feed Tracking is stored in an object, ending with the suffix Feed (for a Standard object) or __Feed (for a Custom object). If you dig further, records created by feed tracking will have API Type = TrackedChange, other value:
From the above query, you can see FeedTrackedChange is linked to the FeedItem object (using the FeedItemId field) and used to store the field name and old and new values. FeedTrackedChange object starts with the prefix 0D6 and FeedItem starts with the prefix 0D5.
If the user change value of more than 1 field in one update, it will be captured into only one feed (no matter how many fields are changed).
You can hide the feed by clicking the "Hide Feed" link or clicking "Fewer Updates" in Show: to show only the feed created manually (The feed automatically created by Feed Tracking will not be shown).
Feed Tracking is stored in an object, ending with the suffix Feed (for a Standard object) or __Feed (for a Custom object). If you dig further, records created by feed tracking will have API Type = TrackedChange, other value:
- ContentPost - an uploaded file on a feed
- LinkPost - a URL posting on a feed
- PollPost - a poll posted on a feed
- TextPost - a direct text entry on a feed
- QuestionPost - a post as a question
You also can find the exact same value in the FeedItem object (with API version 23.0 or later).
SELECT Id, CreatedDate, CreatedById, CreatedBy.FirstName, CreatedBy.LastName, ParentId, Type, Parent.Name, Body,
(SELECT ID, FieldName, OldValue, NewValue FROM FeedTrackedChanges ORDER BY ID DESC)
FROM FeedItem
WHERE CreatedDate > LAST_MONTH
ORDER BY CreatedDate DESC
From the above query, you can see FeedTrackedChange is linked to the FeedItem object (using the FeedItemId field) and used to store the field name and old and new values. FeedTrackedChange object starts with the prefix 0D6 and FeedItem starts with the prefix 0D5.
While for Set History Tracking from the object level, has almost the same function as feed tracking to track field change, but is stored in a different object and for the different purposes:
1. Record end with prefix History (for a Standard object) or __History (for a Custom object).
2. Every field change will have its own record in the history object and be directly linked to the ParentId.
3. The user can easily run a History report to display values change related to the object.
Subscribe to:
Posts (Atom)









